# Self-Test Mode

If the repo root contains `.fixture-meta.json` and `.fixture-seed-prompt.txt`,
treat the run as a **fixture self-test**.

In self-test mode:

1. Read `.fixture-seed-prompt.txt` before asking any questions.
2. Treat the approved design summary and Phase 1 answers from the fixture input
   as already approved by the human, unless a safety-critical ambiguity remains.
3. Do NOT open a fresh brainstorming or design-approval loop.
4. Do NOT read unrelated meta-skills such as `brainstorming` during the fixture run.
   The approved design summary already satisfies that requirement.
5. For greenfield fixture runs, install only the manifest-declared shipped sub-skills by copying them as-is.
   Do NOT read every sub-skill file before generation unless validation later proves
   one of them must be inspected to fix a concrete failure.
6. Complete **Phase 0 through Phase 4 only**. Do NOT enter Phase 5.
7. Keep context tight:
   - Read only the templates needed for the next concrete generation step.
   - If both `.fixture-scaffold-values.json` and `tools/render-scaffold.mjs` are present, do NOT open `.tmpl` files before the first renderer invocation.
   - Prefer generating core docs/scripts first, then validating, before inspecting optional details.
   - Do NOT recursively enumerate every file under `.agents/skills/project-scaffold/` during fixture discovery.
     Treat the installed skill bundle as trusted input; open specific templates by path when needed.
   - Do NOT exhaustively dump every template file before writing if the fixture
     constraints already determine the scaffold shape.
8. Use fixture runs to test scaffold behavior, not to invent project features.

## Self-test fast path for greenfield fixtures

If self-test mode is active and Phase 0 discovery shows a greenfield repo with no
existing scaffold docs, no dependency manifests, and no runnable app surface:

1. Read only these repo files first:
   - `README.md`
   - `.fixture-meta.json`
   - `.fixture-seed-prompt.txt`
   - `.fixture-scaffold-values.json` (if present)
2. If `.fixture-meta.json` contains a `template_read_plan` or `generation_order`,
   follow those lists directly instead of discovering your own read order.
3. Write the Discovery Report from those inputs plus the repo root listing.
4. Record the approved Phase 1 answers from the fixture input without asking again.
5. Decompose milestones immediately, with the initial milestone focused on the missing verification capability and current repo constraints.
6. Generate the scaffold in this order:
   - `AGENTS.md`
   - `docs/project_spec.md`
   - `docs/plan.md`
   - `docs/prompt.md`
   - `docs/implement.md`
   - `docs/documentation.md`
   - `docs/failures/taxonomy.md`
   - `docs/compaction-strategy.md`
   - `docs/feedback-profile.json`
   - `docs/harness-manifest.json`
   - the primary `scripts/validate-docs.*` and `scripts/quality-gates.*` pair for the repo's primary shell
   - install only the sub-skills declared in `docs/harness-manifest.json` into `.agents/skills/`
7. Only after those files are written, run validation and inspect any template or
   sub-skill source needed to fix a concrete validation failure.

If `.agents/skills/project-scaffold/tools/render-scaffold.mjs` is present, prefer:

1. Start from `.fixture-scaffold-values.json` when it exists; otherwise create one scaffold values JSON file with the resolved placeholders.
2. Run the renderer once to materialize the manifest-declared docs/scripts.
3. Validate and patch only the concrete failures that remain.
4. Treat any `template_read_plan` from fixture metadata as a fallback-only recovery path after a concrete render or validation failure, not as a required pre-render checklist.

This fast path exists to keep fixture self-tests focused on generation and validation,
not on redundant exploration of the installed skill bundle.

## Self-test fast path for messy-existing fixtures

If self-test mode is active and the repo already contains scaffold-like docs
such as `AGENTS.md`, `docs/plan.md`, or `docs/prompt.md`:

1. Read the existing repo evidence before generating replacements:
   - `README.md`
   - `AGENTS.md` (if present)
   - `docs/plan.md` (if present)
   - `docs/prompt.md` (if present)
   - `.fixture-meta.json`
   - `.fixture-seed-prompt.txt`
2. Classify those docs as `healthy`, `salvageable`, `stale`, or `redundant`
   before opening templates or running the renderer.
3. If a doc is `stale`, archive the old version into `docs/archive/` with a
   dated filename before rendering a replacement.
4. If a doc is `healthy`, preserve it unless discovery proves it is inaccurate.
5. Only after the audit and any required archiving should you update scaffold
   values, run the renderer, or patch the generated outputs.

This path exists so fixture self-tests exercise real reorganize behavior instead
of silently treating an existing repo like a blank slate.
