Audit workflow prompts and move orchestration rules out of agent briefs #1199

Goal

Audit the actual prompts produced by the adversarial implementation workflow and propose a smaller task-specific brief. The workflow should impose orchestration structure; agents should receive the information needed to perform their work and discover relevant details through documentation.

The user explicitly permits doing this audit directly, without the implementation workflow, and requires an independent Astra reviewer.

Observed evidence

The first Opus prompt for #1165 contains95,598 characters, excluding provider system/tool definitions and later reads:
-28,010 instructions/workflow rules.
-53,148 embedded recorded inputs.
-3,036 prepared assignment.
-11,404 response instructions/result schema.

Embedded inputs contain an accepted contract8,438chars, issue snapshot8,160, consumer assessment4,481, Implementor guide11,153, and implementation plan19,787, plus JSON formatting/escaping. The Implementor guide is also injected as role instructions. The issue snapshot retains an obsolete design-only scheduling note; the role guide retains whole-document reading language despite the user's scoped-reading instruction.

Frozen inspection copies and exact prompt:
/Users/tarasmankovski/Documents/Codex/2026-11-04/new-realtime-voice-chat/1165-prompt-inspection/
Start with README.md, metrics.json and full-initial-prompt.txt.

Original evidence, read-only:
/private/tmp/xmd-decision-resolution-1165-20261108/
Prompt owner: runtime/examples/adversarial-implementation/components/Phase/Instructions.md.
Role guide: source/.agents/implementor.md.
Do not mutate or interrupt the active #1165 run.

Audit method

Use the assembled prompt as the unit. For each meaningful block/instruction, record purpose, actual owner, source/assembly location, enforcement evidence and disposition.

Classify as:

1. Enforced by the workflow already: remove redundant agent protocol where safe.
2. Workflow responsibility currently prompt-only/partial: identify the smallest missing executable enforcement.
3. Agent judgment or task-specific information: retain in one authoritative brief/contract.
4. Discoverable reference: supply an entry point instead of embedding it.
5. Duplicate, stale or obsolete: propose removal or correction.

Trace actual runtime checks/tests rather than assuming a rule is enforced. Include provider/model allocation, identity, routing, budgets, reservations, publication, evidence validity, known result metadata, handoff selection and response schema. Distinguish semantic facts the agent must report from metadata the workflow can supply. Tool/permission restrictions must not be declared enforced solely because prompt text prohibits an action.

Retain unique behavioral requirements and necessary task context. Do not simply delete constraints to hit a character target or move the same long handbook to a different prompt.

Deliverables and review

• One temporary audit matrix with concrete source evidence and prioritized findings.
• One readable proposed replacement implementation brief, showing supplied information versus discoverable references.
• A before/after payload breakdown with exact counting boundaries; do not infer tokens, billing savings or faster reasoning from characters alone.
• A bounded change plan separating harmless duplication removal from missing workflow enforcement and product/interface decisions.
• An independent Astra review of the actual matrix and replacement brief, checking ownership, lost requirements, unsafe assumptions and whether orchestration has truly left the agent's job.

Start with #1165's initial prompt; inspect a retained correction/another role only where needed to test a concrete generalization. Use existing histories and deterministic checks; no additional paid implementation experiments or broad spec reading.

Boundaries

Audit/design/review are authorized now; production workflow refactoring, merge and broad rollout are not implied. A separate follow-up can implement the accepted changes. Do not turn the audit ledger into another permanent rulebook or build a generic policy framework.

This work is separate from #1165 implementation, #1160→#1162 cost delivery and REPL journal fixes. No queue transfer, native-session reuse, budget reset or live prompt rewriting. The user's scoped-reading policy applies to the auditor and Astra reviewer alike.

Accepted pilot follow-up: revise the staged guide and repair review-summary delivery

The user authorized implementing the following changes, then running a fresh pair of pilots only after all changes are ready. This supersedes the earlier audit-only implementation boundary for this focused follow-up. It does not authorize merging or wider rollout of #1203 before the new pilot decision.

Completed pilot/debrief summary

Both original agents read the full frozen submission guide during initial gathering: Codex about six seconds after the request; Opus about 4.7 seconds. This provides no demonstrated deferred-reading benefit and establishes no token, cost or efficiency conclusion.

Codex's same-session debrief says it gathered named instructions as routine preparation. Ownership/cleanup rules, verification sequence, evidence reuse and artifact restrictions were needed before work. Exact JSON schema, field limits and successor routing were mainly needed before submission. Its explanation of habit and practicality is retrospective self-report.

Opus's same-session debrief says evidence identity, tested revision versus candidate, first-failure preservation, artifact receipts and the same-call completion rule were needed before work. The schema and field limits could wait. During long checks it ended the original call with progress prose and a wakeup instead of the required JSON. Later explicit instructions to join owned processes and finish the result in the same call helped.

Provenance of the background/wakeup affordances: in the retained native Opus transcript, Claude's Bash tool returned “You will be notified when it completes” after background launches (for example lines 613 and 918). Opus invoked the available ScheduleWakeup tool at line 928, then ended with progress rather than the required result. These were native Claude tool interactions; no matching ScheduleWakeup/background-notification text was found in the inspected workflow/role-guide files. The precise origin of any broader system-level encouragement is not established. Opus's causal explanation remains self-report, not proof.

