opencode-plugin-flow 4.3.3 → 4.3.5

package/dist/cli.js

@@ -178,7 +178,7 @@ stay separate:
 | --- | --- | --- |
 | Repo shape is unclear before planning | Discovery pass | Requirements, decisions, targets, validation entries, or a review-first feature |
 | A broad finding set needs refutation | Audit pass | Surviving findings with guards checked and gaps named |
-| Changed files or risk lenses are too broad for one review pass | Review pass | One \`featureReview\` or \`finalReview\` payload owned by the manager |
+| Changed files or risk lenses are too broad for one review pass | Review pass | One feature review packet or \`finalReview\` payload owned by the manager |
 | Test strategy or route coverage is unclear | Validation pass | Candidate commands or authorized raw command evidence |
 | A claim is single-source, surprising, high-stakes, or payload-bound | Verification pass | Per-claim keep, narrow, rewrite, or remove decisions |
 | Multiple implementation paths are plausible | Candidate pass | Candidate patches inspected and validated by the manager before use |
@@ -412,7 +412,7 @@ Where accepted evidence goes:
 - Validation evidence may become \`validationRun\` only when the worker was
   explicitly authorized to run the command and reported the exact command,
   status, and raw outcome summary.
-- Review evidence informs \`featureReview\` or \`finalReview\`, but the manager
+- Review evidence informs \`featureReviewDepth\` plus \`featureReview\`, or \`finalReview\`, but the manager
   owns the pass/fail verdict and must resolve blockers, contradictions, and
   coverage gaps before returning the payload.
 - Audit evidence becomes findings only after refutation; blocking findings need
@@ -539,10 +539,10 @@ suggestions do not move into the next pass or user-facing answer.
 `;
 
 // skills/flow/references/recovery-playbook.md
-var recovery_playbook_default = '# Recovery playbook\n\nUse this when a Flow tool returns `status: "error"`, a blocker, or a `nextAction` that conflicts with memory.\n\n## First response\n\n1. Re-anchor with `flow_status`.\n2. Read the returned `summary`, `recovery`, `lastError`, and active feature.\n3. Fix the cause, then retry the smallest valid Flow action.\n\n## Common cases\n\n- `missing_session`: start with `flow_plan_save` using the user\'s goal.\n- `missing_goal`: ask for a concrete goal before planning.\n- `Approved plans cannot be changed`: use `flow_feature_reset` when only affected features need another pass; otherwise close and start a new goal.\n- `No feature is currently running`: call `flow_run_start` before completing.\n- `already in progress`: finish, reset, or block the active feature before starting another.\n- `Completion requires recorded validation evidence`: run real validation and include at least one passing `validationRun`.\n- `Completion requires all recorded validation to pass`: fix failures and rerun. Do not relabel failed checks as passed.\n- `Non-final feature completion requires targeted validation`: use `validationScope: "targeted"` for ordinary features.\n- `Final feature completion requires broad validation`: run the project-level gate and use `validationScope: "broad"`.\n- `Completion requires a passing featureReview`: run or request a real review and include a passing `featureReview` only when there are no blocking findings.\n- `Final feature completion requires a finalReview`: perform final review and include `finalReview`.\n- `Final review depth must match the plan policy`: use `reviewDepth` equal to the approved plan\'s `finalReviewPolicy`; valid final-review values are `broad` and `detailed`.\n- `Cannot close ... unfinished features`: complete, reset, defer, or abandon honestly. Do not mark completed while work remains.\n\n## Reset guidance\n\nUse `flow_feature_reset` when the active or completed work was built on the wrong assumption, validation revealed a design issue, dependencies need to be rerun, or dependent features must be invalidated. Resetting a feature also resets its dependents.\n\n## Closure guidance\n\nUse `flow_session_close`:\n\n- `completed`: only after all planned features are complete.\n- `deferred`: the user intentionally postpones unfinished work.\n- `abandoned`: the session should be archived without claiming delivery.\n\nAfter closure, the active `.flow/session.json` is removed and the archived JSON is stored under `.flow/history/`.\n';
+var recovery_playbook_default = '# Recovery playbook\n\nUse this when a Flow tool returns `status: "error"`, a blocker, or a `nextAction` that conflicts with memory.\n\n## First response\n\n1. Re-anchor with `flow_status`.\n2. Read the returned `summary`, `recovery`, `lastError`, and active feature.\n3. Fix the cause, then retry the smallest valid Flow action.\n\n## Common cases\n\n- `missing_session`: start with `flow_plan_save` using the user\'s goal.\n- `missing_goal`: ask for a concrete goal before planning.\n- `Approved plans cannot be changed`: use `flow_feature_reset` when only affected features need another pass; otherwise close and start a new goal.\n- `No feature is currently running`: call `flow_run_start` before completing.\n- `already in progress`: finish, reset, or block the active feature before starting another.\n- `Completion requires recorded validation evidence`: run real validation and include at least one passing `validationRun`.\n- `Completion requires all recorded validation to pass`: fix failures and rerun. Do not relabel failed checks as passed.\n- `Non-final feature completion requires targeted validation`: use `validationScope: "targeted"` for ordinary features.\n- `Final feature completion requires broad validation`: run the project-level gate and use `validationScope: "broad"`.\n- `Feature review depth ... does not meet the plan requirement`: rerun review\n  at the feature\'s planned depth or reset/replan if the depth was chosen\n  incorrectly.\n- `Completion requires a passing featureReview`: run or request a real review and include a passing `featureReview` only when there are no blocking findings.\n- `Review retry budget exhausted`: stop and report the remaining blocker. Do\n  not keep patching; reset or replan only after explicit user direction.\n- `Final feature completion requires a finalReview`: perform final review and include `finalReview`.\n- `Final review depth must match the plan policy`: use `reviewDepth` equal to the approved plan\'s `finalReviewPolicy`; valid final-review values are `broad` and `detailed`.\n- `Completed ... features since the last Flow checkpoint`: stop the current\n  root session and resume from `.flow/session.json` in a fresh OpenCode session.\n- `Cannot close ... unfinished features`: complete, reset, defer, or abandon honestly. Do not mark completed while work remains.\n\n## Reset guidance\n\nUse `flow_feature_reset` when the active or completed work was built on the wrong assumption, validation revealed a design issue, dependencies need to be rerun, or dependent features must be invalidated. Resetting a feature also resets its dependents.\n\n## Closure guidance\n\nUse `flow_session_close`:\n\n- `completed`: only after all planned features are complete.\n- `deferred`: the user intentionally postpones unfinished work.\n- `abandoned`: the session should be archived without claiming delivery.\n\nAfter closure, the active `.flow/session.json` is removed and the archived JSON is stored under `.flow/history/`.\n';
 
 // skills/flow/SKILL.md
