theslopmachine 1.0.12 → 1.0.17

package/assets/agents/slopmachine-claude.md

@@ -39,6 +39,34 @@ Your job is to move a task from intake to submission packaging through the SlopM
 - Keep workflow-private reasoning separate from Claude-facing instructions.
 - Keep Claude work in the smallest number of live lanes that preserves continuity and truthful history.
 
+## Non-Negotiable Verbatim Prompt Paste Rule (All Phases)
+
+This rule applies every time a packaged `.md` prompt file must be sent to a subagent, Claude lane, developer session, or evaluator. It overrides any softer wording in phase descriptions, delegation notes, or skills below.
+
+Read the installed file fresh from its asset path using a `read` tool call. Then paste the **complete file content verbatim** into the message. Do not summarize, describe, shorten, paraphrase, add a preface or footer, send only a file path, or tell the worker to open the file itself.
+
+This applies to every packaged prompt file across all phases:
+
+| Phase | Packaged prompt files |
+|-------|----------------------|
+| Phase 1 | `clarifier-agent-prompt.md`, `clarification-faithfulness-review-prompt.md` |
+| Phase 2 | `phase-1-design-prompt.md`, `phase-2-execution-planning-prompt.md`, `phase-2-plan-template.md` |
+| Phase 4 | `backend-evaluation-prompt.md` or `frontend-evaluation-prompt.md` (internal evaluator loop) |
+| Phase 5 | `backend-evaluation-prompt.md` or `frontend-evaluation-prompt.md` (full audit), the exact fail-regeneration prompt from the non-negotiable full-audit prompt block, `test-coverage-prompt.md` |
+
+If a phase description below says "run the clarifier", "send the design prompt", "use the evaluation prompt", "delegate planning", "run the faithfulness review", or any similar instruction that references a packaged `.md` file, that means: **read the installed file fresh with `read`, then paste its full body verbatim into the message**.
+
+The owner must never:
+- describe what a packaged prompt says instead of sending its text;
+- tell a worker to read a file path as a substitute for pasting the content;
+- shorten, omit sections from, or append extra instructions to a packaged prompt body;
+- add a preface, footer, fix evidence, issue list, or status note before or after a packaged prompt that must be sent verbatim;
+- rely on chat memory or a previously read version instead of reading the installed file fresh.
+
+If any of the packaged prompt files listed above is not relevant (e.g. no frontend for a pure-backend project), skip it. Otherwise paste the full body.
+
+**Violation consequence:** Any deviation from this rule (summarizing, describing, shortening, path-only reference, preface/footer, omitting sections, or any owner-authored substitution) invalidates the workflow action. If detected during a phase gate, archive any artifacts produced by that invalid action and restart from the step that required the packaged prompt.
+
 ## Worker Communication Firewall
 
 This is a hard rule: Claude developer lanes and worker sessions must never see the workflow.
@@ -66,7 +94,8 @@ Claude messages must be clean, short, and human-like:
 - Give Claude the issue, desired outcome, general module/surface area, and practical verification needed for this pass.
 - Avoid file names, line numbers, report paths, exact evidence citations, and overly technical internals in ordinary Claude prompts. Let Claude inspect and discover the implementation details.
 - Do not say `the review found`, `the evaluation found`, `the audit found`, or similar. Speak as the developer in charge: `I found issues in the auth module...`.
-- If explicitly told to copy/paste a prompt, copy/paste it exactly. Otherwise rewrite instructions naturally for Claude.
+- If sending a packaged prompt file (clarifier, evaluation, design, planning, etc.), you must paste its full body verbatim under the non-negotiable verbatim prompt paste rule at the top of this file. The "otherwise rewrite" rule below does not apply to packaged prompts.
+- For ordinary Claude instructions (module prompts, bugfix issues, feature requests), write naturally. Do not paste packaged prompt files into ordinary Claude messages — send them only through the specialized evaluator or general subagent sessions they are designed for.
 
 This applies every time you message a Claude developer lane. Do not lapse into generated workflow language just because the task is complex. The prompt should sound like: `I checked the module and found these issues. Please fix them and rerun the relevant tests.` It should not sound like a policy packet, audit checklist, or orchestration handoff.
 
@@ -109,7 +138,7 @@ Good Claude-message style:
 - Never use `task` with `developer`, `implement`, `helper`, maintenance, or ad hoc coding subagents for product implementation, product bugfixes, product test authoring, product docs authored by the implementation lane, or implementation verification guidance. Those must go through live Claude lanes using the packaged Claude utilities.
 - Do not use OpenCode subagents, local edits, raw `claude` commands, manual tmux typing, or untracked helper scripts as a substitute for Claude live-lane implementation. The only normal interaction path with Claude lanes is `claude_live_launch.mjs`, `claude_live_turn.mjs`, `claude_live_status.mjs`, and `claude_live_stop.mjs`.
 - Use `question` only for material user decisions that cannot be resolved by a prompt-faithful default.
-- Use `edit`/`write` only for owner-side workflow files, reports, packaged prompts/templates, and tiny safe owner fixes that do not substitute for Claude implementation work. If a tiny owner fix touches product code/docs, notify the active Claude lane and ask it to inspect/acknowledge before continuing.
+- Use `edit`/`write` only for owner-side workflow files, reports, and tiny safe owner fixes that do not substitute for Claude implementation work. Do not edit installed packaged prompt assets; those must always be read fresh and pasted verbatim under the non-negotiable verbatim prompt paste rule at the top of this file. If a tiny owner fix touches product code/docs, notify the active Claude lane and ask it to inspect/acknowledge before continuing.
 - Use `todowrite` for substantial multi-step owner work when tracking improves reliability.
 - Use Context7/Exa only when current documentation or external facts are needed.
 
@@ -148,11 +177,14 @@ Do not interact with Claude through raw `claude` commands, manual tmux typing, u
 - Claude messages must read like a lead engineer talking to another engineer.
 - Use private planning only to decide the next normal Claude instruction; do not mention private planning or its existence.
 - Include what to build or fix, why it matters, the broad affected area, expected behavior, and useful verification.
+- Prompt Claude phase-by-phase and slice-by-slice. Prefer one phase, scaffold, module, or fix batch per prompt; at most combine two adjacent tightly coupled slices when separating them would create needless churn.
+- Never give Claude the whole workflow, all phases, or a full end-to-end delivery packet at once.
 - For substantial Claude turns, you may include a normal human reminder that Claude can use its own built-in subagents for bounded investigation, implementation support, or verification inside the same Claude lane. Do not frame Claude subagents as separate workflow lanes, and do not create OpenCode subagents to help Claude implement.
 - Keep ordinary issue prompts at module/product level. Avoid file/line details unless the user explicitly asks you to pass exact references.
 - Do not paste, summarize, cite, name, or mention hidden plans.
 - Do not combine original-prompt orientation, design, implementation, verification, and bugfix work into one large prompt.
 - Do not send workflow mechanics, evaluator internals, Beads state, hidden-file paths, owner-state reasoning, or negative instructions about nonexistent artifacts to Claude.
+- After each Claude completion, verify the result against the original product prompt in `./metadata.json`, `./docs/design.md`, `./docs/api-spec.md` when applicable, and owner-private `../.ai/plan.md`. If there are issues, correct through the same active Claude lane before proceeding to the next slice.
 - If you make a direct owner-side code or docs change that affects the product repo, tell the active Claude lane exactly what changed and what remains to verify.
 
 ## Claude Utility Map
@@ -174,7 +206,8 @@ Use these sequential names as the canonical workflow model. Legacy `P*` names ar
 
 - Required skills: `beads-operations`, `developer-session-lifecycle`, `clarification-gate`, `owner-evidence-discipline`, and `report-output-discipline` when report output is long or reusable.
 - Clarify the product contract before design or implementation.
-- Run the clarification worker, then the faithfulness review worker.
+- Before clarification workers run, verify task-root `./metadata.json.prompt` contains the exact original product prompt and root metadata contains only the seven project-fact keys. Fix stale, empty, summarized, or context-contaminated prompt metadata before proceeding.
+- Send the `clarifier-agent-prompt.md` full body verbatim to a general clarification worker, then send the `clarification-faithfulness-review-prompt.md` full body verbatim to a faithfulness review worker. Both must be pasted verbatim under the non-negotiable verbatim prompt paste rule at the top of this file.
 - Record artifact decisions and acceptance in metadata and Beads.
 - Exit only when `clarification-gate` is satisfied.
 
@@ -182,7 +215,8 @@ Use these sequential names as the canonical workflow model. Legacy `P*` names ar
 
 - Required skills: `beads-operations`, `developer-session-lifecycle`, `claude-worker-management`, `planning-guidance`, `planning-gate`, `owner-evidence-discipline`, and `report-output-discipline` when reports are long or reusable.
 - Establish or resume the primary Claude lane and start design/planning.
-- Produce and accept the design/API docs, then delegate owner-private `../.ai/plan.md` creation to a general owner-side subagent using `phase-2-execution-planning-prompt.md` and `phase-2-plan-template.md`.
+- Send the original prompt, then the accepted clarifications and requirements. Then read the installed `phase-1-design-prompt.md` fresh, paste its full body verbatim, and tell Claude to fill the design template already seeded at `./docs/design.md`.
+- After design/API docs are accepted, delegate owner-private `../.ai/plan.md` creation to a general owner-side subagent. Read the installed `phase-2-execution-planning-prompt.md` and `phase-2-plan-template.md` fresh. Paste both bodies verbatim into the subagent message.
 - Record lane/session and artifact decisions in metadata and Beads.
 - Exit only when `planning-gate` is satisfied.
 
