opencode-plugin-flow 4.1.16 → 4.1.17

package/dist/cli.js

@@ -1,5 +1,5 @@
 #!/usr/bin/env node
-import{createHash as Pe}from"node:crypto";import{mkdir as je,readdir as re,readFile as Se,rm as We,writeFile as b}from"node:fs/promises";import{createRequire as Oe}from"node:module";import{dirname as Be,join as u,normalize as ze,sep as Ee}from"node:path";var S=`# Flow worker handoff contract
+import{createHash as ze}from"node:crypto";import{mkdir as Ee,readdir as ne,readFile as Be,rm as ie,writeFile as x}from"node:fs/promises";import{createRequire as Ve}from"node:module";import{dirname as Ne,join as h,normalize as Ge,sep as Me}from"node:path";var S=`# Flow worker handoff contract
 
 Flow managers merge only the worker's final response. Treat that response as the
 worker report of record: it must include the assigned scope, what was actually
@@ -137,86 +137,21 @@ live-verified | test-verified | type-check-only | not-verified
 
 The manager must inspect and validate any candidate patch before recording Flow
 completion.
-`;var W=`# Parallel full-wave example
-
-Use this example after \`parallel-orchestration.md\` when a broad Flow task needs a
-concrete worker wave shape.
-
-Goal: review whether bundled Flow command guidance is self-contained and aligned
-with hidden worker permissions.
-
-Serial orientation: the manager reads \`src/config-shared.ts\` enough to identify
-five public command templates and six hidden worker configs. The manager keeps
-\`flow-status\` local because it is one line and does not need a worker.
-
-Coverage gate: ten countable items remain after the local check.
-
-- Slice A: \`flow-auto\`, \`flow-plan\`, and \`flow-run\` templates, expected 3/10.
-- Slice B: \`flow-review\` template plus \`flow-reviewer\` config, expected 2/10.
-- Slice C: remaining hidden worker permission blocks, expected 5/10 after
-  excluding the reviewer already covered by Slice B.
-
-Worker prompts:
-
-\`\`\`text
-Overall goal, context only: confirm Flow public commands are self-contained.
-Mode: evidence
-Your exact slice: flow-auto, flow-plan, and flow-run templates in src/config-shared.ts.
-Expected coverage: 3/3 templates.
-Do: report bundled sections, setup preflight coverage, and any gaps with file:line evidence.
-Do not: call state-changing Flow tools, edit .flow/**, own sibling slices, or make the final Flow verdict.
-Return exactly the matching handoff shape from handoff-format.md.
-\`\`\`
-
-\`\`\`text
-Overall goal, context only: confirm Flow review command and hidden reviewer behavior.
-Mode: review
-Your exact slice: flow-review command template and flow-reviewer config in src/config-shared.ts.
-Expected coverage: 2/2 surfaces.
-Do: separate blocking findings from advisory notes and cite file:line evidence.
-Do not: call state-changing Flow tools, edit .flow/**, own sibling slices, or make the final Flow verdict.
-Return exactly the matching handoff shape from handoff-format.md.
-\`\`\`
-
-\`\`\`text
-Overall goal, context only: confirm hidden worker permissions match the orchestration model.
-Mode: audit
-Your exact slice: flow-evidence-worker, flow-validation-worker, flow-audit-worker, flow-candidate-worker, and flow-verifier-worker permissions in src/config-shared.ts.
-Expected coverage: 5/5 worker permission blocks.
-Do: report edit, bash, task, skill, flow_*, and flow_status permissions with evidence.
-Do not: call state-changing Flow tools, edit .flow/**, own sibling slices, or make the final Flow verdict.
-Return exactly the matching handoff shape from handoff-format.md.
-\`\`\`
-
-Handoff checks: the manager accepts only reports with terminal status, matching
-coverage counts, concrete file:line evidence, confidence tags, and claims inside
-the assigned slice. A claim such as \`[high] validation workers may run commands;
-evidence: src/config-shared.ts:281-288; corroboration: single source\` is usable.
-A claim such as \`[high] permissions look safe; evidence: config reviewed\` is
-dropped or retasked.
-
-Verifier pass: the manager sends any single-source claim that will enter the
-Flow payload to \`flow-verifier-worker\`, for example: \`C1: validation, audit,
-candidate, and verifier workers have bash ask while evidence and review workers
-have bash deny; sources: src/config-shared.ts worker permission blocks\`.
-
-Final synthesis: the manager re-reads the relevant config lines, keeps only
-verified or clearly labeled claims, and records one artifact such as a plan
-decision, review payload, or docs patch. Raw handoffs and unverified suggestions
-do not move into the next wave or user-facing answer.
-`;var O=`# Parallel orchestration
+`;var W=`# Parallel orchestration
 
 Use fan-out when Flow work is broad enough that independent workers can gather
 evidence faster than one linear pass. The manager still owns the Flow session:
 only the manager calls state-changing Flow tools, approves plans, completes
 features, records reviews, or closes sessions.
 
-Read these companion references before a broad wave:
+Read these companion references before a broad parallel pass:
 
+- \`parallel-pass-patterns.md\` for pass selection, effort defaults, and stop or
+  follow-up rules.
 - \`handoff-format.md\` for the exact worker response shapes.
 - \`verification-gates.md\` for coverage checks, handoff acceptance, verifier
   triggers, and synthesis rules.
-- \`parallel-full-wave-example.md\` for a concrete end-to-end wave after the rules
+- \`parallel-pass-example.md\` for a concrete end-to-end pass after the rules
   below are clear.
 
 ## Quick path
@@ -237,9 +172,9 @@ Read these companion references before a broad wave:
 
 - Prefer serial work when the scope is small, tightly coupled, or blocked by one
   decision that must be made before slices are meaningful.
-- A normal first wave is two to five workers with independent slices. Use more
+- A normal first pass is two to five workers with independent slices. Use more
   only when the coverage gate is countable and the slices remain non-overlapping.
-- Run at most one routine follow-up wave. Extra waves need an explicit manager
+- Run at most one routine follow-up pass. Extra passes need an explicit manager
   reason, such as a high-stakes verifier check or a newly discovered bounded
   slice.
 - Do not fan out just to keep agents busy. Every worker should reduce a known
@@ -274,7 +209,7 @@ Skip fan-out when:
    scope, and carry confidence labels.
 8. Send important low-confidence, single-source, contested, or citation-heavy
    claims to \`flow-verifier-worker\`.
-9. Run second waves only for material gaps, conflicts, narrowed scope, or
+9. Run follow-up passes only for material gaps, conflicts, narrowed scope, or
    verification needs.
 10. Apply the manager synthesis barrier: keep only distilled, evidence-backed
     claims and synthesize one Flow artifact, such as plan fields, completion
@@ -363,7 +298,7 @@ Your exact slice: <paths, modules, command, claim ids, risk lens, or worktree>
 Expected coverage: <count, paths, range, or complete question set>
 Do: <bounded actions>
 Do not: call state-changing Flow tools, edit .flow/**, own sibling slices, or make the final Flow verdict.
-Return exactly the matching handoff shape from handoff-format.md.
+Return only the matching Flow handoff from handoff-format.md.
 \`\`\`
 
 For research or current-doc slices, require source checks for versioned or
@@ -390,11 +325,11 @@ the smallest check that can settle the disagreement.
 
 The manager synthesis barrier means raw handoffs do not move forward by default.
 Only claims that survived coverage, evidence, confidence, and verifier checks may
-enter the next wave, Flow payload, patch decision, or user-facing answer.
+enter the next pass, Flow payload, patch decision, or user-facing answer.
 
-## Second waves
+## Follow-up passes
 
-Start a follow-up wave when first-wave handoffs reveal:
+Start a follow-up pass when first-pass handoffs reveal:
 
 - missing coverage in the original slice map.
 - conflicting findings that matter to the Flow decision.
@@ -403,8 +338,167 @@ Start a follow-up wave when first-wave handoffs reveal:
 - bounded implementation candidates after research converges.
 
 Do not recurse by default. If a worker says it needs another worker, the manager
-decides whether that is a second wave and writes the next bounded prompt.
-`;var B='# 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 z=`# Verification gates
+decides whether that is a follow-up pass and writes the next bounded prompt.
+`;var O=`# Parallel pass example
+
+Use this example after \`parallel-orchestration.md\` when a broad Flow task needs a
+concrete pass shape.
+
+Goal: review whether bundled Flow command guidance is self-contained and aligned
+with hidden worker permissions.
+
+Serial orientation: the manager reads \`src/config-shared.ts\` enough to identify
+five public command templates and six hidden worker configs. The manager keeps
+\`flow-status\` local because it is one line and does not need a worker.
+
+Coverage gate: ten countable items remain after the local check.
+
+- Slice A: \`flow-auto\`, \`flow-plan\`, and \`flow-run\` templates, expected 3/10.
+- Slice B: \`flow-review\` template plus \`flow-reviewer\` config, expected 2/10.
+- Slice C: remaining hidden worker permission blocks, expected 5/10 after
+  excluding the reviewer already covered by Slice B.
+
+Worker prompts:
+
+\`\`\`text
+Overall goal, context only: confirm Flow public commands are self-contained.
+Mode: evidence
+Your exact slice: flow-auto, flow-plan, and flow-run templates in src/config-shared.ts.
+Expected coverage: 3/3 templates.
+Do: report bundled sections, setup preflight coverage, and any gaps with file:line evidence.
+Do not: call state-changing Flow tools, edit .flow/**, own sibling slices, or make the final Flow verdict.
+Return only the matching Flow handoff from handoff-format.md.
+\`\`\`
+
+\`\`\`text
+Overall goal, context only: confirm Flow review command and hidden reviewer behavior.
+Mode: review
+Your exact slice: flow-review command template and flow-reviewer config in src/config-shared.ts.
+Expected coverage: 2/2 surfaces.
+Do: separate blocking findings from advisory notes and cite file:line evidence.
+Do not: call state-changing Flow tools, edit .flow/**, own sibling slices, or make the final Flow verdict.
+Return only the matching Flow handoff from handoff-format.md.
+\`\`\`
+
+\`\`\`text
+Overall goal, context only: confirm hidden worker permissions match the orchestration model.
+Mode: audit
+Your exact slice: flow-evidence-worker, flow-validation-worker, flow-audit-worker, flow-candidate-worker, and flow-verifier-worker permissions in src/config-shared.ts.
+Expected coverage: 5/5 worker permission blocks.
+Do: report edit, bash, task, skill, flow_*, and flow_status permissions with evidence.
+Do not: call state-changing Flow tools, edit .flow/**, own sibling slices, or make the final Flow verdict.
+Return only the matching Flow handoff from handoff-format.md.
+\`\`\`
+
+Handoff checks: the manager accepts only reports with terminal status, matching
+coverage counts, concrete file:line evidence, confidence tags, and claims inside
+the assigned slice. A claim such as \`[high] validation workers may run commands;
+evidence: src/config-shared.ts:307-320; corroboration: single source\` is usable.
+A claim such as \`[high] permissions look safe; evidence: config reviewed\` is
+dropped or retasked.
+
+Verifier pass: the manager sends any single-source claim that will enter the
+Flow payload to \`flow-verifier-worker\`, for example: \`C1: validation, audit,
+candidate, and verifier workers have bash ask while evidence and review workers
+have bash deny; sources: src/config-shared.ts worker permission blocks\`.
+
+Final synthesis: the manager re-reads the relevant config lines, keeps only
+verified or clearly labeled claims, and records one artifact such as a plan
+decision, review payload, or docs patch. Raw handoffs and unverified suggestions
+do not move into the next pass or user-facing answer.
+`;var z=`# Parallel pass patterns
+
+Flow uses parallel workers to reduce uncertainty, not to delegate decisions.
+Each pass has a bounded purpose, an explicit coverage rule, and one
+manager-owned synthesis result.
+
+## Choose a pass
+
+| Situation | Flow pass | Output the manager may synthesize |
+| --- | --- | --- |
+| 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 |
+| 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 |
+
+Prefer serial work when one file, command, or design question determines the
+next step. A parallel pass should reduce a named planning, validation, review,
+audit, or implementation uncertainty.
+
+## Pass Shapes
+
+### Discovery pass
+
+Use before planning when the manager has oriented enough to name disjoint slices
+but not enough to write reliable plan fields. Workers read specific modules,
+routes, docs, commands, or risk lenses. The manager turns only evidenced claims
+into plan fields.
+
+### Audit pass
+
+Use when a report starts from candidate findings. Workers actively look for
+guards, lifecycle resets, deployment constraints, and counterexamples before
+reporting a finding. A finding that lacks refutation work stays advisory or
+becomes a follow-up question.
+
+### Review pass
+
+Use when changed files or risks can be reviewed independently. Review workers
+separate blocking findings from advisory notes. The manager resolves conflicts,
+checks cited artifacts, and returns one review payload.
+
+### Validation pass
+
+Use when coverage is unclear or command evidence can be gathered independently.
+Validation workers may run only manager-authorized commands and must report
+exact command, status, raw outcome summary, coverage, confidence, and gaps.
+
+### Verification pass
+
+Use for atomic claims. Give the verifier claim ids, cited sources or commands,
+and the acceptance question. Do not ask a verifier to redesign the work or
+review the whole feature.
+
+### Candidate pass
+
+Use only with explicit user authorization plus isolated worktrees or exact
+non-overlapping path ownership. Candidate patches are proposals until the
+manager inspects, merges or rejects them, and validates the main workspace.
+
+## Effort Defaults
+
+- Start with two to five workers. Use more only when the coverage gate is
+  countable and the manager can verify every handoff.
+- Run at most one routine follow-up pass. Extra passes need a stated reason,
+  such as a high-stakes verification check or a newly discovered bounded slice.
+- Spend effort where being wrong costs more: public API, persistence, security,
+  permissions, release behavior, data loss, and Flow payload claims.
+- Do not fan out to keep agents busy. Worker setup and synthesis have real cost.
+
+## Stop And Extend
+
+Stop after a pass when:
+
+- the coverage rule is satisfied.
+- accepted claims are evidenced, scoped, and confidence-labeled.
+- material single-source, contested, high-stakes, or payload-bound claims have
+  been verified or downgraded.
+- remaining gaps are explicit and do not block the Flow artifact being produced.
+
+Start a bounded follow-up pass only when:
+
+- the original slice map missed material scope.
+- workers disagree on a claim that affects the Flow decision.
+- a high-stakes or payload-bound claim needs verification.
+- a first pass exposes a narrower implementation or validation slice worth
+  isolating.
+
+The manager synthesis barrier applies after every pass: raw handoffs remain
+candidate evidence until the manager checks coverage, resolves conflicts,
+preserves confidence, and records one Flow-owned artifact.
+`;var E='# 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 B=`# Verification gates
 
 Verification is how Flow keeps parallel work from turning into parallel
 guesswork. Worker handoffs are candidate evidence; the manager decides what can
