@punks/cli 1.0.7 → 2.0.0-beta.1

package/dist/skills/agnostic/planning/goalify/EXAMPLES.md

@@ -0,0 +1,72 @@
+# Goalify Examples
+
+Use these as structure, not fixed templates. Keep the generated goal prompt matched to the user context.
+
+## Delivery-Style Goal
+
+```text
+/goal Deliver <objective> in <repo/path> without stopping until the implementation is reviewed, validated, and documented or a concrete blocker is proven.
+
+Scope:
+- repo/path: <path>
+- in scope: <bounded changes>
+- out of scope: <explicit non-goals>
+
+Use these skills/tools:
+- <skills/phases/tools named by context>
+
+Read first:
+- <handoff/spec/plan/issue paths>
+- repo AGENTS.md and relevant scoped AGENTS.md files
+
+Pinned context:
+- <architecture decisions, invariants, branch constraints>
+
+Workflow:
+1. Inspect read-first sources and confirm scope.
+2. Reuse or create required artifacts.
+3. Implement in checkpoints.
+4. Review changed work.
+5. Debug only when validation produces runtime evidence.
+6. Run docs ingest or record why it is not needed.
+
+Validation:
+- <exact commands/scenarios/artifacts>
+
+Stopping condition:
+- Done when <verifiable end state>.
+- Stop early only if <concrete blocker condition>.
+
+Progress reports:
+- Report current checkpoint, what was verified, what remains, and whether blocked.
+
+Final report:
+- Changed files, validation evidence, unresolved questions, and follow-up goals if split.
+```
+
+## Debugging-Style Goal
+
+```text
+/goal Debug <broken behavior> in <repo/path> until the failing scenario passes with evidence or a concrete external blocker is proven.
+
+Read first:
+- <logs/handoff/issues/specs>
+
+Inputs:
+- <recordings, commands, browser paths, fixtures>
+
+Workflow:
+1. Build an evidence matrix for expected vs observed behavior.
+2. Reproduce the failure with the closest existing harness.
+3. Inspect logs and runtime events before patching.
+4. Patch only the proven cause.
+5. Add or update focused regression coverage.
+6. Rerun the failing scenario and targeted tests.
+
+Validation:
+- <commands/scenarios/log evidence>
+
+Stopping condition:
+- Done when <scenario> passes and evidence shows <events/outputs>.
+- Stop early only if <missing input/access/external service blocker>.
+```

package/dist/skills/agnostic/planning/goalify/SKILL.md

@@ -0,0 +1,97 @@
+---
+name: goalify
+description: Compile messy intent, handoffs, issues, logs, specs, or notes into a ready-to-paste `/goal` prompt with a durable objective and verifiable stopping condition. Use when the user asks to goalify a task, write a goal prompt, prepare goal mode, or turn context into a long-running Codex goal.
+---
+
+# Goalify
+
+`goalify` is a prompt compiler. It produces a `/goal` prompt; it does not run the
+goal unless the user explicitly asks.
+
+## Use When
+
+- The user asks to "goalify", "write the goal prompt", "prepare a goal", or "turn this into a goal".
+- The input includes messy scope, handoffs, tracker issues, specs, plans, logs, recordings, evals, examples, or repo notes.
+- The work is long-running enough to need independent Codex progress across turns.
+- The desired output is a self-contained goal-mode contract.
+
+## Do Not Use When
+
+- The user wants immediate execution, not a prompt.
+- The task is tiny enough for one normal turn.
+- Requirements are still materially unresolved; use requirements discovery first.
+- You cannot name one objective, one stopping condition, and at least one validation signal.
+
+## Goal Criteria
+
+Every generated goal prompt must include:
+
+- one durable objective
+- exact repo, path, branch, worktree, or environment when known
+- scope and non-goals
+- read-first sources
+- relevant skills, tools, phases, or plugins from the supplied context
+- pinned constraints, invariants, and guardrails
+- workflow checkpoints
+- validation commands, scenarios, or artifacts
+- evidence expectations
+- stopping condition
+- early-stop or blocker conditions
+- progress-report expectations
+- final-report expectations
+
+## Workflow
+
+1. **Collect context.**
+   - Read supplied handoffs, issues, specs, plans, logs, examples, and scoped repo guidance when available.
+   - Preserve exact paths, issue ids, commands, URLs, recordings, and artifact names.
+   - If sources conflict, prefer repo/spec/log evidence over stale summaries.
+2. **Normalize the objective.**
+   - Reduce the request to one durable objective.
+   - Keep adjacent wishes as non-goals, follow-ups, or blocker conditions.
+   - If one objective cannot be named, ask one clarifying question instead of drafting.
+3. **Define proof.**
+   - Name what proves progress and what proves done.
+   - Prefer commands, test suites, browser checks, route generation, eval scores, scenario matrices, or log/event evidence.
+   - If proof is manual, state the exact human-verifiable scenario.
+4. **Compile the prompt.**
+   - Use [EXAMPLES.md](EXAMPLES.md) for structure.
+   - Include only context the future goal runner needs.
+   - Make the prompt self-contained enough to survive compaction.
+5. **Review before returning.**
+   - Confirm the prompt has one objective and one stopping condition.
+   - Confirm it says what to read first.
+   - Confirm it tells Codex when to stop early.
+   - Confirm validation is explicit, not "make sure it works".
+
+## Output Contract
+
+Return:
+
+1. A ready-to-paste `/goal ...` prompt in a fenced `text` block.
+2. A short note listing any assumptions or missing inputs.
+3. No execution, no file edits, no tracker updates, and no commits unless separately requested.
+
+## Prompt Sections
+
+Use these headings when they fit:
+
+- Objective
+- Scope
+- Use these skills/tools
+- Read first
+- Pinned context
+- Workflow
+- Validation
+- Stopping condition
+- Progress reports
+- Final report
+- Guardrails
+
+## Gotchas
+
+- Do not hardcode project-specific phase families; use the skills/phases named by the context.
+- Do not turn a backlog grab bag into one goal. Split or ask.
+- Do not bury the stopping condition near the end in vague prose.
+- Do not include secrets, private tokens, or unnecessary personal data.
+- Do not tell the future runner to mutate test inputs, recordings, fixtures, or handoffs unless the user explicitly asks.