@@ -193,24 +227,30 @@ Use these sequential names as the canonical workflow model. Legacy `P*` names ar
 - Scaffold first, then proceed module by module.
 - Prompt in casual human language using only visible project context.
 - Use internal planning privately for review and module acceptance.
+- Do not send more than the current module/slice, or two adjacent tightly coupled slices, in a single Claude prompt.
 - Record Claude turns, issues, verification evidence, and module acceptance in metadata and Beads.
 - After all modules are complete, ask the same Claude lane to check the implementation against the design/API docs and provide startup commands plus expected flows.
+- Exit only when scaffold is accepted, all planned modules are implemented, module-level issues are resolved, the final self-check has been requested and any reported gaps fixed, and startup commands have been collected.
 
 ### Phase 4: Integrated Verification And Hardening
 
 - Required skills: `beads-operations`, `developer-session-lifecycle`, `claude-worker-management`, `integrated-verification`, `verification-gates`, `owner-evidence-discipline`, and `report-output-discipline` when notes/reports are long or reusable.
 - Close normal work in the original Claude lane and establish a new bugfix lane.
 - Run owner-side plan-based review, internal evaluator discovery loop, and local non-Docker verification.
+- For the internal evaluator loop, read the installed `backend-evaluation-prompt.md` or `frontend-evaluation-prompt.md` fresh and include its full body verbatim in the prepared packet under the non-negotiable verbatim prompt paste rule.
 - Send issues to the bugfix lane in broad human language.
 - Record lanes, issue lists, reports, fixes, verification evidence, and closure decisions in metadata and Beads.
+- Exit only when owner plan-based review issues are fixed, internal evaluator loop has completed, local non-Docker verification has passed, and README/runtime/test surfaces are coherent enough for final evaluation.
 
 ### Phase 5: Evaluation And Fix Verification
 
 - Required skills: `beads-operations`, `developer-session-lifecycle`, `claude-worker-management`, `final-evaluation-orchestration`, `evaluation-triage`, `owner-evidence-discipline`, and `report-output-discipline`.
 - Run two strict audit/remediation cycles using evaluator sessions and the active bugfix lane.
+- In each audit cycle, send the complete installed evaluation prompt asset through the exact saved send packet verbatim. If a Fail report is fixed, send only the exact regeneration prompt verbatim. Any deviation invalidates the cycle: archive cycle files unchanged and restart that cycle.
+- Each audit cycle must close with both a rich 150+ line `./.tmp/audit_report-<N>.md` and `./.tmp/audit_report-<N>-fix_check.md` confirming all kept-report items are fixed or that there were zero scoped items.
 - Preserve reports, extract complete issue sets, and route fixes in broad human language.
 - After both audit cycles, close the bugfix lane and start a test-coverage/final-reconciliation lane.
-- Complete only when the coverage/README audit passes with at least 90% test score.
+- Complete only when both Audit Cycle 1 and Audit Cycle 2 are complete with kept audit reports and fix-check reports, the bugfix lane is closed, and the coverage/README audit passes with at least 90% test score.
 - Treat README hard-gate failures, missing true endpoint coverage, missing frontend unit tests for web/fullstack, and missing FE-BE proof as reconciliation work for the active Claude lane before this phase closes.
 
 ### Phase 6: Final Readiness Decision
@@ -225,6 +265,7 @@ Use these sequential names as the canonical workflow model. Legacy `P*` names ar
 - Route final reconciliation work to the active Claude lane whenever it is more than a tiny, safe owner-side edit. If the owner makes a minor direct safe fix, send a minimal note to the active Claude lane describing the changed surface and ask it to inspect/acknowledge before continuing.
 - Use platform-equivalent checks for Android, iOS, desktop, or other native projects.
 - Do not pass readiness with unresolved blocker/high findings, unverified runtime claims, README drift, or known fake behavior.
+- Exit only when all D1-D9 readiness categories are pass/not-applicable/risk-accepted, runtime/test/browser checks pass, and no unresolved blocker/high findings remain.
 
 ### Phase 7: Submission Packaging
 

package/assets/agents/slopmachine.md

@@ -39,6 +39,34 @@ Your job is to move a task from intake to submission packaging through a control
 - Keep workflow-private reasoning separate from developer-facing instructions.
 - Use one active implementation session whenever possible. Start new sessions only for context limits, evaluator isolation, bugfix/fix-check isolation, or a concrete workflow reason.
 
+## Non-Negotiable Verbatim Prompt Paste Rule (All Phases)
+
+This rule applies every time a packaged `.md` prompt file must be sent to a subagent, Claude lane, developer session, or evaluator. It overrides any softer wording in phase descriptions, delegation notes, or skills below.
+
+Read the installed file fresh from its asset path using a `read` tool call. Then paste the **complete file content verbatim** into the message. Do not summarize, describe, shorten, paraphrase, add a preface or footer, send only a file path, or tell the worker to open the file itself.
+
+This applies to every packaged prompt file across all phases:
+
+| Phase | Packaged prompt files |
+|-------|----------------------|
+| Phase 1 | `clarifier-agent-prompt.md`, `clarification-faithfulness-review-prompt.md` |
+| Phase 2 | `phase-1-design-prompt.md`, `phase-2-execution-planning-prompt.md`, `phase-2-plan-template.md` |
+| Phase 4 | `backend-evaluation-prompt.md` or `frontend-evaluation-prompt.md` (internal evaluator loop) |
+| Phase 5 | `backend-evaluation-prompt.md` or `frontend-evaluation-prompt.md` (full audit), the exact fail-regeneration prompt from the non-negotiable full-audit prompt block, `test-coverage-prompt.md` |
+
+If a phase description below says "run the clarifier", "send the design prompt", "use the evaluation prompt", "delegate planning", "run the faithfulness review", or any similar instruction that references a packaged `.md` file, that means: **read the installed file fresh with `read`, then paste its full body verbatim into the message**.
+
+The owner must never:
+- describe what a packaged prompt says instead of sending its text;
+- tell a worker to read a file path as a substitute for pasting the content;
+- shorten, omit sections from, or append extra instructions to a packaged prompt body;
+- add a preface, footer, fix evidence, issue list, or status note before or after a packaged prompt that must be sent verbatim;
+- rely on chat memory or a previously read version instead of reading the installed file fresh.
+
+If any of the packaged prompt files below is not relevant (e.g. no frontend for a pure-backend project), skip it. Otherwise paste the full body.
+
+**Violation consequence:** Any deviation from this rule (summarizing, describing, shortening, path-only reference, preface/footer, omitting sections, or any owner-authored substitution) invalidates the workflow action. If detected during a phase gate, archive any artifacts produced by that invalid action and restart from the step that required the packaged prompt.
+
 ## Worker Communication Firewall
 
 This is a hard rule: developer and worker sessions must never see the workflow.
@@ -66,7 +94,8 @@ Worker prompts must be clean, short, and human-like:
 - Give the worker the issue, desired outcome, general module/surface area, and practical verification needed for this pass.
 - Avoid file names, line numbers, report paths, exact evidence citations, and overly technical internals in ordinary developer prompts. Let the developer inspect and discover the implementation details.
 - Do not say `the review found`, `the evaluation found`, `the audit found`, or similar. Speak as the developer in charge: `I found issues in the auth module...`.
-- If explicitly told to copy/paste a prompt, copy/paste it exactly. Otherwise rewrite instructions naturally for the worker.
+- If sending a packaged prompt file (clarifier, evaluation, design, planning, etc.), you must paste its full body verbatim under the non-negotiable verbatim prompt paste rule at the top of this file. The "otherwise rewrite" rule below does not apply to packaged prompts.
+- For ordinary development instructions (module prompts, bugfix issues, feature requests), write naturally. Do not paste packaged prompt files into ordinary development messages — paste them only into the specialized subagent or evaluator sessions they are designed for.
 
 This applies every time you message a developer/worker session. Do not lapse into generated workflow language just because the task is complex. The prompt should sound like: `I checked the module and found these issues. Please fix them and rerun the relevant tests.` It should not sound like a policy packet, audit checklist, or orchestration handoff.
 
@@ -108,7 +137,7 @@ Good worker-message style:
 - Do not use `implement`, `helper`, maintenance, or extra ad hoc subagents for product implementation unless the user explicitly asks. Keep implementation in the tracked active developer session except for evaluator-isolated work or a recorded recovery/context reason.
 - Use `question` only for material user decisions that cannot be resolved by a prompt-faithful default.
 - Use `bash` for git, package managers, tests, Docker, CLIs, runtime checks, and artifact commands.
-- Use `edit`/`write` for owner-side workflow files, tiny safe fixes, reports, and packaged prompts/templates.
+- Use `edit`/`write` for owner-side workflow files, tiny safe fixes, and reports. Do not edit installed packaged prompt assets; those must always be read fresh and pasted verbatim under the non-negotiable verbatim prompt paste rule at the top of this file.
 - Use `todowrite` for substantial multi-step owner work when tracking improves reliability.
 - Use Context7/Exa only when current documentation or external facts are needed.
 
@@ -127,10 +156,13 @@ All other subagent types are forbidden for owner use unless the user explicitly
 - Developer messages must read like a lead engineer talking to another engineer.
 - Use private planning only to decide the next normal implementation instruction; do not mention private planning or its existence.
 - Include what to build or fix, why it matters, the broad affected area, expected behavior, and useful verification.
+- Prompt developers phase-by-phase and slice-by-slice. Prefer one phase, scaffold, module, or fix batch per prompt; at most combine two adjacent tightly coupled slices when separating them would create needless churn.
+- Never give the developer the whole workflow, all phases, or a full end-to-end delivery packet at once.
 - Keep ordinary issue prompts at module/product level. Avoid file/line details unless the user explicitly asks you to pass exact references.
 - Do not paste, summarize, cite, name, or mention hidden plans.
 - Do not combine original-prompt orientation, design, implementation, verification, and bugfix work into one large prompt.
 - Do not send workflow mechanics, evaluator internals, Beads state, hidden-file paths, owner-state reasoning, or negative instructions about nonexistent artifacts to developers.
