v2.0.24

[2.0.24] - 2026-05-09

Make review-scope recovery scaffold-safe

Flow 2.0.24 hardens review and review-and-fix completion recovery around reviewScopeLedger. Recovery details now label exampleReviewScopeLedger as scaffold-only guidance, and generated example entries carry an explicit scaffold residual-risk placeholder so the runtime can distinguish guidance from reviewer evidence.

The runtime now rejects blind scaffold replay. Worker completion payloads and final reviewer decisions that resubmit the scaffold placeholder unchanged fail with review-scope accounting recovery, while a retry with evidence-grounded scope entries and truthful residual risk succeeds. This keeps structured recovery helpful without allowing the runtime-provided example to become fake review evidence.

Prompt, command, and OpenCode tool guidance now tell workers and reviewers to reassess every declared scope, replace scaffold residual risk, avoid resending identical decisions, and use finding refs only when mapped to the declared scope. The investigation notes also clarify that the observed “runtime provided the missing scope ledger entries” retry wording was expected recovery behavior with misleading prose, not proof that review work had already been done.

The release deliberately does not add commands, tools, runtime modes, package exports, dependencies, state paths, worker/reviewer payload shapes, or automatic finding-ref assignment. It preserves zod / @opencode-ai/plugin alignment, keeps review-scope recovery as guidance rather than evidence, and records the separate newest-OpenCode-plugin regression investigation as pending documentation only.

Constraint: Treat recovery examples as scaffold-only guidance, never as completed review evidence
Constraint: Require evidence-grounded reviewScopeLedger entries with truthful residual risk before review/review-and-fix completion can pass
Constraint: Preserve the existing public tool surface and payload shape while tightening validation semantics
Constraint: Keep dependency and SDK-boundary versions unchanged
Rejected: Let agents replay exampleReviewScopeLedger unchanged | that can convert runtime guidance into unsupported review evidence
Rejected: Auto-assign closed finding refs from recovery candidates | candidates still require reliable scope mapping before they become ledger evidence
Rejected: Add a new recovery or review tool | existing structured recovery details and retry paths are sufficient
Confidence: high
Scope-risk: moderate
Reversibility: clean
Directive: Keep future recovery examples explicitly labeled as non-evidence and pair any scaffold payloads with validation that rejects unchanged placeholders
Tested: bun test tests/completion-gates.test.ts tests/runtime/final-review-contracts.test.ts tests/runtime-tools.test.ts tests/config/prompt-contracts.test.ts tests/recovery-hint-parity.test.ts tests/protocol-parity.test.ts (130 pass, 1229 expect calls); bunx biome check src/runtime/domain/review-scope-accounting.ts tests/completion-gates.test.ts tests/runtime/final-review-contracts.test.ts --files-ignore-unknown=true; bun run typecheck; bun run check
Not-tested: Live OpenCode UI final-review recovery retry; live newest-OpenCode-plugin regression reproduction; live GitHub-hosted CI/release workflow run for tag v2.0.24 before push

v2.0.23

[2.0.23] - 2026-05-08

Make singleton runtime retries idempotent and artifact-repairable

Flow 2.0.23 narrows retry noise around singleton runtime transitions without expanding the public surface. Review, plan approval, and run-start paths now distinguish requested tool metadata from persisted state more clearly, and identical singleton retries no-op instead of rewriting state where the runtime can prove the requested transition is already applied.

The release also makes no-op mutation retries artifact-repairable. A lost-response retry that reloads an already-mutated session still skips the session-state save, but it now runs artifact sync when the action's syncArtifacts contract allows it. This preserves idempotent state writes while letting retries repair missing rendered artifacts after a partial save/sync failure.

Execution-start retry handling is now aligned with prompt guidance. An implicit flow_run_start({}) retry no-ops only when the current active feature is already in_progress; explicit attempts to switch to a different feature while one is active still fail. Review-record behavior is documented as current identical-decision no-op behavior plus changed-decision singleton overwrite, with no reviewer-history append.