@@ -458,6 +552,25 @@ Use \`flow-verifier-worker\` when a claim is:
 Give the verifier atomic claims, cited sources or commands, and the acceptance
 question. Do not ask it to redesign the work or review the whole feature.
 
+## Verification tiers
+
+Use the cheapest check that matches the risk:
+
+- **Accept locally**: low-risk claims with direct evidence that the manager can
+  cheaply inspect or recount.
+- **Verify once**: single-source, surprising, inferred, citation-heavy, or
+  Flow-payload-bound claims.
+- **Verify strongly**: claims that affect security, persistence, permissions,
+  public API behavior, release behavior, data loss, or blocking review outcome.
+  Use independent verifier checks, manager-run commands, or direct artifact
+  inspection strong enough to settle the claim.
+- **Do not accept**: claims without concrete evidence, claims outside the
+  assigned slice, claims contradicted by inspected artifacts, or claims where the
+  cited evidence supports only the topic rather than the assertion.
+
+Verifier prompts should use stable claim ids, one atomic assertion per id, the
+cited source or command for each id, and the exact acceptance question.
+
 ## Flow payload acceptance
 
 Planning fields may use worker evidence only when the source and scope are clear.
@@ -496,7 +609,7 @@ Before presenting or recording the result:
 
 \`Status: success\` only says the worker believes its slice is done. The manager
 still checks coverage and evidence before trusting the result.
-`;var E=`---
+`;var V=`---
 name: flow
 description: Run the end-to-end Flow loop for skills-first OpenCode work. Use when a user asks for Flow-guided planning through implementation, resumable autonomous delivery, session status, or completion with validation and review gates.
 ---
@@ -518,7 +631,7 @@ Use Flow as a minimal state ledger, not as a framework. Skills provide judgment;
 5. 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\`.
 6. After all features are complete, archive the session with \`flow_session_close\` using \`kind: "completed"\`.
 
-Use \`references/parallel-orchestration.md\` for broad read-only discovery, audit, validation, review, verification, or candidate implementation waves. Hidden Flow workers are injected by plugin config; invoke the named worker when it is available. Its \`references/handoff-format.md\` and \`references/verification-gates.md\` companions define the worker contracts. The manager owns every \`flow_*\` state change.
+Use \`references/parallel-orchestration.md\` for broad read-only discovery, audit, validation, review, verification, or candidate implementation passes. Hidden Flow workers are injected by plugin config; invoke the named worker when it is available. Its \`references/parallel-pass-patterns.md\`, \`references/handoff-format.md\`, and \`references/verification-gates.md\` companions define pass selection, worker contracts, and claim acceptance. The manager owns every \`flow_*\` state change.
 
 Do not commit, push, amend, rebase, publish, or mutate releases during the
 autonomous Flow loop. Load \`flow-commit\` only when the user explicitly asks for
@@ -729,7 +842,7 @@ Weak evidence includes:
 - Public contracts and compatibility shims remain intact or were explicitly planned.
 - Deleted code is actually unreachable or obsolete.
 - Validation can catch a realistic mistake in the refactor.
-`;var V=`# Deslop smell rubric
+`;var M=`# Deslop smell rubric
 
 Use this rubric to turn vague cleanup instincts into reviewable findings.
 
@@ -763,7 +876,7 @@ class; severity; location; evidence read; refutation checked; why it matters; sa
 \`\`\`
 
 Rate as blocking only when the smell materially raises defect risk, blocks planned work, hides behavior, or makes the success claim unverifiable. Style-only cleanup is advisory.
-`;var M=`---
+`;var L=`---
 name: flow-deslop
 description: Clean up and refactor code with evidence-backed code-smell analysis. Use for AI-slop removal, overengineering reduction, maintainability refactors, behavior-preserving cleanup, duplicated or bloated code, speculative abstractions, dead code, or broad cleanup/refactor review.
 ---
@@ -805,11 +918,11 @@ For each claimed smell removal, verify:
 - **blast radius** — public contracts and downstream callers still work.
 
 Never approve cleanup because it "looks cleaner" without evidence. Tests passing is necessary but not sufficient when the refactor changes structure across files.
-`;var L=`# Parallel discovery
+`;var $=`# Parallel discovery
 
 Use this only after a serial orientation pass has identified the repo shape and the likely slices. Workers are read-only evidence gatherers; the planner owns the plan.
 
-For broad waves, also load \`../../flow/references/parallel-orchestration.md\`.
+For broad parallel passes, also load \`../../flow/references/parallel-orchestration.md\`.
 Use its pre-fan-out coverage gate and
 \`../../flow/references/handoff-format.md\` response shapes.
 
@@ -823,7 +936,7 @@ Use its pre-fan-out coverage gate and
 
 ## Flow repo default slices
 
-For this repository, good first-wave slices are:
+For this repository, good first-pass slices are:
 
 - Runtime gates: \`src/runtime/schema.ts\`, \`src/runtime/transitions.ts\`,
   \`src/runtime/api.ts\`, and \`tests/runtime-gates.test.ts\`.
@@ -881,7 +994,7 @@ If workers disagree, inspect the source artifact yourself. If a candidate findin
 Apply the manager synthesis barrier from
 \`../../flow/references/verification-gates.md\`: only distilled, evidence-backed
 claims become plan fields.
-`;var $=`# Planning examples
+`;var Q=`# Planning examples
 
 ## Rate limiting feature set
 
@@ -966,7 +1079,7 @@ Better plan:
 - Validation that only says "manual testing".
 - Targets that name the entire repo.
 - Features with hidden dependencies instead of \`dependsOn\`.
-`;var Q=`---
+`;var K=`---
 name: flow-plan
 description: "Plan Flow work for the v4 skills-first runtime: inspect the repo, decompose a user goal into right-sized features, save a draft with flow_plan_save, and approve it with flow_plan_approve."
 ---
@@ -1036,7 +1149,7 @@ Use only \`finalReviewPolicy: "broad"\` or \`"detailed"\`. These are the canonic
 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.
-`;var K=`# Review rubric
+`;var Y=`# Review rubric
 
 Use this to decide whether a \`featureReview\` or \`finalReview\` payload may pass.
 
@@ -1124,7 +1237,7 @@ When reviewing a findings report, verify findings adversarially:
 - Downgrade or reject findings that do not survive refutation.
 
 Approve only on evidence actually inspected. A review is a claim of coverage, not a courtesy stamp.
-`;var Y=`---
+`;var X=`---
 name: flow-review
 description: "Review Flow work in the v4 runtime: inspect feature or final-session changes, classify findings, and return featureReview or finalReview payloads for flow_feature_complete."
 ---
@@ -1194,7 +1307,7 @@ Use \`status: "failed"\` when any blocking finding remains. Advisory findings ma
   \`finalReview\` payload.
 
 Never approve to unblock completion, fix findings in the review pass, or vouch for validation you did not inspect.
-`;var X=`# Audit findings rubric
+`;var J=`# Audit findings rubric
 
 What counts as a valid finding when the feature's deliverable is a findings report: a codebase audit, a review-first feature, or any report whose findings a later feature will fix. The commands you run are still governed by \`validation-rubric.md\`; this rubric governs the findings themselves.
 
@@ -1247,7 +1360,7 @@ follow-up order — correctness and persisted/user-input surfaces first
 \`\`\`
 
 Never: promote a hypothesis to blocking severity; cite a line you did not read in context; rate severity against a deployment model the product does not have; pad the report to look thorough — six verified findings outrank nine where three die on first contact.
-`;var J=`# Validation evidence rubric
+`;var Z=`# Validation evidence rubric
 
 Use this before recording \`flow_feature_complete\`.
 
@@ -1304,7 +1417,7 @@ Broad validation usually means the repo's full check command, full relevant test
 - If validation needs external access, missing credentials, or ambiguous user input, record \`status: "needs_input"\` with an honest \`outcome\`.
 
 Never trim failing output, relabel a failed command as passed, or use "not run" as completion evidence.
-`;var Z=`---
+`;var H=`---
 name: flow-run
 description: "Execute one approved Flow feature in the v4 runtime: start a feature with flow_run_start, make scoped changes, gather real validation evidence, obtain review payloads, and complete with flow_feature_complete."
 ---
@@ -1391,7 +1504,7 @@ Complete with:
 \`\`\`
 
 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 H=`---