+- After each developer completion, verify the result against the original product prompt in `./metadata.json`, `./docs/design.md`, `./docs/api-spec.md` when applicable, and owner-private `../.ai/plan.md`. If there are issues, correct through the same active developer session before proceeding to the next slice.
 - If you make a direct owner-side code or docs change that affects the product repo, tell the active developer session exactly what changed and what remains to verify.
 
 ## Phase Model
@@ -141,7 +173,8 @@ Use these sequential names as the canonical workflow model. Legacy `P*` names ar
 
 - Required skills: `beads-operations`, `developer-session-lifecycle`, `clarification-gate`, `owner-evidence-discipline`, and `report-output-discipline` when report output is long or reusable.
 - Clarify the product contract before design or implementation.
-- Run the clarification worker, then the faithfulness review worker.
+- Before clarification workers run, verify task-root `./metadata.json.prompt` contains the exact original product prompt and root metadata contains only the seven project-fact keys. Fix stale, empty, summarized, or context-contaminated prompt metadata before proceeding.
+- Send the `clarifier-agent-prompt.md` full body verbatim to a general clarification worker, then send the `clarification-faithfulness-review-prompt.md` full body verbatim to a faithfulness review worker. Both must be pasted verbatim under the non-negotiable verbatim prompt paste rule at the top of this file.
 - Record artifact decisions and acceptance in metadata and Beads.
 - Exit only when `clarification-gate` is satisfied.
 
@@ -149,7 +182,8 @@ Use these sequential names as the canonical workflow model. Legacy `P*` names ar
 
 - Required skills: `beads-operations`, `developer-session-lifecycle`, `planning-guidance`, `planning-gate`, `owner-evidence-discipline`, and `report-output-discipline` when reports are long or reusable.
 - Establish or resume the primary developer session and start design/planning.
-- Produce and accept the design/API docs, then delegate owner-private `../.ai/plan.md` creation to a general owner-side subagent using `phase-2-execution-planning-prompt.md` and `phase-2-plan-template.md`.
+- Send the original prompt, then the accepted clarifications and requirements. Then read the installed `phase-1-design-prompt.md` fresh, paste its full body verbatim, and tell the developer to fill the design template already seeded at `./docs/design.md`.
+- After design/API docs are accepted, delegate owner-private `../.ai/plan.md` creation to a general owner-side subagent. Read the installed `phase-2-execution-planning-prompt.md` and `phase-2-plan-template.md` fresh. Paste both bodies verbatim into the subagent message.
 - Record session and artifact decisions in metadata and Beads.
 - Exit only when `planning-gate` is satisfied.
 
@@ -160,24 +194,30 @@ Use these sequential names as the canonical workflow model. Legacy `P*` names ar
 - Scaffold first, then proceed module by module.
 - Prompt in casual human language using only visible project context.
 - Use internal planning privately for review and module acceptance.
+- Do not send more than the current module/slice, or two adjacent tightly coupled slices, in a single developer prompt.
 - Record session turns, issues, verification evidence, and module acceptance in metadata and Beads.
 - After all modules are complete, ask the same session to check the implementation against the design/API docs and provide startup commands plus expected flows.
+- Exit only when scaffold is accepted, all planned modules are implemented, module-level issues are resolved, the final self-check has been requested and any reported gaps fixed, and startup commands have been collected.
 
 ### Phase 4: Integrated Verification And Hardening
 
 - Required skills: `beads-operations`, `developer-session-lifecycle`, `integrated-verification`, `verification-gates`, `owner-evidence-discipline`, and `report-output-discipline` when notes/reports are long or reusable.
 - Close normal work in the original development session and establish a new bugfix session.
 - Run owner-side plan-based review, internal evaluator discovery loop, and local non-Docker verification.
+- For the internal evaluator loop, read the installed `backend-evaluation-prompt.md` or `frontend-evaluation-prompt.md` fresh and include its full body verbatim in the prepared packet under the non-negotiable verbatim prompt paste rule.
 - Send issues to the bugfix session in broad human language.
 - Record sessions, issue lists, reports, fixes, verification evidence, and closure decisions in metadata and Beads.
+- Exit only when owner plan-based review issues are fixed, internal evaluator loop has completed, local non-Docker verification has passed, and README/runtime/test surfaces are coherent enough for final evaluation.
 
 ### Phase 5: Evaluation And Fix Verification
 
 - Required skills: `beads-operations`, `developer-session-lifecycle`, `final-evaluation-orchestration`, `evaluation-triage`, `owner-evidence-discipline`, and `report-output-discipline`.
 - Run two strict audit/remediation cycles using evaluator sessions and the active bugfix lane.
+- In each audit cycle, send the complete installed evaluation prompt asset through the exact saved send packet verbatim. If a Fail report is fixed, send only the exact regeneration prompt verbatim. Any deviation invalidates the cycle: archive cycle files unchanged and restart that cycle.
+- Each audit cycle must close with both a rich 150+ line `./.tmp/audit_report-<N>.md` and `./.tmp/audit_report-<N>-fix_check.md` confirming all kept-report items are fixed or that there were zero scoped items.
 - Preserve reports, extract complete issue sets, and route fixes in broad human language.
 - After both audit cycles, close the bugfix lane and start a test-coverage/final-reconciliation lane.
-- Complete only when the coverage/README audit passes with at least 90% test score.
+- Complete only when both Audit Cycle 1 and Audit Cycle 2 are complete with kept audit reports and fix-check reports, the bugfix lane is closed, and the coverage/README audit passes with at least 90% test score.
 - Treat README hard-gate failures, missing true endpoint coverage, missing frontend unit tests for web/fullstack, and missing FE-BE proof as reconciliation work for the active lane before this phase closes.
 
 ### Phase 6: Final Readiness Decision
@@ -192,6 +232,7 @@ Use these sequential names as the canonical workflow model. Legacy `P*` names ar
 - Route final reconciliation work to the active developer session whenever it is more than a tiny, safe owner-side edit. If the owner makes a minor direct safe fix, send a minimal note to the active developer session describing the changed surface and ask it to inspect/acknowledge before continuing.
 - Use platform-equivalent checks for Android, iOS, desktop, or other native projects.
 - Do not pass readiness with unresolved blocker/high findings, unverified runtime claims, README drift, or known fake behavior.
+- Exit only when all D1-D9 readiness categories are pass/not-applicable/risk-accepted, runtime/test/browser checks pass, and no unresolved blocker/high findings remain.
 
 ### Phase 7: Submission Packaging
 

package/assets/skills/clarification-gate/SKILL.md

@@ -19,10 +19,10 @@ Phase 1 has exactly two worker passes:
 - First, send the original prompt plus stack/context information to one general clarification worker. That worker generates `./docs/questions.md` and `../.ai/requirements-breakdown.md`.
 - Second, send the original prompt plus those generated artifacts to one faithfulness review worker. That worker checks that the requirements and questions did not drift, narrow, or expand away from the original prompt, then writes `../.ai/clarification-faithfulness-review.md`.
 
-Clarification should:
-- start from the original prompt plus supporting stack/context notes
-- run one bounded general clarification worker using the packaged clarifier-agent-prompt verbatim
-- copy that full clarifier prompt text into the worker message itself rather than telling the worker to open the file
+ Clarification should:
+ - start from the original prompt plus supporting stack/context notes
+ - run one bounded general clarification worker using the packaged clarifier-agent-prompt verbatim—paste its complete body into the worker message, do not describe or summarize
+ - copy that full clarifier prompt text into the worker message itself rather than telling the worker to open the file
 - require the worker to output both `./docs/questions.md` and `../.ai/requirements-breakdown.md`
 - treat those 2 files as the clarification artifacts planning depends on
 - extract an approved requirements-and-clarification package from `../.ai/requirements-breakdown.md` plus `./docs/questions.md` before Phase 2
@@ -37,39 +37,68 @@ It must not become planning, architecture design, execution planning, or conveni
 
 Do not pad `./docs/questions.md` with AI-inferred missing requirements, speculative feature ideas, generic best-practice questions, or implementation-task prompts. It should contain only genuine business-logic ambiguities, data relationship uncertainties, boundary conditions, contradictions, and accepted resolutions from the original prompt.
 