The release deliberately does not add commands, tools, runtime modes, package exports, dependencies, state paths, worker/reviewer payload shapes, or history-appending completion idempotency. It keeps completion calls non-idempotent without new worker evidence, preserves snapshot-primary runtime persistence, keeps prompts/docs descriptive rather than authoritative over runtime semantics, and accepts a narrow 6 KiB bundle-budget increase for release-bound retry/idempotency metadata and guidance.

Constraint: Treat runtime tool metadata as request progress until the structured response confirms persisted state
Constraint: Preserve singleton no-op behavior only where the runtime can prove the same transition is already applied
Constraint: Keep no-op retries artifact-repairable without saving session state again
Constraint: Preserve completion history semantics; do not make flow_run_complete_feature idempotent without new worker evidence
Constraint: Accept only a narrow 6 KiB bundle-budget increase for release-bound retry/idempotency metadata and prompt guidance
Rejected: Make all repeated runtime calls successful no-ops | history-appending completion and changed reviewer decisions carry new evidence/state and must remain explicit
Rejected: Add new runtime status or retry tools | existing status, recovery metadata, and no-op transitions are sufficient
Rejected: Broaden prompt guidance into runtime authority | runtime transitions remain the behavior source of truth; prompts only describe safe retry boundaries
Confidence: high
Scope-risk: moderate
Reversibility: clean
Directive: Keep future retry/idempotency work transition-specific, test-backed, and explicit about whether artifacts sync, session state saves, or history rows are appended
Tested: bun test tests/runtime-tools-metadata.test.ts tests/runtime-tools.test.ts tests/config/prompt-contracts.test.ts tests/reviewer-decision-scope.test.ts tests/runtime/plan-and-tool-schema-contracts.test.ts tests/prompt-snapshot.test.ts tests/prompt-eval-corpus.test.ts (76 pass, 1314 expect calls); focused runtime/prompt/tool/docs gate bundle (133 pass, 2587 expect calls); bun run eval:prompt-capture:check; bun run eval:review-capture:check; bun run typecheck; final focused RepoPrompt review for doc/export blockers; bun run check
Not-tested: Live OpenCode UI session exercising lost-response retry rendering; live GitHub-hosted CI/release workflow run for tag v2.0.23 before push

v2.0.22

[2.0.22] - 2026-05-08

Make attachment materialization runtime-guided and content-policy explicit

Flow 2.0.22 tightens the /flow-auto attachment contract introduced in 2.0.21. Auto preparation now exposes attachment availability as runtime-owned attachmentGuidance, and prompt/mode contracts instruct coordinators to materialize attachments only when attachmentGuidance.materializationRequired is true, using the provided tool and args before planning, repository inspection, or Task/subagent handoff.

The release also clarifies that supported attachment formats are MIME/content-policy based rather than filename-extension trust based. Captured file names are used only for safe slug bases; materialization normalizes MIME, requires matching data URL MIME, verifies image magic bytes, and writes canonical extensions from the validated MIME policy. A JPEG uploaded with a misleading .png filename therefore imports as .jpg, not as the user-provided extension.