package/dist/skills/agnostic/planning/implement-spec/SKILL.md

@@ -11,9 +11,9 @@ description: Implement an approved spec folder while keeping `IMPLEMENTATION-NOT
 - **Entrypoint type:** public entrypoint
 - **Upstream:** reviewed spec folder with `SPEC.md` and `PLAN.md`
 - **Delegates to:** `$tdd`, `$simplify`, and internal worker orchestration in parallel mode
-- **Downstream:** `docs-maintenance` when the resulting spec folder should be ingested into domain knowledge
+- **Downstream:** `docs-ingest-phase` when the resulting spec folder should be ingested into domain knowledge
 - **Entry conditions:** existing reviewed spec folder; stop and use `create-plan` if `PLAN.md` is missing
-- **Stop conditions:** shared acceptance audit complete, spec folder finalized, blocked work reported honestly
+- **Stop conditions:** shared acceptance audit complete, final manual review checklist written, spec folder finalized, blocked work reported honestly
 
 ## Required Inner Skills
 
@@ -45,7 +45,7 @@ That means `implement-spec` itself owns all of the following in parallel mode:
 5. Execute only the chosen mode. Do not mix modes inside one run.
 6. After each completed task or wave, update `PLAN.md`, `IMPLEMENTATION-NOTES.md`, and spec-linked tech debt before advancing.
 7. If backlog sync is in scope, keep epic/story bodies product-facing and use native metadata or comments instead of execution handoff rewrites.
-8. Finish with the shared acceptance audit and spec finalization contract.
+8. Finish with the shared acceptance audit, manual review checklist, and spec finalization contract.
 
 ## Mode selection
 

package/dist/skills/agnostic/planning/implement-spec/assets/IMPLEMENTATION-NOTES-TEMPLATE.md

@@ -28,6 +28,12 @@
 |-----------|--------|-------|
 | | | |
 
+## Manual Review Checklist
+
+| Area | Check | How to perform | Expected result |
+|------|-------|----------------|-----------------|
+| | | | |
+
 ## Pre-existing Issues
 
 - 

package/dist/skills/agnostic/planning/implement-spec/references/lifecycle.md

@@ -126,18 +126,38 @@ Re-read `SPEC.md` acceptance criteria and mark each one:
 
 Record a reason for every unmet or blocked item in `IMPLEMENTATION-NOTES.md`.
 
-## 11. Finalize the spec folder
+## 11. Write the manual review checklist
+
+Before finalization, `IMPLEMENTATION-NOTES.md` must contain `## Manual Review Checklist`.
+
+This section is a user handoff checklist, not an agent completion tracker. Derive it from completed tasks, `review_mode`, `tdd_target`, acceptance criteria, touched public surfaces, deviations, and risky integrations.
+
+Use exactly this table shape:
+
+| Area | Check | How to perform | Expected result |
+|------|-------|----------------|-----------------|
+
+Rules:
+
+- Browser or mixed review tasks must include concrete user flows to try end to end.
+- CLI review tasks must include exact commands, fixtures, or scenarios the user can rerun.
+- Include manual-only checks for product behavior, visual review, integration smoke, tracker/docs review, or anything automation cannot prove.
+- Empty checklist sections are invalid.
+- If no manual review applies, write one explicit row explaining why there is no user-verifiable surface.
+
+## 12. Finalize the spec folder
 
 Before reporting back:
 
 - remove empty sections from `IMPLEMENTATION-NOTES.md`
 - ensure **Execution mode** reflects the mode actually used
 - ensure **Sanity checks** lists only commands actually run