+## Verbatim Prompt Paste Rule
+
+Phase 1 must follow the owner-level non-negotiable verbatim prompt paste rule defined in the owner agent (`slopmachine.md` or `slopmachine-claude.md`). That rule requires: read the installed `.md` file fresh with a `read` tool call, then paste its **complete body verbatim** into the subagent message. Do not summarize, describe, shorten, paraphrase, add preface/footer, or send a file path reference.
+
+The packaged prompt files for Phase 1 are:
+- `clarifier-agent-prompt.md` — first worker
+- `clarification-faithfulness-review-prompt.md` — faithfulness review worker
+
+## Root Metadata Gate
+
+## Root Metadata Gate
+
+Before any clarification worker runs, the owner must verify task-root `./metadata.json` is populated with the exact original product prompt.
+
+Rules:
+- `./metadata.json` is the product metadata file that ships with the task. It must keep only the seven project-fact keys: `prompt`, `project_type`, `frontend_language`, `backend_language`, `database`, `frontend_framework`, and `backend_framework`.
+- `prompt` must contain the original product prompt, exactly enough to anchor design, evaluation, packaging, and session lineage.
+- If the user's intake text contains a prompt block followed by appended stack/context/operator notes, keep only the product prompt in `./metadata.json.prompt` and record the supporting context under `../.ai/startup-context.md` or another owner-private workflow artifact.
+- If `./metadata.json.prompt` is empty, stale, summarized, or mixed with non-prompt operator context, fix it before launching the clarifier.
+- Do not add accepted clarifications, requirements breakdowns, workflow state, phase state, Beads ids, session ids, evaluator paths, or owner-private notes as extra keys in root `./metadata.json`.
+- Accepted clarifications belong in `./docs/questions.md`, `../.ai/requirements-breakdown.md`, the approved clarification package summary in `../.ai/metadata.json`, and Beads comments.
+- `project_type` must be exactly one of the six accepted values: `backend`, `fullstack`, `web`, `android`, `ios`, or `desktop`. Do not use `api`, `spa`, `cli`, `nextjs`, `nuxt`, or any other variant. If the project type becomes clear during clarification, update `project_type` in root metadata. If it is not yet clear, leave it as an empty string until Phase 2 design confirms it.
+- If project type or stack facts become clear during clarification, update only the existing seven project-fact fields in `./metadata.json`; leave unknown fields as empty strings until truthfully known.
+
+Phase 1 cannot close if root `./metadata.json.prompt` is missing, stale, or contaminated with non-product workflow/operator text.
+
 ## Procedure
 
 1. **Confirm the inputs.**
    - Keep the original product prompt as the source of truth.
    - Treat supporting stack/context as supporting information unless it materially changes the product contract.
+   - Verify and, if needed, correct `./metadata.json.prompt` before launching the clarification worker.
+   - Record any metadata correction in `../.ai/metadata.json` and Beads without exposing workflow metadata to implementation sessions.
 
-2. **Run the general clarification worker.**
-   - Use the packaged `clarifier-agent-prompt.md` verbatim.
-   - Copy the full packaged prompt body into the sent worker message.
-   - Inject only the original prompt and supporting stack/context notes into that packet; do not prepend or append a second owner-written clarification contract, and do not tell the worker to read the packaged file itself.
+ 2. **Run the general clarification worker.**
+   - Read the installed `clarifier-agent-prompt.md` file fresh from its asset path using a `read` tool call.
+   - Paste that file's **complete body verbatim** into the sent worker message under the non-negotiable verbatim paste rule.
+   - After the packaged prompt body, inject only the original prompt and supporting stack/context notes; do not prepend or append a second owner-written clarification contract, and do not tell the worker to read the packaged file itself.
    - Require both `./docs/questions.md` and `../.ai/requirements-breakdown.md` as output.
    - After the worker returns, record both artifact paths in `../.ai/metadata.json` and add a Beads `ARTIFACT:` comment.
 
-3. **Review `questions.md` and `../.ai/requirements-breakdown.md` critically.**
-   - It should extract the core requirements from the prompt explicitly.
-   - It should use evaluation-grade extraction depth: business goal, main flows, actors, required surfaces, modules, APIs/jobs/data, security boundaries, mock/fake boundaries, documentation/static-verifiability expectations, test/coverage expectations, frontend state obligations, and FE-BE wiring expectations when applicable.
-   - Those requirements should be defined in enough depth that design and planning can rely on them directly.
-   - It should explain what later planning could miss if each important requirement is not carried forward explicitly.
-   - It should distinguish between explicit prompt requirements, implied but binding requirements, and locked safe defaults where that separation helps later planning.
+ 3. **Review `questions.md` and `../.ai/requirements-breakdown.md` critically.**
+   - It must extract the core requirements from the prompt explicitly.
+   - It must use evaluation-grade extraction depth: business goal, main flows, actors, required surfaces, modules, APIs/jobs/data, security boundaries, mock/fake boundaries, documentation/static-verifiability expectations, test/coverage expectations, frontend state obligations, and FE-BE wiring expectations when applicable.
+   - Those requirements must be defined in enough depth that design and planning can rely on them directly.
+   - It must explain what later planning could miss if each important requirement is not carried forward explicitly.
+   - It must distinguish between explicit prompt requirements, implied but binding requirements, and locked safe defaults where that separation helps later planning.
    - It must end with a planning-miss checklist strong enough to expose details later design/planning commonly underbuild.
-   - It should explicitly cover hidden environment and trust-boundary assumptions when the prompt mentions or implies on-prem, intranet, offline, LAN, browser access, auth cookies/tokens, local storage, self-contained deployment, external reachability, or secure/insecure transport.
-   - It should cover material ambiguity only.
-   - It should preserve prompt faithfulness and avoid convenience narrowing.
+   - It must explicitly cover hidden environment and trust-boundary assumptions when the prompt mentions or implies on-prem, intranet, offline, LAN, browser access, auth cookies/tokens, local storage, self-contained deployment, external reachability, or secure/insecure transport.
+   - It must cover material ambiguity only.
+   - It must preserve prompt faithfulness and avoid convenience narrowing.
    - Each entry must end with a decisive solution.
-   - It should not leak into planning or implementation structure.
+   - It must not leak into planning or implementation structure.
    - Reread it once against the original prompt and reject any degradation of implied scope, enforcement, workflow closure, operator/admin behavior, or core requirement meaning.
    - If the file is materially sound and only small wording, ordering, duplication, or overreach cleanup remains, patch `questions.md` directly instead of rerunning the clarifier.
    - If the file is materially weak, convenience-shaped, or still ambiguous, rerun clarification before leaving Phase 1.
 
-4. **Run prompt-faithfulness review.**
+ 4. **Run prompt-faithfulness review.**
    - Launch one short-lived faithfulness review worker.
    - Send the original prompt, the supporting stack/context notes, `../.ai/requirements-breakdown.md`, and `./docs/questions.md` together.
-   - Use the packaged `clarification-faithfulness-review-prompt.md` body in that message.
+   - Read the installed `clarification-faithfulness-review-prompt.md` file fresh from its asset path.
+   - Paste that file's **complete body verbatim** as the review instruction under the non-negotiable verbatim paste rule.
    - Require it to write `../.ai/clarification-faithfulness-review.md`.
    - After the review returns, record the review path and verdict in `../.ai/metadata.json` and add a Beads `ARTIFACT:` or `VERIFY:` comment.
    - If the review finds only small owner-fixable wording or coverage issues, patch `../.ai/requirements-breakdown.md` and `./docs/questions.md` directly.
@@ -106,6 +135,7 @@ Reject the clarification result if:
 ## Exit Condition
 
 `Phase 1: Clarification` is complete only when:
+- `./metadata.json.prompt` contains the exact original product prompt and root metadata contains only the seven project-fact keys
 - `./docs/questions.md` exists
 - `../.ai/requirements-breakdown.md` exists
 - `../.ai/clarification-faithfulness-review.md` exists

package/assets/skills/developer-session-lifecycle/SKILL.md

@@ -31,8 +31,8 @@ Use this skill for startup preflight, session policy, metadata consistency, lane
 - Add a Beads `SESSION:` comment for launch/resume/replacement.
 - Add `VERIFY:`, `ISSUE:`, or `HANDOFF:` comments when a turn produces accepted evidence, defects, or a work handoff.
 - Phase 4 starts and uses the dedicated bugfix/fix-check implementation lane for remediation and verification guidance; the original development lane is closed for normal implementation at development completion.
-- Phase 5 uses fresh evaluator sessions for full audits; the only evaluator-session reuse is scoped fix-check for a kept Partial Pass report.
-- Product fixes from Phase 5 final audits go through the dedicated evaluation bugfix/fix-check implementation lane.
+- Phase 5 uses fresh evaluator sessions for full audits. Evaluator-session reuse occurs in three cases: (1) fail-regeneration — same session receives only the regeneration prompt after fixes; (2) Partial Pass fix-check — same session verifies all scoped issues are fixed; (3) Pass-with-items fix-check — same session verifies all scoped recommendations are closed.
+- Audit Cycle 1 and Audit Cycle 2 fixes go through the dedicated bugfix lane. After both audit cycles complete, the bugfix lane is closed and a new test-coverage/final-reconciliation lane takes over for coverage/README remediation.
 - Phase 6 reconciliation uses the currently active developer/Claude lane for Docker, runtime, browser, account, `run_tests.sh`, coverage, README, and final readiness fixes unless a new lane is explicitly justified by context limits or isolation risk.
 - If the owner directly changes docs, wrappers, config, cleanup, or light glue, send the active lane a minimal acknowledgement request that names the changed surface and asks it to inspect/confirm before readiness continues.
 

package/assets/skills/development-guidance/SKILL.md

@@ -20,6 +20,8 @@ Use this skill during `Phase 3: Development` before prompting the active develop
 
 Prompt like a human developer working with an AI coding assistant.
 
+Prompt one bounded slice at a time. The preferred unit is one phase-purpose, scaffold, module, work package, or fix batch. At most combine two adjacent tightly coupled slices in one prompt, and only when splitting them would make the work less coherent. Never send all phases, the full private plan, or a start-to-finish workflow packet to the developer/Claude lane.
+
 Use direct wording such as:
 - `I checked the user module and found a missing authorization test. Please add that and rerun the relevant tests.`
 - `Continue with the invoice module. Build the create/list/detail flow against the existing product contract and cover the main success and validation paths.`
@@ -29,7 +31,7 @@ Do not send robotic process language. Do not require a specific response format.
 
 Do not keep restating visible doc paths in routine follow-up prompts when the same session already knows the project contract. It is fine to say `existing product contract`, `accepted docs`, or simply name the module. Mention exact doc paths only when orienting a new session, resolving confusion, or asking for a final contract check.
 
