Release gate: CUA mid-stream-exit scenario as pre-publication prerequisite (regression OPENCODE-MOBILE-6/-7)

Why

v0.4.16 shipped a fatal native crash (Sentry OPENCODE-MOBILE-6 id 7828678202, OPENCODE-MOBILE-7 id 7829185724; react-native-screens header config: child already has a parent). Fixed in v0.4.17, commit 0bbfa70. No existing test caught it: the JS tests cannot see native view races, and the CUA showcase scenario never navigates away from a session while it is streaming. Pipeline gap verified 2026-11-05: on the v0.4.17 tag, Play publication (run 42026918221) completed 12:45 UTC BEFORE tag CUA (run 42026917867) completed 12:50 UTC — both trigger independently on the tag; Play has no dependency on CUA. The tag went straight to production with no staged soak.

Work Log row (source of record): https://app.notion.com/p/40fac25eb49f81ec817cdf17402b74d4

Scope — three sub-items

Mid-stream-exit CUA scenario as a publication prerequisite. Add a CUA/Maestro scenario to the release pipeline: open a session, start a streaming response, navigate back mid-stream, repeat several times. Make the Play publish workflow depend on this scenario passing on the exact release commit — a failure must prevent publication, not just run in parallel. Acceptance: streaming proven active before each back-navigation; race repeated; process survival + usable session re-entry verified; logcat/screenshots retained with exact tested SHA/APK identity; a deliberately failing scenario demonstrably blocks publication. A green generic showcase run does NOT satisfy this.
3-day post-release Sentry watch — RECONCILED, do not duplicate. The daily job opencode-sentry-fix-release already reviews Sentry every day (new issues + new events since watermark), verifies FATALs against code, fixes and releases them. That covers detection and same-loop escalation. Remaining gap only: for 3 days after each release, record version-filtered evidence for the new version (fatal issues seen for that version, and whether telemetry is actually arriving — absence of events alone is not a pass). That evidence note belongs to the sentry-fix-release loop's state, not a new watch.
Staged-rollout evaluation. Evaluate Play staged rollout (halt / rollout %) so a bad build reaches a fraction of users first. Deliverable is an evaluation + recommendation recorded on this issue (current rollout config, proposed %, halt criteria tied to the Sentry watch in item 2). Changing Play rollout settings is a release action — Den's go required; evaluation only here.

Constraints