-var SKILL_default = "---\nname: flow\ndescription: Manage the end-to-end Flow loop for skills-first OpenCode work. Use when a user asks for Flow-guided delivery from goal to completion, resumable autonomous delivery, or resuming or closing a Flow session. For plan-only work use flow-plan; for executing one approved feature use flow-run.\n---\n\n# Flow\n\nUse Flow as a minimal state ledger, not as a framework. Skills provide judgment; the runtime only records the approved plan, active feature, validation evidence, review evidence, and closure.\n\nRouting: this manager skill owns the whole loop and every state-changing `flow_*` call. Load `flow-plan` alone for plan-only requests and `flow-run` alone when an approved plan needs one feature executed. Answer status-only questions with `flow_status`; no skill load is needed. `flow-test`, `flow-deslop`, and `flow-ui-quality` are optional helpers loaded from inside the loop; `flow-commit` is user-triggered only and never part of the autonomous loop.\n\n## Loop\n\n1. Call `flow_status` first. Trust its active session and next action over conversation memory.\n   If the result includes `setup.skills`, follow the Skill Availability rules\n   below before loading any Flow skill.\n2. If there is no active session and the user gave a goal, load `flow-plan`, save a plan with `flow_plan_save`, then approve it with `flow_plan_approve` only after explicit user approval or prior authorization for autonomous implementation. If there is no goal, ask for one.\n3. Load `flow-run`, call `flow_run_start`, implement exactly one feature, validate it, and prepare a `flow_feature_complete` payload. For validation-heavy, regression-sensitive, browser QA, route QA, or failure-prone work, use `flow-test` to choose and summarize evidence before completion.\n4. Load `flow-review` for the required feature review. The reviewer reports a `featureReview` payload; the manager records it inside `flow_feature_complete`.\n5. On the final feature, run broad validation and include `finalReview` in the same `flow_feature_complete` call. Its `reviewDepth` must match the plan's `finalReviewPolicy`.\n6. After all features are complete, archive the session with `flow_session_close` using `kind: \"completed\"`.\n\nUse `references/parallel-orchestration.md` for broad read-only discovery, audit, validation, review, verification, or candidate implementation passes. It is the whole pass playbook — orient, slice, manifest, fan out, account, verify, synthesize, extend or stop — and its `references/handoff-format.md` companion holds the worker report templates the manager pastes into prompts. Hidden Flow workers are injected by plugin config; invoke the named worker when it is available. The manager owns every `flow_*` state change.\n\nDo not commit, push, amend, rebase, publish, or mutate releases during the\nautonomous Flow loop. Load `flow-commit` only when the user explicitly asks for\ncommit preparation or commit creation.\n\n## Skill Availability\n\nIf `flow_status` returns `setup.skills`, report that setup status and stop\nnative-loading Flow skills in the current OpenCode startup. Missing, incomplete,\nor outdated managed skills require a sync/restart cycle before their native skill\ninstructions can be trusted by the running process. Public command bundles are\nself-contained and may continue when the command prompt already embeds the\nrequired Flow instructions.\n\nIf optional helper skills such as `flow-test`, `flow-deslop`, or\n`flow-ui-quality` are unavailable, continue only with explicit coverage gaps. Do\nnot copy their rubrics into another skill and do not claim their quality checks\nwere completed.\n\n## Runtime Surface\n\n- `flow_status`: read the active session.\n- `flow_plan_save`: create a session and/or save a draft plan.\n- `flow_plan_approve`: lock the draft plan.\n- `flow_run_start`: start one runnable feature.\n- `flow_feature_complete`: record completion or a real blocker with validation and review evidence.\n- `flow_feature_reset`: reset one feature and its dependents.\n- `flow_session_close`: archive the active session as `completed`, `deferred`, or `abandoned`.\n\nThere is no `flow_context`, no separate review-record tool, and no multi-session activation surface. The single active source of truth is `.flow/session.json`; closed sessions are archived under `.flow/history/`.\n\nPlanning and running require loaded Flow tools; do not simulate plan approval or feature completion when the runtime is unavailable. Review may still return advisory output when tools, skills, or references are stale or unavailable, but the manager must not record it as Flow-gated evidence.\n\n## Hard Gates\n\n- Approved plans are immutable. To change direction, reset affected features or close the session and start a new goal.\n- Only one feature can be active at a time.\n- Completion requires at least one passing `validationRun` entry.\n- Non-final completion requires `validationScope: \"targeted\"`.\n- Final completion requires `validationScope: \"broad\"` and a passing `finalReview`.\n- Every completed feature requires a passing `featureReview` with no blocking findings.\n- `flow_session_close` accepts `kind: \"completed\"` only after an approved plan has passed final completion.\n\n## Recovery\n\n- Confused state: call `flow_status` and follow `nextAction`.\n- Wrong assumption or failed implementation path: use `flow_feature_reset` for the feature and dependents, then rerun from the corrected plan.\n- Missing validation or review evidence: gather real evidence, then call `flow_feature_complete`.\n- Approved plan is materially wrong: reset the affected features, save a revised plan if the session is back in planning; otherwise close and start a new goal.\n- Unknown runtime error: read `summary` and `recovery`; see `references/recovery-playbook.md` for common cases.\n\nNever fabricate validation output, backfill review approval you did not perform, or close as `deferred`/`abandoned` merely to avoid an unfinished-work blocker.\n";
+var SKILL_default = "---\nname: flow\ndescription: Manage the end-to-end Flow loop for skills-first OpenCode work. Use when a user asks for Flow-guided delivery from goal to completion, resumable autonomous delivery, or resuming or closing a Flow session. For plan-only work use flow-plan; for executing one approved feature use flow-run.\n---\n\n# Flow\n\nUse Flow as a minimal state ledger, not as a framework. Skills provide judgment; the runtime only records the approved plan, active feature, validation evidence, review evidence, and closure.\n\nRouting: this manager skill owns the whole loop and every state-changing `flow_*` call. Load `flow-plan` alone for plan-only requests and `flow-run` alone when an approved plan needs one feature executed. Answer status-only questions with `flow_status`; no skill load is needed. `flow-test`, `flow-deslop`, and `flow-ui-quality` are optional helpers loaded from inside the loop; `flow-commit` is user-triggered only and never part of the autonomous loop.\n\n## Loop\n\n1. Call `flow_status` first. Trust its active session and next action over conversation memory.\n   If the result includes `setup.skills`, follow the Skill Availability rules\n   below before loading any Flow skill.\n   If it includes `session.resumePacket` or `session.budget.phaseBoundary`, stop\n   and report the resume instructions unless this is a fresh user invocation\n   explicitly resuming the session. Only then may the next `flow_run_start` use\n   `phaseBoundaryAck: true`.\n2. If there is no active session and the user gave a goal, load `flow-plan`, save a plan with `flow_plan_save`, then approve it with `flow_plan_approve` only after explicit user approval or prior authorization for autonomous implementation. If there is no goal, ask for one.\n3. Load `flow-run`, call `flow_run_start`, implement exactly one feature, validate it, and prepare a `flow_feature_complete` payload. For validation-heavy, regression-sensitive, browser QA, route QA, or failure-prone work, use `flow-test` to choose and summarize evidence before completion.\n4. Load `flow-review` for the required feature review. Send a compact review\n   packet, not the accumulated root transcript. The reviewer reports\n   `featureReviewDepth` and `featureReview`; the manager records both inside\n   `flow_feature_complete`.\n5. On the final feature, run broad validation and include `finalReview` in the same `flow_feature_complete` call. Its `reviewDepth` must match the plan's `finalReviewPolicy`.\n6. After all features are complete, archive the session with `flow_session_close` using `kind: \"completed\"`.\n\nUse `references/parallel-orchestration.md` for broad read-only discovery, audit, validation, review, verification, or candidate implementation passes. It is the whole pass playbook — orient, slice, manifest, fan out, account, verify, synthesize, extend or stop — and its `references/handoff-format.md` companion holds the worker report templates the manager pastes into prompts. Hidden Flow workers are injected by plugin config; invoke the named worker when it is available. The manager owns every `flow_*` state change.\n\nDo not commit, push, amend, rebase, publish, or mutate releases during the\nautonomous Flow loop. Load `flow-commit` only when the user explicitly asks for\ncommit preparation or commit creation.\n\n## Skill Availability\n\nIf `flow_status` returns `setup.skills`, report that setup status and stop\nnative-loading Flow skills in the current OpenCode startup. Missing, incomplete,\nor outdated managed skills require a sync/restart cycle before their native skill\ninstructions can be trusted by the running process. Public command bundles are\nself-contained and may continue when the command prompt already embeds the\nrequired Flow instructions.\n\nIf optional helper skills such as `flow-test`, `flow-deslop`, or\n`flow-ui-quality` are unavailable, continue only with explicit coverage gaps. Do\nnot copy their rubrics into another skill and do not claim their quality checks\nwere completed.\n\n## Runtime Surface\n\n- `flow_status`: read the active session.\n- `flow_plan_save`: create a session and/or save a draft plan.\n- `flow_plan_approve`: lock the draft plan.\n- `flow_run_start`: start one runnable feature.\n- `flow_feature_complete`: record completion or a real blocker with validation and review evidence.\n- `flow_feature_reset`: reset one feature and its dependents.\n- `flow_session_close`: archive the active session as `completed`, `deferred`, or `abandoned`.\n\nThere is no `flow_context`, no separate review-record tool, and no multi-session activation surface. The single active source of truth is `.flow/session.json`; closed sessions are archived under `.flow/history/`.\n\nPlanning and running require loaded Flow tools; do not simulate plan approval or feature completion when the runtime is unavailable. Review may still return advisory output when tools, skills, or references are stale or unavailable, but the manager must not record it as Flow-gated evidence.\n\n## Hard Gates\n\n- Approved plans are immutable. To change direction, reset affected features or close the session and start a new goal.\n- Only one feature can be active at a time.\n- Each feature's planned `reviewDepth` is the minimum accepted\n  `featureReviewDepth` for completion.\n- Completion requires at least one passing `validationRun` entry.\n- Non-final completion requires `validationScope: \"targeted\"`.\n- Final completion requires `validationScope: \"broad\"` and a passing `finalReview`.\n- Every completed feature requires a passing `featureReview` with no blocking findings.\n- Failed reviews pause the loop by default. Autonomous repair may make at most\n  one repair plus one retry review before stopping.\n- Phase boundaries stop the current root session; resume from\n  `.flow/session.json` in a fresh OpenCode session.\n- `flow_session_close` accepts `kind: \"completed\"` only after an approved plan has passed final completion.\n\n## Budget And Retry Boundaries\n\nFlow can enforce review retry counts and feature-count phase boundaries in the\nruntime ledger. The current OpenCode plugin surface does not expose per-turn\ntoken usage to Flow; when usage is visible in the host UI or logs, stop the\ncurrent autonomous loop once the root session is large enough to threaten\nlatency or cost and report a compact handoff instead of continuing. Treat high\nvisible tokens, high non-cache tokens, or repeated reviewer fan-out as a reason\nto finish the current feature, emit the resume packet, and continue in a fresh\nsession.\n\n## Recovery\n\n- Confused state: call `flow_status` and follow `nextAction`.\n- Wrong assumption or failed implementation path: use `flow_feature_reset` for the feature and dependents, then rerun from the corrected plan.\n- Missing validation or review evidence: gather real evidence, then call `flow_feature_complete`.\n- Approved plan is materially wrong: reset the affected features, save a revised plan if the session is back in planning; otherwise close and start a new goal.\n- Unknown runtime error: read `summary` and `recovery`; see `references/recovery-playbook.md` for common cases.\n\nNever fabricate validation output, backfill review approval you did not perform, or close as `deferred`/`abandoned` merely to avoid an unfinished-work blocker.\n";
 
 // skills/flow-commit/SKILL.md
 var SKILL_default2 = `---
@@ -845,6 +845,60 @@ Apply the manager synthesis barrier from
 evidence-backed claims become plan fields.
 `;
 
