feat: planner selection, per-deliverable integrate, worker-launch skills

[smota]

Implements #54, #55 and #58.
Closes #54
Closes #55
Closes #58

One commit per issue.

What changes

• [feature] planner: select the planner harness or tier explicitly instead of requiring model_tier top #54 [planner] selection (6f5cb52). [planner] harness = "<name>" plans with that selected harness whatever its model_tier. It is still probed, dispatch-checked and quota-gated. [planner] tier = "Tier1|Tier2|Tier3" changes the routing tier. The default stays Tier3, and invalid or conflicting values are rejected on load.
  • plan --json reports data.planner (harness, model_ref, real model_tier, selected_by).
  • NoCandidate names the override key.
  • doctor --json reports data.planner.eligible and warns when nothing can plan.
• [feature] integrate: land a subset of nodes per deliverable for one-PR-per-issue delivery #55 per-deliverable integrate (228c7b6). TaskNode gains an optional deliverable tag, which uses the same character set as graph_id and is listed in the planner contract.
  • integrate --graph <id> --deliverable <tag> --into <ref> without --accept-integrate builds <graph>/integrate-<tag> from run_base for review. With the flag, it lands that worktree, using the existing dirty-check and fast-forward-or---no-ff rules.
  • Attempts start from the shared integrate head, so each attempt branch also carries earlier nodes' commits. Only each node's own <attempt base>..<attempt branch> commits are replayed: the tagged nodes plus their transitive dependencies, in topological order. Dependencies with another tag are reported as outside_dependencies. This design was accepted on [feature] integrate: land a subset of nodes per deliverable for one-PR-per-issue delivery #55.
  • An unknown tag, an unaccepted node and a replay conflict each produce a named error.
  • status, inspect and the plan output show each node's deliverable.
  • Documented in r1-closed-loop-design.md, docs/engineering/agent-workflow.md and docs/start.md.
• [docs] skills: worker launch needs user action or an explicit permission rule; paste-safe commands #58 skills (5d637ab): meshloop-plan, meshloop-run, meshloop-review-plan and their session-bundle copies.
  • plan, run, resume and review-plan --adjust start unattended agents. If a permission check refuses one, that is correct: the user runs the command or adds a permission rule, and the agent must not route around it.
  • Example commands are one line, in PowerShell and POSIX forms, with no <...> placeholders.
  • Corrects the claim that doctor detects the origin session: it only echoes --origin-* / MESHLOOP_ORIGIN_*.
  • docs/start.md gains "Supervising from an Agent Session".

Provenance

Implemented directly by Claude Code (Opus 5.5) in one session, at @smota's direction. Meshloop wasn't used for this delivery. There was no independent review: @smota authorized merging without one.

Checks

• cargo run --locked -p xtask -- check (fmt, clippy -D warnings, all workspace tests, embedded skill pack match) passes on 5d637ab. Windows 11.
• New tests:
  • [planner] config parsing and rejection.
  • plan with only a mid-tier harness: the error names the override, and with [planner] harness set it succeeds and reports MidTier.
  • doctor planner eligibility across three configs.
  • End-to-end over a 4-node, 3-deliverable fixture graph: each deliverable replays only its own and its dependencies' commits, even though node 3's attempt base already contained another deliverable's node 4. Also covers an unknown tag and landing on a branch.
  • An illegal tag is rejected at plan review.
• Not run: a live plan with [planner] harness against a real harness (fixture harness only).
• Not covered: the replay-conflict path. The fixture harness can't easily produce a conflict, so the DeliverableConflict message is untested.

Limitations

• The meshloop-accept, meshloop-status and meshloop-orchestrate skills still contain <...> placeholders. They're outside [docs] skills: worker launch needs user action or an explicit permission rule; paste-safe commands #58's scope, and their commands don't start workers.

🤖 Generated with Claude Code