+- ensure **Manual Review Checklist** has at least one concrete row, or one explicit non-applicability row
 - ensure **Remaining work** matches any unmet or blocked criteria
 - set `SPEC.md` frontmatter `status: implemented`
 - set `PLAN.md` `**Status:** Complete` when that line exists
 
-## 12. Final report shape
+## 13. Final report shape
 
 Summarize:
 
@@ -145,5 +165,6 @@ Summarize:
 - validation results
 - key deviations or surprises
 - acceptance-criteria status
+- manual review checklist
 - blocked tasks needing input
 - whether the spec-linked tech-debt file was created or updated

package/dist/skills/agnostic/planning/resolve-debt-phase/SKILL.md

@@ -0,0 +1,87 @@
+---
+name: resolve-debt-phase
+description: Resolves one candidate or accepted tech debt item through validation, resolution spec creation, delivery, and closeout. Use when the user asks to resolve a tech debt entry, process a debt candidate, or continue from a canonical `docs/reference/tech-debt/<domain>/<spec>/<debt-slug>.md` artifact.
+---
+
+# Resolve Debt Phase
+
+## Contract
+
+- **Role:** public lifecycle entrypoint for one tech debt phase item
+- **Scope:** one candidate or accepted debt item, never generic debt management
+- **Canonical input:** `docs/reference/tech-debt/<domain>/<spec>/<debt-slug>.md`
+- **Source of truth:** debt file; backlog mirrors are secondary and may be stale
+- **Delegates to:** `$parallel-research` for independent readonly checks; `$create-spec` or equivalent spec workflow for accepted debt; `$delivery-phase` for implementation
+- **Stop conditions:** draft decision requested, accepted item handed to delivery, resolved item no-oped, or completed item marked resolved with links
+
+## Use When
+
+- The user provides or points to one tech debt artifact under `docs/reference/tech-debt/`.
+- The user asks to validate, accept, delete, or resolve one debt candidate.
+- The user asks to continue an accepted tech debt item into implementation.
+
+## Do Not Use When
+
+- Creating a broad debt register, backlog cleanup, or multi-item debt campaign.
+- Resolving normal feature work with no canonical debt file.
+- The backlog issue is the only artifact and no debt file can be found or created by the owning workflow.
+
+## Workflow
+
+1. Locate the debt file at `docs/reference/tech-debt/<domain>/<spec>/<debt-slug>.md`; stop if multiple items are implied.
+2. Read the debt file first and extract status, domain, originating spec, linked backlog mirror, evidence, and proposed resolution.
+3. Treat the debt file as canonical. Use backlog mirrors only to sync status or discover context.
+4. Branch by status: `draft`, `accepted`, or `resolved`. If missing or ambiguous, inspect context and ask before changing state.
+
+## Status Handling
+
+### `draft`
+
+Run readonly validation before asking for a lifecycle decision.
+
+1. Inspect the debt file.
+2. Inspect original `SPEC.md`, `PLAN.md`, `IMPLEMENTATION-NOTES.md`, review notes, and related docs.
+3. Inspect current code, tests, runtime logs, docs, and external evidence needed to prove whether the debt is real, stale, already fixed, or underspecified.
+4. Use `$parallel-research` when checks can run independently across code, docs, tests, runtime evidence, or external sources.
+5. Synthesize evidence with citations to local files, commands, logs, or sources.
+6. Ask the user to choose exactly one: accept, delete, or authorize more research.
+
+Do not create a resolution spec from a `draft` item until the user accepts it.
+
+### `accepted`
+
+Move the one accepted item toward delivery.
+
+1. Create or update a debt-resolution spec tied to the original domain/spec and debt slug.
+2. The resolution spec must state the initial debt, why it matters, the bounded fix, non-goals, acceptance checks, and closeout requirements.
+3. Run `$delivery-phase` against that resolution spec.
+4. Keep implementation work scoped to resolving the accepted item, not adjacent cleanup.
+
+### `resolved`
+
+No-op by default.
+
+- Report that the item is already resolved.
+- Include the resolution spec and implementation notes links if present.
+- Inspect history only when the user explicitly asks.
+
+## After Delivery
+
+When delivery finishes:
+
+1. Update the debt file status to `resolved`.
+2. Link the resolution spec.
+3. Link implementation notes or final delivery evidence.
+4. Record validation commands and outcomes.
+5. Sync the backlog mirror when available, without treating it as source of truth.
+6. Report any residual follow-up as new debt only if it is distinct from the resolved item.
+
+## Output Contract
+
+Always report:
+
+- debt file path and status before/after
+- evidence inspected or validation performed
+- decision requested for `draft`, handoff/result for `accepted`, or no-op reason for `resolved`
+- resolution spec and implementation notes links when present
+- backlog mirror sync outcome when available