The release deliberately does not expand attachment ingress. It adds no commands, runtime modes, package exports, dependencies, state paths, persisted attachment indexes, SVG support, raw base64 transport, filesystem path imports, file: imports, or HTTP URL imports. It keeps binary assets outside .flow/**, preserves zod / @opencode-ai/plugin alignment, and accepts a narrow 4 KiB bundle-budget increase for runtime attachment guidance snapshots and coordinator instructions.

Constraint: Treat attachment materialization as a runtime-guided preparation contract, not a prompt-inferred goal classification
Constraint: Keep the format restriction MIME/content-policy based; never trust the uploaded filename extension for validation or output extension selection
Constraint: Preserve the 2.0.21 ingress boundary: supported data: image attachments only, root-bound destinations, no .flow/** asset writes, no dependency-version changes, and only a narrow 4 KiB bundle-budget increase
Rejected: Materialize based on whether prose appears attachment-dependent | the runtime already knows current/latest attachment availability and skipped unsupported records
Rejected: Preserve user-supplied filename extensions | filenames are untrusted metadata and may not match the payload MIME or bytes
Rejected: Broaden attachment sources or formats in this patch | SVG, raw base64, filesystem, file:, and HTTP sources need separate threat-model review
Confidence: high
Scope-risk: moderate
Reversibility: clean
Directive: Keep future attachment changes driven by explicit runtime attachment guidance and validated MIME/content policy, not model inference or filename suffixes
Tested: bun test tests/attachment-materialization.test.ts tests/auto-prepare.test.ts tests/config/plugin-surface.test.ts tests/config/prompt-contracts.test.ts tests/runtime-tool-routing.test.ts tests/prompt-mode-behavior-eval.test.ts tests/docs-stale-reference-policy.test.ts (86 pass, 1298 expect calls); bun run typecheck; bun run eval:prompt-capture:check; bunx biome check ... --files-ignore-unknown=true; bun run check
Not-tested: Live OpenCode UI attachment upload session; live GitHub-hosted CI/release workflow run for tag v2.0.22 before push

v2.0.21

[2.0.21] - 2026-05-08

Materialize OpenCode image attachments before Flow automation planning

Flow 2.0.21 adds a narrow attachment-ingress bridge for /flow-auto goals that depend on user-supplied images. The OpenCode plugin now captures supported chat/file parts for the active session and exposes flow_attachments_materialize, a coordinator-only tool that imports PNG, JPEG, WebP, GIF, and AVIF data: attachments into explicit workspace asset paths before planning, implementation inspection, or Task/subagent handoff.

The release is a deliberate surface-freeze exception: it adds one public Flow tool because the previous behavior left chat-visible image attachments unavailable as shell-readable project files, forcing manual user file placement. The new tool is bounded to /flow-auto, returns workspace-relative paths for plan/evidence handoff, and keeps binary assets outside .flow/**; Flow session state remains snapshot-primary and derived docs remain markdown artifacts only.

The materialization path is intentionally conservative. It allowlists image MIME types, keeps SVG unsupported, rejects raw base64, filesystem, file:, and HTTP URL sources, enforces data-size limits before decode, sanitizes filenames, prevents traversal and .flow/** destinations, rejects symlink destination ancestry, and writes final files exclusively with deterministic collision suffixes. Unsupported or stale attachments are reported as skipped metadata instead of silently falling back to older captured files.

Prompt, mode, descriptor, docs, and schema contracts now teach flow-auto to materialize attachments only when the classified goal depends on them. Ordinary goals must not call the tool, and planner/worker/reviewer handoffs should receive concrete imported paths rather than chat-only attachment references.

The release deliberately does not add commands, runtime modes, package exports, dependencies, state paths, worker/reviewer payload shapes, evidence-packet binary transport, or persisted attachment indexes. It preserves zod / @opencode-ai/plugin alignment and accepts a narrow bundle budget increase for the release-bound attachment capture, policy, and root-safe materialization guards.

Constraint: Add exactly one narrow /flow-auto workspace tool to bridge supported OpenCode image attachments into project asset files
Constraint: Keep imported binary assets outside .flow/**; Flow-owned state remains session JSON plus derived markdown docs
Constraint: Preserve worker/reviewer/tool JSON payload contracts except for the explicit flow_attachments_materialize raw arg schema
Constraint: Preserve zod / @opencode-ai/plugin alignment; no dependency-version changes
Constraint: Accept only a narrow bundle budget increase for attachment capture, validation, and exclusive-write safety guards
Rejected: Treat chat attachments as filesystem files without materialization | OpenCode file parts are model-visible context and may not be shell-readable workspace paths
Rejected: Store attachment bytes or imported assets under .flow/** | Flow state paths are runtime/session artifacts, not project asset storage
Rejected: Support SVG, raw base64, filesystem paths, file:, or HTTP URLs now | those sources need separate trusted-origin and threat-model review
Rejected: Reuse evidence packets or worker artifacts as binary transport | those contracts are metadata references, not attachment byte channels
Confidence: high
Scope-risk: moderate
Reversibility: clean
Directive: Keep future attachment ingress narrow, permissioned, root-bound, and explicitly documented before expanding formats or source URL support
Tested: bun test tests/attachment-materialization.test.ts tests/config/plugin-surface.test.ts tests/config/tool-schemas.test.ts tests/runtime-tools-metadata.test.ts tests/config/prompt-contracts.test.ts tests/mode-contracts.test.ts tests/prompt-mode-behavior-eval.test.ts tests/smoke/dist-load.test.ts (88 pass, 2095 expect calls); bun run typecheck; bun run check before tag push
Not-tested: Live OpenCode UI attachment upload session; live GitHub-hosted CI/release workflow run for tag v2.0.21 before push

v2.0.20

[2.0.20] - 2026-05-08

Make feature identifiers drill down to Flow-rendered feature docs

Flow 2.0.20 connects visible featureId references in status, history, execution, review, and metadata surfaces to the existing Flow-rendered per-feature markdown artifact. Feature drilldowns are presentation-only targets over .flow/active, .flow/stored, and .flow/completed docs; canonical session state, worker results, reviewer decisions, and tool argument schemas remain unchanged.

The release hardens path handling around explicit drilldown sources. Caller-provided session directories and session paths must resolve under the expected Flow lifecycle root, and malformed or missing docs degrade to unavailable drilldown metadata instead of breaking read-only status/history responses. This preserves passive feature inspection without creating subagent sessions or widening runtime persistence.

Status and history presenters now own the fallback resolver for feature docs. Active, stored, and completed sessions can expose available feature-doc targets when rendered docs exist, while pruned or not-yet-rendered feature docs surface as missing drilldowns that still point at the intended artifact location.

The release deliberately does not add commands, tools, runtime modes, package exports, dependencies, state paths, or worker/reviewer schema changes. It keeps feature drilldowns in summary, presenter, history, and metadata layers, matching the existing Flow artifact lifecycle rather than introducing child-session navigation for passive inspection. It accepts a narrow 5 KiB bundle budget increase for release-bound drilldown presentation and path-hardening code.

Constraint: Treat feature drilldown as a derived presentation model over Flow-owned rendered artifacts and session history
Constraint: Keep active/stored/completed session path derivation root-bound under .flow/**
Constraint: Preserve worker/reviewer/tool JSON schemas and persisted session shape; no dependency-version changes
Constraint: Accept only a narrow 5 KiB bundle budget increase for release-bound feature drilldown presentation and path-hardening code
Rejected: Open or create subagent sessions for passive featureId inspection | subagents represent delegated planner/worker/reviewer work, while feature docs already provide the passive detail target
Rejected: Add a new persisted drilldown index | status/history can derive the target from existing session roots and feature ids
Rejected: Fail status/history when optional feature docs are malformed or missing | drilldown is presentation-only and must degrade without blocking read surfaces
Confidence: high
Scope-risk: moderate
Reversibility: clean
Directive: Keep future feature-inspection UX in artifact/presenter metadata layers unless a concrete runtime state requirement justifies schema expansion
Tested: bun test tests/feature-doc-drilldown.test.ts tests/runtime-operator-history.test.ts tests/runtime-summary.test.ts tests/runtime-tools-metadata.test.ts (46 pass, 338 expect calls); bun run typecheck; bun run check before tag push
Not-tested: Live GitHub-hosted CI/release workflow runs for tag v2.0.20 before push

v2.0.19

[2.0.19] - 2026-05-08

Make subagent work visible without weakening Flow runtime contracts

Flow 2.0.19 adds a derived task-progress projection for Flow sessions so operators can see planning, execution, validation, review, final-review, and recovery work as concise task rows in status summaries, history responses, rendered session docs, and OpenCode action metadata. The projection is presentation-only: worker results, reviewer decisions, tool payloads, and persisted session schemas remain the runtime-owned machine contracts.

The release also updates prompt guidance around role-aware Task/subagent handoffs. Coordinators can split independent planning, implementation, and review work into fresh child contexts, while leaf reviewer/audit roles stay evidence-backed report producers rather than recursive orchestrators. This keeps the investigation recommendation grounded in current runtime ownership: prompts describe orchestration, and Flow tools still own state transitions.

Stored-session history now keeps parked-session UX consistent. When flow_history_show displays a non-completed stored session, task-progress rows and operator summaries point to session activation instead of direct work that would not update the parked runtime state. Completed and active session summaries keep their existing task-progress behavior.

The release deliberately does not add commands, tools, runtime modes, state paths, package exports, dependencies, or worker/reviewer schema changes. It accepts a narrow bundle budget increase for the release-bound task-progress presentation code while preserving direct JSON tool contracts, zod / @opencode-ai/plugin alignment, and snapshot-primary runtime persistence.

Constraint: Keep task/session progress as a derived presentation model over canonical session, history, validation, review, and tool metadata
Constraint: Preserve worker/reviewer/tool JSON schemas and direct OpenCode tool(...) arg shapes without stringified or nested transport wrappers
Constraint: Keep zod aligned with @opencode-ai/plugin; no dependency-version changes in this release
Constraint: Accept only a narrow 8 KiB bundle budget increase for release-bound task-progress projection and presentation code
Rejected: Replace worker/reviewer JSON with prose | runtime schemas, adapter schemas, completion gates, and regression tests depend on strict machine-readable payloads
Rejected: Add first-class child-session tree persistence now | current runtime history is flat and feature/session-oriented, so projection-first UX avoids a schema migration
Rejected: Let parked stored sessions show direct work next steps | direct work outside Flow would not update parked runtime records, so activation must be the visible next action
Confidence: high
Scope-risk: moderate
Reversibility: clean
Directive: Keep future subagent/task UX improvements in summary, presenter, render, history, and metadata layers unless a concrete runtime requirement justifies persisted child-session modeling
Tested: bun test tests/runtime-operator-history.test.ts tests/runtime-summary.test.ts tests/runtime-tools-metadata.test.ts tests/runtime-actionable-metadata.test.ts tests/config/prompt-contracts.test.ts (62 pass, 735 expect calls); bun run typecheck; bun run check before tag push
Not-tested: Live GitHub-hosted CI/release workflow runs for tag v2.0.19 before push

v2.0.18

[2.0.18] - 2026-05-08

Restore the hosted generated-drift lane after the Flow Core release

Flow 2.0.18 is a fix-forward release for the hosted CI failure observed immediately after v2.0.17. The v2.0.17 release workflow published successfully, but the main-branch CI generated-drift preflight still invoked Bun with the old test-name pattern descriptor family parity. The descriptor suite was intentionally renamed around the smaller OpenCode registry, so the hosted pattern matched zero tests even though the local full bun run check path had passed.

This release keeps the Flow Core snapshot-first simplification from v2.0.17 unchanged. It updates the generated-drift package script to use the renamed descriptor parity suite selector, preserving the same registry/projection/docs parity surface while matching the current test contract.

The release deliberately does not add commands, tools, runtime modes, state paths, package exports, dependencies, or behavior changes. It only restores hosted CI coverage for generated descriptor drift after the descriptor-suite rename.

Constraint: Fix the hosted CI lane without rewriting the already-pushed v2.0.17 tag or weakening generated-drift coverage
Constraint: Preserve the v2.0.17 Flow Core snapshot-first product contract unchanged
Constraint: Keep zod aligned with @opencode-ai/plugin; no dependency-version changes in this patch
Rejected: Force-move v2.0.17 | the release workflow already succeeded and the tag was pushed, so fix-forward is safer and more auditable
Rejected: Remove descriptor parity from generated-drift checks | that would weaken the release gate that caught the stale test selector
Rejected: Keep the stale descriptor family parity selector | it no longer names the active descriptor parity suite and matched zero hosted tests
Confidence: high
Scope-risk: narrow
Reversibility: clean
Directive: Keep generated-drift selectors synchronized with descriptor parity suite names when the suite is renamed
Tested: bun run check:generated-drift; bun run check
Not-tested: Live GitHub-hosted CI/release workflow runs for tag v2.0.18 before push

v2.0.17

[2.0.17] - 2026-05-08

Make Flow Core snapshot-first and retire replay infrastructure

Flow 2.0.17 completes the current simplification pass by freezing the supported Flow Core vNext contract around runtime transitions, the session-engine persistence boundary, and snapshot-first active/stored/completed session state. The new Flow Core facade exposes compact command and query names without becoming a second state engine; transitions still own behavior, and the session engine still owns load -> transition -> save -> render synchronization.

The release replaces duplicated OpenCode descriptor/projection metadata with a smaller tool registry that keeps tool names, runtime bindings, mode visibility, descriptions, and docs metadata in one local surface. Generated projections and docs rows now derive from that smaller registry instead of preserving a broader duplicated descriptor family.

Replay/event/checkpoint/projection persistence is intentionally retired as a product-supported surface. The live product path was already snapshot-primary, so the release deletes the core workflow replay wrappers, event/checkpoint/projection stores, replay tests, and event-store benchmark while keeping runtime transition invariants, session history, rendered artifacts, and the new snapshot persistence gate. Historical release and investigation docs may still mention the retired replay architecture as historical evidence.

Strict review governance is narrowed to review/review-and-fix or explicit strict review modes. Ordinary implementation flows keep compact completion safety, while supplied final-review behavior evidence is still sanity-checked so approved/passing final reviews cannot carry needs_fix, unsafe refs, or validation refs that were not actually recorded.

The release deliberately does not add commands, tools, runtime modes, package exports, dependencies, or looser completion paths. It retires unsupported replay state surfaces in favor of the documented snapshot-first contract and keeps zod / @opencode-ai/plugin alignment unchanged.

Constraint: Preserve runtime transition authority and session-engine snapshot persistence while deleting duplicated replay/product metadata surfaces
Constraint: Retire .flow/events, .flow/checkpoints, and .flow/projections as supported product state paths without changing active/stored/completed session snapshots
Constraint: Keep command names, tool names, package exports, dependencies, and zod / @opencode-ai/plugin alignment stable
Rejected: Keep event/checkpoint/projection stores as dormant compatibility code | dead product surfaces would keep release gates and architecture shaped around unsupported replay behavior
Rejected: Treat the new Flow Core facade as a new state engine | it is only a command/query boundary over existing runtime application handlers and transitions
Rejected: Drop all behavior-evidence checks outside strict review mode | supplied invalid evidence must still fail even when strict completeness is optional
Confidence: high
Scope-risk: broad
Reversibility: moderate
Directive: Keep Flow Core vNext snapshot-first unless a future release deliberately reintroduces event-sourced persistence with migration, public state-path docs, and replay gates
Tested: bun test tests/runtime-tool-routing.test.ts tests/completion-gates.test.ts (47 pass, 319 expect calls); bun run typecheck; touched-file Biome; bun run check
Not-tested: Live GitHub-hosted CI/release workflow runs for tag v2.0.17 before push

v2.0.16

[2.0.16] - 2026-05-07

Harden review-scope recovery accounting before release

Flow 2.0.16 closes the release-readiness gaps in the review-scope accounting contract. Recovery examples now stay conservative: they list closed finding refs as candidates, but no longer assign every closed finding to every declared scope. Agents must map findings to the specific scope they actually prove before using finding_closed.

Completion and reviewer validation now route review-scope failures through structured failure kinds instead of substring matching. Worker completion recovery remains tied to worker evidence, while final-reviewer recovery now points at the recorded final reviewer decision when the reviewer approval ledger is the failing artifact.

Historical completed feature evidence is accepted only when its reviewScopeLedger is structurally valid and covers every declared scope for that feature. Recursive glob review targets also use standard globstar semantics, so src/**/*.ts grounds both src/index.ts and nested TypeScript paths without broadening unsupported bracket or brace glob syntax.