+`;var ee=`---
 name: flow-test
 description: Test, validate, make test plans, triage failures, and gather Flow validation evidence. Use when selecting checks, running tests, running browser QA for UI changes, classifying failures, or preparing validationRun evidence for flow_feature_complete.
 ---
@@ -1515,7 +1628,7 @@ covered. Static inspection alone is a gap for behavioral changes.
 
 Never relabel a failed command as passed, invent output, or use "not run" as
 completion evidence.
-`;var ee=`# UI quality rubric
+`;var ae=`# UI quality rubric
 
 Use this rubric for frontend planning, implementation, and review.
 
@@ -1559,7 +1672,7 @@ class; severity; location or screenshot area; evidence inspected; user impact; f
 \`\`\`
 
 Blocking UI findings are issues that prevent task completion, hide required information, break accessibility basics, create incoherent layout at supported sizes, or make the visual success claim unverifiable.
-`;var ae=`# Visual verification workflow
+`;var te=`# Visual verification workflow
 
 Use this workflow when UI changes can be run locally. Flow execution may create visual evidence; Flow review usually assesses recorded evidence because the reviewer is read-only.
 
@@ -1599,7 +1712,7 @@ Record the reason and use the strongest available substitute:
 - code inspection against existing component patterns.
 
 Do not claim visual polish was verified if no visual artifact was inspected.
-`;var te=`---
+`;var oe=`---
 name: flow-ui-quality
 description: Review and improve frontend UI quality for Flow work. Use for UX/UI design, frontend polish, visual quality review, responsive and accessible interfaces, interaction states, screenshots, browser-verified UI work, and avoiding generic AI-generated UI.
 ---
@@ -1647,23 +1760,23 @@ Approve only when the interface is both useful and inspectable:
 - Screenshot/browser evidence supports the claim whenever feasible.
 
 Never approve a UI change based only on code shape. If users will judge it visually, Flow evidence should include visual inspection.
-`;var y=[{name:"flow",files:[{relativePath:"SKILL.md",content:E},{relativePath:"references/recovery-playbook.md",content:B},{relativePath:"references/parallel-orchestration.md",content:O},{relativePath:"references/parallel-full-wave-example.md",content:W},{relativePath:"references/handoff-format.md",content:S},{relativePath:"references/verification-gates.md",content:z}]},{name:"flow-plan",files:[{relativePath:"SKILL.md",content:Q},{relativePath:"references/planning-examples.md",content:$},{relativePath:"references/parallel-discovery.md",content:L}]},{name:"flow-run",files:[{relativePath:"SKILL.md",content:Z},{relativePath:"references/validation-rubric.md",content:J},{relativePath:"references/audit-rubric.md",content:X}]},{name:"flow-test",files:[{relativePath:"SKILL.md",content:H}]},{name:"flow-review",files:[{relativePath:"SKILL.md",content:Y},{relativePath:"references/review-rubric.md",content:K}]},{name:"flow-deslop",files:[{relativePath:"SKILL.md",content:M},{relativePath:"references/smell-rubric.md",content:V},{relativePath:"references/refactor-workflow.md",content:G}]},{name:"flow-ui-quality",files:[{relativePath:"SKILL.md",content:te},{relativePath:"references/ui-rubric.md",content:ee},{relativePath:"references/visual-verification.md",content:ae}]},{name:"flow-commit",files:[{relativePath:"SKILL.md",content:N}]}];var q=".flow-skill-version";function _(){return process.env.HOME??process.env.USERPROFILE??""}function D(e=_()){return u(e,".config","opencode","skills")}function g(e){return Pe("sha256").update(e).digest("hex")}function k(e,a){return[`version=${a}`,...e.files.map((t)=>`file=${t.relativePath} sha256=${g(t.content)}`),""].join(`
-`)}async function m(e){try{return await Se(e,"utf8")}catch(a){if(a.code==="ENOENT")return null;throw a}}function T(e){let a=new Map;if(!e)return a;for(let t of e.split(/\r?\n/)){let r=/^file=(.+) sha256=([a-f0-9]{64})$/.exec(t)??/^file=(.+)=sha256:([a-f0-9]{64})$/.exec(t);if(r?.[1]&&r[2])a.set(r[1],r[2]);let s=/^hash=sha256:([a-f0-9]{64})$/.exec(t);if(s?.[1]&&!a.has("SKILL.md"))a.set("SKILL.md",s[1])}return a}function Ne(e){if(!e)return null;for(let a of e.split(/\r?\n/)){let t=/^version=(.+)$/.exec(a);if(t?.[1])return t[1]}return null}function x(e,a){let t=ze(u(e,...a.split("/")));if(t!==e&&t.startsWith(`${e}${Ee}`))return t;throw Error(`Unsafe skill file path '${a}'.`)}async function Ge(e,a){let t=`${e}.backup.${g(a).slice(0,12)}`;for(let r=0;;r+=1){let s=r===0?t:`${t}.${r}`;try{return await b(s,a,{encoding:"utf8",flag:"wx"}),s}catch(n){if(n.code==="EEXIST")continue;throw n}}}async function Ve(e,a,t){let r=u(t,e.name),s=u(r,q),n=await m(s),d=T(n);if(await m(u(r,"SKILL.md"))!==null&&n===null)return{name:e.name,action:"skipped_foreign"};let i=!1,l=[];for(let o of e.files){let c=x(r,o.relativePath),h=await m(c);if(h===o.content)continue;i=!0;let w=d.get(o.relativePath);if(h!==null&&(w?g(h)!==w:n!==null))l.push(await Ge(c,h))}if(!i&&n===k(e,a))return{name:e.name,action:"unchanged"};if(!i)return await b(s,k(e,a),"utf8"),{name:e.name,action:"marker_updated"};let v=n!==null;for(let o of e.files){let c=x(r,o.relativePath);await je(Be(c),{recursive:!0}),await b(c,o.content,"utf8")}return await b(s,k(e,a),"utf8"),{name:e.name,action:l.length>0?"updated_with_backup":v?"updated":"installed",...l.length>0?{backupPaths:l}:{}}}function Me(){return y.map((e)=>e.name)}function Le(e){return`npx -y opencode-plugin-flow@${e} doctor`}function F(){if(process.env.npm_package_version)return process.env.npm_package_version;try{let e=Oe(import.meta.url);for(let a of["../package.json","../../package.json"])try{let t=e(a);if(t.version)return t.version}catch{}}catch{}return"0.0.0"}async function ne(e,a=_()){let t=D(a);return Promise.all(y.map((r)=>Ve(r,e,t)))}async function se(e=F(),a=_()){let t=D(a),r=new Set(Me()),s=await Promise.all(y.map(async(o)=>{let c=u(t,o.name),h=await m(u(c,q)),w=Ne(h),P=T(h);if(await m(u(c,"SKILL.md"))===null)return{name:o.name,path:c,status:"missing",markerVersion:w,missingFiles:o.files.map((f)=>f.relativePath),editedFiles:[],outdatedFiles:[]};if(h===null)return{name:o.name,path:c,status:"foreign",markerVersion:w,missingFiles:[],editedFiles:[],outdatedFiles:[]};let R=[],U=[],C=[];for(let f of o.files){let A=await m(x(c,f.relativePath));if(A===null){R.push(f.relativePath);continue}if(A===f.content)continue;let j=P.get(f.relativePath);if(j&&g(A)!==j){U.push(f.relativePath);continue}C.push(f.relativePath)}let de=h!==k(o,e),le=R.length>0?"incomplete":U.length>0?"edited":de||C.length>0?"outdated":"ok";return{name:o.name,path:c,status:le,markerVersion:w,missingFiles:R,editedFiles:U,outdatedFiles:C}})),n=[];try{n=await re(t)}catch(o){if(o.code!=="ENOENT")throw o}let d=n.filter((o)=>(o==="flow"||o.startsWith("flow-"))&&!r.has(o)).map((o)=>u(t,o)),p=s.filter((o)=>["missing","incomplete","outdated"].includes(o.status)).map((o)=>o.name),i=s.filter((o)=>["foreign","edited"].includes(o.status)).map((o)=>o.name),l=i.length>0,v=p.length>0;return{status:l?"action_required":v?"sync_required":"ok",version:e,root:t,expectedSkills:[...r],skills:s,syncRequiredSkills:p,actionRequiredSkills:i,unmanagedFlowSkills:d}}function oe(e,a,t){if(t.length===0)return;e.push(`- ${a}: ${t.join(", ")}`)}function ie(e){let a=["Flow doctor",`- status: ${e.status}`,`- plugin version: ${e.version}`,`- skills root: ${e.root}`,`- expected skills: ${e.expectedSkills.join(", ")}`];oe(a,"startup sync can install/update",e.syncRequiredSkills),oe(a,"needs user decision",e.actionRequiredSkills),a.push("","Skills:");for(let t of e.skills){if(a.push(`- ${t.name}: ${t.status} (${t.path})${t.markerVersion?` marker=${t.markerVersion}`:""}`),t.missingFiles.length>0)a.push(`  missing: ${t.missingFiles.join(", ")}`);if(t.editedFiles.length>0)a.push(`  edited: ${t.editedFiles.join(", ")}`);if(t.outdatedFiles.length>0)a.push(`  outdated: ${t.outdatedFiles.join(", ")}`)}if(e.unmanagedFlowSkills.length>0){a.push("","Unmanaged Flow-like skill folders:");for(let t of e.unmanagedFlowSkills)a.push(`- ${t}`)}if(a.push("","Recommendation:"),e.status==="ok")a.push("- Flow skills are present and current.");else if(e.status==="sync_required")a.push("- Start or restart OpenCode with opencode-plugin-flow enabled so startup sync can install or update the listed skills. If Flow then reports restart_required, restart OpenCode once more so the refreshed skill registry is used.");else a.push("- Resolve user-owned or edited managed skill folders, then restart OpenCode. Move a folder aside to let Flow recreate it, or keep it intentionally as a local override.");return a.push(`- Details command: ${Le(e.version)}`),`${a.join(`
+`;var k=[{name:"flow",files:[{relativePath:"SKILL.md",content:V},{relativePath:"references/recovery-playbook.md",content:E},{relativePath:"references/parallel-orchestration.md",content:W},{relativePath:"references/parallel-pass-patterns.md",content:z},{relativePath:"references/parallel-pass-example.md",content:O},{relativePath:"references/handoff-format.md",content:S},{relativePath:"references/verification-gates.md",content:B}]},{name:"flow-plan",files:[{relativePath:"SKILL.md",content:K},{relativePath:"references/planning-examples.md",content:Q},{relativePath:"references/parallel-discovery.md",content:$}]},{name:"flow-run",files:[{relativePath:"SKILL.md",content:H},{relativePath:"references/validation-rubric.md",content:Z},{relativePath:"references/audit-rubric.md",content:J}]},{name:"flow-test",files:[{relativePath:"SKILL.md",content:ee}]},{name:"flow-review",files:[{relativePath:"SKILL.md",content:X},{relativePath:"references/review-rubric.md",content:Y}]},{name:"flow-deslop",files:[{relativePath:"SKILL.md",content:L},{relativePath:"references/smell-rubric.md",content:M},{relativePath:"references/refactor-workflow.md",content:G}]},{name:"flow-ui-quality",files:[{relativePath:"SKILL.md",content:oe},{relativePath:"references/ui-rubric.md",content:ae},{relativePath:"references/visual-verification.md",content:te}]},{name:"flow-commit",files:[{relativePath:"SKILL.md",content:N}]}];var D=".flow-skill-version";function _(){return process.env.HOME??process.env.USERPROFILE??""}function T(e=_()){return h(e,".config","opencode","skills")}function v(e){return ze("sha256").update(e).digest("hex")}function F(e,a){return[`version=${a}`,...e.files.map((t)=>`file=${t.relativePath} sha256=${v(t.content)}`),""].join(`
+`)}async function f(e){try{return await Be(e,"utf8")}catch(a){if(a.code==="ENOENT")return null;throw a}}function P(e){let a=new Map;if(!e)return a;for(let t of e.split(/\r?\n/)){let r=/^file=(.+) sha256=([a-f0-9]{64})$/.exec(t)??/^file=(.+)=sha256:([a-f0-9]{64})$/.exec(t);if(r?.[1]&&r[2])a.set(r[1],r[2]);let n=/^hash=sha256:([a-f0-9]{64})$/.exec(t);if(n?.[1]&&!a.has("SKILL.md"))a.set("SKILL.md",n[1])}return a}function Le(e){if(!e)return null;for(let a of e.split(/\r?\n/)){let t=/^version=(.+)$/.exec(a);if(t?.[1])return t[1]}return null}function b(e,a){let t=Ge(h(e,...a.split("/")));if(t!==e&&t.startsWith(`${e}${Me}`))return t;throw Error(`Unsafe skill file path '${a}'.`)}async function re(e,a){let t=`${e}.backup.${v(a).slice(0,12)}`;for(let r=0;;r+=1){let n=r===0?t:`${t}.${r}`;try{return await x(n,a,{encoding:"utf8",flag:"wx"}),n}catch(s){if(s.code==="EEXIST")continue;throw s}}}async function $e(e,a,t){let r=h(t,e.name),n=h(r,D),s=await f(n),d=P(s);if(await f(h(r,"SKILL.md"))!==null&&s===null)return{name:e.name,action:"skipped_foreign"};let c=!1,l=[],y=new Set(e.files.map((i)=>i.relativePath));for(let i of e.files){let u=b(r,i.relativePath),p=await f(u);if(p===i.content)continue;c=!0;let g=d.get(i.relativePath);if(p!==null&&(g?v(p)!==g:s!==null))l.push(await re(u,p))}for(let[i,u]of d){if(y.has(i))continue;let p=b(r,i),g=await f(p);if(g===null)continue;if(c=!0,v(g)!==u)l.push(await re(p,g));await ie(p,{force:!0})}if(!c&&s===F(e,a))return{name:e.name,action:"unchanged"};if(!c)return await x(n,F(e,a),"utf8"),{name:e.name,action:"marker_updated"};let o=s!==null;for(let i of e.files){let u=b(r,i.relativePath);await Ee(Ne(u),{recursive:!0}),await x(u,i.content,"utf8")}return await x(n,F(e,a),"utf8"),{name:e.name,action:l.length>0?"updated_with_backup":o?"updated":"installed",...l.length>0?{backupPaths:l}:{}}}function Qe(){return k.map((e)=>e.name)}function Ke(e){return`npx -y opencode-plugin-flow@${e} doctor`}function I(){if(process.env.npm_package_version)return process.env.npm_package_version;try{let e=Ve(import.meta.url);for(let a of["../package.json","../../package.json"])try{let t=e(a);if(t.version)return t.version}catch{}}catch{}return"0.0.0"}async function ce(e,a=_()){let t=T(a);return Promise.all(k.map((r)=>$e(r,e,t)))}async function de(e=I(),a=_()){let t=T(a),r=new Set(Qe()),n=await Promise.all(k.map(async(o)=>{let i=h(t,o.name),u=await f(h(i,D)),p=Le(u),g=P(u);if(await f(h(i,"SKILL.md"))===null)return{name:o.name,path:i,status:"missing",markerVersion:p,missingFiles:o.files.map((w)=>w.relativePath),editedFiles:[],outdatedFiles:[]};if(u===null)return{name:o.name,path:i,status:"foreign",markerVersion:p,missingFiles:[],editedFiles:[],outdatedFiles:[]};let U=[],A=[],C=[];for(let w of o.files){let q=await f(b(i,w.relativePath));if(q===null){U.push(w.relativePath);continue}if(q===w.content)continue;let j=g.get(w.relativePath);if(j&&v(q)!==j){A.push(w.relativePath);continue}C.push(w.relativePath)}let he=u!==F(o,e),fe=U.length>0?"incomplete":A.length>0?"edited":he||C.length>0?"outdated":"ok";return{name:o.name,path:i,status:fe,markerVersion:p,missingFiles:U,editedFiles:A,outdatedFiles:C}})),s=[];try{s=await ne(t)}catch(o){if(o.code!=="ENOENT")throw o}let d=s.filter((o)=>(o==="flow"||o.startsWith("flow-"))&&!r.has(o)).map((o)=>h(t,o)),m=n.filter((o)=>["missing","incomplete","outdated"].includes(o.status)).map((o)=>o.name),c=n.filter((o)=>["foreign","edited"].includes(o.status)).map((o)=>o.name),l=c.length>0,y=m.length>0;return{status:l?"action_required":y?"sync_required":"ok",version:e,root:t,expectedSkills:[...r],skills:n,syncRequiredSkills:m,actionRequiredSkills:c,unmanagedFlowSkills:d}}function se(e,a,t){if(t.length===0)return;e.push(`- ${a}: ${t.join(", ")}`)}function le(e){let a=["Flow doctor",`- status: ${e.status}`,`- plugin version: ${e.version}`,`- skills root: ${e.root}`,`- expected skills: ${e.expectedSkills.join(", ")}`];se(a,"startup sync can install/update",e.syncRequiredSkills),se(a,"needs user decision",e.actionRequiredSkills),a.push("","Skills:");for(let t of e.skills){if(a.push(`- ${t.name}: ${t.status} (${t.path})${t.markerVersion?` marker=${t.markerVersion}`:""}`),t.missingFiles.length>0)a.push(`  missing: ${t.missingFiles.join(", ")}`);if(t.editedFiles.length>0)a.push(`  edited: ${t.editedFiles.join(", ")}`);if(t.outdatedFiles.length>0)a.push(`  outdated: ${t.outdatedFiles.join(", ")}`)}if(e.unmanagedFlowSkills.length>0){a.push("","Unmanaged Flow-like skill folders:");for(let t of e.unmanagedFlowSkills)a.push(`- ${t}`)}if(a.push("","Recommendation:"),e.status==="ok")a.push("- Flow skills are present and current.");else if(e.status==="sync_required")a.push("- Start or restart OpenCode with opencode-plugin-flow enabled so startup sync can install or update the listed skills. If Flow then reports restart_required, restart OpenCode once more so the refreshed skill registry is used.");else a.push("- Resolve user-owned or edited managed skill folders, then restart OpenCode. Move a folder aside to let Flow recreate it, or keep it intentionally as a local override.");return a.push(`- Details command: ${Ke(e.version)}`),`${a.join(`
 `)}
-`}async function ce(e=_()){let a=D(e),t=[],r=[],s;try{s=await re(a)}catch(n){if(n.code==="ENOENT")return{removed:t,kept:r};throw n}for(let n of s){if(n!=="flow"&&!n.startsWith("flow-"))continue;let d=u(a,n),p=await m(u(d,q));if(p===null){r.push(d);continue}let i=T(p),l=!1;for(let[v,o]of i){let c=await m(x(d,v));if(c!==null&&g(c)!==o){l=!0;break}}if(l){r.push(d);continue}await We(d,{recursive:!0,force:!0}),t.push(d)}return{removed:t,kept:r}}function I(){return["usage: opencode-plugin-flow <doctor|sync|uninstall> [options]","","commands:","  doctor              Inspect managed Flow skills","  sync                Install or refresh managed Flow skills","  uninstall           Remove pristine Flow-owned managed skills","","doctor options:","  --json              Write the doctor report as JSON","  --check, --strict   Exit nonzero when doctor status is not ok","","global options:","  --help              Show this help","  --version           Print the plugin version"].join(`
-`)}function $e(e,a){return e.every((t)=>a.has(t))}function Qe(e,a){if(a.json){process.stdout.write(`${JSON.stringify(e,null,2)}
-`);return}process.stdout.write(ie(e))}async function Ke(e){let a=e[2],t=e.slice(3);if(a==="--help"||a==="-h"){process.stdout.write(`${I()}
-`);return}if(a==="--version"||a==="-v"){process.stdout.write(`${F()}
-`);return}if(a!=="uninstall"&&a!=="doctor"&&a!=="sync"){process.stderr.write(`${I()}
-`),process.exitCode=2;return}if(a==="doctor"){if(!$e(t,new Set(["--json","--check","--strict"]))){process.stderr.write(`${I()}
-`),process.exitCode=2;return}let n=await se();if(Qe(n,{json:t.includes("--json")}),(n.status==="sync_required"||n.status==="action_required")&&(t.includes("--check")||t.includes("--strict")))process.exitCode=1;return}if(t.length>0){process.stderr.write(`${I()}
-`),process.exitCode=2;return}if(a==="sync"){let s=F(),n=await ne(s),d=n.filter((i)=>["installed","updated","updated_with_backup"].includes(i.action)),p=n.filter((i)=>i.action==="skipped_foreign");process.stdout.write(`Flow skill sync (${s})
-`);for(let i of n){process.stdout.write(`- ${i.name}: ${i.action}
-`);for(let l of i.backupPaths??[])process.stdout.write(`  backup: ${l}
+`}async function ue(e=_()){let a=T(e),t=[],r=[],n;try{n=await ne(a)}catch(s){if(s.code==="ENOENT")return{removed:t,kept:r};throw s}for(let s of n){if(s!=="flow"&&!s.startsWith("flow-"))continue;let d=h(a,s),m=await f(h(d,D));if(m===null){r.push(d);continue}let c=P(m),l=!1;for(let[y,o]of c){let i=await f(b(d,y));if(i!==null&&v(i)!==o){l=!0;break}}if(l){r.push(d);continue}await ie(d,{recursive:!0,force:!0}),t.push(d)}return{removed:t,kept:r}}function R(){return["usage: opencode-plugin-flow <doctor|sync|uninstall> [options]","","commands:","  doctor              Inspect managed Flow skills","  sync                Install or refresh managed Flow skills","  uninstall           Remove pristine Flow-owned managed skills","","doctor options:","  --json              Write the doctor report as JSON","  --check, --strict   Exit nonzero when doctor status is not ok","","global options:","  --help              Show this help","  --version           Print the plugin version"].join(`
+`)}function Ye(e,a){return e.every((t)=>a.has(t))}function Xe(e,a){if(a.json){process.stdout.write(`${JSON.stringify(e,null,2)}
+`);return}process.stdout.write(le(e))}async function Je(e){let a=e[2],t=e.slice(3);if(a==="--help"||a==="-h"){process.stdout.write(`${R()}
+`);return}if(a==="--version"||a==="-v"){process.stdout.write(`${I()}
+`);return}if(a!=="uninstall"&&a!=="doctor"&&a!=="sync"){process.stderr.write(`${R()}
+`),process.exitCode=2;return}if(a==="doctor"){if(!Ye(t,new Set(["--json","--check","--strict"]))){process.stderr.write(`${R()}
+`),process.exitCode=2;return}let s=await de();if(Xe(s,{json:t.includes("--json")}),(s.status==="sync_required"||s.status==="action_required")&&(t.includes("--check")||t.includes("--strict")))process.exitCode=1;return}if(t.length>0){process.stderr.write(`${R()}
+`),process.exitCode=2;return}if(a==="sync"){let n=I(),s=await ce(n),d=s.filter((c)=>["installed","updated","updated_with_backup"].includes(c.action)),m=s.filter((c)=>c.action==="skipped_foreign");process.stdout.write(`Flow skill sync (${n})
+`);for(let c of s){process.stdout.write(`- ${c.name}: ${c.action}
+`);for(let l of c.backupPaths??[])process.stdout.write(`  backup: ${l}
 `)}if(d.length>0)process.stdout.write(`Restart OpenCode so the refreshed skill registry is used.
-`);if(p.length>0)process.stdout.write(`Some managed skill folders are user-owned or edited; run doctor for repair guidance.
-`);return}let r=await ce();for(let s of r.removed)process.stdout.write(`Removed Flow skill: ${s}
-`);for(let s of r.kept)process.stdout.write(`Kept non-Flow or user-edited skill: ${s}
+`);if(m.length>0)process.stdout.write(`Some managed skill folders are user-owned or edited; run doctor for repair guidance.
+`);return}let r=await ue();for(let n of r.removed)process.stdout.write(`Removed Flow skill: ${n}
+`);for(let n of r.kept)process.stdout.write(`Kept non-Flow or user-edited skill: ${n}
 `);process.stdout.write(`Remove opencode-plugin-flow from your OpenCode plugin config and restart OpenCode.
-`)}Ke(process.argv).catch((e)=>{process.stderr.write(`${e instanceof Error?e.message:String(e)}
+`)}Je(process.argv).catch((e)=>{process.stderr.write(`${e instanceof Error?e.message:String(e)}
 `),process.exitCode=1});