+// skills/flow-plan/references/plan-quality-checklist.md
+var plan_quality_checklist_default = `# Plan quality checklist
+
+Use this checklist before \`flow_plan_save\` and again before approval if the plan
+changed during discussion. The goal is not a long planning artifact; it is a
+compact plan another agent can execute without rediscovering the work.
+
+## Must pass
+
+- Outcome: \`summary\` names the user-visible result, not an internal activity.
+- Requirements: acceptance criteria, constraints, and non-goals that affect
+  implementation are captured in \`requirements\`.
+- Decisions: assumptions, scope choices, and architecture choices already made
+  are captured in \`decisions\`.
+- Uncertainty: specification uncertainty is resolved by a decision or a user
+  question; environment uncertainty is resolved by inspection, discovery, or a
+  first evidence-producing feature.
+- Feature shape: each feature has one coherent outcome and can be reviewed on
+  its own.
+- Targets: each feature names bounded files, modules, routes, commands, docs, or
+  generated surfaces. Whole-repo targets are allowed only for explicit broad
+  audits or final validation.
+- Validation: each feature names expected check levels, such as targeted unit,
+  integration, browser/e2e, package/build, docs/static, cleanup preservation, or
+  broad project gate.
+- Dependencies: \`dependsOn\` captures true ordering and avoids hidden dependency
+  chains.
+- Review policy: \`finalReviewPolicy\` is \`detailed\` when the work changes
+  behavior, persistence, public contracts, security posture, release surfaces,
+  or multiple modules.
+
+## Revise when you see this
+
+- A feature title describes a step like "update files" instead of a result.
+- A validation entry says only "manual testing" or "run tests".
+- A feature has targets but no behavior or artifact that can be judged.
+- A feature claims cleanup or simplification without an evidence-producing
+  audit or cited smell.
+- A docs feature depends on behavior that is not yet implemented but lacks
+  \`dependsOn\`.
+- A low-risk \`finalReviewPolicy: "broad"\` is used while the plan crosses runtime,
+  schema, persistence, security, or release boundaries.
+
+## Approval summary
+
+When presenting the plan for approval, include:
+
+- The promised outcome.
+- The feature order and any dependencies that matter.
+- The main validation levels.
+- Material assumptions in \`decisions\`.
+- Any known gaps that remain intentional.
+`;
+
 // skills/flow-plan/references/planning-examples.md
 var planning_examples_default = `# Planning examples
 
@@ -923,6 +977,164 @@ Better plan:
 3. Add behavior-preservation tests for the changed service paths.
 \`\`\`
 
+## Bugfix plan
+
+Human summary:
+
+1. Reproduce and localize the failed password reset redirect.
+2. Fix the redirect state handling and cover the regression.
+3. Update release notes only if user-facing behavior changed.
+
+Payload:
+
+\`\`\`json
+{
+  "goal": "Fix password reset links landing users on the wrong page",
+  "plan": {
+    "summary": "Password reset links land users on the intended reset confirmation flow.",
+    "overview": "Start with a focused reproduction, then fix the redirect state and update user-facing notes only if the behavior change needs documentation.",
+    "requirements": [
+      "Preserve existing token validation and expiry behavior.",
+      "Users with valid reset links should not be sent to the generic sign-in page before completing the reset."
+    ],
+    "decisions": [
+      "Treat the current redirect mismatch as a regression until reproduction proves otherwise."
+    ],
+    "finalReviewPolicy": "detailed",
+    "features": [
+      {
+        "id": "reset-redirect-repro",
+        "title": "Redirect reproduction",
+        "summary": "Produce a failing focused check or trace that identifies where the reset redirect is lost.",
+        "targets": ["src/auth/reset", "tests/auth"],
+        "validation": ["targeted unit or integration reproduction for reset redirect behavior"],
+        "dependsOn": []
+      },
+      {
+        "id": "reset-redirect-fix",
+        "title": "Redirect fix",
+        "summary": "Preserve reset redirect state through token validation and completion.",
+        "targets": ["src/auth/reset", "tests/auth"],
+        "validation": ["targeted regression test passes", "auth package/build check if available"],
+        "dependsOn": ["reset-redirect-repro"]
+      },
+      {
+        "id": "reset-redirect-notes",
+        "title": "User-facing notes",
+        "summary": "Document the corrected reset-link behavior if release notes or help text mention the flow.",
+        "targets": ["CHANGELOG.md", "docs/auth.md"],
+        "validation": ["docs/static check if available", "review docs against implemented behavior"],
+        "dependsOn": ["reset-redirect-fix"]
+      }
+    ]
+  }
+}
+\`\`\`
+
+## UI/frontend plan
+
+Human summary:
+
+1. Map the current checkout empty state and responsive constraints.
+2. Implement the empty state with accessible controls and mobile layout.
+3. Verify the visual states with screenshots or browser evidence.
+
+Good feature outline:
+
+\`\`\`text
+1. Empty-state discovery - inspect the route, component boundaries, design tokens, existing empty states, and likely responsive breakpoints.
+2. Empty-state implementation - add the checkout empty state, action wiring, focus order, and loading/error boundaries in the existing component style.
+3. Visual and interaction verification - capture desktop and mobile evidence, run available route/component checks, and fix overlap or accessibility regressions.
+\`\`\`
+
+Why this is better than one "build UI" feature: the plan names the uncertain
+surface first, keeps implementation scoped to the route/components, and makes
+visual evidence part of completion rather than an afterthought.
+
+## Runtime or schema plan
+
+Human summary:
+
+1. Introduce the schema change behind a backward-compatible parser.
+2. Migrate callers and persistence writes.
+3. Add compatibility validation and docs.
+
+Good feature outline:
+
+\`\`\`text
+1. Compatible schema reader - accept old and new session payloads, with targeted parser tests for both.
+2. New writer path - emit the new field from runtime transitions and update affected callers.
+3. Compatibility sweep - run persistence/workspace tests, update docs, and verify old sessions still recover.
+\`\`\`
+
+Use \`finalReviewPolicy: "detailed"\` for this shape. Persistence and schema work
+usually has hidden downstream contracts, so feature validation should name both
+targeted parser checks and broader workspace/runtime gates.
+
+## Docs-only plan
+
+Docs-only work can use \`finalReviewPolicy: "broad"\` when it does not change
+commands, configuration, generated files, or release metadata.
+
+Good feature outline:
+
+\`\`\`text
+1. Align installation docs - update README and troubleshooting steps for the current setup flow.
+2. Verify commands and links - check documented commands against package scripts and make sure links/paths resolve.
+\`\`\`
+
+Bad validation:
+
+\`\`\`text
+validation: ["manual review"]
+\`\`\`
+
+Better validation:
+
+\`\`\`text
+validation: ["docs/static link and path review", "command examples checked against package scripts"]
+\`\`\`
+
+## Audit-first and review-first plans
+
+Use an evidence-producing first feature when the request asks to "review",
+"audit", "clean up", "modernize", or "improve" a broad area.
+
+Good feature outline:
+
+\`\`\`text
+1. Audit checkout state management - cite concrete findings with file:line evidence, refutation checks, severity, and recommended fix order.
+2. Fix confirmed high-impact state leak - only for findings that survived the audit.
+3. Regression validation - add or run checks covering the changed state paths.
+\`\`\`
+
+Do not plan fixes for guessed findings. If the audit might find no actionable
+issue, say that in the first feature summary and make later features conditional
+on evidence.
+
+## Validation examples
+
+Weak:
+
+\`\`\`text
+validation: ["run tests", "manual testing"]
+\`\`\`
+
+Stronger:
+
+\`\`\`text
+validation: [
+  "targeted unit tests for empty and invalid input",
+  "integration test for persisted session recovery",
+  "package/build gate for changed TypeScript exports",
+  "browser screenshot at desktop and mobile widths for layout-sensitive UI",
+  "docs/static review for changed command examples"
+]
+\`\`\`
+
+The stronger version says what level of evidence is expected and which behavior
+or surface it covers.
+
 ## Decomposition anti-patterns
 
 - Feature per file when behavior crosses files.
@@ -995,6 +1207,7 @@ Call \`flow_plan_save\` with:
         "id": "lowercase-kebab-case",
         "title": "Short title",
         "summary": "Outcome this feature delivers",
+        "reviewDepth": "standard",
         "targets": ["files, modules, routes, commands, or docs in scope"],
         "validation": ["focused checks expected before completion"],
         "dependsOn": []
@@ -1006,6 +1219,23 @@ Call \`flow_plan_save\` with:
 
 Use only \`finalReviewPolicy: "broad"\` or \`"detailed"\`. These are the canonical final-review policy and \`reviewDepth\` enum values. Use \`"broad"\` only for low-risk, narrow work. Use \`"detailed"\` for behavioral changes, cross-module edits, migrations, releases, security-sensitive code, or large refactors.
 
+Set each feature's \`reviewDepth\` to one of:
+
+- \`quick\`: docs, comments, config-only changes, generated output, or mechanical changes fully covered by tooling.
+- \`standard\`: the default for ordinary implementation slices. The review reads every changed file and relevant tests.
+- \`detailed\`: persistence, migrations, concurrency, security, cross-module behavior, release/package surfaces, large refactors, weak validation, or any work where a missed edge case would be expensive.
+
+Do not make reviews shallower to save tokens. Reduce token use by splitting features, keeping \`targets\` precise, and using scoped review packets during execution.
+
+## Plan quality gate
+
+Before saving or asking for approval, load
+\`references/plan-quality-checklist.md\` and check the draft against it. Revise the
+plan until it passes, or record the remaining gap in \`decisions\` when the gap is
+an intentional assumption. Do not approve a plan whose outcome, requirements,
+targets, validation, or dependency order are still too vague for another agent
+to execute.
+
 ## Feature sizing
 
 - Each feature should have one owner, one coherent outcome, and a validation story.
@@ -1016,12 +1246,17 @@ Use only \`finalReviewPolicy: "broad"\` or \`"detailed"\`. These are the canonic
   validation entry should name the expected test level, such as targeted unit,
   integration, browser/e2e, package/build, docs/static, cleanup preservation, or
   broad project gate.
+- Assign \`reviewDepth\` from risk. Use \`detailed\` for persistence, migration,
+  concurrency, security, final-delivery-adjacent, or cross-module slices; use
+  \`standard\` for normal code changes; reserve \`quick\` for low-risk non-behavioral
+  work.
 
 ## Approval
 
 After saving, summarize the plan to the user. Call \`flow_plan_approve\` only after explicit user approval, unless the user already authorized autonomous implementation. Approved plans are immutable; changing them later requires reset/closure rather than silent edits.
 
-See \`references/planning-examples.md\` for payload examples and decomposition anti-patterns.
+See \`references/planning-examples.md\` for payload examples and decomposition
+anti-patterns.
 `;
 
 // skills/flow-review/references/review-rubric.md
