opencode-plugin-flow 6.6.0 → 6.8.0

package/CHANGELOG.md

@@ -6,6 +6,97 @@ One short entry per release, written for users deciding whether to upgrade.
 
 No changes yet.
 
+## [6.8.0] - 2026-07-24
+
+Checkpoint-safe continuation and leaner review convergence:
+
+- `/flow-auto` now remains waiting through same-revision checkpoint replies and
+  enqueues exactly one continuation only after the same host observes an
+  accepted Flow mutation whose tool assistant resolves through cached
+  `message.updated` parentage to the authoritative user reply; missing or
+  mismatched provenance fails closed. Mechanical progress must match that
+  revision exactly, except for the single state-constrained reviewer-result
+  revision after an authenticated `flow_review_start`.
+- Compaction carries reply authority only across an authenticated trigger
+  assistant, automatic compaction marker, summary assistant, and successor user
+  lineage while authority remains unchanged; incomplete or unrelated lineage
+  fails closed.
+- From idle, auto-routing requires a same-host accepted non-replayed
+  `flow_plan_save` for the newly created Flow session; a baseline that already
+  has a pending reviewer retains a narrow temporal exception.
+- `/flow-auto stop` and `/flow-auto cancel` now revoke the process-local
+  continuation lease without closing, deferring, abandoning, or otherwise
+  mutating the durable Flow session.
+- Manager command rewrites preserve every nonblank raw request, including
+  exterior whitespace, exactly once while keeping synthetic guidance separate.
+- Initial auto/run prompts, dynamically loaded run guidance, compaction context,
+  and synthetic continuations share one concise manager kernel for reserved
+  roles, the exact `failedReviewCount === 1` retry gate, and current-source plus
+  relevant baseline evidence.
+- Guidance represents race-heavy risk checks as one transition matrix and
+  preserves stable finding IDs, relevant baseline facts, and prior dispositions.
+  Ordinary reviewer summaries keep IDs mapped to the active feature or supplied
+  explicitly in its packet; final review covers every approved requirement or
+  feature ID. Both keep each still-live prior finding through failed reviews; a
+  proven repair remains pending until a later passing review, so closure and
+  archive replay need no prerequisite detail read or unbounded historical
+  ledger. The Session v5 schema is unchanged.
+  Provider/model execution remains unverified unless the opt-in manual canary
+  is run.
+
+Install or update:
+
+```bash
+opencode plugin opencode-plugin-flow@6.8.0 --global --force
+```
+
+## [6.7.0] - 2026-07-23
+
+Bounded auto-continuation lore keeps user-authorized goals moving while making
+checkpoints, retries, and validation freshness explicit:
+
+- `/flow-auto` now treats ready features and completed sessions as mechanical
+  loop states, so authorized work continues without an intermediate “ready for
+  the next feature” handoff. Its host lease starts from a provisional compact
+  baseline and auto-routes only after the initiating turn advances that same
+  Flow session; unchanged or replacement sessions fail closed, while
+  conversational plan approval remains resumable.
+- Failed features are never selected implicitly while their latest relevant
+  reviewed outcome remains failed. Auto mode may continue untouched independent
+  work; when only retry-required candidates remain it waits for direction.
+  While a failed run is blocked, optional `nextFeatureId` makes its authorized
+  reset and exact next run atomic. Once that run is superseded and status is
+  ready, explicit `flow_run_start(featureId)` starts its authorized retry. This
+  adds no durable hold or retry ledger.
+- Each feature now receives a before-edit evidence/environment preflight and
+  adversarial risk checklist. Manager policy withholds review while required
+  evidence is knowingly skipped, and reviewers treat missing proof as blocking;
+  no skipped-evidence state is persisted. Workers receive the checklist before
+  coding, and reviewers explicitly inspect adjacent/repeated transitions,
+  overlapping invariants, base diffs, and file modes.
+- Stable source finding IDs remain traceable in immutable feature prose.
+  Active Flow work uses only the reserved worker and reviewer roles, while
+  precise missing-evidence review failures can request manager-run proof.
+- Accepted validation markers expose their recorded revision as a concurrency
+  token, avoiding status reads made only to recover it. Only `passed: true` may
+  feed review while all runtime gates hold; failed, incomplete, and
+  source-drifted observations may use the token only for fresh validation. A
+  drifted marker reports `passed: false` plus its explicit ineligibility reason.
+  New review admission requires its current-source pass to be newer than the
+  latest relevant failure or drift; accepted reviews remain grandfathered.
+- Status workflow data now includes a small non-authoritative timer for the
+  latest `/flow-auto` in the current plugin process. Active milliseconds are
+  coordinator-classified wall time, not CPU or pure coding time; user-wait
+  milliseconds cover only projected plan-approval and
+  `await-user-direction` checkpoints. Paused, inactive, errored, and
+  unprojected waits are excluded, and reload resets the timer.
+
+Install or update:
+
+```bash
+opencode plugin opencode-plugin-flow@6.7.0 --global --force
+```
+
 ## [6.6.0] - 2026-07-22
 
 Projection-guided recovery lore makes Flow's next step easier to understand

