[vjovanov]

Closes #586

Two commands rhei prints on success now name the target they were typed with, as a help does. rhei release's undo used to have no target, so it failed when pasted from anywhere but inside the project. The command rhei next hands a manual supervisor used to name the whole project the typed member widened to, as an absolute path.

Before and after

From the directory above a project, using the fixture from #586:

$ rhei release project/auth.rhei.md --task auth.2
Released Task auth.2 (was assigned to someone)

Before, the note's undo had no target, and pasted from the same directory it failed:

  note: still in 'working'. ... reclaim it explicitly with `rhei next project/auth.rhei.md --task auth.2`, or move it back with `rhei transition --task auth.2 --from working --to todo`.

$ rhei transition --task auth.2 --from working --to todo
  × no Rhei plan found at or above /tmp/.../work. Target resolution
  │ only walks up, but there is a project below it:

Now both commands in the note name the plan, and the undo runs as printed:

  note: still in 'working'. ... reclaim it explicitly with `rhei next project/auth.rhei.md --task auth.2`, or move it back with `rhei transition project/auth.rhei.md --task auth.2 --from working --to todo`.

$ rhei transition project/auth.rhei.md --task auth.2 --from working --to todo
Task auth.2 transitioned: 'working' → 'todo'

For a manual supervisor, rhei next project/auth.rhei.md --task auth.1 used to hand over rhei transition /tmp/.../work/project --task auth.1 --from supervising --to supervising --release-subtree. It now hands over rhei transition project/auth.rhei.md --task auth.1 ... --release-subtree.

What changed

• The release note. rhei release builds both commands in the note, the rhei next reclaim and the rhei transition ... --to <initial> undo, with help_command_with_or. Each one names the target as it was typed: a member as typed, a project as typed, and with no target the same discovered word the rhei next half already printed. Each also carries a --state-machine if one was typed. Before, the rhei next half had the target but dropped a typed machine, and the undo had neither (crates/rhei-cli/src/cli/release_command.rs).
• The manual supervisor's handoff. The self-loop rhei transition that rhei next hands a manual supervisor gets its target from help_target_word_or(input), not shell_quote(input.display()). By that point input is the absolute project the typed member widened to. The machine argument it already carried is unchanged (crates/rhei-cli/src/cli/manual_supervision_release.rs).
• The manual-release refusal. When manual_release_preflight refuses a release that would drop unread checkpoints, its message used to print rhei retry <id> and rhei transition <id> ... --release-subtree with no target, while its help printed the full commands. Now each command is built once and used in both the message and the help.

The spec now says both lines follow the target rule a help follows (§FS-rhei-errors.1.2.1). That settles the question the issue left open: does a rule written for helps also cover a success note? No point changes meaning.

• §FS-rhei-release.3.1 gains a paragraph: the note offers rhei next and rhei transition as commands to paste, both name the target and machine rhei release was given, and neither is printed without a target, so each runs from the directory rhei release was typed in.
• §FS-rhei-supervision.3.4 gains a sentence: the handoff's plan path is the target rhei next was given, a typed member printed as typed rather than the project it widens to.

Verification

• tests/e2e/help_target_success_line_tests.rs is new and covers each line for a typed member, a typed project, an omitted target and a typed machine. Six of its tests were committed red (#[ignore = "red until #586 ..."]) before the fix and pass after it. The other two, a typed project and an omitted target for the supervisor's handoff, already held and stay as guards.
• New unit test manual_release_refusal_message_names_the_typed_target.
• Three older assertions pinned the targetless text, which is the defect itself, and now follow the contract:
  • integration release_explains_a_ticket_left_past_the_initial_state (tests/integration/integration_markdown_plans/release.rs) now expects rhei transition <plan> --task plan.1 --from in-progress --to pending --state-machine <machine>;
  • unit engine_release_with_pending_checkpoints_keeps_existing_semantics (tests_retry_supervision.rs) now expects rhei retry <plan> --task plan.1;
  • e2e tests/e2e/supervision_manual_release_guard_tests.rs now expects rhei retry and --task plan.1.
• The reproducer from the issue, extended to the omitted-target and typed-project cases, exits 0 on 3c7c00755d (DEFECT GONE: both lines name project/auth.rhei.md).
• pre-commit run --all-files passes on 3c7c00755d, with grund at CI's pinned 0.18.0. Earlier in the run, cargo fmt --check, cargo clippy -D warnings, cargo build --workspace --all-targets and fissile check --staged also passed.

Found and not fixed

Review round 1 approved the change with no blocker or major findings. These were left as they are on purpose:

• R1-01 (minor). §FS-rhei-transition-cmd.2 still writes the refusal's commands as rhei retry <ID> and rhei transition <ID> ... --release-subtree. This is read as shorthand, and both forms are valid.
• R1-02 (nit). The looser needles in supervision_manual_release_guard_tests.rs would also match the old text. The unit test above is what pins the message's target.
• R1-03 (nit). A unit test asserts the <plan> placeholder spelling, which exists only in tests.
• Other sites of the same shape, deferred to a follow-up. Each one's text is fixed word for word by its own spec point, so changing it would widen this fix: visit_halt_recovery.rs's rhei retry {task} halt line (§FS-rhei-retry.3), the run-report rows in ready_halt_causes.rs (§FS-rhei-run-report), and rhei remove {pending} in rhei-core's root_access_removal.rs / remove_command.rs (§FS-rhei-remove.6.2).

AI workflow: `rhei`, 9 agent invocations across 1 model; 6 tasks completed, 10 in progress.

1. github-issues-agent-grounds-rhei-586-implement-3041c2c5.ticket supervising (visit 1) — cld, anthropic/claude-opus-5-5 — 59.0s — 462.9k in / 4.1k out
2. github-issues-agent-grounds-rhei-586-implement-3041c2c5.ticket supervising (visit 2) — cld, anthropic/claude-opus-5-5 — 1m08s — 525.8k in / 5.7k out
3. github-issues-agent-grounds-rhei-586-implement-3041c2c5.ticket.specify specify — cld, anthropic/claude-opus-5-5 — 14m57s — 2.7M in / 25.4k out
4. github-issues-agent-grounds-rhei-586-implement-3041c2c5.ticket supervising (visit 3) — cld, anthropic/claude-opus-5-5 — 41.0s — 224.5k in / 3.8k out
5. github-issues-agent-grounds-rhei-586-implement-3041c2c5.ticket.implement implement — cld, anthropic/claude-opus-5-5 — 9m45s — 2.0M in / 13.6k out
6. github-issues-agent-grounds-rhei-586-implement-3041c2c5.ticket supervising (visit 4) — cld, anthropic/claude-opus-5-5 — 34.0s — 232.5k in / 3.1k out
7. github-issues-agent-grounds-rhei-586-implement-3041c2c5.ticket.review-1 review — cld, anthropic/claude-opus-5-5 — 2m39s — 1.4M in / 9.2k out
8. github-issues-agent-grounds-rhei-586-implement-3041c2c5.ticket supervising (visit 5) — cld, anthropic/claude-opus-5-5 — 36.0s — 317.6k in / 2.3k out
9. github-issues-agent-grounds-rhei-586-implement-3041c2c5.ticket supervising (visit 6) — cld, anthropic/claude-opus-5-5 — 24.0s — 241.4k in / 2.1k out

Accounting	Value
cost	$6.28
total tokens	8.2M
input tokens (incl. cache)	8.2M
input cache read	7.5M
input cache write	678.4k
output tokens (incl. cache)	69.4k
output cache read	-
output cache write	-
coverage	Complete