@fernado03/zoo-flow 0.11.1 → 0.11.3

package/examples/demo-transcripts/04-refactor.md

@@ -1,37 +0,0 @@
-# Refactor
-
-## User request
-
-"The auth module is getting hard to change. Decouple provider-specific logic."
-
-## Orchestrator recommendation
-
-Working behavior, structural problem, cross-module risk.
-
-1. Plan the refactor first
-2. Explore the auth module first
-
-## User approval
-
-"Plan the refactor first."
-
-## Delegation message
-
-Task: Plan auth provider decoupling.
-Command: `/refactor`
-Proceed policy: Ask before selecting a candidate and before implementation.
-Context hints: auth module, provider-specific logic.
-Allowed scope: targeted reads plus Markdown planning output.
-Must follow: command protocol and `/refactor` phase checklist.
-
-## Worker behavior
-
-System Architect runs the architecture skill, lists candidates, asks which to explore, grills the chosen plan, records the approved plan, then switches to Code Tweaker. Code Tweaker executes the test-first implementation path.
-
-## Verification / review
-
-Code Tweaker suggests `/verify`, then `/review`, then `/commit-and-document`. The user must explicitly approve each follow-up.
-
-## Completion summary
-
-Custom Orchestrator summarizes architecture decision, behavior-preservation checks, files changed, and next suggested command.

package/examples/demo-transcripts/05-review-and-verify.md

@@ -1,37 +0,0 @@
-# Review And Verify
-
-## User request
-
-"Review and verify this branch before I commit."
-
-## Orchestrator recommendation
-
-This asks for evidence plus inspection. Run verification first, then review.
-
-1. Run verification checks
-2. Review the diff first
-
-## User approval
-
-"Run verification checks."
-
-## Delegation message
-
-Task: Verify current branch changes.
-Command: `/verify`
-Proceed policy: Proceed automatically after changed scope and project checks are identified.
-Context hints: current branch diff.
-Allowed scope: repository checks only.
-Must follow: command protocol, command file, referenced skill only.
-
-## Worker behavior
-
-Code Tweaker loads `.roo/commands/verify.md`, sees `Skill: .roo/skills/engineering/verify/SKILL.md`, inspects project config and changed files, runs the smallest useful checks, and reports exact commands and results.
-
-## Verification / review
-
-After verification completes, Custom Orchestrator summarizes and asks whether to continue with the plain-language review workflow. It does not auto-launch review. If approved, System Architect loads `.roo/commands/review.md`, follows the review skill, reads targeted diffs and needed standards/specs, then reports findings by severity.
-
-## Completion summary
-
-The final summary includes verification status, review result, remaining risk, and whether commit is recommended. Commit requires explicit approval.

package/examples/feature-flow.md