NEVER change applicationId cc.agentlabs.opencode.
This issue does NOT authorize pushing main or any v* tag. Implementation lands via PR + review; releases happen only on Den's explicit go or through opencode-sentry-fix-release.
App code changes go through Google AI Studio (Den's rule), applied mechanically with typecheck + full tests as the gate.
Follow dev_workflow (claim -> design in Notion -> implementation -> review loop -> merge -> Stage 5.5 sync -> Stage 6 validation). Design first: no implementation until the design (scenario spec + workflow-dependency design + rollout evaluation) exists in Notion and passes review.

Acceptance criteria

Design in Notion covering items 1-3, reviewed
Item 1: scenario merged via PR, publish workflow depends on it, failure-blocks-publication demonstrated
Item 2: version-filtered 3-day evidence procedure recorded in the sentry-fix-release loop state process (no duplicate watch created)
Item 3: staged-rollout evaluation + recommendation recorded; no Play settings changed without Den's go
Stage 5.5 Design/PRD sync recorded; Stage 6 validation evidence on this issue

Claim — agent session c180b3eb-aecc-4868-9634-24633667d057 in progress.

Scope: Stages 0-2 ONLY (claim, context, design) per dev_workflow. No implementation, no PR, no push/tag, no Play/Sentry settings changes.

Checked before claiming: issue comments = 0, open PRs (only #220, unrelated, 2026-10-26), recent commits (head 0bbfa70, 2026-11-05) — no self-signed claim by another actor on #227.

Deliverable: context brief + design page in Notion under the OpenCode Mobile hub covering (1) mid-stream-exit CUA scenario spec, (2) workflow-dependency design, (3) Sentry watch reconciliation, (4) staged-rollout evaluation, then a separate design-review subagent verdict recorded here.

Stage 2 design — recorded by claim session c180b3eb-aecc-4868-9634-24633667d057.

Design page (Notion, under the OpenCode Mobile hub): https://app.notion.com/p/410ac25eb49f818a89c2d3cbac4ec88f — covers (1) mid-stream-exit scenario spec (5 cycles, streaming proven per cycle, PID/logcat/re-entry assertions, manifest with SHA + APK sha256), (2) workflow dependency (option A: gate job inside publish-play-store.yml, publish job needs: it; release:published trigger retired), (3) Sentry reconciliation (version-filtered 3-day evidence block in the opencode-sentry-fix-release state process, no new watch), (4) staged-rollout evaluation (20% hold for the 3-day window; Play settings change needs Den's go — evaluation only).

Design review verdict (separate review agent, 2026-11-06): FAIL on v1 — 5 findings, no re-architecture: (1) §1/§2 contradiction on where the scenario lives; (2) §2 contradiction on release:published funnel vs retirement, dependents unexamined; (3) failure-blocks proof force-fail mechanism undefined; (4) unsupported 'both manifests' identity claim; (5) §4 halt criteria partly unmeasurable, actor unnamed.

All 5 findings folded into the design page (verified by re-fetch): gate job only in publish-play-store.yml with cua-smoke.yml byte-unchanged + explicit 'green showcase does not satisfy'; post-change entry list = tag push + workflow_dispatch, release:published retired with evidence the sentry-fix loop releases via tag push; dispatch-only cua_force_fail boolean input specified; identity claim replaced with same-run/same-SHA by construction; vitals halt criterion dropped, halt/raise actor named (existing release owner). Re-review owed: diff-check of §1/§2/§4 only — the Supervisor admits the next stage.

Unresolved gates: implementation gated on Google AI Studio route via the existing release owner after re-review; staged-rollout change needs Den's go; ~/workspace/goals/opencode-mobile/hidden_files/sentry-fix-state.md does not exist yet (the sentry-fix job creates it on first run per its body). No implementation, PR, push/tag, or Play/Sentry change in this stage.

Continuation claim — agent session 0b59552e-37e1-46b7-9db2-e8ed6759fe37 in progress.

Scope: design RE-REVIEW only (diff-check of design page sections 1, 2 and 4 against the 5 v1 findings recorded in comment 6673299261, plus the 2026-11-06 product-owner guidance on the Work Log row). Prior claim session c180b3eb-aecc-4868-9634-24633667d057 completed Stages 0-2; no competing/active claim found (issue has exactly 2 comments, both from that session).

No implementation, no PR, no push/tag, no Play/Sentry settings changes in this stage.

Design RE-REVIEW (diff-check of §1/§2/§4) — agent session 0b59552e-37e1-46b7-9db2-e8ed6759fe37, 2026-11-06. Design page: https://app.notion.com/p/410ac25eb49f818a89c2d3cbac4ec88f (fetched current version for this check).

Verdict: FAIL — one blocking finding, no re-architecture. All 5 v1 findings are verified resolved; the failure is a new precision gap in §1 against the product-owner guidance on the Work Log row (2026-11-06 01:00 UTC).

V1 findings — verified resolved

§1/§2 scenario location: §1 now states the gate job lives only in publish-play-store.yml, cua-smoke.yml is byte-unchanged, and 'a green showcase run does not satisfy it'; §2 Decision A (job 1 in publish-play-store.yml, publish job needs: it) is consistent with §1. Resolved.
§2 release:published: post-change entry paths are named (tag push + workflow_dispatch, both funnel through the gate job); release: published is retired, not funnelled, with dependents examined — build.yml creates the GitHub release from the tag, and the opencode-sentry-fix-release loop releases by pushing main + creating a v* tag and reads the release back as a downstream artifact. Resolved.
§2 force-fail mechanism: dispatch-only boolean input cua_force_fail (default false), wired to the scenario step env as CUA_FORCE_FAIL=1; the input does not exist on tag pushes. Evidence spec: run URL, CUA job = failure, publish job = skipped, no Play upload step executed. Resolved.
§1 identity claim: the unsupported 'both manifests' claim is gone; identity is same-run / same-SHA by construction (publish job in the same workflow run, needs: on the gate job), and the manifest records github.sha, tag, APK sha256, package and versionName/versionCode from aapt dump badging. Resolved.
§4 halt criteria / actor: halt triggers are measurable — 1 new FATAL Sentry issue on the new version, or telemetry UNVERIFIED at day 1 (per §3's 24 h rule); Play vitals is explicitly dropped as a halt criterion; the actor for both the halt and the day-3 20%→100% raise is named (the existing release owner). Resolved.

Also confirmed against the PO guidance: 5 cycles kept; same-PID survival asserted (§1 step 4); usable re-entry asserted (session renders, composer accepts text); logcat retained with no FATAL EXCEPTION / no 'child already has a parent' (§1 step 4 + artifacts); §3 PASS requires events actually arriving — 0 events for the version after 24 h = 'telemetry UNVERIFIED', never a pass.

Blocking finding — §1 streaming proof does not meet the navigation-boundary precision rule

PO guidance (Work Log row, 2026-11-06 01:00 UTC): text growth between two samples proves recent activity but can precede completion before the back press; require timestamped active-stream evidence at the navigation boundary, and reject cycles that finished before navigation.

§1 as written: step 2 proves streaming by reply text length growing between 2 polls 1 s apart, 'recorded in the manifest' — no timestamps are required for the samples or for the back press. Step 3 says navigate back 'while the stream is still running' but specifies no still-streaming check at the navigation boundary and no rule rejecting a cycle whose reply completed between the last growth sample and the back press. Such a cycle would be counted toward the 5 while never exercising the mid-stream race — the exact failure this gate exists to catch.

Required amendment (§1 steps 2–3 + manifest only): (a) the manifest records a timestamp for each streaming-proof sample and for the back-press action, per cycle; (b) a still-streaming check at the boundary — a final growth sample / still-streaming indicator taken immediately before the back press; (c) a cycle whose reply completed before the back press is INVALID (fails the gate or is re-run), never counted toward the 5 cycles.

Minor, fold into the same amendment: §3's day-3 verdict is written as PASS/FAIL only — name UNVERIFIED as a day-3 outcome when telemetry is absent or the window is unfinished, so it cannot be read as PASS-by-absence (the 'never a pass' rule is already in §3; this is verdict vocabulary only).

Next step

Design owner amends §1 (and the §3 verdict word) → short re-check of §1 only → Supervisor admits implementation: Google AI Studio route via the existing release owner, PR + Stage 4 review. The §4 staged-rollout change (userFraction/status) still needs Den's explicit go; no push of main, no v* tag, no Play/Sentry change is authorized by this review.

Design amendment — agent session e5e3ce0e-9fa1-477b-80a5-8dd2cd8686b8, 2026-11-06. Scope: design page only (https://app.notion.com/p/410ac25eb49f818a89c2d3cbac4ec88f), in response to the re-review FAIL in comment 6674288624. No code, no push/tag, no Play/Sentry change. §2 and §4 were not changed (verified by re-fetch: section text identical before/after).

What changed:

§1 step 2 — streaming-proof samples are timestamped: "Record each poll in the manifest with its UTC timestamp and its text length." (was: growth "recorded in the manifest", no timestamps.)
§1 step 3 — still-streaming check at the back-press boundary + timestamped back press + INVALID rule. New step 3 text: "Check still-streaming at the back-press boundary, then navigate back (header back): take a final sample immediately before the back press — reply text length still growing since the previous poll, or the streaming indicator still visible — and record that final sample in the manifest with its UTC timestamp. Record the back press in the manifest with its UTC timestamp. If the reply completed before the back press, the cycle is INVALID: it does not count toward the 5 cycles and is re-run. Navigate back only when the boundary check shows the stream still running."
§1 manifest spec — now records, per cycle: "each streaming-proof sample (UTC timestamp + text length, including the final boundary sample), the back-press UTC timestamp, an INVALID flag when the reply completed before the back press, and PID".
§3 minor (verdict vocabulary only) — day-3 verdict now reads: "PASS (no new FATAL for the version + events arriving), FAIL (ids listed), or UNVERIFIED (telemetry absent, or the 3-day window unfinished — UNVERIFIED is never a pass)."

Verified by re-fetching the design page after the edit: the amended §1 steps 2–3, the amended manifest spec, and the amended §3 verdict line are present exactly as above; §2/§4 text is unchanged.

Next step (not done here, per dispatch): separate reviewer runs the §1-only re-check.

Claim — agent session 4c15f089-526a-4c29-b891-54a96f274322 in progress.

Scope: §1-ONLY design re-check per dev_workflow (fresh reviewer; did not write or amend the design). Checking §1 steps 2–3 + manifest spec against the blocking finding in comment 6674288624 and the PO guidance (Work Log row, 2026-11-06 01:00 UTC), plus §3 UNVERIFIED naming; spot-check §2/§4 unchanged in meaning. No design edit, no implementation, no PR, no push/tag, no Play/Sentry change.

Design §1-ONLY re-check — agent session 4c15f089-526a-4c29-b891-54a96f274322, 2026-11-06. Fresh reviewer (did not write or amend the design). Fetched current design page https://app.notion.com/p/410ac25eb49f818a89c2d3cbac4ec88f and the Work Log row PO guidance (2026-11-06 01:00 UTC).

Verdict: PASS. The blocking finding in comment 6674288624 is resolved; no remaining findings in scope.

Blocking finding — checked element by element

PO guidance (Work Log row, 2026-11-06 01:00 UTC): 'text growth between two samples proves recent activity, but can precede completion before the back press. Require timestamped active-stream evidence at the navigation boundary, and reject cycles that finished before navigation.'

(a) Timestamps per sample + back press, per cycle: §1 step 2 — 'Record each poll in the manifest with its UTC timestamp and its text length.' §1 step 3 — final sample and back press each 'record ... in the manifest with its UTC timestamp'. Manifest spec — per cycle: 'each streaming-proof sample (UTC timestamp + text length, including the final boundary sample), the back-press UTC timestamp'. PASS.
(b) Still-streaming check at the boundary: §1 step 3 — 'take a final sample immediately before the back press — reply text length still growing since the previous poll, or the streaming indicator still visible'; 'Navigate back only when the boundary check shows the stream still running.' PASS.
(c) INVALID rule: §1 step 3 — 'If the reply completed before the back press, the cycle is INVALID: it does not count toward the 5 cycles and is re-run.' Manifest spec carries 'an INVALID flag when the reply completed before the back press, and PID'. PASS — a completed-before-navigation cycle can no longer count toward the 5.

Amendment text matches comment 6674434559 exactly in the fetched page.

§3 minor — confirmed

Day-3 verdict now reads: 'PASS (no new FATAL for the version + events arriving), FAIL (ids listed), or UNVERIFIED (telemetry absent, or the 3-day window unfinished — UNVERIFIED is never a pass).' Matches the PO rule that an unfinished window / missing telemetry stays UNVERIFIED, not PASS-by-absence.

Spot-check §2/§4 — unchanged in meaning

§2: Decision A (gate job in publish-play-store.yml, publish job needs: it), entry paths tag push + workflow_dispatch, release:published retired with dependents examined, dispatch-only cua_force_fail proof. §4: 20% hold for the 3-day window, halt on 1 new FATAL or telemetry UNVERIFIED at day 1, vitals dropped, actor = existing release owner, Play change needs Den's go. Both consistent with the resolved v1 findings; no substance change detected.

Also intact in §1: 5 cycles, same-PID survival (§1 step 4), usable re-entry, logcat with no FATAL EXCEPTION / no 'child already has a parent'.

Next step

Supervisor admits implementation: Google AI Studio route via the existing release owner, PR + Stage 4 review. The §4 staged-rollout Play change (userFraction/status) still needs Den's explicit go. No push of main / no v* tag by this chain. No design edit, implementation, or Play/Sentry change in this re-check.

Claim — agent session cbdde2f3-9974-4899-8d66-40cd60c47390 in progress.

Scope: Stage 3 IMPLEMENTATION only, design §1 + §2 (design PASS, comment 6674529569). Branch + PR only — no merge, no push to main, no v* tag, no release, no workflow dispatch.

§1: new mid-stream-exit mode in scripts/android-cua-smoke.py (5 cycles, timestamped streaming-proof samples, boundary sample, INVALID/re-run rule, PID/logcat/re-entry assertions, manifest + logcat + per-cycle screenshots).
§2 Option A: cua-mid-stream gate job as job 1 in .github/workflows/publish-play-store.yml, publish job needs: [cua-mid-stream], release: published trigger retired, dispatch-only cua_force_fail boolean input wired to CUA_FORCE_FAIL=1. cua-smoke.yml byte-unchanged.

Exclusions: no §3, no §4 (no userFraction/track/status change), no app-side code (src/, app config), applicationId cc.agentlabs.opencode unchanged.

Checked before claiming: all 7 issue comments read — prior sessions c180b3eb, 0b59552e, e5e3ce0e, 4c15f089 all completed design stages; open PRs = only #220 (unrelated); main head = 0bbfa70. No live competing claim.

Stage 3 IMPLEMENTATION shipped — agent session cbdde2f3-9974-4899-8d66-40cd60c47390.

PR: #228 (Refs #227, does not close it)
Branch: feat/issue-227-mid-stream-exit-gate — head SHA 33b4b2a (read back via API; compare vs main 0bbfa70 = ahead, 2 files: scripts/android-cua-smoke.py +634/-1, .github/workflows/publish-play-store.yml +251/-5).

Scope = design §1 + §2 only, per the PASS design (comment 6674529569). Exclusions honored: no merge, no push to main, no v* tag, no release, no workflow dispatch (failure-blocks proof runs after Stage 4), no §3, no §4 (no userFraction/track/status change), no app-side code, applicationId unchanged, cua-smoke.yml byte-unchanged.

Local verification (full evidence on the PR): py_compile OK; stub-openai/fake-adb runs prove CUA_FORCE_FAIL=1 → exit 1 + manifest, MODEL_CAPABLE=false → exit 1 (fatal) + manifest; _apk_identity parses aapt badging + sha256; workflow YAML parses with publish needs [cua-mid-stream], release trigger retired, cua_force_fail boolean present. Live emulator 5-cycle run NOT executed locally (no emulator/server on this VM) — first real execution is the gate job at the post-Stage-4 proof stage.

Test-count delta: test files 49 → 49, test cases added 0 — this adds a CUA scenario mode, not unit/mock tests.

Next: Stage 4 review (separate reviewer) → Supervisor. Merge NOT authorized.

Stage 4 review of PR #228: FAIL — verdict + numbered findings on the PR: #228 (comment) (1 blocking: §1 logcat scan runs before re-entry; 2 minor). Head reviewed 33b4b2a. Fix loop back to implementation; do not merge.

Fix-round claim — agent session 22a7f44d-614d-4faf-b9fe-8f1c1fdf5b56 in progress.

Scope: Stage 4 FIX LOOP for PR #228 only, addressing all 3 findings in verdict comment 6675504462 (pointer comment 6675507887): (1) BLOCKING post-re-entry logcat dump+scan per cycle incl. final, recorded in manifest, collected by upload step; (2) manifest github.sha key shape; (3) stream-state not-frozen disposition (enforce definable check or explicit acceptance rationale on PR).

Checked before claiming: all issue #227 comments read (latest = 6675507887, Stage 4 FAIL pointer); prior implementer session cbdde2f3-9974-4899-8d66-40cd60c47390 completed Stage 3; no live competing claim since the verdict. PR head verified 33b4b2a, base main 0bbfa70.

No merge, no tag, no workflow dispatch, no userFraction/track/status change, no app-side code, applicationId untouched, cua-smoke.yml byte-unchanged.

fix(cua): post-re-entry logcat scan, manifest github.sha, frozen-stre…

Stage 4 re-review of PR #228 fix round: PASS — verdict comment 6675710831 on PR #228 (head f6db786). All 3 findings disposed (blocking post-re-entry logcat scan fixed; github.sha nested; frozen-stream enforcement accepted with residual risk recorded). Test-count delta: 49 → 49 files, 0 cases added/removed.

Claim — PROOF stage, agent session d4f71ffb-f580-4c47-9ec0-11adf369c4bc in progress.

Scope: design §2 FAILURE-BLOCKS-PUBLICATION proof ONLY for PR #228 (head f6db786, branch feat/issue-227-mid-stream-exit-gate; Stage 4 re-review PASS = PR comment 6675710831). Exactly ONE workflow_dispatch of publish-play-store.yml at that ref with track=internal, status=draft, cua_force_fail=true. Expected: cua-mid-stream FAILS, publish SKIPPED, no Play upload step executes. No merge, no tag, no push to main, no second dispatch, no Play/Sentry changes.

Stage 0 claim — PROOF-MONITOR

Session/agent id: 775df05d-9b40-455a-ada3-be6d769785f3 (proof-monitor task subagent, opencode-hourly Supervisor dispatch)

Scope: monitoring proof run 42154476280 only — no re-dispatch, no merge/tag/push.

Run: https://github.com/dzianisv/opencode-mobile/actions/runs/42154476280 — workflow "Publish to Google Play Store", workflow_dispatch, branch feat/issue-227-mid-stream-exit-gate, head f6db786, cua_force_fail=true (design §2 failure-blocks proof). Already dispatched exactly once by the previous Supervisor run; this agent polls it to completion and posts the verdict. Design PASS (comment 6674529569) and Stage 4 re-review PASS (PR #228 comment 6675710831, head f6db786) are already recorded — not redone.

Proof verdict (design §2 failure-blocks) — PASS

Monitored by proof-monitor session 775df05d-9b40-455a-ada3-be6d769785f3. No re-dispatch, no merge/tag/push — run 42154476280 was dispatched exactly once by the previous Supervisor run.

Evidence (read back via GitHub API):

Run: https://github.com/dzianisv/opencode-mobile/actions/runs/42154476280 — "Publish to Google Play Store", workflow_dispatch, branch feat/issue-227-mid-stream-exit-gate, head f6db786, status=completed, conclusion=failure, created 2026-11-06T03:06:26Z, completed/updated 2026-11-06T03:28:51Z.
Job cua-mid-stream (id 127685223732): status=completed, conclusion=failure, 03:06:29–03:28:51Z. Its step 16 "Run mid-stream-exit CUA gate with emulator" concluded failure (03:27:17–03:28:48Z) — the cua_force_fail=true force-fail worked. Prior steps succeeded, including "Install dependencies & build APK" (03:07:02–03:26:57Z).
Job publish (id 127692776172): status=completed, conclusion=skipped, steps=[] — the publish job never ran and no upload step executed.
Overall run conclusion=failure.

This matches the expected PASS shape exactly: cua failure blocks publish. Proof PASS for design §2 failure-blocks on head f6db786.

OWNER DECISION (Den, 2026-11-06): DISABLE the CUA gate for now. The real mid-stream CUA run cannot pass — there are no model tokens/credits available for it — so as built it would block every release for a funding reason, not a product defect. Direction for PR #228: amend it so the cua-mid-stream job is DISABLED as a publish gate (non-blocking / manual-dispatch only); keep the scenario and workflow code in the repo so re-enabling is a one-line change once tokens are funded. The failure-blocks proof already recorded stands as evidence the gate mechanism works. After the amendment: re-review (Stage 4) on the new head, then the merge decision returns to Den. Do NOT merge, tag, or push main from the Supervisor chain.

CLAIM — Muse, task lead (dev_workflow, OpenCode Mobile). Scope: amend PR #228 on branch feat/issue-227-mid-stream-exit-gate per Den's owner decision 2026-11-06 (comment 6680801512 on this issue / 6680801908 on PR #228): make the cua-mid-stream job in .github/workflows/publish-play-store.yml non-blocking / manual-dispatch only so publish no longer needs it; scenario code (scripts/android-cua-smoke.py mid-stream-exit) stays untouched; then Stage 4 re-review on the new head. Stage 0 check done 2026-11-06: no competing claim — last activity on #227 (08:39:09Z) and #228 (08:39:11Z) is Den's decision itself; PR head verified f6db786, main unchanged 0bbfa70. HARD GATES: no merge of #228, no push to main, no tags, no publish dispatch — merge decision stays with Den after re-review.

fix(ci): disable CUA mid-stream gate as publish blocker

Amendment shipped + Stage 5.5 record (Muse, task lead; claim 6681683968).

Owner decision consumed: Den 2026-11-06, comment 6680801512 here / 6680801908 on PR #228 — CUA gate DISABLED for now (no model tokens/credits for the real run; gate would block releases for a funding reason). Acknowledged in the Work Log row notes.

Amendment (implementation subagent, diff read back by task lead): PR #228 new head f551fb8 (parent f6db786). ONE file changed: .github/workflows/publish-play-store.yml (+7/-3) — cua-mid-stream gets if: workflow_dispatch only + DISABLED comment (re-enable = remove if: + restore publish needs:, one line each); publish job's needs: [cua-mid-stream] removed. Scenario code untouched: scripts/android-cua-smoke.py blob b056a95352c85fe2b01eabbedbd62404a99caccb identical at both heads. YAML parses at new head.

Stage 4 re-review (separate reviewer): PASS — PR #228 comment 6681812356, 2026-11-06T09:36:57Z, criteria 1-6 all PASS. Test-count delta: test files 49 -> 49, cases added 0 / removed 0.

Stage 5.5 Design/PRD sync: Design UPDATED — https://app.notion.com/p/410ac25eb49f818a89c2d3cbac4ec88f section 2 now carries a 'Superseded in part — Den, 2026-11-06' note recording the disabled/manual-only gate, the re-enable steps, and that the original failure-blocks proof (6676092875) stands; read back after edit, exactly one note. PRD: none exists for this project (verified 2026-11-01) — nothing to sync.

Next: merge decision on amended PR #228 stays with Den. No merge, no main push, no tag, no publish dispatch performed.

Merge PR #228: mid-stream-exit CUA gate (disabled per owner, #227)

OWNER CLOSE-OUT (2026-11-07):

PR feat(cua): mid-stream-exit release gate + publish workflow gate job (#227) #228 MERGED by owner decision. Merge SHA 399a770 on main (verified via refs/heads/main readback). This lands the mid-stream-exit CUA scenario with the gate in its amended, DISABLED form (non-blocking / manual-dispatch only, per Den 2026-11-06 — no tokens for the real run; one-line re-enable once funded). No tag pushed; nothing published — merge to main is not a release.
Item 2 (3-day post-release Sentry watch): covered by the standing daily job opencode-sentry-fix-release (daily Sentry review + fix + release loop, running since 2026-11-06). No duplicate watch.
Item 3 (staged Play rollout): decision = ADOPT, tracked as its own follow-up issue (staged rollout for future releases) so it does not hold this gate work. It needs a publish-workflow change + Play track config; scheduled with the next release cycle.

Closing #227: gate built, failure-blocks behavior proven (run 42154476280), gate disabled by owner decision, watch delegated to the daily loop.

Navigation Menu

Repository navigation

Release gate: CUA mid-stream-exit scenario as pre-publication prerequisite (regression OPENCODE-MOBILE-6/-7) #227

Why

Scope — three sub-items

Constraints

Acceptance criteria

V1 findings — verified resolved

Blocking finding — §1 streaming proof does not meet the navigation-boundary precision rule

Next step

Blocking finding — checked element by element

§3 minor — confirmed

Spot-check §2/§4 — unchanged in meaning

Next step

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Release gate: CUA mid-stream-exit scenario as pre-publication prerequisite (regression OPENCODE-MOBILE-6/-7) #227

Description

Why

Scope — three sub-items

Constraints

Acceptance criteria

Activity

dzianisv commented on Nov 6, 2026

dzianisv commented on Nov 6, 2026

dzianisv commented on Nov 6, 2026

dzianisv commented on Nov 6, 2026

V1 findings — verified resolved

Blocking finding — §1 streaming proof does not meet the navigation-boundary precision rule

Next step

dzianisv commented on Nov 6, 2026

dzianisv commented on Nov 6, 2026

dzianisv commented on Nov 6, 2026

Blocking finding — checked element by element

§3 minor — confirmed

Spot-check §2/§4 — unchanged in meaning

Next step

dzianisv commented on Nov 6, 2026

dzianisv commented on Nov 6, 2026

dzianisv commented on Nov 6, 2026

dzianisv commented on Nov 6, 2026

dzianisv commented on Nov 6, 2026

dzianisv commented on Nov 6, 2026

dzianisv commented on Nov 6, 2026

dzianisv commented on Nov 6, 2026

dzianisv commented on Nov 6, 2026

dzianisv commented on Nov 6, 2026

dzianisv commented on Nov 6, 2026

dzianisv commented on Nov 7, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions