@fernado03/zoo-flow 0.11.1 → 0.11.3

package/docs/philosophy.md

@@ -1,73 +0,0 @@
-# Philosophy
-
-Zoo Flow is built around a small number of opinions. They are listed here so
-you can decide whether the template is a good fit before you adopt it.
-
-## 1. The router should not write code
-
-Most failure modes in agentic coding come from a single agent trying to do
-three jobs at once: deciding what to do, planning how to do it, and doing
-it. Zoo Flow splits those into three modes and refuses to collapse them.
-
-- `custom-orchestrator` decides **what** to do, by mapping a request to a
-  command from a fixed routing matrix.
-- `system-architect` decides **how** to do it, in Markdown.
-- `code-tweaker` does it.
-
-The orchestrator has no `read`, `edit`, `command`, or `mcp` tool groups.
-It cannot freelance into implementation work even if it wants to.
-
-## 2. Slash commands are the public API
-
-Free-form requests are fine, but the moment work starts, it goes through a
-slash command. Commands are the only way the orchestrator delegates and
-the only way modes know which workflow they are running.
-
-This has two payoffs:
-
-- A command name in chat is a checkable artifact. You can grep your history
-  for `/fix` or `/feature` and know exactly which workflow ran.
-- Each command file is a single, readable place to change behavior. No
-  hunting through prompts.
-
-Commands live at `templates/full/.roo/commands/{command}.md` and are loaded
-through the protocol described in
-[`architecture.md`](architecture.md#command-protocol).
-
-## 3. Path safety beats cleverness
-
-Skills always live at `templates/full/.roo/skills/{bucket}/{skill}/SKILL.md`.
-Never under `.roo/rules/`. Never relative to the command file. Never invented
-by the model.
-
-This is enforced by `00-paths.md`, which ships as an always-on rule. If a
-skill path drifts, the rule catches it. The cost is one rule file. The
-benefit is no more `ENOENT` rabbit holes.
-
-## 4. Same-window switches for tight loops, `new_task` for clean boundaries
-
-There are two delegation primitives in Zoo Code:
-
-- `switch_mode` keeps the same task window and hands the keyboard to a
-  different mode. Cheap. Good for `/fix` going architect → tweaker → architect.
-- `new_task` opens a delegated subtask with its own window. Expensive. Good
-  for orchestrator handing real work to architect or tweaker.
-
-Zoo Flow uses both, deliberately. The orchestrator only ever uses
-`new_task`. Modes only ever use `switch_mode`. They never cross.
-
-## 5. HITL hard stops are features
-
-Several commands force a halt. `/feature` halts after sharpening, after
-prototype, after PRD, after issues. `/fix` halts after diagnosis. The git
-flow halts before commit. These are not friction; they are the points
-where a human review is cheaper than a rollback.
-
-## 6. The skill set is replaceable
-
-The bundled skills are a starting point. You should expect to delete some,
-add some, and rename a bucket. The control plane — modes, commands, rules —
-is the part that should be stable.
-
-If a skill cannot be invoked through a command, it does not belong in the
-template.

package/docs/quality-scorecard.md

@@ -1,23 +0,0 @@
-# Quality Scorecard
-
-Zoo Flow uses a deterministic rule-based quality scorecard to gate releases. Every
-category must score >= 9.5/10 for `release:check` to pass.
-
-## Categories
-
-| Category | Weight | What it measures |
-|---|---|---|
-| command_integrity | 20% | Every command has a correct `mode:` declaration matching the command-policy map. Required rules exist. Routing table is in sync. |
-| skill_quality | 20% | Skills use canonical `Skill:` marker. Referenced skills exist. Skills have purpose, steps, and output format. No thin wrappers. Bucket layout. |
-| validation_depth | 20% | Doctor validates files, skill refs, mode slugs, built-in bans, .roomodes permission, routing rows, old-doc leakage, ADR path consistency. |
-| token_economy | 10% | Context-economy rule exists. Domain-doc read gate. Completion evidence format. Risk-based routing. |
-| verification | 10% | Verify command + skill with evidence output and no-claim-unless-run rule. Fixture tests. Routing evals. Package-link check. |
-| review_process | 10% | Review command + skill with standards/spec/Security-Risk axes. Severity-ordered findings. Canonical result line. |
-| release_readiness | 10% | `release:check` runs all validation scripts. Score thresholds enforced. `npm pack --dry-run` passes. |
-
-## How scoring works
-
-- Each category defines specific checks (see `quality/scorecard.json`).
-- Each check is pass/fail. Missing items reduce the category score toward 0.
-- The weighted composite score must be >= 9.5 for `npm run release:check` to pass.
-- Scoring is fully deterministic — no AI grading, no subjective evaluation.

package/docs/skill-maintenance.md

@@ -1,32 +0,0 @@
-# Skill maintenance policy
-
-This is repo-maintenance policy for the bundled skill set. It does not
-need to be in the model's context on every turn, so it lives in `docs/`
-rather than `.roo/rules/`. The runtime path-safety contract is in
-[`templates/full/.roo/rules/00-paths.md`](../templates/full/.roo/rules/00-paths.md).
-
-## Skill bucket layout
-
-Skills are organized into bucket folders under `.roo/skills/`:
-
-- `.roo/skills/engineering/` — daily code work
-- `.roo/skills/productivity/` — daily non-code workflow tools
-- `.roo/skills/misc/` — kept around but rarely used
-- `.roo/skills/personal/` — tied to a maintainer's setup, not promoted
-- `.roo/skills/in-progress/` — drafts not yet ready to ship
-- `.roo/skills/deprecated/` — no longer used
-
-## Promotion rules
-
-Skills in `.roo/skills/personal/`, `.roo/skills/in-progress/`, and
-`.roo/skills/deprecated/` must not appear in the top-level `README.md`
-as promoted skills. They may appear in internal indexes only when
-clearly marked as personal, in-progress, or deprecated.
-
-Every skill in `.roo/skills/engineering/`, `.roo/skills/productivity/`,
-or `.roo/skills/misc/` must have a reference in the top-level
-`README.md`.
-
-Each bucket folder has a `README.md` that lists every skill in the
-bucket with a one-line description, with the skill name linked to its
-`SKILL.md`.

package/docs/skills-index.md

@@ -1,64 +0,0 @@
-# Skills Index
-
-This is human-facing reference documentation for Zoo Flow skills.
-
-It is intentionally kept outside `.roo/rules/` because Zoo Code loads
-`.roo/rules/` automatically on every turn.
-
-Commands load skills directly from explicit `.roo/skills/.../SKILL.md`
-paths, so this index is not required for runtime execution.
-
-## engineering
-
-| Skill | Path |
-|---|---|
-| `commit-and-document` | `.roo/skills/engineering/commit-and-document/SKILL.md` |
-| `diagnose` | `.roo/skills/engineering/diagnose/SKILL.md` |
-| `grill-with-docs` | `.roo/skills/engineering/grill-with-docs/SKILL.md` |
-| `improve-codebase-architecture` | `.roo/skills/engineering/improve-codebase-architecture/SKILL.md` |
-| `prototype` | `.roo/skills/engineering/prototype/SKILL.md` |
-| `review` | `.roo/skills/engineering/review/SKILL.md` |
-| `scaffold-context` | `.roo/skills/engineering/scaffold-context/SKILL.md` |
-| `setup-matt-pocock-skills` | `.roo/skills/engineering/setup-matt-pocock-skills/SKILL.md` |
-| `tdd` | `.roo/skills/engineering/tdd/SKILL.md` |
-| `to-issues` | `.roo/skills/engineering/to-issues/SKILL.md` |
-| `to-prd` | `.roo/skills/engineering/to-prd/SKILL.md` |
-| `triage` | `.roo/skills/engineering/triage/SKILL.md` |
-| `tweak` | `.roo/skills/engineering/tweak/SKILL.md` |
-| `update-docs` | `.roo/skills/engineering/update-docs/SKILL.md` |
-| `verify` | `.roo/skills/engineering/verify/SKILL.md` |
-| `zoom-out` | `.roo/skills/engineering/zoom-out/SKILL.md` |
-
-## productivity
-
-| Skill | Path |
-|---|---|
-| `caveman` | `.roo/skills/productivity/caveman/SKILL.md` |
-| `grill-me` | `.roo/skills/productivity/grill-me/SKILL.md` |
-| `handoff` | `.roo/skills/productivity/handoff/SKILL.md` |
-| `write-a-skill` | `.roo/skills/productivity/write-a-skill/SKILL.md` |
-
-## misc
-
-| Skill | Path |
-|---|---|
-| `git-guardrails-claude-code` | `.roo/skills/misc/git-guardrails-claude-code/SKILL.md` |
-| `migrate-to-shoehorn` | `.roo/skills/misc/migrate-to-shoehorn/SKILL.md` |
-| `scaffold-exercises` | `.roo/skills/misc/scaffold-exercises/SKILL.md` |
-| `setup-pre-commit` | `.roo/skills/misc/setup-pre-commit/SKILL.md` |
-
-## personal _(not promoted)_
-
-| Skill | Path |
-|---|---|
-| `edit-article` | `.roo/skills/personal/edit-article/SKILL.md` |
-| `obsidian-vault` | `.roo/skills/personal/obsidian-vault/SKILL.md` |
-
-## in-progress _(drafts)_
-
-| Skill | Path |
-|---|---|
-| `teach` | `.roo/skills/in-progress/teach/SKILL.md` |
-| `writing-beats` | `.roo/skills/in-progress/writing-beats/SKILL.md` |
-| `writing-fragments` | `.roo/skills/in-progress/writing-fragments/SKILL.md` |
-| `writing-shape` | `.roo/skills/in-progress/writing-shape/SKILL.md` |

package/docs/team-mode.md

@@ -1,46 +0,0 @@
-# Team Mode
-
-Zoo Flow separates local agent runtime config from shared project knowledge.
-
-## Local/private
-
-Usually gitignored:
-
-- `.roo/`
-- `.roomodes`
-- `.zoo-flow/`
-- `.scratch/`
-- `docs/journal/`
-
-These files are local because different users may have different Zoo Code setups, different installed skills, and different scratch context.
-
-## Shared/committed
-
-Usually committed:
-
-- `AGENTS.md`
-- `CONTRIBUTING.md`
-- `docs/agents/`
-- `docs/architecture/`
-- `docs/adr/`
-- `README.md`
-
-Project knowledge should be promoted into shared docs when it affects the team.
-
-## When to promote local context
-
-Promote `.zoo-flow/CONTEXT.md` or `.zoo-flow/docs/adr/` into shared docs when:
-
-- multiple people need the same terminology
-- architecture decisions affect future work
-- the agent repeatedly needs the same project knowledge
-- onboarding would improve from committed docs
-
-## Suggested shared layout
-
-- `AGENTS.md`
-- `docs/agents/issue-tracker.md`
-- `docs/agents/triage-labels.md`
-- `docs/agents/domain.md`
-- `docs/architecture/`
-- `docs/adr/`

package/docs/token-budget.md

@@ -1,22 +0,0 @@
-# Token Budget
-
-Zoo Flow enforces tiered token budgets to prevent bloat. Each tier has a
-maximum byte size. Files exceeding their tier must have an explicit
-exception in `quality/token-budget.exceptions.json`.
-
-## Tiers
-
-| Tier | Paths | Budget |
-|---|---|---|
-| Tier 1 — Rules | `.roo/rules/`, `.roo/rules-{mode}/` | 16 KB |
-| Tier 2 — Commands | `.roo/commands/` | 8 KB |
-| Tier 3 — Skills | `.roo/skills/` | 32 KB |
-| Tier 4 — Config | `.roomodes` | 4 KB |
-| Tier 5 — Docs | `docs/` | 64 KB |
-| Tier 6 — Evidence | `.zoo-flow/evals/` | 8 KB |
-
-## Exceptions
-
-Add to `quality/token-budget.exceptions.json` with a reason and max byte
-override. Exceptions must be justified (e.g., single-file bundle docs
-are inherently large).

package/docs/troubleshooting.md

@@ -1,288 +0,0 @@
-# Troubleshooting
-
-Common failure modes and their fixes. Each section starts with the
-symptom you will actually see in chat or in tool output.
-
-> **Where rules live, in one paragraph.** Global rules that apply to
-> every mode are in `.roo/rules/`. Mode-specific behavior is in
-> `.roo/rules-{modeSlug}/` — `rules-custom-orchestrator/`,
-> `rules-system-architect/`, `rules-code-tweaker/`. `.roomodes` is
-> minimal and points at those folders. Zoo Flow uses the preferred
-> `.roo/rules-{modeSlug}/` directory form only; legacy single-file
-> fallbacks such as `.roorules-{modeSlug}` and `.clinerules-{modeSlug}`
-> are not used by this template. See [`mode-rules.md`](mode-rules.md)
-> for the full layout.
-
-## `.roo/rules/skills/...` ENOENT
-
-**Symptom**
-
-A mode tries to read a path like
-`.roo/rules/skills/engineering/tweak/SKILL.md` and you get
-`ENOENT: no such file or directory`.
-
-**Cause**
-
-A skill path drifted under `.roo/rules/`. Skills always live at
-workspace-root `.roo/skills/...`. The most common triggers:
-
-- A command file referenced a skill via a path that started with
-  `.roo/rules/`.
-- The mode resolved the skill path relative to the location of the
-  rules file instead of the workspace root.
-- A model "helpfully" rewrote the path because it thought rules and
-  skills should sit together.
-
-**Fix**
-
-1. Confirm `templates/full/.roo/rules/00-paths.md` is present and that
-   the rules loader picks up `.roo/rules/*.md`. If you copied only some
-   of the rules into your workspace, copy the rest.
-2. Open the offending command file under
-   `templates/full/.roo/commands/` and check the `Run skill:` line. The
-   path must look like:
-
-   ```
-   .roo/skills/{bucket}/{skill}/SKILL.md
-   ```
-
-   Not:
-
-   ```
-   .roo/rules/skills/{bucket}/{skill}/SKILL.md
-   ```
-
-If you cannot find a stale reference and the model still produces this
-path, paste the rules in `00-paths.md` directly into the chat as a
-reminder, then file an issue with the chat transcript.
-
-## `new_task` missing in orchestrator
-
-**Symptom**
-
-The orchestrator says it cannot delegate, or it tries to do
-implementation work itself, or it switches mode (which it should never
-do).
-
-**Cause**
-
-The orchestrator's tool groups in `.roomodes` are `[]` — that is correct
-— but the host UI has not exposed `new_task` to it. Some UIs only enable
-`new_task` when at least one tool group is present.
-
-**Fix**
-
-1. Confirm `templates/full/.roomodes` has not been edited to add
-   read/edit/command/mcp groups for `custom-orchestrator`. The empty
-   groups list is intentional.
-2. In Zoo Code settings, confirm subtasks (sometimes called
-   "delegated tasks" or "Boomerang tasks") are enabled.
-3. If subtasks are disabled in the host, the orchestrator's correct
-   behavior is to stop and report. That is what rule 4 of its
-   `customInstructions` says. Do not work around this by giving it more
-   tool groups.
-
-## `run_slash_command` disabled
-
-**Symptom**
-
-The mode reports that it cannot run the slash command, or it falls back
-to running the command file but seems unsure.
-
-**Cause**
-
-`run_slash_command` is an experimental tool in Zoo Code and must be
-enabled in settings before it is available. When it is not enabled,
-or when the host UI does not expose it, the command protocol expects the
-mode to fall back gracefully.
-
-**Fix**
-
-1. Confirm `templates/full/.roo/rules/01-command-protocol.md` is loaded.
-   It is the rule that tells the mode what to do.
-2. Step 3 of the protocol is the fallback: read
-   `templates/full/.roo/commands/{command}.md` directly and execute it.
-   If the mode does not do this, the rule is not in context.
-3. `run_slash_command` is experimental and must be enabled in Zoo Code
-   settings. Zoo Flow still works without it because its command
-   protocol falls back to reading `.roo/commands/{command}.md` directly.
-   That fallback is a first-class path, not a workaround.
-
-## Architect trying to edit source
-
-**Symptom**
-
-The architect tries to write to a `.ts`, `.py`, or other source file
-and either gets refused by the host or silently writes a Markdown file
-"about" the change instead of the change itself.
-
-**Cause**
-
-Either:
-
-- The architect's `edit` `fileRegex` in `.roomodes` was loosened beyond
-  Markdown, `.scratch/`, and `docs/`, or
-- The architect ignored its rule 2 ("NO IMPLEMENTATION CODING") and
-  tried to edit anyway.
-
-**Fix**
-
-1. Restore the regex in `.roomodes`. The shipped form is:
-
-   ```json
-   { "fileRegex": "(.*\\.md$|^\\.scratch/.*|^docs/.*)" }
-   ```
-
-2. The correct architect behavior is to summarize the implementation
-   work and `switch_mode` to `code-tweaker` in the same task window.
-   If the work is part of a delegated subtask, the architect uses
-   `attempt_completion` instead — but only when the delegation contract
-   actually expected a planning result, not implementation.
-3. If the architect keeps trying to edit source, paste the relevant
-   line from the architect's `customInstructions` directly into chat.
-
-## Prototype running in the wrong mode
-
-**Symptom**
-
-During `/feature`, the architect runs a prototype directly: edits source
-files, starts a dev server, or builds UI scaffolding. Or, the tweaker
-ends up doing PRD or sharpening work instead of the prototype.
-
-**Cause**
-
-Phase 2 of `/feature` is "the architect summarizes the prototype
-question and switches to `code-tweaker` to run `/prototype`". If the
-architect skips the switch, it ends up doing implementation work it
-cannot do safely. If the orchestrator routes `/prototype` directly to
-`system-architect`, the chain is broken.
-
-**Fix**
-
-1. Open `templates/full/.roo/commands/feature.md` and confirm phase 2
-   reads:
-
-   - Architect summarizes the prototype question.
-   - Architect MUST `switch_mode` -> `code-tweaker`.
-   - Tweaker executes `/prototype`.
-   - Tweaker MUST `switch_mode` -> `system-architect` with result.
-
-2. Confirm the routing matrix in `.roomodes` lists `/prototype` under
-   `code-tweaker`, not `system-architect`.
-3. If the architect refuses to switch, paste rule 3 from its
-   `customInstructions` ("FEATURE PROTOTYPES") into chat. It is the
-   single most-violated rule in practice.
-
-## Slash command leakage from subtask summaries
-
-**Symptom**
-
-A subtask's `attempt_completion` summary contains a line like
-"Recommended next command: `/refactor`". The orchestrator then
-launches `/refactor` immediately, without you typing it.
-
-**Cause**
-
-The orchestrator's rule 2 ("EXPLICIT COMMANDS") is being ignored.
-Slash commands inside a subtask summary are guidance for *you*, not
-authorization for the orchestrator to launch a new subtask.
-
-**Fix**
-
-1. Open `.roomodes`. Confirm rule 2 of `custom-orchestrator` reads:
-   "If the HUMAN USER explicitly types a supported slash command,
-   delegate it directly using the Routing Matrix. **Ignore slash
-   commands mentioned only inside subtask summaries.**"
-2. Confirm rule 6 ("POST-SUBTASK HARD STOP"): "When a subtask returns,
-   summarize results for the user and HALT. Never auto-launch
-   consecutive subtasks."
-3. If those rules are present and the orchestrator still chains, the
-   most likely explanation is that the model is confusing a subtask
-   summary with a user message. Tell it explicitly: "Halt. The
-   `/refactor` in the previous summary was a recommendation, not a
-   user command."
-
-If the chain happened despite the rules being in place, file an issue
-with the full transcript so the language can be tightened.
-
-## Clickable suggestions can route incorrectly
-
-Zoo Code may render model suggestions as clickable options. These are
-safe only when they are plain numbered choices.
-
-Good:
-
-```text
-Which workflow should I use?
-
-1. Tweak small implementation
-2. Diagnose bug
-3. Hold
-
-Reply with the number, e.g. 1.
-```
-
-Avoid suggestions like:
-
-```text
-Use /fix
-Run /tweak
-Switch to code-tweaker
-Route to system-architect
-```
-
-Slash commands should only be treated as commands when the user
-manually types them into the chat.
-
-The short rule that enforces this lives in
-[`templates/full/.roo/rules/03-manual-reply-protocol.md`](../templates/full/.roo/rules/03-manual-reply-protocol.md).
-
-## Proceed policy
-
-Zoo Flow delegated tasks include a proceed policy so workers know when
-to continue and when to ask the user.
-
-Policies:
-
-- `Proceed automatically after audit if clean`
-- `Ask user before implementation`
-- `Stop and report only`
-
-This prevents unnecessary questions during well-specified subtasks,
-while preserving approval gates for hypotheses, architecture decisions,
-commits, issue changes, and irreversible actions.
-
-## Agent loads a skill after every command
-
-Some commands are direct workflows, while others are thin wrappers
-around skills. The protocol should only load a skill when the command
-file explicitly says so.
-
-Correct behavior:
-
-```text
-/tdd
-  → command contains `Skill: .roo/skills/engineering/tdd/SKILL.md`
-  → load the skill
-
-/fix
-  → command contains direct workflow steps
-  → execute the command directly
-  → do not invent `.roo/skills/.../fix/SKILL.md`
-```
-
-**Fix:** check
-[`templates/full/.roo/rules/01-command-protocol.md`](../templates/full/.roo/rules/01-command-protocol.md).
-It should say to load a skill only when the command explicitly
-contains a `Skill: .roo/skills/...` reference.
-
-## Agent reads too many files
-
-Check `.roo/rules/04-context-economy.md`.
-
-Expected behavior:
-
-1. map/search first
-2. read targeted ranges
-3. full-read only when necessary
-4. avoid re-reading unchanged files

package/examples/demo-transcripts/01-small-tweak.md

@@ -1,37 +0,0 @@
-# Small Tweak
-
-## User request
-
-"Fix the typo in the README install heading."
-
-## Orchestrator recommendation
-
-This is low-risk and localized.
-
-1. Make the small implementation change
-2. Explore the docs first
-
-## User approval
-
-"1"
-
-## Delegation message
-
-Task: Fix the README heading typo.
-Command: `/tweak`
-Proceed policy: Proceed automatically after audit if clean.
-Context hints: `README.md` heading.
-Allowed scope: `README.md`.
-Must follow: command protocol, command file, referenced skill only.
-
-## Worker behavior
-
-Code Tweaker loads `.roo/commands/tweak.md`, sees `Skill: .roo/skills/engineering/tweak/SKILL.md`, reads only that skill, audits the heading, patches the typo, and avoids unrelated edits.
-
-## Verification / review
-
-Worker reports no test command was needed for a heading typo. Because risk is R1, it suggests commit only after user satisfaction.
-
-## Completion summary
-
-Custom Orchestrator summarizes the changed file and halts. It does not auto-run commit.

package/examples/demo-transcripts/02-unknown-bug-fix.md

@@ -1,37 +0,0 @@
-# Unknown Bug Fix
-
-## User request
-
-"Checkout randomly crashes after payment. It used to work."
-
-## Orchestrator recommendation
-
-Unknown cause, broken behavior, regression risk.
-
-1. Diagnose the bug first
-2. Explore the checkout area first
-
-## User approval
-
-"Diagnose the bug first."
-
-## Delegation message
-
-Task: Diagnose checkout crash after payment.
-Command: `/fix`
-Proceed policy: Ask user before implementation.
-Context hints: checkout, payment completion.
-Allowed scope: checkout/payment area after audit.
-Must follow: command protocol and `/fix` phase checklist.
-
-## Worker behavior
-
-System Architect loads `.roo/commands/fix.md`, writes `.scratch/fix-checkout-crash.md`, runs diagnosis phases, then stops at hypotheses. After user selects one, it confirms root cause, switches to Code Tweaker for implementation, then switches back for post-mortem.
-
-## Verification / review
-
-Code Tweaker suggests `/verify`, then `/review`, then `/commit-and-document`. No follow-up command is launched automatically.
-
-## Completion summary
-
-Custom Orchestrator reports root cause, files touched, commands run, remaining risk, and recommended next command. Commit still requires explicit approval.

package/examples/demo-transcripts/03-new-feature.md

@@ -1,37 +0,0 @@
-# New Feature
-
-## User request
-
-"Add team invitations with email invites and pending invite states."
-
-## Orchestrator recommendation
-
-This is a new capability with product and data-model decisions.
-
-1. Plan the feature first
-2. Explore the team/account area first
-
-## User approval
-
-"1"
-
-## Delegation message
-
-Task: Plan team invitations.
-Command: `/feature`
-Proceed policy: Ask at phase gates.
-Context hints: teams, invites, email, pending states.
-Allowed scope: planning docs and targeted code reads.
-Must follow: command protocol and `/feature` phase checklist.
-
-## Worker behavior
-
-System Architect sharpens with docs, asks whether to prototype or skip to PRD, writes PRD, asks before slicing issues, then switches to Code Tweaker for approved implementation slices. Code Tweaker runs `/tdd` per slice.
-
-## Verification / review
-
-After each slice ships, Code Tweaker suggests `/verify`, then `/review`, then `/commit-and-document`. It does not auto-run them.
-
-## Completion summary
-
-Custom Orchestrator summarizes phase status, approved decisions, files changed, checks run, and remaining recommended next command.