-For larger module slices, group expectations by user/business behavior instead of turning every endpoint, field, and negative case into a long checklist. Ask for real backend-backed behavior, visible UI states, and meaningful success/failure tests, but keep the wording natural.
+For larger module slices, group expectations by user/business behavior instead of turning every endpoint, field, and negative case into a long checklist. Ask for real backend-backed behavior, visible UI states, and meaningful success/failure tests, but keep the wording natural. If a module is too large to explain without becoming a checklist packet, split it into smaller sequential prompts.
 
 Example of a good larger module prompt:
 
@@ -61,11 +63,13 @@ Do not say `the review found`, `the evaluation found`, or `the audit found`. The
 
 3. **Proceed module by module.**
    - Select the next section/module from `./docs/design.md` and the private plan.
-   - Prompt the developer using the docs only.
+   - Prompt the developer using the docs only, one module/work package at a time by default.
    - Ask for the implementation and the relevant tests/checks for that module.
+   - Combine two adjacent modules/work packages only when they share the same user flow or data contract and are easier to verify together.
 
 4. **Owner checks after each module.**
    - Inspect changed files manually.
+   - Compare behavior against the original product prompt in `./metadata.json`.
    - Compare behavior against `./docs/design.md` and `./docs/api-spec.md`.
    - Privately compare against `../.ai/plan.md` for tests, coverage, discoverability, functionality, and module completeness.
    - Run targeted checks when practical.
@@ -92,7 +96,7 @@ Also give me the startup commands and the main flows I should expect to exercise
 
 ## Owner Review Checklist
 
-For each scaffold/module, check:
+For each scaffold/module, the owner must verify:
 - changed files are integrated, referenced, and not orphaned
 - implementation matches `./docs/design.md`
 - API/interface behavior matches `./docs/api-spec.md` when applicable

package/assets/skills/evaluation-triage/SKILL.md

@@ -53,7 +53,7 @@ When a failed report is regenerated in the same evaluator session:
 - reject reports if the last ordinary audit send was not the exact saved send packet content
 - reject reports that are continuation-shaped, fix-only, stale against current files, or contradicted by current repo evidence
 - reject reports that drop required endpoint/surface inventory, hard-gate README review, severity panels, verdict blocks, or finding details expected by the underlying prompt
-- if rejected, send the full prepared evaluation prompt again instead of using the degraded report
+- if rejected, archive every report or candidate report from the invalid cycle unchanged, record the reason, and restart that audit cycle from a fresh evaluator session using the installed prompt asset and exact saved send packet required by `final-evaluation-orchestration`
 
 ## Partial Pass Handling
 
@@ -64,25 +64,39 @@ When a failed report is regenerated in the same evaluator session:
 - Do not narrow fix-check to Blocker/High issues.
 - The same evaluator session that wrote the kept Partial Pass report performs the fix-check.
 
+## Pass With Items Handling
+
+- A kept Pass report with any issue, recommendation, caveat, suggestion, action item, or requested change also requires closure.
+- Save the kept Pass report under the same cycle audit report name: `./.tmp/audit_report-1.md` or `./.tmp/audit_report-2.md`.
+- Extract every issue/recommendation/caveat/suggestion/action item/requested change from it.
+- The fix-check scope is the full extracted set.
+- The same evaluator session that wrote the kept Pass report performs the fix-check.
+- Save the fix-check under the fixed cycle path: `./.tmp/audit_report-1-fix_check.md` or `./.tmp/audit_report-2-fix_check.md`.
+- A Pass report with zero scoped items still requires the cycle fix-check report. The fix-check must explicitly confirm that the kept audit report had no scoped issues to close and that the cycle is clean.
+
 ## Fix-Check Handling
 
 - Read the full fix-check report.
 - If every scoped issue is fixed, save/keep the fix-check report.
 - If anything is not fixed or partially fixed, send only the unresolved behavior back to the developer lane in broad human language, then rerun the fix-check in the same evaluator session.
 - The regenerated fix-check must still address the full kept audit issue set, not only the unresolved items that were most recently sent back.
+- Before sending the exact fix-check instruction, provide the same evaluator session with concise developer fix evidence, exact verification results when available, and the exact full audit-scoped issue list from the kept `audit_report-<N>.md`.
 - Reject fix-check reports that narrow the scope, skip low-priority kept issues, perform a broad new audit instead of scoped checking, or use history-exposing language.
 - Do not edit evaluator report text.
 
 ## Send Packet Validation
 
 Before accepting any full audit report:
-- confirm `prepare_evaluation_prompt.mjs` was used to build the prepared prompt for the right project type
-- confirm `prepare_evaluation_send_packet.mjs` was used to build the exact send packet
+- confirm `prepare_evaluation_send_packet.mjs` was used to build the exact send packet, including {prompt} interpolation and report path insertion
+- record both the installed prompt asset path and the exact saved send packet path
 - read the saved send packet before sending
-- confirm the evaluator received the exact saved send packet content, not a summary, footer, file reference, or shortened prompt
-- record prepared prompt path, send packet path, report path, and evaluator session id in metadata and Beads
+- confirm the evaluator received the exact saved send packet content, not a summary, footer, file reference, shortened prompt, or owner-authored replacement
+- confirm the saved send packet contains the complete installed evaluation prompt content, with nothing omitted from the installed asset and no owner-added text outside the packet
+- record installed prompt asset path, prepared prompt path, send packet path, report path, and evaluator session id in metadata and Beads
+
+If any part cannot be confirmed, reject the report, archive every report or candidate report from the invalid cycle unchanged, and restart that audit cycle from a fresh evaluator session with a valid installed prompt asset plus saved send packet.
 
-If any part cannot be confirmed, reject the report and rerun with a valid saved send packet.
+For failed-report regeneration, do not build or improvise a new prompt. Use only the exact fail-regeneration prompt from `final-evaluation-orchestration`, verbatim and with no preface, suffix, issue list, fix evidence, or extra wording.
 
 ## State Updates
 

package/assets/skills/final-evaluation-orchestration/SKILL.md

@@ -7,7 +7,7 @@ description: Phase 5 evaluation/remediation cycles, fix-checks, and coverage/REA
 
 Use this skill during `Phase 5: Evaluation And Fix Verification`.
 
-This phase is strict. Follow the cycle rules exactly.
+This phase is strict. Follow the cycle rules exactly. If another section appears to conflict with the non-negotiable prompt block below, the non-negotiable prompt block wins.
 
 ## Core Shape
 
@@ -18,16 +18,47 @@ Phase 5 has three parts:
 
 The existing bugfix lane from Phase 4 remains active through Audit Cycle 1 and Audit Cycle 2. After both audit cycles complete and the 4 required audit reports exist, close that bugfix lane and start a new test-coverage/final-reconciliation lane.
 
-## Prompt Preparation
+## Non-Negotiable Full-Audit Prompt Block
 
-- Prepare the evaluation prompt with `prepare_evaluation_prompt.mjs` based on project type.
-- Build the exact evaluator send packet with `prepare_evaluation_send_packet.mjs` before every full audit send.
-- Use `backend-evaluation-prompt.md` for backend, fullstack, API, mobile, desktop, CLI, data, or any non-pure-frontend project.
-- Use `frontend-evaluation-prompt.md` for pure frontend projects.
-- Read the saved send packet file and send that exact content verbatim to the evaluator subagent.
-- Record the prepared prompt path and exact send packet path in metadata and Beads.
-- Save evaluator session ids in `../.ai/metadata.json` and Beads.
-- Treat evaluator reports as immutable once written.
+This block controls every full audit and fail-regeneration evaluator send. Do not reinterpret it from later sections.
+
+Only two evaluator prompts are allowed in the full-audit/fail-regeneration cycle:
+
+1. **Initial full audit prompt**
+   - Determine project type.
+   - Use and record both the installed full evaluation prompt asset and the generated send packet.
+   - The installed asset is the source prompt, located under the installed SlopMachine assets directory (the same directory where `backend-evaluation-prompt.md` and `frontend-evaluation-prompt.md` were installed by setup).
+   - Use `backend-evaluation-prompt.md` for backend, fullstack, API, mobile, desktop, CLI, data, or any non-pure-frontend project.
+   - Use `frontend-evaluation-prompt.md` for pure frontend projects.
+   - Prepare the send packet with `prepare_evaluation_send_packet.mjs` after prompt interpolation and exact output path insertion.
+   - The installed evaluation prompt content must be preserved word-for-word with nothing omitted. The evaluator must receive the whole long prompt packet, not a summary, not a path, not a shortened excerpt, and not an owner-authored substitute. If the installed prompt is 400+ lines, all 400+ lines must be present in the packet sent to the evaluator.
+   - Read the complete saved send packet before sending.
+   - Paste/send the complete saved send packet into the evaluator subagent word-for-word, with nothing added, removed, summarized, paraphrased, or appended.
+   - The owner must not add a preface, footer, clarification, instruction, file reference substitute, or any extra sentence.
+
+2. **Fail-regeneration prompt**
+   - If a full audit report is Fail, archive the failed report unchanged, extract all issues, fix them through the active bugfix lane, and owner-verify the fixes.
+   - Return to the same evaluator session that produced the failed report.
+   - Send exactly the regeneration prompt below, verbatim, with absolutely nothing added, removed, summarized, paraphrased, prefaced, suffixed, or otherwise modified.
+
+```text
+Regenerate the audit on a new file. Check, I fixed every issues you identified. but don't make it obvious that it is a regeneration, you shouldn't mention that the previous issues are fixed on the current audit, just put the new updated verdict and only mention remaining or newly found issues.
+
+Refrain from using words like "Remaining, still, now", and the likes that may expose this current audit is a regen.
+```
+
+No other full-audit or fail-regeneration prompt is allowed. In particular, the owner must not:
+- shorten the installed evaluation prompt;
+- send only a path to the prompt instead of the complete prompt packet;
+- add local context outside the prepared packet;
+- append rerun footers or status notes;
+- rewrite the regeneration prompt;
+- combine the regeneration prompt with issue summaries, fix evidence, or extra report instructions;
+- replace a fail-regeneration send with a different custom prompt.
+
+If any deviation is found from either allowed prompt send, the current audit cycle is invalid. Archive every report or candidate report generated during that invalid cycle unchanged under `../.ai/archive/`, record the restart reason in metadata and Beads, then restart that audit cycle from a fresh evaluator session using the installed asset and exact saved send packet. Do not patch, rename, or reuse invalid-cycle reports as kept reports.
+
+Record the installed prompt asset path, prepared prompt path, exact send packet path, evaluator session id, and report path in metadata and Beads. Treat evaluator reports as immutable once written.
 
 ## Report Paths And Names
 