The release deliberately does not add commands, tools, runtime modes, state paths, package exports, dependencies, or looser completion paths. It narrows recovery guidance and historical evidence reuse while preserving the existing review/review-and-fix surface. The bundle sanity ceiling moves from 708 KiB to 716 KiB to account for the added release-critical recovery checks while preserving a fixed budget check.

Constraint: Preserve strict review and review-and-fix completion gates without changing persisted session shape
Constraint: Keep recovery details machine-readable while avoiding automatic closed-finding-to-scope assignment
Constraint: Accept only a narrow 8 KiB bundle budget increase for release-critical recovery/accounting checks
Constraint: Keep zod aligned with @opencode-ai/plugin; no dependency-version changes in this patch
Rejected: Populate every recovery example scope with all closed finding refs | that overstates which findings were actually mapped to each declared scope
Rejected: Select review-scope recovery by matching error-message substrings | structured failure kinds are safer and keep worker vs final-reviewer recovery targets explicit
Rejected: Let partial historical ledgers or one-directory-only globstar behavior satisfy final accounting | both would silently drop declared review scope evidence
Confidence: high
Scope-risk: moderate
Reversibility: clean
Directive: Keep review-scope ledgers scoped and evidence-grounded; historical completions can contribute only after every declared feature scope is accounted
Tested: bun test tests/completion-gates.test.ts tests/runtime-tools.test.ts (48 pass, 395 expect calls); bun run typecheck; targeted Biome; targeted completion/recovery gates and bun run check before tag push
Not-tested: Live GitHub-hosted CI/release workflow runs for tag v2.0.16 before push

