opencode-plugin-flow 6.5.0 → 6.7.0

package/CHANGELOG.md

@@ -6,6 +6,83 @@ One short entry per release, written for users deciding whether to upgrade.
 
 No changes yet.
 
+## [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
+without adding persisted diagnostics or more orchestration:
+
+- `/flow-run` now follows one ordered compact-status route, handles idle and
+  planning entry explicitly, and refreshes execution state before dispatching a
+  recovered reviewer assignment so stale work is reset rather than redispatched.
+- Status failures report the exact summary and optional recovery guidance.
+  Post-review uncertainty no longer incorrectly claims that no lifecycle
+  mutation occurred.
+- Blocked-review handoffs now explain attempts, recurring and new findings,
+  validation evidence, Flow-reported artifacts, completed and untouched work,
+  the exact next action, and whether another repair attempt needs authorization.
+  `/flow-status` obtains that evidence through one detail read.
+- Typed status, execution, reviewer, detail, delivery, operation, and close
+  recovery projections replace broad record casts. Accepted archive retry,
+  accepted manual recovery, unconfirmed replay, and archive lookup collision
+  remain distinct without changing Session v5 or persisted state.
+- OpenCode tool serialization preserves those specialized response types while
+  requiring every handler to return the Flow response envelope. Expanded prompt,
+  runtime, close-recovery, and integration tests cover the contracts; the
+  failed-review retry boundary and bounded worker waves remain unchanged.
+
+Install or update:
+
+```bash
+opencode plugin opencode-plugin-flow@6.6.0 --global --force
+```
+
 ## [6.5.0] - 2026-07-22
 
 Convergence-safe recovery lore makes long Flow sessions easier to trust

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.5.0 --global --force
+opencode plugin opencode-plugin-flow@6.7.0 --global --force
 ```
 
 Omit `--global` for project scope. Exact version pins do not update
-automatically. To update, replace `6.5.0` with the new release and rerun the
+automatically. To update, replace `6.7.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.5.0"]
+  "plugin": ["opencode-plugin-flow@6.7.0"]
 }
 ```
 
@@ -64,7 +64,10 @@ 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.
 
 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 +79,34 @@ 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 the first in-scope failed review may automatically reset and atomically
+start one fresh full retry; a `[scope-blocker]` checkpoints immediately. 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.
+
+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 missing proof as blocking if the gap
+reaches its 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.
 
 For plan-only or advanced use, plan first:
 
@@ -97,24 +121,42 @@ 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. Missing proof is recorded as a precise blocking
+   evidence request.
+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.
 
 State lives in `.flow/session.json`, so `/flow-status` can recover the next
 action after a restart or context change.
@@ -128,6 +170,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 +181,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,8 +195,13 @@ 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).