@@ -40,6 +71,15 @@ Use task-local report paths under `./.tmp/`. The kept report paths are:
 
 Do not write final kept reports under `../.tmp` or `./tmp`.
 
+Cycle naming is fixed:
+- Audit Cycle 1 kept full audit report: `./.tmp/audit_report-1.md`.
+- Audit Cycle 1 fix-check report, when required: `./.tmp/audit_report-1-fix_check.md`.
+- Audit Cycle 2 kept full audit report: `./.tmp/audit_report-2.md`.
+- Audit Cycle 2 fix-check report, when required: `./.tmp/audit_report-2-fix_check.md`.
+- Coverage/README report: `./.tmp/test_coverage_and_readme_audit_report.md`.
+
+A cycle fix-check is required for every kept full audit report, including Pass reports with zero issues. The fix-check report must confirm that all issues from the kept audit report are fixed; when the kept audit report has zero scoped issues, the fix-check must explicitly state that the kept audit report had no scoped issues to close and that the cycle is clean.
+
 Archive failed/superseded reports unchanged under `../.ai/archive/`.
 
 ## Audit Cycle Procedure
@@ -50,9 +90,10 @@ Run this procedure twice: once for Audit Cycle 1 and once for Audit Cycle 2.
 
 - Start a new `evaluator` subagent session.
 - Save its session id.
-- Send the exact saved evaluator send packet verbatim.
+- Send the exact saved evaluator send packet verbatim under the non-negotiable full-audit prompt block.
 - Require the report to be written to the current cycle's candidate report path.
 - Reject the report if you cannot confirm the last evaluator send used the exact saved send packet content.
+- Reject and restart the cycle if you cannot cite both the installed prompt asset path and the exact saved send packet path used for that evaluator send.
 
 ### 2. If The Report Is Fail
 
@@ -63,16 +104,10 @@ Run this procedure twice: once for Audit Cycle 1 and once for Audit Cycle 2.
 - Convert the issue list into broad human language.
 - Send the full issue set to the existing bugfix lane without file/line details, report names, or evaluator language.
 - Do not run a fix-check for a Fail report. First fix every issue from the failed report and verify the fixes owner-side.
-- After the bugfix lane fixes every issue from the failed report and the owner verifies, return to the same evaluator session and send this exact regeneration instruction verbatim, with no additions, removals, preface, suffix, or wording changes:
-
-```text
-Regenerate the audit on a new file. Check, I fixed every issues you identified. but don't make it obvious that it is a regeneration, you shouldn't mention that the previous issues are fixed on the current audit, just put the new updated verdict and only mention remaining or newly found issues.
-
-Refrain from using words like "Remaining, still, now", and the likes that may expose this current audit is a regen.
-```
+- After the bugfix lane fixes every issue from the failed report and the owner verifies, return to the same evaluator session and send only the exact fail-regeneration prompt from the non-negotiable full-audit prompt block.
 
 - Validate the regenerated report before using it.
-- If the regenerated report is less than 150 lines or materially less complete than the archived report in content size/depth, reject it and resend the full prepared evaluation prompt.
+- If the regenerated report is less than 150 lines or materially less complete than the archived report in content size/depth, reject it as invalid and repeat the fail-remediation/regeneration path using only the exact fail-regeneration prompt from the non-negotiable block after fixes are verified.
 - Reject the regenerated report if it is continuation-shaped, fix-only, materially omits required sections/tables/verdict panels/evidence style, or appears stale against current repo state.
 - If the regenerated report is reasonably similar in depth and structure, proceed with its verdict.
 - If the regenerated report is still Fail, archive it unchanged, extract every issue again, fix every issue again through the bugfix lane, owner-verify again, then return to the same evaluator session and send the same exact regeneration instruction verbatim again.
@@ -103,15 +138,44 @@ Refrain from using words like "Remaining, still, now", and the likes that may ex
 
 - Keep the report as the cycle's audit report.
 - Save it under the cycle's kept report path in `./.tmp/`.
-- If it contains any issue or recommendation, treat those as the cycle issue set and run the same bugfix/fix-check discipline needed to close them.
-- If it contains no issues or recommendations, the cycle is complete with no fix-check required unless an explicit report requirement says otherwise.
+- If it contains any issue, recommendation, caveat, suggestion, action item, or requested change, treat those as the cycle issue set.
+- Send the full issue set to the existing bugfix lane in broad human language, then owner-verify the fixes.
+- Run the fix-check in the same evaluator session that wrote the kept Pass report.
+- The fix-check must address every scoped issue/recommendation/caveat/suggestion/action item/requested change from the kept Pass report.
+- Save the fix-check report as:
+  - Cycle 1: `./.tmp/audit_report-1-fix_check.md`
+  - Cycle 2: `./.tmp/audit_report-2-fix_check.md`
+- If the fix-check says any item is only partially fixed or not fixed, send those items back to the bugfix lane, then rerun the fix-check in the same evaluator session against the whole kept report issue set.
+- If it contains no issues, recommendations, caveats, suggestions, action items, or requested changes, run the same-session cycle fix-check anyway; the fix-check must state that the kept audit report had zero scoped items to close and that the cycle is clean.
+
+### 5. Cycle Completion Validation
+
+Before a cycle can close, validate the whole cycle as a hard gate. If any item fails, archive every candidate/kept/fix-check report produced in that cycle unchanged under `../.ai/archive/`, record the reason, and restart that audit cycle from a fresh evaluator session using the non-negotiable full-audit prompt block.
+
+Required for each cycle:
+- the installed evaluation prompt asset path is recorded and matches the project type;
+- the exact saved send packet path is recorded;
+- the full saved send packet was read before send and sent word-for-word with no owner additions, omissions, summaries, path-only substitutions, or footers;
+- if the cycle had any Fail report, the failed report was archived unchanged, fixes were verified owner-side, and the exact fail-regeneration prompt was sent word-for-word with no owner additions, omissions, summaries, issue lists, fix evidence, or footers;
+- the kept audit report exists at `./.tmp/audit_report-<N>.md`;
+- the kept audit report is rich and complete: at least 150 lines and not materially shallower than the installed prompt's required output structure;
+- the kept audit report includes the required verdict, scope/boundary, prompt/repository mapping, section review or blocker/high panel as applicable, issues/suggestions or explicit no-issue statement, security/data-risk review where applicable, and test/logging/coverage sections required by the installed prompt;
+- the cycle fix-check report exists at `./.tmp/audit_report-<N>-fix_check.md`;
+- the cycle fix-check report confirms every issue/recommendation/caveat/suggestion/action item/requested change from the kept audit report is fixed, or explicitly confirms the kept audit report had zero scoped items to close;
+- the fix-check report does not perform a broader new audit and does not use history-exposing comparison language.
+
+No audit cycle is complete without both `./.tmp/audit_report-<N>.md` and `./.tmp/audit_report-<N>-fix_check.md` passing this validation gate.
 
 ## Fix-Check Prompt
 
-Use this exact fix-check instruction after a kept Partial Pass report has been fixed:
+Use this exact fix-check instruction after a kept Pass or Partial Pass report with any scoped issue/recommendation/caveat/suggestion/action item/requested change has been fixed. Send it verbatim to the same evaluator session after providing concise developer fix evidence, exact verification results when available, and the exact full audit-scoped issue list from the kept `audit_report-<N>.md`:
 
 ```text
-Check the current repository state against every issue and recommendation from the kept audit report for this audit. Write the fix-check report to the requested file. For each scoped issue, state whether the current repository satisfies the expected behavior, cite current evidence, and identify any issue that is not fully fixed. Do not perform a broader new audit.
+Only confirm whether those exact earlier items are fixed; do not perform a broader new review.
+
+The follow-up report must describe each scoped issue's current status, current evidence, and any important verification caveats. It must not describe issues as `resolved`, `remaining`, `still open`, `no longer existing`, `left`, or compare against prior audit history.
+
+Write the follow-up report to `./.tmp/audit_report-<N>-fix_check.md`.
 ```
 
 Do not allow fix-check scope to shrink. It must cover all issues from the kept audit report.
@@ -136,9 +200,9 @@ I found several issues that need cleanup. The auth behavior still has security g
 
 Phase 5 cannot move to coverage/README reconciliation until both cycles are complete and these reports exist:
 - `./.tmp/audit_report-1.md`
-- `./.tmp/audit_report-1-fix_check.md` when Cycle 1 required fixes
+- `./.tmp/audit_report-1-fix_check.md`
 - `./.tmp/audit_report-2.md`
-- `./.tmp/audit_report-2-fix_check.md` when Cycle 2 required fixes
+- `./.tmp/audit_report-2-fix_check.md`
 
 Once both cycles are complete:
 - close the existing bugfix lane

package/assets/skills/integrated-verification/SKILL.md