package/README.md

@@ -21,11 +21,11 @@ into the active goal.
 Install the exact npm release through OpenCode:
 
 ```bash
-opencode plugin opencode-plugin-flow@6.6.0 --global --force
+opencode plugin opencode-plugin-flow@6.8.0 --global --force
 ```
 
 Omit `--global` for project scope. Exact version pins do not update
-automatically. To update, replace `6.6.0` with the new release and rerun the
+automatically. To update, replace `6.8.0` with the new release and rerun the
 command.
 
 Before upgrading from Flow v5 or earlier, finish or explicitly close any active
@@ -43,7 +43,7 @@ The equivalent manual project configuration is:
 ```json
 {
   "$schema": "https://opencode.ai/config.json",
-  "plugin": ["opencode-plugin-flow@6.6.0"]
+  "plugin": ["opencode-plugin-flow@6.8.0"]
 }
 ```
 
@@ -64,7 +64,17 @@ Start a complete workflow:
 Flow inspects the worktree, proposes a feature plan, and asks for approval
 unless your request already authorized implementation. It then runs one
 runnable feature at a time, validates the actual workspace, obtains an
-independent review, and repeats until it can close the session.
+independent review, and repeats until it can close the session. While
+implementation remains authorized, `ready` and `completed` are internal loop
+states: `/flow-auto` does not hand back “ready for the next feature” or wait for
+another command between passing features. From idle, auto-routing first requires
+a same-host accepted non-replayed `flow_plan_save` for the created Flow session;
+an active baseline that already has a pending reviewer retains a narrow temporal
+exception for that completion.
+
+Send `/flow-auto stop` or `/flow-auto cancel` in the same OpenCode session to
+revoke only the process-local continuation lease. This does not close, defer,
+abandon, or otherwise mutate the durable Flow session.
 
 Before every manager-owned Flow mutation, including direct `/flow-plan` and
 `/flow-run` use, the manager compares the current request with the active goal.
@@ -76,13 +86,53 @@ continue, defer, or abandon the active work. If that work is completed but not
 closed, Flow closes it as completed before starting the new request.
 
 Existing implementation authority carries across approval and feature outcomes.
