opencode-plugin-flow 6.3.1 → 6.5.0

package/CHANGELOG.md

@@ -6,6 +6,74 @@ One short entry per release, written for users deciding whether to upgrade.
 
 No changes yet.
 
+## [6.5.0] - 2026-07-22
+
+Convergence-safe recovery lore makes long Flow sessions easier to trust
+without adding another state model:
+
+- Before every manager-owned mutation, Flow aligns the request with the active
+  goal. Same-goal approved plan-only requests report immutable plan progress and
+  stop; materially new or expanded work waits for explicit closure. Exact
+  cleanup of an already-accepted close runs before alignment and grants no new
+  work authority.
+- Prospectively, a known failed exact plan-listed command needs a byte-identical
+  current-source pass at new review admission. Accepted Session v5 pending and
+  completed reviews remain grandfathered; close adds no retroactive veto.
+- A run can retain the maximum 64 exact planned gates plus separate broad
+  evidence. This widens a Session v5 writer bound, so active rollback to an
+  older Flow build is intentionally unsupported rather than hidden behind a
+  migration or capability layer.
+- Only the first in-scope failed review receives one automatic fresh full retry.
+  A `[scope-blocker]` is the sole special finding marker and checkpoints
+  immediately, while a second failure projects `await-user-direction` before
+  another user-authorized attempt.
+- Every durably accepted close returns the same concise delivery summary on
+  success, archive recovery, or replay. Delivery is derived rather than
+  persisted, reporting each feature's attempt count, latest outcome, terminal
+  findings, and explicitly Flow-reported artifact paths rather than an exact Git
+  delta.
+- Exact close replay confirms the existing active document and filesystem
+  durability boundary without rewriting Session v5. Archive recovery re-syncs
+  publication and cleanup even when a previous attempt already removed active
+  state; closed status re-derives a conflicting archive so automatic retry stays
+  stopped for manual inspection after interruption.
+
+Install or update:
+
+```bash
+opencode plugin opencode-plugin-flow@6.5.0 --global --force
+```
+
+## [6.4.0] - 2026-07-21
+
+Continuous-flow lore keeps an authorized goal inside Flow while preserving the
+small, single-run architecture:
+
+- `/flow-auto` is the normal end-to-end driver. An active session remains
+  authoritative until explicit completed, deferred, or abandoned closure, and
+  existing implementation authority carries across plan approval, feature
+  outcomes, qualifying worker waves, and in-scope failed-review repair.
+- Direct `/flow-run` remains a one-feature advanced or recovery control. Work
+  stays inside the active feature, serial execution remains the default, and
+  bounded parallel waves still add no scheduler, durable wave state, telemetry,
+  or concurrent active features.
+- Reviewers now receive every applicable passing validation while final review
+  still requires a broad gate. Reviewer guidance explicitly permits
+  workspace-local non-shell inspection, removing an ambiguity that could block
+  valid reviews.
+- Deterministic coverage now exercises concurrent completion replay,
+  configuration collisions and warnings, the documented 1-through-1000 review
+  step range, temporary-workspace cleanup, and release-version derivation.
+- Real-provider evidence completed an overlapping two-worker wave, a serial
+  integration feature, failed-review reset and repair, and ten ordinary
+  `/flow-auto` sessions through explicit closure.
+
+Install or update:
+
+```bash
+opencode plugin opencode-plugin-flow@6.4.0 --global --force
+```
+
 ## [6.3.1] - 2026-07-21
 
 Read-only retry lore closes the recovery and documentation gaps in 6.3.0:

package/README.md

@@ -11,28 +11,39 @@ Flow keeps one durable active feature run at a time. When implementation divides
 cleanly, the manager may ask a small host-native worker cohort to contribute in
 parallel before it validates and reviews the combined result.
 
+Once a Flow session starts, it remains the workflow for that goal until Flow
+records completed, deferred, or abandoned closure. It never silently falls back
+to ordinary non-Flow coding, and it does not fold a materially different request
+into the active goal.
+
 ## Install
 
 Install the exact npm release through OpenCode:
 
 ```bash
-opencode plugin opencode-plugin-flow@6.3.1 --global --force
+opencode plugin opencode-plugin-flow@6.5.0 --global --force
 ```
 
 Omit `--global` for project scope. Exact version pins do not update