@@ -1,117 +0,0 @@
-# Example: `/feature` flow
-
-The `/feature` chain is the longest one Zoo Flow ships. It exists
-specifically because the most expensive mistakes happen when an agent
-implements a feature it has not properly sharpened. The chain forces
-the slow steps before any code is written.
-
-## Setup
-
-- Active mode: `🪃 Custom Orchestrator`.
-- Example feature:
-
-  > "Add a dark mode toggle to the settings page."
-
-## Phase 1 — orchestrator routes
-
-Type:
-
-```
-/feature Add a dark mode toggle to the settings page.
-```
-
-The orchestrator delegates with `new_task` to `system-architect`.
-
-## Phase 2 — architect sharpens
-
-The architect runs `grill-with-docs` to sharpen the request. Expect:
-
-- Questions about target users and platforms.
-- Questions about existing theming infrastructure.
-- Questions about persistence (per-user, per-device, system-default).
-- Updates to relevant docs.
-
-**Hard stop**: the architect halts and asks:
-
-> Prototype, or skip to PRD?
-
-Answer one or the other. For this example:
-
-```
-Prototype.
-```
-
-## Phase 3 — prototype handoff (optional)
-
-Because you chose Prototype:
-
-1. Architect summarizes the prototype question, constraints, relevant
-   context, and the decision the prototype is meant to settle.
-2. Architect calls `switch_mode` to `code-tweaker` **in the same task
-   window**.
-3. Tweaker executes `/prototype` per the command protocol.
-4. Tweaker calls `switch_mode` back to `system-architect` with the
-   prototype result, run command or URL if any, and the decision needed.
-
-**Hard stop**: architect halts and asks for your verdict on the
-prototype.
-
-This is the phase that breaks most often if the architect skips the
-`switch_mode`. See
-[`docs/troubleshooting.md`](../docs/troubleshooting.md#prototype-running-in-the-wrong-mode).
-
-## Phase 4 — PRD
-
-The architect runs `to-prd`, summarizing the prior phases in three
-bullets and producing a PRD draft.
-
-**Hard stop**: "Ready to slice into issues?"
-
-Answer:
-
-```
-Yes.
-```
-
-## Phase 5 — slice into issues
-
-The architect runs `to-issues`, producing a list of well-scoped issues.
-
-**Hard stop**: wait for your approval of the issue list. Edit, drop,
-or merge issues here. Once approved, the chain continues.
-
-## Phase 6 — implement
-
-The architect summarizes the approved issues and `switch_mode`s to
-`code-tweaker`. The tweaker, for each issue:
-
-1. Runs `/tdd` per the command protocol.
-2. Implements the issue.
-3. After each issue ships, suggests `/commit-and-document`.
-
-The orchestrator does not auto-launch `/commit-and-document`. You run
-it explicitly when you want the commit.
-
-## Phase 7 — return
-
-When the chain completes (or hits a blocker), the active mode calls
-`attempt_completion`. The orchestrator summarizes and halts.
-
-## Pass criteria
-
-- [ ] Orchestrator delegated to `system-architect`.
-- [ ] Architect halted after sharpening, asked for Prototype or PRD.
-- [ ] If you picked Prototype, the architect used `switch_mode` to
-      hand off; the architect did not run the prototype itself.
-- [ ] Architect did not edit application source code at any point.
-- [ ] Architect halted before producing the PRD, after the PRD, and
-      after the issue list.
-- [ ] Tweaker ran `/tdd` per issue, not freeform implementation.
-- [ ] Tweaker did not commit without explicit approval.
-
-## Why this chain has so many stops
-
-Each hard stop is a place where the cheapest fix is "your input,
-right now". A wrong sharpening assumption is cheap to correct in
-phase 2, expensive after a PRD, and very expensive after an issue
-slice. The hard stops are not friction — they are the design.

package/examples/fix-flow.md

@@ -1,139 +0,0 @@
-# Example: `/fix` flow
-
-A worked example of the multi-phase `/fix` chain: orchestrator delegates
-to the architect, architect diagnoses, architect switches to the tweaker
-to implement, tweaker switches back, architect runs the post-mortem,
-tweaker prepares the commit. The whole flow has explicit HITL stops.
-
-## Setup
-
-- Active mode: `🪃 Custom Orchestrator`.
-- Workspace has a real bug to fix. For this example, assume:
-
-  > "The login button does nothing on the second click. First click
-  > works."
-
-## Phase 1 — orchestrator routes
-
-Type:
-
-```
-/fix The login button does nothing on the second click. First click works.
-```
-
-**Expected**
-
-Orchestrator looks up the routing matrix and delegates with `new_task`
-targeting `system-architect`. The delegated message includes the
-slash form, user context, proceed policy, command-protocol pointer,
-skills location, and the completion rule.
-
-## Phase 2 — architect diagnoses
-
-The new task window opens in `🏗️ System Architect`. The architect:
-
-1. Loads `/fix` per the command protocol.
-2. Runs the `diagnose` skill, phases 1–3.
-3. Produces a short list of hypotheses.
-4. **Halts** and asks you to pick one.
-
-**Expected message (paraphrased)**
-
-> Hypotheses:
-> 1. Click handler is wired once and never re-bound after a state change.
-> 2. The button enters a disabled state on first click and never resets.
-> 3. A queued network request is canceling the second click's handler.
->
-> Which would you like to instrument? (1 / 2 / 3)
-
-You answer:
-
-```
-2
-```
-
-## Phase 3 — architect instruments
-
-The architect runs phase 4 of the `diagnose` skill on hypothesis 2.
-This phase may involve reading state-management code, adding a
-console-log or instrumentation suggestion (Markdown only — the architect
-cannot edit source), and producing a confirmed root cause.
-
-**Expected**
-
-> Root cause confirmed: `LoginButton` sets `disabled` on the first
-> click and the `onSuccess` handler does not reset it. The second
-> click is being absorbed by the disabled state.
-
-The architect summarizes the proposed fix and prepares to hand off.
-
-## Phase 4 — architect switches to tweaker
-
-The architect calls `switch_mode` to `code-tweaker` **inside the same
-task window** with a summary of:
-
-- The root cause.
-- The proposed fix (`onSuccess` resets `disabled`).
-- The files involved.
-- The tests to add or extend.
-
-The tweaker takes over without losing context.
-
-## Phase 5 — tweaker implements
-
-The tweaker:
-
-1. Edits the `LoginButton` component to reset `disabled` on success
-   and on error.
-2. Adds or extends tests covering the second-click case.
-3. Runs the test suite.
-4. Reports back.
-
-**HITL stop**: the tweaker does not commit. Per the git rule, it waits
-for your approval.
-
-## Phase 6 — back to architect for post-mortem
-
-The tweaker calls `switch_mode` back to `system-architect`. The
-architect runs phase 6 of `diagnose` (post-mortem):
-
-- What was the original assumption that masked the bug?
-- Is this an isolated mistake or a pattern?
-- If a pattern, would `/refactor` help?
-
-The architect produces a short post-mortem note in `docs/` or
-`.scratch/` (Markdown only) and either drops the matter there or
-suggests `/refactor`.
-
-## Phase 7 — tweaker prepares the commit
-
-The architect switches back to the tweaker. The tweaker suggests
-`/commit-and-document`. **The orchestrator does not auto-launch it.**
-That command runs only when you type it.
-
-## Phase 8 — return to orchestrator
-
-When the chain is complete (or blocked), the active mode calls
-`attempt_completion`. The orchestrator summarizes for you and halts.
-
-## Pass criteria
-
-- [ ] Orchestrator delegated to `system-architect`, not the tweaker.
-- [ ] Architect halted after phase 3 hypotheses, did not instrument
-      until you picked one.
-- [ ] Architect did not edit source code at any point.
-- [ ] Architect used `switch_mode` (same window) to hand off, not
-      `new_task`.
-- [ ] Tweaker did not run `git commit` or `git push` without your
-      explicit approval.
-- [ ] After return, orchestrator halted instead of auto-launching
-      `/commit-and-document`.
-
-## Common slips
-
-- Architect tries to edit source: see
-  [`docs/troubleshooting.md`](../docs/troubleshooting.md#architect-trying-to-edit-source).
-- Tweaker commits without approval: tighten the git rule in the
-  tweaker's `customInstructions`.
-- Orchestrator launches `/commit-and-document` automatically: see
-  [`docs/troubleshooting.md`](../docs/troubleshooting.md#slash-command-leakage-from-subtask-summaries).

package/quality/scorecard.json

@@ -1,88 +0,0 @@
-{
-  "version": 1,
-  "minimum_score": 9.5,
-  "categories": {
-    "command_integrity": {
-      "weight": 0.20,
-      "checks": [
-        "All documented commands have mode declarations",
-        "All mode declarations match command-policy map",
-        "Global rules cover paths, protocol, failure, reply, context-economy",
-        "Mode rule folders exist for all three custom modes",
-        "Routing table matches command-policy map"
-      ],
-      "max_score": 10.0
-    },
-    "skill_quality": {
-      "weight": 0.20,
-      "checks": [
-        "Every command referencing a skill uses canonical Skill: marker",
-        "Referenced skills exist on disk",
-        "Skills describe purpose, steps, and output format",
-        "No thin non-canonical skill wrappers exist",
-        "Skills follow bucket layout under .roo/skills/"
-      ],
-      "max_score": 10.0
-    },
-    "validation_depth": {
-      "weight": 0.20,
-      "checks": [
-        "Doctor validates all required files exist",
-        "Doctor checks skill-reference integrity",
-        "Doctor checks mode slugs against allowed set",
-        "Doctor detects built-in delegation targets",
-        "Doctor checks .roomodes permits documented commands",
-        "Doctor validates routing table rows",
-        "Doctor detects old doc-name leakage",
-        "Doctor validates ADR path consistency"
-      ],
-      "max_score": 10.0
-    },
-    "token_economy": {
-      "weight": 0.10,
-      "checks": [
-        "Context-economy rule exists and is referenced",
-        "Domain-doc read gate defers broad reads",
-        "Completion rules specify evidence output format",
-        "Orchestrator routes by risk level to lightest safe workflow"
-      ],
-      "max_score": 10.0
-    },
-    "verification": {
-      "weight": 0.10,
-      "checks": [
-        "Verify command exists and references verify skill",
-        "Verify skill specifies evidence output format",
-        "Verify skill hard-codes no-claim-unless-run rule",
-        "Doctor fixture tests exist and pass",
-        "Routing eval cases exist and validate",
-        "Package-link integrity check exists"
-      ],
-      "max_score": 10.0
-    },
-    "review_process": {
-      "weight": 0.10,
-      "checks": [
-        "Review command exists and references review skill",
-        "Review skill covers standards and spec axes",
-        "Review skill has Security/Risk axis",
-        "Review findings ordered by severity",
-        "Review result ends with one of four canonical results"
-      ],
-      "max_score": 10.0
-    },
-    "release_readiness": {
-      "weight": 0.10,
-      "checks": [
-        "release:check script exists in package.json",
-        "release:check runs doctor, eval-routing, package-links",
-        "release:check runs package-manifest check",
-        "release:check runs token-budget check",
-        "release:check runs score-quality check",
-        "quality/scorecard.json defines minimum thresholds",
-        "npm pack --dry-run succeeds"
-      ],
-      "max_score": 10.0
-    }
-  }
-}

package/quality/token-budget.exceptions.json

@@ -1,13 +0,0 @@
-{
-  "_comment": "Token budget exceptions. Keys are relative file paths from project root. Values are reason + override size.",
-  "overrides": {
-    "compiled.md": {
-      "reason": "Single-file bundle doc, expected to be large",
-      "max_bytes": 819200
-    },
-    "ZOO-FLOW-BUNDLE.md": {
-      "reason": "Single-file bundle doc, expected to be large",
-      "max_bytes": 819200
-    }
-  }
-}