@@ -76,9 +76,9 @@ Purpose:
 - send consolidated issue batches to the bugfix lane in human language
 
 Procedure:
-1. Prepare the evaluator prompt packet using `prepare_evaluation_prompt.mjs` based on project type.
-2. Use `backend-evaluation-prompt.md` for backend/fullstack/mixed/non-pure-frontend work.
-3. Use `frontend-evaluation-prompt.md` for pure frontend work.
+1. Prepare the evaluator prompt packet using `prepare_evaluation_send_packet.mjs` based on project type, ensuring the installed prompt file body is included verbatim in the packet under the owner-level verbatim prompt paste rule.
+2. The installed asset is `backend-evaluation-prompt.md` for backend/fullstack/mixed/non-pure-frontend work.
+3. The installed asset is `frontend-evaluation-prompt.md` for pure frontend work.
 4. Start one isolated evaluator subagent session.
 5. Send the prepared packet and require a report file under `../.ai/internal-verification/` or another stable internal path.
 6. Archive each generated report unchanged.

package/assets/skills/p8-readiness-reconciliation/SKILL.md

@@ -1,3 +1,8 @@
+---
+name: p8-readiness-reconciliation
+description: Phase 6 final readiness reconciliation and issue classification after Phase 5.
+---
+
 # Phase 6 Readiness Reconciliation
 
 Use this skill for final readiness decision and issue classification after Phase 5.
@@ -31,6 +36,7 @@ Use these D1-D9 buckets for major issue classification:
 - Partial Pass only if residual risks are explicit, bounded, and user-accepted.
 - Fail if core prompt-fit, security, runtime/test, delivery credibility, or evidence integrity remains materially broken.
 - Never imply unrun verification passed.
+- A check is "not applicable" only when the project type genuinely cannot support it (e.g. no browser UI for a pure-backend API) and the reason is user-confirmed. Cost, convenience, or time pressure are not valid not-applicable reasons — route the failing check to the active developer/Claude lane instead.
 
 ## Required Final Checks
 
@@ -48,7 +54,7 @@ Use these D1-D9 buckets for major issue classification:
 - If `docker compose up --build`, native/platform startup, browser/API manual checks, account/seeded-value checks, or `./repo/run_tests.sh` fails, do not move to packaging.
 - Route the failure to the currently active developer/Claude implementation lane in broad human language: describe the failing behavior, command, and user-visible/runtime impact without exposing evaluator or owner-private mechanics.
 - After the lane reports a fix, the owner verifies the changed surface and reruns the failed check.
-- Repeat fix, verify, and rerun until the check is green, not applicable for a documented reason, or explicitly risk-accepted by the user.
+- Repeat fix, verify, and rerun until the check is green, demonstrably not applicable to the project type and confirmed by the user, or explicitly risk-accepted by the user.
 - Record every failed command, routed issue, fix acknowledgement, rerun result, and final decision in metadata and Beads.
 
 ## Owner Direct Fixes

package/assets/skills/planning-guidance/SKILL.md

@@ -39,11 +39,13 @@ Phase 2 establishes the primary developer session and produces the accepted plan
    - Do not reveal hidden paths or workflow mechanics.
    - Explain that these are accepted clarifications and requirements to use for design.
 
-3. Create `./docs/design.md`.
-   - Send the packaged design prompt and design template, or a direct instruction to use the seeded `./docs/design.md` template when it already exists.
+ 3. Create `./docs/design.md`.
+   - Read the installed `phase-1-design-prompt.md` fresh from its asset path.
+   - Paste its full body verbatim into the developer message under the non-negotiable verbatim prompt paste rule. Do not describe, summarize, or tell the developer to read the file path.
+   - Tell the developer to fill the design template already seeded at `./docs/design.md` (the template was created during `slopmachine init`). Do not paste the template file body — it is already in the workspace.
    - The design must be a true product/system design, not an execution plan.
-   - It should define product behavior, actors, flows, modules, data, security, UI/API surfaces, assumptions, and verification strategy at design level.
-   - It should not become a step-by-step coding checklist.
+   - The design must define product behavior, actors, flows, modules, data, security, UI/API surfaces, assumptions, and verification strategy at design level.
+   - It must not become a step-by-step coding checklist.
    - When the design is returned, record the artifact path and Claude turn result in metadata and Beads.
 
 4. Owner reviews and cleans the design.
@@ -68,10 +70,11 @@ Phase 2 establishes the primary developer session and produces the accepted plan
    - The owner must delegate creation of `../.ai/plan.md` to one general owner-side planning subagent.
    - Do not ask Claude/developer implementation lanes to create, edit, review, or know about `../.ai/plan.md`.
    - Provide original prompt, stack/context, accepted questions, requirements breakdown, design, and API spec.
-   - The general subagent must use the packaged `phase-2-execution-planning-prompt.md` as its instruction prompt.
-   - The general subagent must use the packaged `phase-2-plan-template.md` as the required structure for `../.ai/plan.md`.
-   - Require output to `../.ai/plan.md` and `../.ai/test-coverage.md` when useful.
-   - Record private plan and coverage artifact paths in metadata and Beads after the subagent returns.
+    - The general subagent must receive the complete body of the packaged `phase-2-execution-planning-prompt.md` as its instruction prompt, pasted verbatim into the sent message.
+   - The general subagent must receive the complete body of the packaged `phase-2-plan-template.md` as the required structure for `../.ai/plan.md`, pasted verbatim into the sent message.
+- Require output to `../.ai/plan.md` and `../.ai/test-coverage.md` when useful.
+- Record private plan and coverage artifact paths in metadata and Beads after the subagent returns.
+- Ensure the private plan can be executed as small sequential developer prompts. Reject plans that require dumping multiple phases or the whole delivery contract into a single developer/Claude prompt.
 
 8. Owner accepts or rejects the planning package.
    - Use `planning-gate`.

package/assets/skills/retrospective-analysis/SKILL.md

@@ -12,7 +12,7 @@ Use this skill only during Phase 8 Retrospective, after Phase 7 Submission Packa
 - inspect what happened across the whole workflow run
 - identify what caused churn, waste, late defects, or preventable corrections
 - capture lessons that should improve future runs
-- write package-specific retrospective files under `/Users/yohannesakd/slopmachine/retrospectives/`
+- write package-specific retrospective files under the installed SlopMachine assets directory (`<asset-root>/retrospectives/`)
 
 ## Phase role
 
@@ -26,7 +26,7 @@ Use this skill only during Phase 8 Retrospective, after Phase 7 Submission Packa
 
 Write run-scoped retrospective files under:
 
-- `/Users/yohannesakd/slopmachine/retrospectives/`
+- `<asset-root>/retrospectives/`
 
 Preferred filenames:
 

package/assets/skills/submission-packaging/SKILL.md

@@ -1,3 +1,8 @@
+---
+name: submission-packaging
+description: Phase 7 submission packaging, package-boundary validation, and final closure.
+---
+
 # Submission Packaging
 
 Use this skill for Phase 7 submission packaging and final closure.
@@ -49,7 +54,8 @@ Packaging must reject or remove stale workflow notes and scratch execution artif
 ## Required `.tmp` Report Shape
 
 - `.tmp/` must contain the kept immutable evaluator reports and fix-check reports required by the evaluation phase.
-- Normal 2-audit-session path must end with `audit_report-1.md`, `audit_report-2.md`, `test_coverage_and_readme_audit_report.md`, and the corresponding `audit_report-<N>-fix_check.md` files for every kept Partial Pass report that required fix-check.
+- Normal 2-audit-session path must end with `audit_report-1.md`, `audit_report-1-fix_check.md`, `audit_report-2.md`, `audit_report-2-fix_check.md`, and `test_coverage_and_readme_audit_report.md`.
+- A cycle fix-check file is never omitted. Even a Pass report with zero scoped issues requires a fix-check report stating that there were no scoped issues to close.
 - Do not leave archived failed reports, stale report variants, numbered coverage variants, owner reconciliation notes, or superseded reports in final `.tmp/`; archived lineage belongs under `../.ai/archive/`.
 - Read the final coverage/README report holistically as an acceptance signal and reconcile any repo/README/docs mismatch before closing packaging.
 
@@ -91,6 +97,7 @@ Do not run broad Docker prune commands that can affect unrelated projects.
 ## Metadata And Naming
 
 - `./metadata.json` must truthfully describe the delivered project and contain only these seven project-fact keys: `prompt`, `project_type`, `frontend_language`, `backend_language`, `database`, `frontend_framework`, and `backend_framework`.
+- `prompt` in `./metadata.json` must be the original product prompt captured during Phase 1, not a summary, clarified rewrite, workflow note, or prompt-plus-operator-context dump.
 - Normalize `project_type` to exactly one of the six accepted task classifications: `backend`, `fullstack`, `web`, `android`, `ios`, or `desktop`.
 - If a task/question id exists, use that exact id for final deliverable/archive naming without adding an extra `ID-` prefix.
 - Record the package-root manifest: workflow root, task root, package root, docs path, `.tmp` path, separate session handoff path if present, and any explicit validation exceptions.

package/assets/slopmachine/phase-2-execution-planning-prompt.md

@@ -50,6 +50,8 @@ Use the provided plan template.
 
 `../.ai/plan.md` must be actionable enough to support one clean human implementation prompt at a time without exposing this file.
 
+The plan must be sequenced so the owner can prompt the developer/Claude lane one bounded slice at a time. Prefer one work package per prompt. Mark any pair that should be sent together only when two adjacent slices are tightly coupled and easier to verify together. Do not create a plan that requires sending all phases, all modules, or the full delivery workflow to the implementation lane at once.
+
 `../.ai/test-coverage.md`, when written, should summarize planned coverage by module, API/interface, UI flow, risk, and final verification need.
 
 If the design or API spec has a material contradiction, record it as a planning exception instead of silently rewriting the contract.

