Continue initial planning through discovery without coordinator reconstruction #1084

Outcome

Move the repeated initial Planner -> Architect -> original Planner handoff into the existing adversarial implementation workflow, so the outer coordinating chat does not reconstruct that route after planning asks for discovery.

This is a focused successor to #1064's delivery/workflow foundation and related to the broader composition in #301. Taras explicitly approved proceeding after an evidence-based first-pass distillation. It does not expand #1064, replace its current rollout, or start the other distilled improvements.

Observed failures

Two separate current tasks demonstrate the same boundary:

• Require explicit --allow-absolute permission for host directory access #1075 / PR Require opt-in for absolute host directories and preserve approved imports #1074: the initial Planner produced a substantive needs_discovery response, but two discovery attribution fields named Architect as author instead of the actual Planner. Phase.Response rejected it with metadata-8. The original normal run retained a hold with no canonical planning result or implementation manifest. The coordinator preserved the raw failure, prepared a separately validated attribution view, called the original Architect through phase.md, then prepared the return to the original Planner.
• Support standard ACP interaction with explicit weaker session guarantees #1081: the initial Planner likewise returned needs_discovery, hit metadata-8, and left no canonical result. The outer coordinator reconciled the result and arranged the next design/handoff work.

The current run.md ordinary-planning path holds when the first planning result is not complete, before implementation.json exists. Existing Phase.Next, Phase.Route, Phase.Preparation, Phase.Run and Ticket composition already supply most of the routing and validation. The missing consumer is the initial-planning/discovery continuation. An outer chat repeating those handoffs is not full normal-workflow adoption.

Required behavior

1. The normal launch owns the bounded ordinary planning/discovery path. A validated initial Planner request for discovery routes to the applicable original Architect, retains its contract/evidence, returns to the same original Planner, and proceeds to implementation only when that Planner supplies an accepted implementation handoff.
2. Attribution comes from the actual role invocation. Keep the author of a request distinct from the requested next owner so this route does not require a coordinator to relabel role-authored metadata. Preserve the original raw response and validation disposition; never rewrite a rejected attempt into a historical canonical success or weaken unrelated identity/revision/correspondence validation.
3. Reuse the same task, exact source revision, original role conversations, initialization standing, selected evidence and existing correction/repair policies. Read-only planning/discovery leave source unchanged. Completing a routing transition alone is not a source correction and does not reset or invent an allowance.
4. Retain enough existing phase/Ticket state to continue the same work after a stop or interruption, including a hold before implementation. Do not relaunch the initial Planner, repeat a completed role, allocate substitute conversations, overwrite old attempts or require the coordinator to rebuild a manifest from chat text.
5. Invalid or contradictory results, genuine unresolved product choices, unavailable authorization and uncertain effects still stop truthfully. Preserve the pending obligation and the supported next action. Discovery does not authorize scope growth, extra paid qualification, an automatic format retry or a hidden approval.
6. Use existing Markdown workflow components and retained execution/phase records first. No generic scheduler, background watcher, new process owner, parallel ledger, broad resume API or additional mandatory reviewer stage.

Exact public spelling and any necessary schema adjustment are selected in the plan against existing APIs; this issue does not preapprove a new API family.

Evidence before feedback

Use deterministic stub roles and the production workflow composition, retaining minimal sanitized fixtures for the two incidents.

• A Planner requesting discovery reaches the original Architect and then the same Planner, followed by the ordinary implementation/review path.
• A valid discovery route does not fail because the requested successor is confused with the known reporting actor. Original raw output and validation provenance remain inspectable.
• Interrupt/continue at the initial planning hold and after Architect completion. Already completed role effects are not repeated; sessions, initialization standing, counters and selected inputs remain correct.
• Blocked/decision-needed/invalid-attribution or revision-mismatch cases stop before an unauthorized successor or source effect. No automatic repair call occurs with response-correction limit zero.
• Initial complete planning, accepted-implementation launch, API-foundation routing, existing Ticket correction loops and delivery requirements keep their established behavior.

Follow the repository focused-feedback-commit procedure and exact-head independent review. CI retains the ordinary exhaustive delivery checks. A live paid provider experiment is not necessary merely to prove this control-flow repair; request separately if the actual plan demonstrates a concrete missing boundary.

Ownership and sequencing

Integration owns this focused workflow successor. Taras's newer priority is to finish the currently active #1075 and Main #1081 work, then complete actual adoption, delivery and merge of both open workflow PRs #1064 and #1058 before starting this issue. #1084 remains before the remaining #1039 diagnostics queue. Do not interrupt current work, edit another owner's source, reuse its logical task as this task, or reset its roles/counters.

Prepare a separate source branch/PR against the verified #1064 foundation. If #1064 is still unmerged, keep the successor separate and reconcile the stack/base explicitly; do not silently modify or claim delivery of #1064. The existing theory/interview/scope-control follow-up remains separately deferred until verified #1064 merge. Ordinary role allocation, correction limits, independent review and merge authority remain in force; consumed grants from other tasks do not transfer.

Distillation boundary

First-pass local case catalog: /private/tmp/xmd-workflow-distillation-20261103/cases.json; evidence hashes: adjacent evidence-index.json. These reference the existing ten-ticket audit and 15 saved evidence files. They are a selected evidence set, not an exhaustive re-audit or a cost measurement.

Only the initial-planning/discovery and attribution cases are selected for this issue. Checkout selection, sandbox permission handoff, joined status and scope-interview changes remain separate candidates. The already-merged Claude executable/model-selection repair stays a regression reference rather than work to repeat.