@@ -1057,22 +1292,54 @@ If unsure whether a finding is real, read more or downgrade it. Do not promote g
 
 ## Final review checklist
 
-- Every feature is complete and together they satisfy the original goal.
-- Broad validation ran and passed.
+- The original goal is satisfied by the delivered behavior or artifacts.
+- Every approved requirement is either met or explicitly accounted for by an
+  accepted gap.
+- Plan decisions and scope boundaries still match the implementation.
+- Every planned feature is complete, has recorded validation evidence, and
+  contributes to the final outcome.
+- Feature dependencies were completed in an order that makes the evidence
+  trustworthy.
+- Changed artifacts match the plan's \`targets\`; extra changed surfaces are
+  explained and reviewed.
+- Broad validation ran and passed, or any skipped broad check is justified as a
+  non-blocking gap.
 - The final \`reviewDepth\` equals the approved \`finalReviewPolicy\`; the only final-review enum values are \`broad\` and \`detailed\`.
 - Feature-level reviews have no unresolved blocking findings.
 - Docs, commands, package metadata, and release surfaces match the delivered behavior.
 - Remaining gaps are explicit and do not contradict \`kind: "completed"\`.
 
+## Final convergence scan
+
+Run this scan before returning a passing \`finalReview\`:
+
+1. Restate the original goal and the approved plan summary in your own words.
+2. Map each requirement to delivered evidence, validation output, or an explicit
+   accepted gap.
+3. Walk every planned feature and confirm its completion evidence, review
+   result, and validation level.
+4. Compare the changed files, docs, commands, generated surfaces, and package
+   metadata to the planned targets and requirements.
+5. Check whether the validation evidence would have caught the main failure
+   modes introduced by the work.
+6. Decide whether remaining gaps are advisory or blocking before setting
+   \`status\`.
+
+Fail the final review when the delivered work cannot be traced back to the
+approved goal and requirements, even if each individual feature review passed.
+
 ## Payloads
 
 Feature review:
 
 \`\`\`json
 {
-  "status": "passed",
-  "summary": "Reviewed changed runtime files and focused tests; validation covers the new gate.",
-  "blockingFindings": []
+  "featureReviewDepth": "standard",
+  "featureReview": {
+    "status": "passed",
+    "summary": "Reviewed changed runtime files and focused tests; validation covers the new gate.",
+    "blockingFindings": []
+  }
 }
 \`\`\`
 
@@ -1080,14 +1347,17 @@ Failed feature review:
 
 \`\`\`json
 {
-  "status": "failed",
-  "summary": "Validation does not exercise the changed persistence path.",
-  "blockingFindings": [
-    {
-      "summary": "No test covers archive removal of .flow/session.json after close.",
-      "severity": "blocking"
-    }
-  ]
+  "featureReviewDepth": "detailed",
+  "featureReview": {
+    "status": "failed",
+    "summary": "Validation does not exercise the changed persistence path.",
+    "blockingFindings": [
+      {
+        "summary": "No test covers archive removal of .flow/session.json after close.",
+        "severity": "blocking"
+      }
+    ]
+  }
 }
 \`\`\`
 
@@ -1147,7 +1417,15 @@ These instructions run in two contexts, and only one of them can load helpers:
 
 - Call \`flow_status\` when available.
 - Identify whether this is a feature review or final review.
+- Prefer the manager's compact review packet over parent-session memory. The
+  packet should name the active feature, minimum \`reviewDepth\`, changed files,
+  diff summary, validation evidence, and targeted paths or risk lenses. If the
+  packet is missing important scope or evidence, record that as a coverage gap
+  or blocker instead of searching the full conversation transcript.
 - Read the approved plan fields relevant to the work: \`requirements\`, \`decisions\`, feature \`targets\`, feature \`validation\`, and dependencies.
+- For final review, also compare the original goal, full feature list, completed
+  feature evidence, changed artifacts, and final validation against the
+  convergence checklist in \`references/review-rubric.md\`.
 - Inspect the actual diff, changed files, tests, and validation output. Do not review only the completion summary.
 - In manager context, load \`flow-test\` for validation-heavy,
   regression-sensitive, browser QA, or unclear coverage reviews. If it is
@@ -1165,16 +1443,23 @@ These instructions run in two contexts, and only one of them can load helpers:
 
 ## Output
 
-For a feature review, return:
+For a feature review, return a packet the manager can copy into
+\`flow_feature_complete\`:
 
 \`\`\`json
 {
-  "status": "passed",
-  "summary": "what was reviewed and why it is acceptable",
-  "blockingFindings": []
+  "featureReviewDepth": "standard",
+  "featureReview": {
+    "status": "passed",
+    "summary": "what was reviewed and why it is acceptable",
+    "blockingFindings": []
+  }
 }
 \`\`\`
 
+\`featureReviewDepth\` must be at least the feature's planned \`reviewDepth\`.
+Use the actual depth performed: \`quick\`, \`standard\`, or \`detailed\`.
+
 For a final review, return:
 
 \`\`\`json
@@ -1326,96 +1611,7 @@ Never trim failing output, relabel a failed command as passed, or use "not run"
 `;
 
 // skills/flow-run/SKILL.md