v2.0.15

[2.0.15] - 2026-05-07

Preserve review-and-fix closure obligations across planning refreshes

Flow 2.0.15 closes the follow-up release gap in the new planning.reviewFindings remediation contract. Active review_and_fix sessions can still refresh planning evidence, but they can no longer remove recorded findings through record_planning_context while the plan depends on those findings for completion. Final completion now keeps the original remediation obligation intact until every planned finding is closed with fix, test, validation, ledger, final-review, and reviewer-approval evidence.

The release also consolidates review-finding closure policy into a small runtime-domain helper instead of leaving closure ledger checks and planned-finding closure checks split across transition-local helpers. Completion transitions still own recovery routing and gate order, while the domain helper owns the closure-policy text and missing-ref calculation.

Final-review coverage gap accounting now treats whitespace-only suggestedValidation entries as missing. If a review context pack records coverage gaps, the final review must carry those gaps forward and provide real follow-up validation guidance rather than satisfying the contract with blank strings.

The release deliberately does not add commands, tools, runtime modes, state paths, package exports, dependencies, or looser completion paths. It narrows the existing review-and-fix contract and keeps the review-first/remediation split from 2.0.14 intact.

Constraint: Preserve strict review_and_fix finding closure after planning context refreshes without changing persisted session shape
Constraint: Keep completion/reviewer gate recovery behavior unchanged while moving closure-policy checks into a focused domain helper
Constraint: Keep zod aligned with @opencode-ai/plugin; no dependency-version changes in this patch
Rejected: Treat empty planning.reviewFindings refreshes as valid during active review_and_fix execution | this would erase the runtime-owned remediation baseline before final completion
Rejected: Store a new persisted immutable findings baseline in this release | guarding the mutation ingress fixes the bypass without a migration or state-shape change
Rejected: Let whitespace-only suggested validation satisfy coverage gaps | blank follow-up guidance weakens final-review evidence quality
Confidence: high
Scope-risk: moderate
Reversibility: clean
Directive: Do not remove planning.reviewFindings from an active review_and_fix session unless replanning out of remediation mode first; every planned finding must remain auditable through closure evidence before final completion
Tested: bun run typecheck; bun run lint; bun test tests/completion-gates.test.ts tests/runtime/evidence-packets.test.ts tests/runtime/final-review-contracts.test.ts (63 pass, 405 expect calls); targeted release gates and bun run check before tag push
Not-tested: Live GitHub-hosted CI/release workflow runs for tag v2.0.15 before push