-Only the first in-scope failed review automatically resets for one fresh full
-retry; a `[scope-blocker]` checkpoints immediately. A second failed review
-projects `await-user-direction`, so Flow reports the blocker and waits for
-explicit direction before one additional attempt. The active session remains
-authoritative while it waits. Ordinary blocking findings are in-scope by
-default; a reviewer uses `[scope-blocker]` only when the required repair would
-materially exceed the approved plan.
+Only when `failedReviewCount === 1` and no `[scope-blocker]` is present may Flow
+automatically reset and atomically start one fresh full retry. A
+feature whose latest relevant reviewed outcome remains failed is never selected
+implicitly. `/flow-auto` may continue untouched, dependency-independent
+features, but when only retry-required candidates remain it projects
+`await-user-direction`. Flow then reports the blocker and waits for an explicit
+retry or independent-feature choice. While the failed run is still blocked, the
+chosen feature is attached to `flow_feature_reset` as `nextFeatureId`, so reset
+and the next run are one operation. If independent work later finishes and only
+the superseded failed feature remains, status is ready with
+`await-user-direction`; explicit retry then uses `flow_run_start` with that
+feature's exact `featureId`, because there is no blocked run left to reset. The
+active session remains authoritative while it waits. Ordinary blocking findings
+are in-scope by default; a reviewer uses `[scope-blocker]` only when the required
+repair would materially exceed the approved plan. After a user checkpoint, the
+process-local continuation resumes only after that same OpenCode session observes
+an accepted non-replayed Flow mutation whose tool assistant ID resolves, through
+the cached `message.updated` `parentID`, to the authoritative user reply. A
+missing or mismatched origin fails closed. Another host cannot establish that
+authority. The mechanical projection must match the credited revision exactly;
+the sole successor allowance is one revision after an authenticated
+`flow_review_start`, where the state machine admits the reserved reviewer result.
+Compaction transfers the reply authority only across an authenticated trigger
+assistant, automatic compaction marker, summary assistant, and successor user
+lineage while the authority is unchanged; an incomplete or unrelated lineage
+fails closed.
+
+Before coding each feature, Flow inventories required evidence and its
+environment, then applies an adversarial risk checklist covering failure
+ordering, repeated and interrupted operations, adjacent state transitions,
+overlapping invariants, and relevant file-mode or platform risks. While required
+behavior or environment evidence is knowingly skipped, manager policy forbids
+requesting review; the reviewer treats proof required to approve the outcome as
+blocking if it is missing from the packet. Flow persists no skipped-evidence
+ledger. Asking the user remains the default when external evidence or authority
+is missing. At a blocked checkpoint, atomic reset-and-start can discard that
+attempt and continue the
+exact authorized retry or dependency-independent feature. At a ready retry
+checkpoint, explicit feature start resumes the already superseded failure.
+Neither route adds a hold or second blocker ledger.
+
+Flow guidance represents the checklist for concurrency and state-machine work
+as one compact transition matrix shared by workers and the reviewer. Review
+packets reuse a refreshed run baseline, carry only feature-relevant file facts
+until final review, and preserve source IDs, current-source evidence, risk
+coverage, and prior finding dispositions in existing text fields—no new audit
+schema.
 
 For plan-only or advanced use, plan first:
 
@@ -97,24 +147,55 @@ Repeating a same-goal plan-only request after approval reports the immutable pla
 and current progress, then stops without rewriting the plan or starting work.
 
 `/flow-run` and `/flow-status` are advanced/recovery controls. At any point,
-`/flow-status` reports the durable state and next action.
+`/flow-status` reports the durable state and next action. After `/flow-auto` has
+run in the current plugin process, status also reports a non-authoritative timer
+for the latest invocation. `activeMs` is process-local wall time classified as
+active by the coordinator, not CPU time or pure coding time.
+`waitingForUserMs` counts only projected `flow_plan_approve` and
+`await-user-direction` checkpoints. Plugin restart resets the timer; paused,
+inactive, errored, and unprojected waits are excluded.
 
 ## How Flow works
 
 1. Planning saves a small feature DAG. Approval locks it.
 2. `/flow-run` starts one feature whose dependencies are complete.
-3. The manager implements it serially or integrates an optional bounded worker
+3. Before editing, the manager preflights required evidence and gives any
+   bounded workers an explicit adversarial acceptance and risk checklist.
+4. The manager implements it serially or integrates an optional bounded worker
    wave.
-4. Flow observes the exact armed validation command against the current
+5. Flow observes the exact armed validation command against the current
    workspace, then creates one independent review assignment. At new review
-   admission, a known-failed exact planned gate needs a current-source pass;
-   already accepted Session v5 pending or completed reviews are not reopened or
-   vetoed later at close.
-5. A passing feature advances the plan. A blocked feature is reset as a fresh
-   full attempt within the retry boundary above. The final passing feature
-   allows explicit closure. Every accepted close returns a concise delivery
-   summary with each feature's attempt count, latest outcome, and terminal
-   findings, derived from Flow's recorded state.
+   admission, a relevant failure or source-drift observation invalidates older
+   passes; the qualifying pass must be newer and match current source. Separately,
+   the manager must not call `flow_review_start` while known required behavior or
+   environment evidence is skipped; this is workflow policy, not persisted
+   admission state. Already accepted Session v5 pending or completed reviews are
+   not reopened or vetoed later at close.
+6. The reviewer inspects adjacent and repeated state transitions, overlapping
+   feature invariants, the changed artifacts, and the packet's base-diff and
+   file-mode inventory. Stable finding IDs survive retries; reviewer guidance
+   requires checking prior dispositions and completing the supplied risk
+   checklist, represented as a bounded matrix when applicable. Missing proof is
+   a precise blocker only when it is required to approve the outcome.
+7. A passing feature advances the plan. A failed feature is not selected again
+   by default. From blocked status, reset atomically starts the exact authorized
+   retry or independent feature through optional `nextFeatureId`. From ready
+   `await-user-direction`, the failed run is already superseded and explicit
+   `flow_run_start(featureId)` begins its retry. The final passing feature allows
+   explicit closure. Every accepted close returns a concise delivery summary
+   with each feature's attempt count, latest outcome, and terminal findings,
+   derived from Flow's recorded state. Ordinary reviewer summaries carry IDs
+   mapped to the active feature or explicitly supplied in its packet; final
+   review carries every approved requirement or feature ID. Both carry each
+   still-live prior finding with its severity and disposition into the latest
+   `outcomeSummary`. Terminal
+   `fixed` requires a later passing review and current evidence. If a failed
+   retry proves one repair but finds another blocker, it carries that ID and a
+   concise evidence reference forward as terminal fixed pending pass; it cannot
+   drop the ID or call it fixed. Unproven fixes stay unverified, `recurring`
+   confirms recurrence, and `residual` requires a confirmed nonblocker. Only a
+   passing review may remove fixed history from the live carry-forward set.
+   Terminal findings retain unresolved blockers and the handoff stays bounded.
 
 State lives in `.flow/session.json`, so `/flow-status` can recover the next
 action after a restart or context change.