-var SKILL_default6 = `---
-name: flow-run
-description: "Use when an approved Flow plan has a feature to implement, validate, or complete in the v4 runtime, and the work is scoped to one active feature. For planning a goal first use flow-plan; for the full goal-to-completion loop or resuming a session use flow."
----
-
-# Flow Run
-
-Use this skill for implementation after a Flow plan is approved. Work one feature at a time.
-
-If \`flow_run_start\` is unavailable, stop and tell the user to check that \`opencode-plugin-flow\` is loaded in OpenCode.
-
-## Start
-
-- Call \`flow_status\`.
-- Call \`flow_run_start\` with no \`featureId\` unless the user or plan requires a specific runnable feature.
-- Treat the returned feature as the sole scope until it is completed, blocked, or reset.
-- Helper rule: when a named helper skill is unavailable, record the gap and
-  keep the corresponding claims conservative instead of simulating its checks.
-- Load \`flow-deslop\` for cleanup/refactor features.
-- Load \`flow-ui-quality\` for frontend, UX, responsive, accessibility, or visual work.
-
-## Implement
-
-- Read the feature \`targets\`, \`summary\`, \`validation\`, dependencies, and plan \`requirements\`/\`decisions\`.
-- Keep edits scoped to the active feature. If new scope appears, stop and replan or defer it to another feature.
-- Preserve unrelated user changes in the worktree.
-- When a wrong assumption invalidates the feature, use \`flow_feature_reset\`; do not pile patches onto a bad path.
-- Do not stage, commit, push, amend, rebase, publish, or mutate releases as part
-  of feature execution. If the user explicitly asks for commit preparation, load
-  \`flow-commit\` only after \`flow_feature_complete\` has been recorded, unless the
-  user explicitly asks for a WIP commit path. Keep Git boundaries separate from
-  Flow state recording.
-
-## Validate
-
-- For complex validation, regression-sensitive changes, browser QA, route QA,
-  failure-prone checks, unclear coverage, exploratory QA, or
-  \`validationRun\` summarization, load \`flow-test\` (helper rule applies).
-- Read \`references/validation-rubric.md\` before completing.
-- Run the strongest practical checks for the changed behavior.
-- Record concrete command names, status, and observed results. "Tests pass" is not evidence.
-- Non-final features complete with \`validationScope: "targeted"\`.
-- The final feature must run a broad project-level gate and use \`validationScope: "broad"\`.
-
-For broad validation research, risky changes, or unclear coverage, use
-\`../flow/references/parallel-orchestration.md\` to fan out named Flow workers.
-Use the mode-to-agent mapping in that reference instead of generic subagents.
-Write its pass manifest before fan-out, paste the matching handoff template
-from \`../flow/references/handoff-format.md\` into every worker prompt, and
-apply its verification tiers to the handoffs that come back.
-They may report command output they actually ran or propose focused checks; the
-manager decides what is strong enough to record.
-
-For independent implementation attempts, use candidate workers only with
-explicit user authorization plus isolated worktrees or exact non-overlapping
-path ownership. Treat their output as candidate patches. The manager inspects,
-merges, validates, and records Flow state serially.
-
-## Review and complete
-
-Before \`flow_feature_complete\`, obtain a \`featureReview\` payload. Load
-\`flow-review\`; for read-only subagent reviews, the manager receives the payload
-and records it.
-
-If \`flow_status\` reports \`setup.skills\` or \`flow-review\` cannot be loaded, do
-not record a Flow-gated \`featureReview\` or \`finalReview\`. You may perform an
-advisory review using available context or the bundled review fallback provided
-by plugin config, then complete with \`status: "needs_input"\` if review evidence
-is required to proceed.
-
-For the final feature, also obtain a \`finalReview\` payload whose \`reviewDepth\` equals the approved plan's \`finalReviewPolicy\`.
-
-Complete with:
-
-\`\`\`json
-{
-  "status": "ok",
-  "featureId": "active-feature-id",
-  "summary": "what changed",
-  "artifactsChanged": [{ "path": "src/file.ts" }],
-  "validationRun": [
-    { "command": "bun test tests/foo.test.ts", "status": "passed", "summary": "3 pass, exercised foo behavior" }
-  ],
-  "validationScope": "targeted",
-  "featureReview": { "status": "passed", "summary": "review summary", "blockingFindings": [] }
-}
-\`\`\`
-
-If genuinely blocked, call \`flow_feature_complete\` with \`status: "needs_input"\` and an \`outcome\` that explains the blocker and next step. Never fabricate validation or review evidence to force progress.
-`;
+var SKILL_default6 = '---\nname: flow-run\ndescription: "Use when an approved Flow plan has a feature to implement, validate, or complete in the v4 runtime, and the work is scoped to one active feature. For planning a goal first use flow-plan; for the full goal-to-completion loop or resuming a session use flow."\n---\n\n# Flow Run\n\nUse this skill for implementation after a Flow plan is approved. Work one feature at a time.\n\nIf `flow_run_start` is unavailable, stop and tell the user to check that `opencode-plugin-flow` is loaded in OpenCode.\n\n## Start\n\n- Call `flow_status`.\n- If `flow_status` returns a `session.resumePacket` or\n  `session.budget.phaseBoundary`, stop the current autonomous loop and report\n  the resume instructions. Only call `flow_run_start` with\n  `phaseBoundaryAck: true` at the start of a fresh user invocation that is\n  explicitly resuming the Flow session; do not acknowledge a boundary inside\n  the same uninterrupted loop that created it.\n- Call `flow_run_start` with no `featureId` unless the user or plan requires a specific runnable feature.\n- Treat the returned feature as the sole scope until it is completed, blocked, or reset.\n- Helper rule: when a named helper skill is unavailable, record the gap and\n  keep the corresponding claims conservative instead of simulating its checks.\n- Load `flow-deslop` for cleanup/refactor features.\n- Load `flow-ui-quality` for frontend, UX, responsive, accessibility, or visual work.\n\n## Implement\n\n- Read the feature `targets`, `summary`, `validation`, dependencies, and plan `requirements`/`decisions`.\n- Treat the feature\'s `reviewDepth` as the minimum feature-review depth that\n  must be recorded in `flow_feature_complete`.\n- Keep edits scoped to the active feature. If new scope appears, stop and replan or defer it to another feature.\n- Preserve unrelated user changes in the worktree.\n- When a wrong assumption invalidates the feature, use `flow_feature_reset`; do not pile patches onto a bad path.\n- Do not stage, commit, push, amend, rebase, publish, or mutate releases as part\n  of feature execution. If the user explicitly asks for commit preparation, load\n  `flow-commit` only after `flow_feature_complete` has been recorded, unless the\n  user explicitly asks for a WIP commit path. Keep Git boundaries separate from\n  Flow state recording.\n\n## Validate\n\n- For complex validation, regression-sensitive changes, browser QA, route QA,\n  failure-prone checks, unclear coverage, exploratory QA, or\n  `validationRun` summarization, load `flow-test` (helper rule applies).\n- Read `references/validation-rubric.md` before completing.\n- Run the strongest practical checks for the changed behavior.\n- Record concrete command names, status, and observed results. "Tests pass" is not evidence.\n- Non-final features complete with `validationScope: "targeted"`.\n- The final feature must run a broad project-level gate and use `validationScope: "broad"`.\n\nFor broad validation research, risky changes, or unclear coverage, use\n`../flow/references/parallel-orchestration.md` to fan out named Flow workers.\nUse the mode-to-agent mapping in that reference instead of generic subagents.\nWrite its pass manifest before fan-out, paste the matching handoff template\nfrom `../flow/references/handoff-format.md` into every worker prompt, and\napply its verification tiers to the handoffs that come back.\nThey may report command output they actually ran or propose focused checks; the\nmanager decides what is strong enough to record.\n\nFor independent implementation attempts, use candidate workers only with\nexplicit user authorization plus isolated worktrees or exact non-overlapping\npath ownership. Treat their output as candidate patches. The manager inspects,\nmerges, validates, and records Flow state serially.\n\n## Review and complete\n\nBefore `flow_feature_complete`, obtain a `featureReview` payload. Load\n`flow-review`; for read-only subagent reviews, the manager receives the review\npacket and records both `featureReviewDepth` and `featureReview`.\n\nSend reviewers a compact review packet. Do not rely on the accumulated parent\nconversation. Include only:\n\n- active feature id, title, summary, `reviewDepth`, targets, validation, and dependencies\n- relevant plan requirements, decisions, and final review policy\n- changed files and a short diff summary\n- validation evidence with exact commands, status, and observed result\n- targeted paths or risk lenses the reviewer must inspect\n\nIf the review returns `status: "failed"`, do not fix inside the review pass.\nRecord the failed attempt by calling `flow_feature_complete` with the otherwise\nprepared completion payload, the failed `featureReview`, and the attempted\n`featureReviewDepth`; the runtime will reject completion and update the retry\nbudget. Default to stopping and reporting the blocker. When the user already\nauthorized autonomous implementation, make at most one repair and run one retry\nreview. If the retry fails or the runtime reports review retry budget\nexhausted, stop with the blocker.\n\nIf `flow_status` reports `setup.skills` or `flow-review` cannot be loaded, do\nnot record a Flow-gated `featureReview` or `finalReview`. You may perform an\nadvisory review using available context or the bundled review fallback provided\nby plugin config, then complete with `status: "needs_input"` if review evidence\nis required to proceed.\n\nFor the final feature, also obtain a `finalReview` payload whose `reviewDepth` equals the approved plan\'s `finalReviewPolicy`.\n\nComplete with:\n\n```json\n{\n  "status": "ok",\n  "featureId": "active-feature-id",\n  "summary": "what changed",\n  "artifactsChanged": [{ "path": "src/file.ts" }],\n  "validationRun": [\n    { "command": "bun test tests/foo.test.ts", "status": "passed", "summary": "3 pass, exercised foo behavior" }\n  ],\n  "validationScope": "targeted",\n  "featureReviewDepth": "standard",\n  "featureReview": { "status": "passed", "summary": "review summary", "blockingFindings": [] }\n}\n```\n\nIf `flow_feature_complete` returns a `session.resumePacket` or\n`session.budget.phaseBoundary`, stop after reporting the compact handoff. If\ngenuinely blocked, call `flow_feature_complete` with `status: "needs_input"` and\nan `outcome` that explains the blocker and next step. Never fabricate validation\nor review evidence to force progress.\n';
 
 // skills/flow-test/SKILL.md
 var SKILL_default7 = `---
@@ -1719,6 +1915,10 @@ var FLOW_SKILL_DEFINITIONS = [
         relativePath: "references/planning-examples.md",
         content: planning_examples_default
       },
+      {
+        relativePath: "references/plan-quality-checklist.md",
+        content: plan_quality_checklist_default
+      },
       {
         relativePath: "references/parallel-discovery.md",
         content: parallel_discovery_default
@@ -2335,4 +2535,4 @@ main(process.argv).catch((error) => {
   process.exitCode = 1;
 });
 
-//# debugId=B10F4D7F094C050864756E2164756E21
+//# debugId=CEC53495ABFBEF8464756E2164756E21