Local evidence:

• Codex: /private/tmp/xmd-adapter-repairs-01a1be06/pilot-1203-retrospective-raw.txt and pilot-1203-retrospective-receipt.json.
• Opus: /private/tmp/xmd-repl-fit-1216-20261109/post-shipment-debrief/reply.txt and receipt.json.
• Opus native transcript: /Users/tarasmankovski/.claude/projects/-private-tmp-xmd-repl-fit-1216-20261109-source/8e883b32-0692-4833-b792-bd29c73a1daa.jsonl.
  These are local evidence paths, not portable public attachments. Preserve evidence identity and distinguish verified trace facts from retrospective rationale.

Requested revision

1. Separate a short upfront work contract from submission-only guidance. Keep evidence/ownership requirements, completion lifetime and the requirement to finish owned processes before returning where the agent sees them before work. Keep the exact schema, field limits and result routing in the frozen submission guide. Explicitly permit deferring that submission-only material until preparing a result, including an early blocker.
2. Align phase-role background/wakeup behavior with the same-call result contract. Establish the actual launch/tool configuration owner before changing it. Use the smallest supported role-specific solution; no global restriction on interactive Sidekick use and no new orchestration framework. Test the supported long-check path and ensure an incomplete progress message is not mistaken for a completed implementation.
3. Close the independent-review summary overflow gap exposed by Fix REPL startup refusal when wrapped source exceeds its measured row width #1216: Fable's substantive review had a 1,541-character summary against the 1,500-character limit. Ticket.Prepare's handoff-input reduction was not invoked by the independent-review return path. Connect bounded response repair/compaction to that path using existing mechanisms where possible. Preserve the original response, findings, verdict, evidence and correction accounting. Do not silently truncate findings, rerun the substantive review, increase limits or reset budgets. Distinguish formatting correction from provider-failure fallback; exhausted repair must remain explicit.
4. Add focused regression coverage for this separation, a long-running role's completion contract, and an oversized independent-review summary that is repaired and delivered without repeating the completed work. Update Stage workflow reporting and bound same-session completion #1203's description around final behavior and fresh evidence, not stale pending pilot notes.

Delegation and next pair of pilots

The existing #1199/#1203 owner coordinates this focused revision and independent Astra review, using current repository authoring/model rules. Rebase safely onto current main and preserve unrelated work and completed pilot histories.

After all accepted changes pass focused checks and review, freeze the exact combined revision and run one fresh Codex Implementor pilot and one fresh Opus Implementor pilot on two suitable small, real queued fixes. Select and name the tickets before dispatch; do not replay completed work or reset ongoing runs to manufacture a pilot. Include independent review in both paths. Record actual workflow/source pins, provider/model/effort and native identity, initial prompt/guide sizes, guide-read timing, first-result validity, corrections/additional calls, overflow handling and manual interventions. Use deterministic regression coverage for overflow if it does not naturally occur; do not fabricate a live failure.

The Orchestrator owns the cross-pilot comparison and recommendation. Return both original agents' single post-task debriefs once their useful work is complete. These two runs are observations on different tasks, not a controlled efficiency benchmark. Keep #1203 unmerged pending the user's decision on the updated evidence.

Supported controls for workflow-role background behavior

The user specifically asked to disable the background/wakeup affordances. Prefer enforced launch configuration over another prompt prohibition:

• Set CLAUDE_CODE_DISABLE_BACKGROUND_TASKS=1 for Claude workflow-role processes. Official documentation says this removes run_in_background from shell/subagent tools and disables auto-backgrounding. It does not disable MCP tasks or Monitor by itself.
• Remove ScheduleWakeup from those roles' available tools through the supported deny/allow-list mechanism (CLI --disallowedTools ScheduleWakeup or the equivalent supported adapter/SDK option). The installed CLI documents this option; prove the actual ACP launch honors it.
• Keep these controls local to workflow-role execution; preserve ordinary interactive Sidekick defaults. Do not patch the vendor SDK merely to hide a tool if supported launch options work.
• Verify actual exposed tool schemas and behavior through the repository's carried adapter, including the long-running command timeout path. Foreground timeout must produce an honest failure/blocker rather than an implied future wakeup or false completion.
• Sources: https://code.claude.com/docs/en/env-vars#variables and https://code.claude.com/docs/en/cli-reference .

Selected unattended pilot pair

The maintainer approved #1178 (fresh Codex Implementor: compact syntax discovery and named structural references) and #1183 (fresh Opus Implementor: follow-up queue admission during live automatic feedback). The prior #1207/#1210 selection was withdrawn before dispatch; those remain backlog. Both replacements are reserved with bounded acceptance and unattended execution authority in their issue bodies. Dispatch after all accepted workflow changes pass review/checks, using one frozen revision. Carry through reviewed PRs and CI and collect one original-agent debrief per task; merging the pilot PRs or #1203 remains for the user's decision.