@@ -128,6 +209,9 @@ targeted follow-up wave may address a concrete gap. Once implementation is
 authorized, a qualifying wave needs no separate approval.
 
 Workers cannot delegate, call Flow lifecycle tools, or approve their own work.
+Generic or general-purpose agents are not used for active Flow work: bounded
+implementation uses `flow-worker`, and independent review uses
+`flow-reviewer`.
 Flow persists no wave state: the manager remains responsible for the combined
 diff, authoritative validation, and the one independent review. Small or
 integration-heavy tasks stay serial.
@@ -136,7 +220,7 @@ integration-heavy tasks stay serial.
 
 | Command | Purpose |
 | --- | --- |
-| `/flow-auto <goal>` | Normal end-to-end driver for the authorized lifecycle; stop after planning if implementation was not authorized. |
+| `/flow-auto <goal>` | Normal end-to-end driver; it stops after planning without implementation authority, otherwise loops through every runnable feature and closure without an intermediate handoff. |
 | `/flow-plan <goal>` | Plan-only/advanced creation, revision, and approval. |
 | `/flow-run` | Advanced/recovery execution of one approved feature. |
 | `/flow-review` | Internal/recovery dispatch for a runtime-created reviewer assignment. |
@@ -150,17 +234,29 @@ plan-only, advanced, internal, or recovery controls.
 Start with `/flow-status`; its next action is durable default workflow
 direction, not permission to exceed the user's authority. For a first failed
 review, read detail once before reset because scope-blocker findings refine the
-compact default. Environment-sensitive transition guards remain authoritative
-when a mutation is attempted. Do not hand-edit
+compact default. Pass the exact retry or dependency-independent choice as
+`nextFeatureId` so reset and run start are atomic; do not reset and then rely on
+default selection. If status is ready with `await-user-direction`, read detail
+once and pass the explicitly authorized retry's exact `featureId` to
+`flow_run_start`; reset is invalid because the failed run was already
+superseded. Environment-sensitive transition guards remain authoritative when a
+mutation is attempted. Do not hand-edit
 `.flow/session.json` to bypass a gate. If validation, review, locking,
 fingerprinting, or archive publication fails, follow the focused steps in
 [troubleshooting](docs/troubleshooting.md).
 
-For an interrupted accepted close, replay the projected `archiveRetry.request`
-exactly once. Flow confirms the existing bytes without rewriting Session v5 and
-re-confirms archive cleanup. A real archive collision removes the automatic
-retry instruction and requires manual inspection; preserve both documents and
-do not overwrite, delete, or loop the request.
+For an interrupted accepted close, compact `/flow-status` supplies
+`archiveRetry.request`. Replay that request exactly once before any additional
+or detail recovery read. Flow confirms the existing bytes without rewriting
+Session v5, re-confirms archive cleanup, and returns the existing concise
+`workflowData.delivery`. Reconstruct only the plan-bounded, terminal disposition
+map from its latest `outcomeSummary` and terminal findings. If delivery is absent,
+report the exact recovery and claim no map. On a close revision conflict,
+refresh compact status and retry only after confirming the same session and goal
+and that status still permits the selected
+closure kind; never close a replacement. A real archive collision removes the
+automatic retry instruction and requires manual inspection; preserve both
+documents and do not overwrite, delete, or loop the request.
 
 ## Development