-automatically. To update, replace `6.3.1` with the new release and rerun the
+automatically. To update, replace `6.5.0` with the new release and rerun the
 command.
 
 Before upgrading from Flow v5 or earlier, finish or explicitly close any active
 session with its original Flow version. Flow v6 opens only Session v5 active
 state; older archives remain inert history.
 
+Do not roll an active session back to an older Flow build after a newer build
+has written it. Newer v6 builds read earlier Session v5 state, but Session v5 is
+not a promise that older readers understand later widened safety bounds. Finish
+or close the active session before downgrading; Flow adds no capability or
+migration layer for rollback.
+
 The equivalent manual project configuration is:
 
 ```json
 {
   "$schema": "https://opencode.ai/config.json",
-  "plugin": ["opencode-plugin-flow@6.3.1"]
+  "plugin": ["opencode-plugin-flow@6.5.0"]
 }
 ```
 
@@ -55,7 +66,25 @@ 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.
 
-For more control, plan first:
+Before every manager-owned Flow mutation, including direct `/flow-plan` and
+`/flow-run` use, the manager compares the current request with the active goal.
+A projected `archiveRetry` is the one exception: it finishes an already-accepted
+close before that comparison and grants no authority for new work.
+A continuation or compatible narrowing may proceed. A materially new or
+expanded request does not start or mutate the active session; Flow offers to
+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.
+
+For plan-only or advanced use, plan first:
 
 ```text
 /flow-plan add rate limiting to the public API
@@ -63,9 +92,12 @@ For more control, plan first:
 
 Review the proposed plan and approve it conversationally. `/flow-plan` does not
 silently grant permission to implement, commit, push, or publish. After
-approval, use `/flow-run` to run or resume one feature.
+approval of a plan-only request, `/flow-run` can run or recover one feature.
+Repeating a same-goal plan-only request after approval reports the immutable plan
+and current progress, then stops without rewriting the plan or starting work.
 
-At any point, `/flow-status` reports the durable state and next action.
+`/flow-run` and `/flow-status` are advanced/recovery controls. At any point,
+`/flow-status` reports the durable state and next action.
 
 ## How Flow works
 
@@ -74,9 +106,15 @@ At any point, `/flow-status` reports the durable state and next action.
 3. The manager implements it serially or integrates an optional bounded worker
    wave.
 4. Flow observes the exact armed validation command against the current
-   workspace, then creates one independent review assignment.
+   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. The final passing feature allows explicit closure.
+   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.
 
 State lives in `.flow/session.json`, so `/flow-status` can recover the next
 action after a restart or context change.
@@ -86,7 +124,8 @@ action after a restart or context change.
 Parallel contribution is optional and local to one active feature. The manager
 may launch two or three `flow-worker` instances only for exact,
 non-overlapping slices, then inspect and integrate their work. At most one
-targeted follow-up wave may address a concrete gap.
+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.
 Flow persists no wave state: the manager remains responsible for the combined
@@ -97,23 +136,32 @@ integration-heavy tasks stay serial.
 
 | Command | Purpose |
 | --- | --- |
-| `/flow-auto <goal>` | Drive the authorized lifecycle; stop after planning if implementation was not authorized. |
-| `/flow-plan <goal>` | Create, revise, or approve a plan through conversation. |
-| `/flow-run` | Run or resume one approved feature. |
+| `/flow-auto <goal>` | Normal end-to-end driver for the authorized lifecycle; stop after planning if implementation was not authorized. |
+| `/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. |
-| `/flow-status` | Inspect the active session and next action. |
+| `/flow-status` | Advanced/recovery inspection of the active session and next action. |
 
-Ordinary workflows start with `/flow-auto`, `/flow-plan`, `/flow-run`, or
-`/flow-status`. `/flow-review` remains public for runtime dispatch and recovery,
-but it is not an ordinary starting point.
+Use `/flow-auto` for the ordinary end-to-end workflow. The other commands expose
+plan-only, advanced, internal, or recovery controls.
 
 ## Recovery
 
-Start with `/flow-status`; its next action is authoritative. Do not hand-edit
+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
 `.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.
+
 ## Development
 
 Requirements: Git, Node.js 24 or newer, Bun 1.3.14, and the versions pinned in