package/assets/slopmachine/phase-2-plan-template.md

@@ -181,9 +181,11 @@ For each module, acceptance requires:
 
 Translate these into human prompts; do not paste this section verbatim.
 
-| Sequence | Human prompt intent | Visible context to mention | Expected completion report |
-|---|---|---|---|
-| 1 |  |  |  |
+Each row should represent one bounded prompt by default. Mark a combined prompt only when two adjacent rows are tightly coupled and should be implemented/verified together. Never combine all phases, the full plan, or the whole delivery into one developer/Claude prompt.
+
+| Sequence | Human prompt intent | Visible context to mention | Expected completion report | Combine with adjacent row? |
+|---|---|---|---|---|
+| 1 |  |  |  | no |
 
 ## 13. Plan Closure Checklist
 

package/assets/slopmachine/utils/README.md

@@ -205,13 +205,9 @@ Bash wrapper that invokes `claude_wait_for_rate_limit_reset.mjs` through Node.
 
 ## Non-Claude Workflow Helpers
 
-### `prepare_evaluation_prompt.mjs`
-
-Builds an owner-side prepared evaluation prompt under workflow-private `.ai` state from a task root. Use `--report-path ./.tmp/<report>.md` to append an owner-required exact report path without editing the canonical prompt text.
-
 ### `prepare_evaluation_send_packet.mjs`
 
-Builds the exact saved evaluator-send packet for Phase 5/Phase 4 workflows from a task root. Use `--report-path ./.tmp/<report>.md` to append an owner-required exact report path without editing the canonical prompt text.
+Builds the exact saved evaluator-send packet for evaluation workflows from a task root. Interpolates `{prompt}` from `./metadata.json`, appends a required report path, and writes the complete packet to workflow-private `.ai/`. Use `--report-path ./.tmp/<report>.md` to append an owner-required exact report path without editing the canonical prompt text. This is the single consolidated script for all evaluation prompt preparation; use it in Phase 4 internal evaluator loops and Phase 5 audit cycles.
 
 ### `prepare_strict_audit_workspace.mjs`
 

package/assets/slopmachine/utils/prepare_evaluation_send_packet.mjs

@@ -60,7 +60,7 @@ try {
 
   const workflowRoot = path.dirname(taskRoot)
   const metadataPath = path.join(taskRoot, 'metadata.json')
-  const defaultOutputPath = path.join(workflowRoot, '.ai', `evaluation-send-${path.basename(promptFile)}`)
+  const defaultOutputPath = path.join(workflowRoot, '.ai', `prepared-${path.basename(promptFile)}`)
 
   let promptText = await fs.readFile(promptFile, 'utf8')
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "theslopmachine",
-  "version": "1.0.12",
+  "version": "1.0.17",
   "description": "SlopMachine installer and project bootstrap CLI",
   "license": "MIT",
   "type": "module",

package/src/constants.js

@@ -69,7 +69,6 @@ export const REQUIRED_SLOPMACHINE_FILES = [
   "utils/convert_ai_session.py",
   "utils/package_claude_session.mjs",
   "utils/analyze_claude_project_dir.mjs",
-  "utils/prepare_evaluation_prompt.mjs",
   "utils/prepare_evaluation_send_packet.mjs",
   "utils/prepare_strict_audit_workspace.mjs",
   "utils/run_with_timeout.mjs",

package/src/init.js

@@ -628,30 +628,23 @@ async function createRepoStructure(workflowRoot, taskRoot, runtimeAssetRoot, age
         run_id: randomUUID(),
         current_phase: initialPhase,
         awaiting_human: false,
-      clarification_approved: false,
-      evaluation_prompt_kind: null,
-      active_evaluator_session_id: null,
-      task_root: 'task',
-      evaluation_reports_root: 'task/.tmp',
-      evaluation_audit_count: 0,
-      evaluation_runs: [],
-      completed_bugfix_session_count: 0,
-      required_bugfix_session_count: 2,
-      coverage_readme_audit_completed: false,
-      coverage_readme_audit_report_path: null,
-      developer_sessions: [],
-      developer_rulebook_file: developerRulebookFile,
-      current_developer_lane: null,
-      active_developer_session_id: null,
-      primary_develop_session_id: null,
-      latest_develop_session_id: null,
-      next_develop_session_number: 1,
-      next_bugfix_session_number: 1,
-      packaging_completed: false,
-      claude_live_root: '.ai/claude-live',
-      bootstrap_mode: options.adoptExisting ? 'adopt' : 'new',
-      requested_start_phase: options.requestedStartPhase,
-    }, null, 2)}\n`, 'utf8')
+        evaluation_prompt_kind: null,
+        active_evaluator_session_id: null,
+        task_root: 'task',
+        evaluation_reports_root: 'task/.tmp',
+        developer_sessions: [],
+        developer_rulebook_file: developerRulebookFile,
+        current_developer_lane: null,
+        active_developer_session_id: null,
+        primary_develop_session_id: null,
+        latest_develop_session_id: null,
+        next_develop_session_number: 1,
+        next_bugfix_session_number: 1,
+        packaging_completed: false,
+        claude_live_root: '.ai/claude-live',
+        bootstrap_mode: options.adoptExisting ? 'adopt' : 'new',
+        requested_start_phase: options.requestedStartPhase,
+      }, null, 2)}\n`, 'utf8')
   }
 
   await createInitialPhaseArtifacts(taskRoot, workflowRoot, runtimeAssetRoot, options)

package/assets/slopmachine/utils/prepare_evaluation_prompt.mjs

@@ -1,81 +0,0 @@
-#!/usr/bin/env node
-
-import fs from 'node:fs/promises'
-import path from 'node:path'
-
-import { parseArgs, printUsageAndExit, readJsonFile, writeFileIfNeeded } from './claude_worker_common.mjs'
-
-const argv = parseArgs(process.argv.slice(2))
-
-if (argv.help === '1') {
-  printUsageAndExit(`Usage:
-  node ~/slopmachine/utils/prepare_evaluation_prompt.mjs --task-root <task-root> --prompt-file <template-file> [--mode <initial|rerun>] [--report-path <./.tmp/report.md>] [--output-file <prepared-file>]
-`)
-}
-
-const SAME_SESSION_RERUN_FOOTER = 'Check the entire current project again against the full prompt above and regenerate the complete report from scratch. Save the report to the same required path. Make the report read as a fresh standalone audit of the current repo state and do not mention or imply any previous run, rerun, regeneration, prior inspection, earlier fixes, or earlier remaining items.\n'
-
-function fail(message) {
-  process.stderr.write(`${message}\n`)
-  process.exit(1)
-}
-
-try {
-  const taskRoot = argv['task-root'] ? path.resolve(argv['task-root']) : null
-  const promptFile = argv['prompt-file'] ? path.resolve(argv['prompt-file']) : null
-  const outputFile = argv['output-file'] ? path.resolve(argv['output-file']) : null
-  const reportPath = argv['report-path'] ? String(argv['report-path']).trim() : ''
-  const mode = argv.mode ? String(argv.mode).trim().toLowerCase() : 'initial'
-
-  if (!taskRoot) {
-    fail('Missing --task-root')
-  }
-
-  if (!promptFile) {
-    fail('Missing --prompt-file')
-  }
-
-  if (mode !== 'initial' && mode !== 'rerun') {
-    fail(`Unsupported --mode '${mode}'. Use initial or rerun.`)
-  }
-
-  if (reportPath && (!reportPath.startsWith('./.tmp/') || !reportPath.endsWith('.md'))) {
-    fail('--report-path must be a markdown path under ./.tmp/, for example ./.tmp/audit_report-1.md')
-  }
-
-  const workflowRoot = path.dirname(taskRoot)
-  const metadataPath = path.join(taskRoot, 'metadata.json')
-  const defaultOutputPath = path.join(workflowRoot, '.ai', `prepared-${path.basename(promptFile)}`)
-
-  let promptText = await fs.readFile(promptFile, 'utf8')
-
-  if (promptText.includes('{prompt}')) {
-    const metadata = await readJsonFile(metadataPath)
-    const projectPrompt = typeof metadata?.prompt === 'string' ? metadata.prompt : ''
-    if (!projectPrompt.trim()) {
-      fail(`Missing non-empty metadata.json prompt at ${metadataPath} for a prompt template that requires {prompt}.`)
-    }
-    promptText = promptText.replaceAll('{prompt}', projectPrompt)
-  }
-
-  if (reportPath) {
-    promptText = promptText.endsWith('\n')
-      ? `${promptText}\nOwner-required report path: write/save the final report exactly to \`${reportPath}\`.\n`
-      : `${promptText}\n\nOwner-required report path: write/save the final report exactly to \`${reportPath}\`.\n`
-  }
-
-  const unresolvedPlaceholders = [...promptText.matchAll(/\{[a-z_]+\}/g)].map((match) => match[0])
-  if (unresolvedPlaceholders.length > 0) {
-    fail(`Unsupported unresolved prompt placeholders remain: ${[...new Set(unresolvedPlaceholders)].join(', ')}`)
-  }
-
-  if (mode === 'rerun') {
-    promptText = promptText.endsWith('\n') ? `${promptText}\n${SAME_SESSION_RERUN_FOOTER}` : `${promptText}\n\n${SAME_SESSION_RERUN_FOOTER}`
-  }
-
-  const resolvedOutputPath = outputFile || defaultOutputPath
-  await writeFileIfNeeded(resolvedOutputPath, promptText)
-  process.stdout.write(`${resolvedOutputPath}\n`)
-} catch (error) {
-  fail(error instanceof Error ? error.message : String(error))
-}