package/dist/skills/agnostic/requirements/requirements-grill/SKILL.md

@@ -1,11 +1,11 @@
 ---
 name: requirements-grill
-description: Runs rigorous requirements grilling, persists branch decisions, and optionally synthesizes high-level wiki knowledge. Use when the user wants a long design interview, product/architecture requirements discovery, branch-by-branch decision closure, compaction-safe grill logs/status updates, or wiki synthesis from grilled requirements.
+description: Runs rigorous requirements grilling, pins glossary/axiom decisions, persists branch decisions, and optionally synthesizes high-level wiki knowledge. Use when the user wants a long design interview, product/architecture requirements discovery, branch-by-branch decision closure, canonical terminology, compaction-safe grill logs/status updates, or wiki synthesis from grilled requirements.
 ---
 
 # Requirements Grill
 
-Use this skill to turn uncertain product, architecture, or implementation ideas into pinned requirements that can feed backlog/user-story creation.
+Use this skill to turn uncertain product, architecture, or implementation ideas into pinned requirements, canonical glossary, and domain axioms that can feed backlog/user-story creation.
 
 This skill has three scoped references:
 
@@ -21,7 +21,7 @@ Use wiki synthesis when the user asks to persist closed grill decisions into `ap
 
 Both workflows can happen in one long session, but keep the responsibilities distinct:
 
-- `docs/<topic>-grill-log.md` and `docs/<topic>-grill-status.md` are the detailed requirements record
+- `docs/<topic>-grill-log.md` and `docs/<topic>-grill-status.md` are the detailed requirements and glossary record
 - `apps/wiki/domains/` is synthesized domain knowledge
 - backlog/user-story creation is the next phase after the grill gate, outside this skill's scope
 
@@ -31,6 +31,7 @@ Both workflows can happen in one long session, but keep the responsibilities dis
 - For every question, provide a recommended answer and the reason for it.
 - Inspect code/docs first when the answer can be found locally.
 - Challenge conflicting glossary, vague terms, and hidden tradeoffs immediately.
+- Pin canonical terms, rejected aliases, relationships, and domain axioms as decisions crystallize.
 - Prefer conservative defaults once enough context exists.
 - If the user authorizes auto-pinning defaults, close obvious remaining decisions without needless extra questions.
 - Treat parked branches as preserved knowledge, not deleted scope.

package/dist/skills/agnostic/requirements/requirements-grill/references/artifact-output.md

@@ -12,7 +12,7 @@ At the start of a serious grilling session, create or reuse:
 - `docs/<topic>-grill-status.md`
 
 The log is the durable decision record.
-The status file is the current branch dashboard.
+The status file is the current branch dashboard plus the current glossary snapshot.
 
 ## Grill Log Contract
 
@@ -34,6 +34,23 @@ Group related decisions under branch headings.
 
 When the user changes an earlier decision, add a new entry that explicitly supersedes the old one.
 
+Record glossary decisions in the log when terms or axioms are first pinned:
+
+```md
+### Glossary Q<N>
+
+Question:
+<terminology or axiom question>
+
+Accepted answer:
+- Canonical term: **<Term>** — <one-sentence definition>
+- Avoid: <alias>, <alias>
+- Relationship: **<Term>** <relationship> **<Other Term>**
+- Axiom: <domain invariant that should not be re-debated>
+```
+
+Omit unused fields. If a later answer changes the glossary, add a superseding entry instead of rewriting history.
+
 ## Status File Contract
 
 Maintain a compact branch dashboard with:
@@ -43,6 +60,9 @@ Maintain a compact branch dashboard with:
 - locked direction
 - still-open items
 - parked branches
+- glossary snapshot
+- pinned axioms
+- flagged ambiguities
 
 Completion percentages are working signals:
 
@@ -52,12 +72,46 @@ Completion percentages are working signals:
 - `100%`: design closed; remaining work is implementation/tuning
 - `parked`: preserved for later, out of current scope
 
+## Glossary Snapshot Contract
+
+Keep the status file glossary compact and current:
+
+```md
+## Glossary
+
+### Terms
+
+- **<Term>**: <one-sentence definition>
+  Avoid: <alias>, <alias>
+
+### Relationships
+
+- **<Term>** belongs to exactly one **<Other Term>**
+
+### Axioms
+
+- <Domain invariant accepted during the grill>
+
+### Flagged Ambiguities
+
+- "<ambiguous word>" was used to mean both **<Term A>** and **<Term B>**. Resolution: <decision>.
+```
+
+Rules:
+
+- Be opinionated: pick one canonical term.
+- Keep definitions to one sentence.
+- Include only terms meaningful to product/domain experts in this grill.
+- Prefer status-file updates for the current glossary; use log entries for the decision trail.
+- Group terms under subheadings only when clusters are natural.
+- Add a short example dialogue only when it clarifies a boundary that keeps recurring.
+
 ## Branch Closure
 
 When a branch closes:
 
 1. Update the grill log with final accepted decisions.
-2. Update the status file percentage and open items.
+2. Update the status file percentage, open items, glossary snapshot, axioms, and ambiguities.
 3. If the branch changes durable domain/product knowledge, run the wiki-output workflow.
 4. Say exactly what changed and which artifacts were updated.
 

package/dist/skills/agnostic/requirements/requirements-grill/references/grilling-flow.md

@@ -27,14 +27,15 @@ Walk the design tree branch by branch until each branch is:
 
 Challenge glossary:
 
-- If a term conflicts with existing specs, docs, or code language, call it out.
-- Propose the canonical term.
-- Make the user choose.
+- If a term conflicts with existing specs, docs, code language, or the grill status glossary, call it out.
+- Propose one canonical term and the aliases to avoid.
+- Make the user choose, then update the glossary sections in the grill artifacts.
 
 Sharpen vague language:
 
 - Identify overloaded words.
-- Replace fuzzy language with explicit states, enum values, ownership boundaries, or lifecycle rules.
+- Replace fuzzy language with explicit terms, states, enum values, ownership boundaries, lifecycle rules, or domain axioms.
+- When the user decides an invariant that should not be re-debated, capture it as an axiom.
 
 Discuss concrete scenarios:
 
@@ -46,6 +47,17 @@ Cross-check with code:
 - Verify user claims against local code when possible.
 - Surface contradictions instead of smoothing them over.
 
+## Glossary Discipline
+
+Keep glossary pressure inside the active grill loop:
+
+- Only add project/domain-specific terms; skip generic programming words.
+- Define what the term is in one sentence, not how it is implemented.
+- Record avoided aliases when competing words exist.
+- Record relationships between terms, including cardinality when obvious.
+- Record flagged ambiguities with the resolution that closed them.
+- Treat glossary corrections from the user as authoritative and update the artifacts immediately.
+
 ## Conservative Closure
 
 When the user asks to reduce scope or stop widening the design:

package/dist/skills/agnostic/requirements/requirements-grill/references/wiki-output.md

@@ -14,6 +14,7 @@ Read status first to understand:
 - active and parked branches
 - branch completion
 - current locked direction
+- current glossary, relationships, axioms, and flagged ambiguities
 - remaining non-design validation work
 
 Read log second to extract:
@@ -22,12 +23,13 @@ Read log second to extract:
 - superseded decisions
 - branch closure notes
 - exact canonical terms
+- why glossary or axiom choices changed
 
 ## Ownership
 
 `requirements-grill` owns wiki synthesis from grilled requirements.
 
-`docs-maintenance` owns formal spec ingest and ordinary docs upkeep.
+`docs-ingest-phase` owns formal spec ingest and ordinary docs upkeep.
 
 ## What Belongs In Wiki
 
@@ -38,6 +40,8 @@ Good wiki targets:
 - product scope
 - user-visible modes and behaviors
 - high-level features
+- canonical domain glossary and relationships
+- domain axioms that constrain future design
 - conversation model
 - lifecycle concepts
 - memory model
@@ -79,7 +83,7 @@ Keep `docs/` as the detailed design record.
 Use `apps/wiki/domains/` for synthesized domain knowledge.
 
 Do not duplicate the full grill log in wiki pages.
-Summarize stable meaning and link back to source docs when useful.
+Summarize stable meaning, glossary, and axioms; link back to source docs when useful.
 
 ## Bookkeeping
 

package/dist/skills/agnostic/requirements/requirements-phase/SKILL.md

@@ -0,0 +1,67 @@
+---
+name: requirements-phase
+description: Orchestrates the human-centric requirements phase from ambiguity through requirements-grill artifacts into backlog shape. Use when the user asks to run a requirements phase, move from discovery to backlog, close requirement branches, decide whether backlog writing is ready, or coordinate requirements-grill with write-backlog.
+---
+
+# Requirements Phase
+
+Human-centric discovery wrapper for `requirements-grill -> write-backlog`.
+
+Normally do not create or update a formal agent goal. This phase is an interview and decision-closure loop, not execution delivery.
+
+## Use when
+
+- The user asks for a requirements phase, requirements discovery, or backlog readiness.
+- Ambiguity needs to become grill branches, glossary, axioms, parked scope, and closure decisions.
+- Existing `*-grill-status.md` / `*-grill-log.md` artifacts need to drive backlog/module/epic/story shape.
+- The user wants to know whether to keep grilling, park scope, or write/sync backlog.
+
+## Do not use when
+
+- The user asks to write `SPEC.md`, `PLAN.md`, implementation notes, code, tests, PRs, or delivery execution.
+- The next step is already an approved spec/plan/implementation task. Use delivery-phase or the specific delivery skill instead.
+- The user wants only a tactical backlog formatting pass from already-closed requirements. Use `write-backlog` directly.
+
+## Workflow
+
+1. Establish phase state.
+   - Identify the topic, source artifacts, current backlog target/provider, and any explicit scope boundary.
+   - If grill artifacts exist, read status first, then log.
+   - State assumptions and known unresolved branches tersely.
+
+2. Route to `requirements-grill` while decisions are open.
+   - Let `requirements-grill` own HITL interviewing.
+   - Ask one question at a time with a recommended answer and why.
+   - Turn ambiguity into named branches, branch percentages, accepted decisions, rejected/superseded decisions, glossary entries, axioms, and parked scope.
+   - Do not write backlog while major branches remain open unless the user explicitly parks them.
+
+3. Decide backlog readiness.
+   - Backlog-ready means active branches are closed enough for module/epic/story shaping, and unresolved branches are either non-blocking, explicitly parked, or recorded as follow-up scope.
+   - If not ready, continue grilling or report the exact blocker branches.
+   - If ready, hand off to `write-backlog`.
+
+4. Run `write-backlog` only after readiness.
+   - Derive modules first, then epics/capabilities, then stories.
+   - Use accepted decisions and locked direction only.
+   - Preserve parked scope and unresolved items as deferred notes, not silent backlog content.
+   - Sync or draft provider payloads only when the user requested backlog write/sync.
+
+5. Stop at the requirements boundary.
+   - Do not create specs, plans, implementation tasks, or code changes from this phase.
+   - Recommend delivery-phase only after backlog state is clear.
+
+## Output contract
+
+End with one of these states:
+
+- `backlog-ready`: branches closed or parked enough; backlog can be written next.
+- `backlog-written`: backlog hierarchy/payloads were produced or synced.
+- `parked`: requirements are intentionally unresolved; parked scope and resume trigger are explicit.
+- `blocked`: named branches still need human decisions before backlog writing.
+
+Include:
+
+- active, closed, parked, and unresolved branches
+- glossary and axiom changes, if any
+- backlog module/epic/story implications, if known
+- next recommended action: continue grill, write/sync backlog, park, or move to delivery-phase