[Jinwoo-H]

	Files	Added	Deleted	Net
Test	13	$\color{#1a7f37}{\Huge{\mathbf{+}}}$​865	$\color{#cf222e}{\Huge{\mathbf{−}}}$​16	$\color{#1a7f37}{\Huge{\mathbf{+}}}$​849
Prod	18	$\color{#1a7f37}{\Huge{\mathbf{+}}}$​130	$\color{#cf222e}{\Huge{\mathbf{−}}}$​47	$\color{#1a7f37}{\Huge{\mathbf{+}}}$​83

ELI5

An obsolete heartbeat could keep a worker’s completion hidden. Orca now checks whether a batch actually contains unread messages before letting it block the inbox. Batch IDs still identify exactly which messages an acknowledgement consumes.

What Changed

Keep the existing deliveries.status for acknowledgement and revocation. Derive replay and notification eligibility through one outstanding_deliveries view: status is outstanding and at least one member is unread. Reading or suppressing messages does not need to update batch status, and checking an obsolete batch needs no repair write.

Schema v41 keeps the table and its columns. It replaces the existing status-based unique index with a nonunique index under the same name; a trigger consulting the view enforces one eligible batch per mailbox. This avoids the previous table rebuild and replacement fencing flag.

Creation and acknowledgement validate ownership, generation, and worker lifecycle inside their transaction. Finished workers cannot consume mail awaiting rerouting. Existing remote states with uncertain liveness remain eligible. Replacement revokes all unacknowledged batches independently of message read state.

Consuming output retains its delivery ID, history does not expose an unrelated acknowledgement ID, and CLI help explains wake-only filtering and whole-batch acknowledgement. The unrelated notification-prefix change was removed.

Why

The stored batch status records acknowledgement or revocation; it is insufficient on its own to determine whether unread work remains. Deriving eligibility removes the synchronization problem without changing the historical storage representation. Partial batches replay their complete original membership, preserving FIFO and acknowledgement safety.

Linked Issue

Direct investigation request; no linked issue.

Visual Proof

N/A — database and CLI behavior verified through automated tests; no rendered UI changes or desktop interaction recording.

Testing

• Automated delivery, lifecycle, migration, fencing, RPC and CLI regressions.
• Broad local suite: 2,931 tests passed, 11 skipped across 207 files on simplified head a82838f5f0.
• Historical database round trip: actual pre-v41 implementation at aac38d698ff7 creates the database; current code upgrades it and advances past a consumed batch; old code reopens, acknowledges both retained batches and writes a new batch; current code reopens and acknowledges that batch.
• Packaged desktop downgrade manually exercised (not performed).

The round-trip test reuses the existing release-checkout harness and temporary SQLite files. Run it with ORCA_BACKGROUND_LAUNCH=1 pnpm test tests/e2e/cross-version-wire/orchestration-delivery-downgrade.unit.test.ts. All test launches use background mode. No live database was modified.

AI Disclosure

Internal contributor workflow using Claude/Codex and independent Astra/Sol reviews.

Review

Previous Astra and Sol reviews identified and resolved the lifecycle race and inconsistent revocation. Final Astra review found no blocking issues and recommends this simpler version after CI passes. Astra independently ran 48 tests across six files, all passing, and endorsed the historical round-trip coverage. Local typecheck and changed-code quality checks also passed.

Agent skill upstream boundary

• Not applicable; no upstream skill-installer content copied or translated.

Notes

The former one-way column-removal warning no longer applies: status remains readable and writable by the tested pre-v41 code. This is database compatibility evidence for that implementation, not a guarantee for every historical app release or packaged downgrade workflow. Older versions retain their original inbox replay bug; they do not acquire the new derived-eligibility behavior.

RPC shapes, execution-host ownership and remote liveness semantics remain unchanged. Stable batch identity, explicit revocation and real acknowledgement timestamps are preserved. No new acknowledgement timestamp is invented during migration.

Checklist

• Explained behavior and design rationale.
• Removed unrelated nudge wording and obsolete migration machinery.
• Automated regression coverage and historical database round trip pass locally.
• Cross-platform, SSH/remote, and compatibility impact considered.
• Final Astra review complete: no blockers.
• CI green for final test commit 52d8ecc034a: all eight test shards, cross-version compatibility, typecheck, static analysis, packaging, native smoke, Pullfrog, and aggregate verification passed. Shard 8 initially failed during pnpm setup with an npm registry ECONNRESET; it passed on retry without code changes. CI run.

[coderabbitai]

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

• @coderabbitai resume to resume automatic reviews.
• @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

• ▶️ Resume reviews
• 🔍 Trigger review

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Advanced

Run ID: 25d3310c-ebed-414e-bdfa-371228e75c8e

📥 Commits

Reviewing files that changed from the base of the PR and between d008782 and 0e70dbc.

📒 Files selected for processing (10)

• docs/reference/orchestration-delivery-storage.md
• src/main/runtime/orchestration/db/dispatch-context/dispatch-capability.ts
• src/main/runtime/orchestration/db/federation/remote-dispatch-attachment-authority.ts
• src/main/runtime/orchestration/db/messages/mailbox-consumer-lifecycle-fencing.test.ts
• src/main/runtime/orchestration/db/messages/mailbox-consumer.ts
• src/main/runtime/orchestration/db/messages/role-mailbox-delivery.ts
• src/main/runtime/orchestration/db/runs/run-binding.ts
• src/main/runtime/orchestration/db/runs/run-lookup.ts
• src/main/runtime/orchestration/db/schema/derived-delivery-migration.test.ts
• src/main/runtime/orchestration/db/worker-dispatch/worker-dispatch-authority.ts

🚧 Files skipped from review as they are similar to previous changes (1)

• docs/reference/orchestration-delivery-storage.md

Included review availability: Your plan provides up to 10 included reviews per hour; 3 remain after this review.

---

📝 Walkthrough

Walkthrough

The change moves mailbox delivery eligibility from deliveries.status to unread message state, acknowledged_at, and fenced. Schema v41 adds the derived view, indexes, trigger, migration logic, and compatibility handling. Delivery APIs now validate dispatch or attachment consumers. Runtime tests cover replay, suppression, fencing, rollback, and migration behavior. Orchestration check output now reports delivery IDs in formatted mode, and notification messages include an Orca prefix.

Priority: ➖ Normal

Merge Risk: 🟡 Moderate · up to 0e70d

This increment renames and consolidates mailbox delivery fencing calls and consumer validation without introducing new defects that could be substantiated; the reviewed changes correctly special-case coordinator mailboxes and cover all active dispatch states. Two previously flagged concerns about the one-way v41 schema migration (a legacy receipt shape that can silently become replay-eligible, and derived schema objects that could bypass migration repair if left in a stale shape) remain unresolved since this round did not touch those migration files, so they should still be addressed or explicitly accepted before merge.

🚥 Pre-merge checks | ✅ 3 | ❌ 2

❌ Failed checks (2 warnings)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 11.76% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 51 functions across 46 files. (1 skipped:…	Write docstrings for the functions missing them to satisfy the coverage threshold.
Description check	⚠️ Warning	The description is detailed, but it fails the required Linked Issue section and contains material contradictions with the changeset. It says deliveries.status remains and that the notification-prefi…	Add a valid linked issue under Linked Issue. Correct the change summary, rationale, notes, and validation details to match the implemented schema v41 migration, fenced delivery state, notification-prefix change, and actual test counts.

✅ Passed checks (3 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Title check	✅ Passed	The title clearly and concisely describes the main change: deriving orchestration delivery eligibility from messages.

Full details: Docstring Coverage

Explanation

Docstring coverage is 11.76% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 51 functions across 46 files. (1 skipped: 1 unsupported.)

Full details: Description check

Explanation

The description is detailed, but it fails the required Linked Issue section and contains material contradictions with the changeset. It says deliveries.status remains and that the notification-prefix change was removed, while the changes remove status, add fenced, and retain the notification prefix.

• Fix all pre-merge checks with AI

✨ Finishing Touches 💡 1

📝 Generate docstrings 💡

• Create stacked PR
• Commit on current branch

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[pullfrog]

ℹ️ No critical issues — a well-scoped, well-tested fix with one UX rough edge noted inline.

Reviewed changes

• Retire fully-read deliveries — markAsRead / markAsReadAndDelivered now retire an outstanding mailbox delivery when every member is read, inside the existing MESSAGE_MUTATION_SAVEPOINT. Retirement records acknowledged (not fenced) so a late consumer --ack stays idempotent, and it is mailbox-scoped so unrelated mailboxes are untouched.
• Repair obsolete heads before replay — getOrCreateMailboxDelivery retires an outstanding delivery whose messages are all read before falling through to selection, so check --wait --types worker_done advances past a suppressed heartbeat head instead of replaying it.
• Wrong-ID --ack guidance — acknowledgeMailboxDelivery detects a message id passed to --ack, names the owning outstanding delivery only when it belongs to the caller's mailbox, and otherwise points at orchestration check; other mailboxes' ids are not exposed.
• Expose deliveryId on history — the --all history result now carries the outstanding deliveryId, preserved through the formatted CLI output path.
• Nudge attribution mitigation — formatMessagePointer prefixes [Orca orchestration notification].

The regressions are exact, not theatre: the lifecycle-retirement, obsolete-replay, transactional-rollback, mailbox-isolation, and RPC history tests all assert specific ids/statuses rather than truthiness, and the retireReadMailboxDelivery NOT EXISTS subquery is genuinely exercised. The root-cause chain (heartbeat delivery minted first, then worker_done suppresses it, leaving a fully-read outstanding head) is reproduced directly.

ℹ️ Nitpicks

• formatMessagePointer also feeds structured-mailbox-pointer-delivery.ts:218, so the new [Orca orchestration notification] prefix now appears in native-chat structured-lane text blocks where sender identity is already unambiguous. Harmless, but the mitigation leaks past the PTY-only intent.
• getOutstandingMailboxDelivery returns exposeDeliveryTimestamps(...), so getOrCreateMailboxDelivery applies it twice (once at the existing lookup, again on return) and hasOutstandingMailboxDelivery now pays a full-row fetch + timestamp transform for a boolean. Idempotent today, but a latent footgun if the exposure ever becomes non-idempotent.

  ^{｜ Fix all ➔ ｜ Fix 👍s ➔ ｜ View workflow run ｜ Using DeepSeek Pro (free via Pullfrog for OSS) ｜ 𝕏}

[pullfrog]

✅ No new issues found.

Reviewed changes — delta since the prior Pullfrog review at b6e7ab9.

• Removed deliveryId from --all history — the history result no longer carries the outstanding deliveryId, and formatOrchestrationCheckText only prints Delivery <id> when a consuming check actually returned one. The >100 rows misleading-label concern from the prior review is fully resolved, with a regression asserting history has no deliveryId property.
• Retired getOutstandingMailboxDelivery — getOrCreateMailboxDelivery reads the outstanding row directly again, retireReadMailboxDelivery now returns a boolean (result.changes > 0) that drives the replay-vs-advance decision, and hasOutstandingMailboxDelivery is back to a SELECT 1. This resolves the double-exposeDeliveryTimestamps footgun noted earlier.
• Simplified wrong-ID --ack guidance — the isGeneratedId(...,'msg') special case is gone; a single stale_delivery message states the delivery_* contract without revealing another mailbox's delivery, and isGeneratedId import was reverted.
• Consumer generation checked before repair — a fenced consumer can no longer retire an already-read delivery; a new regression asserts the consumer_fenced throw while leaving the delivery outstanding.
• Refreshed CLI help and tests — help notes describe --types and replay behavior without the now-removed history deliveryId line, and the three exact-text nudge assertions were updated for the [Orca orchestration notification] prefix.

The changed unit tests (orchestration-retired-delivery.test.ts, check-delivery-history.test.ts, formatter.test.ts, orchestration-check-output.test.ts) pass locally (33 tests), and the retirement SQL is a correct correlated json_each subquery run only inside caller transactions.

  ^{｜ View workflow run ｜ Using DeepSeek Pro (free via Pullfrog for OSS) ｜ 𝕏}

[pullfrog]

✅ No new issues found.

Reviewed changes — delta since the prior Pullfrog review at 733b18a.

• Aligned the orchestration check spec test — src/cli/specs/orchestration.test.ts updates its check assertion to the revised --types note ("Without --wait it has no effect on consuming checks."), keeping the pre-existing spec test in sync with the note wording changed in the previous commit. The suite passes locally (6 tests).

No production code changed in this commit.

  ^{｜ View workflow run ｜ Using DeepSeek Pro (free via Pullfrog for OSS) ｜ 𝕏}

[coderabbitai]

Actionable comments posted: 2

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Advanced

Run ID: d6c4b4c8-eb5b-46ea-a5d4-428942f375dc

📥 Commits

Reviewing files that changed from the base of the PR and between 795d8e5 and d008782.

📒 Files selected for processing (31)

• docs/reference/orchestration-delivery-storage.md
• src/main/runtime/orchestration-dispatch-mailbox-delivery.test.ts
• src/main/runtime/orchestration-message-delivery-identity.test.ts
• src/main/runtime/orchestration/db.ts
• src/main/runtime/orchestration/db/contract-constants.ts
• src/main/runtime/orchestration/db/dispatch-mailbox-consumer-fencing.test.ts
• src/main/runtime/orchestration/db/messages/mailbox-consumer.ts
• src/main/runtime/orchestration/db/messages/role-mailbox-delivery.ts
• src/main/runtime/orchestration/db/runs/run-delivery.ts
• src/main/runtime/orchestration/db/schema/adopt-legacy-run.ts
• src/main/runtime/orchestration/db/schema/delivery-v40-test-fixture.ts
• src/main/runtime/orchestration/db/schema/derived-delivery-migration.test.ts
• src/main/runtime/orchestration/db/schema/migrate-role-mailbox-delivery-v34.ts
• src/main/runtime/orchestration/db/schema/migrate-v2-v12.ts
• src/main/runtime/orchestration/db/schema/migrate-v35.ts
• src/main/runtime/orchestration/db/schema/migrate-v41.ts
• src/main/runtime/orchestration/db/schema/migrate.ts
• src/main/runtime/orchestration/db/schema/schema-column-probes.ts
• src/main/runtime/orchestration/dispatch-consumer-generation-migration.test.ts
• src/main/runtime/orchestration/federation-acknowledgment-migration.test.ts
• src/main/runtime/orchestration/nested-worker-depth-migration.test.ts
• src/main/runtime/orchestration/orchestration-delivery-consumption.test.ts
• src/main/runtime/orchestration/orchestration-derived-delivery.test.ts
• src/main/runtime/orchestration/orchestration-federated-legacy-probe.test.ts
• src/main/runtime/orchestration/orchestration-legacy-storage-db.test.ts
• src/main/runtime/orchestration/orchestration-legacy-storage-test-fixture.ts
• src/main/runtime/orchestration/orchestration-schema-version-skew.ts
• src/main/runtime/orchestration/orchestration-version-skew-migration.test.ts
• src/main/runtime/orchestration/types.ts
• src/main/runtime/rpc/methods/orchestration/messaging/check-delivery-history.test.ts
• src/main/runtime/rpc/methods/orchestration/messaging/check-worker.ts

💤 Files with no reviewable changes (1)

• src/main/runtime/orchestration/db.ts

Included review availability: Your plan provides up to 10 included reviews per hour; 8 remain after this review.

[coderabbitai]

🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win

🔎 Supported by static analysis

🤖 get_repo_knowledge executed:

get_repo_knowledge stablyai/orca /tmp/coderabbit-repo-knowledge/stablyai-orca-89dc44e4/learnings

Length of output: 33738

---

🏁 Script executed:

#!/bin/bash
set -eu
printf '%s\n' '--- target file ---'
sed -n '130,215p' src/main/runtime/orchestration/orchestration-schema-version-skew.ts
printf '%s\n' '--- v41 migration candidates ---'
fd -i 'migrate-v41|.*v41.*' src
printf '%s\n' '--- relevant definitions and callers ---'
rg -n -C 6 "outstanding_deliveries|trg_deliveries_one_outstanding|idx_deliveries_unacknowledged_mailbox|resolveOrchestrationMigrationStartVersion|hasCompletePostV6Schema" src

Repository: stablyai/orca

Length of output: 50369

---

🏁 Script executed:

#!/bin/bash
set -eu
printf '%s\n' '--- files containing v41 migration ---'
rg -l "outstanding_deliveries|trg_deliveries_one_outstanding|idx_deliveries_unacknowledged_mailbox" . --glob '!node_modules/**' --glob '!dist/**' --glob '!build/**'
printf '%s\n' '--- target file outline ---'
ast-grep outline src/main/runtime/orchestration/orchestration-schema-version-skew.ts

Repository: stablyai/orca

Length of output: 1526

---

🏁 Script executed:

#!/bin/bash
set -eu
sed -n '1,260p' src/main/runtime/orchestration/orchestration-schema-version-skew.ts

Repository: stablyai/orca

Length of output: 8661

---

🏁 Script executed:

#!/bin/bash
set -eu
printf '%s\n' '--- target file ---'
sed -n '130,215p' src/main/runtime/orchestration/orchestration-schema-version-skew.ts
printf '%s\n' '--- relevant files ---'
rg -l "outstanding_deliveries|trg_deliveries_one_outstanding|idx_deliveries_unacknowledged_mailbox" . --glob '!node_modules/**' --glob '!dist/**' --glob '!build/**'

Repository: stablyai/orca

Length of output: 3965

---

🏁 Script executed:

#!/bin/bash
set -eu
printf '%s\n' '--- migration and skew definitions ---'
rg -n -C 12 "outstanding_deliveries|trg_deliveries_one_outstanding|idx_deliveries_unacknowledged_mailbox|hasCompletePostV6Schema|resolveOrchestrationMigrationStartVersion" src/main/runtime/orchestration

Repository: stablyai/orca

Length of output: 50369

---

🏁 Script executed:

#!/bin/bash
set -eu
printf '%s\n' '--- v41 migration ---'
cat -n src/main/runtime/orchestration/db/schema/migrate-v41.ts
printf '%s\n' '--- migration dispatch ---'
sed -n '1,80p' src/main/runtime/orchestration/db/schema/migrate.ts
printf '%s\n' '--- consumers of derived delivery objects ---'
rg -n -C 5 "outstanding_deliveries|trg_deliveries_one_outstanding|idx_deliveries_unacknowledged_mailbox|hasOutstandingMailboxDelivery|getOrCreateRunDelivery" src/main/runtime/orchestration/db src/main/runtime/orchestration --glob '!*.test.ts'

Repository: stablyai/orca

Length of output: 37674

---

🏁 Script executed:

#!/bin/bash
set -eu
printf '%s\n' '--- v41 migration ---'
cat -n src/main/runtime/orchestration/db/schema/migrate-v41.ts
printf '%s\n' '--- migration dispatch ---'
sed -n '1,75p' src/main/runtime/orchestration/db/schema/migrate.ts
printf '%s\n' '--- derived delivery consumers ---'
rg -n -C 4 "outstanding_deliveries|hasOutstandingMailboxDelivery|getOrCreateRunDelivery" src/main/runtime/orchestration/db --glob '!*.test.ts'

Repository: stablyai/orca

Length of output: 16551

---

Validate v41 delivery object definitions before accepting the stored version.

hasCompletePostV6Schema checks only object names. A v41 database with incorrect definitions can therefore skip migration repair. A bad view can hide outstanding deliveries from hasOutstandingMailboxDelivery, and a bad trigger can allow multiple deliveries for one mailbox. Validate the index predicate, view predicates, and trigger condition. Add a skew test with incorrect same-named objects and verify repair after reopening.

[pullfrog]

Important

The derived-eligibility redesign is technically sound and exceptionally well covered, but schema v41 is a one-way local upgrade with no rollback backup — shipped binaries that still read deliveries.status cannot reopen an upgraded database. This remains the single gating item to resolve before un-drafting; the rest of the review confirms the implementation itself, and enumerates the concrete resolution paths.

Reviewed changes

• Derive eligibility from a view — outstanding_deliveries (a SQLite view joining deliveries to unread messages via json_each) replaces the stored status column; replay, notification, and the single-active-batch constraint all read this one source. No read-time repair or message↔delivery sync remains.
• Schema v41 migration — drops deliveries.status and its partial unique index, adds a fenced INTEGER, and recreates the single-active-batch backstop as an AFTER INSERT trigger consulting the same view. Version-skew detection now requires the view, trigger, and idx_deliveries_unacknowledged_mailbox at >= 41, so a dropped view is rebuilt on reopen.
• In-transaction consumer validation — the optional requireCurrentRunConsumer flag is replaced by requireMailboxConsumer, which validates run / dispatch / attachment generations (and their run_id) inside the delivery BEGIN IMMEDIATE transaction rather than re-reading them outside it.
• Nudge attribution + CLI text — formatMessagePointer prefixes [Orca orchestration notification]; --types and --ack help notes clarified; Delivery <id> remains printed only on consuming checks.

⚠️ One-way migration has no rollback path

The migration is transactional, so a crash mid-upgrade rolls back cleanly — the risk is not a corrupt database, it is the landed upgrade followed by a downgrade. Options to resolve before merge:

Technical details

# One-way migration has no rollback path

## Affected sites
- src/main/runtime/orchestration/db/schema/migrate-v41.ts — `DROP TABLE deliveries` (dropping `status`) is irreversible; no pre-upgrade backup is created.
- docs/reference/orchestration-delivery-storage.md — already documents the downgrade limitation honestly.

## Required outcome
- Choose a rollback story before un-drafting/merging: either accept + document the one-way upgrade, or preserve a downgrade path.

## Suggested approach (optional)
- Snapshot the database file(s) — including `-wal` / `-shm` if journaled in WAL mode — before the destructive `DROP TABLE`, so a downgraded binary can be pointed at the pre-v41 copy; or
- keep `status` in the v41 table (unmaintained/stale but readable) so older binaries can still open the database, trading away the "no stored status" goal.

## Open questions for the human (optional)
- Is there a realistic downgrade flow (auto-update rollback / version pin) a user could hit? If not, accepting the one-way upgrade as documented may be the right call.

  ^{｜ Fix it ➔ ｜ View workflow run ｜ Using DeepSeek Pro (free via Pullfrog for OSS) ｜ 𝕏}

[pullfrog]

✅ No new issues found.

Reviewed changes — delta since the prior Pullfrog review at d008782. This commit implements the lifecycle-race fix and streamlines revocation.

• Validate consumers under the delivery lock — requireMailboxConsumer now limits dispatch consumers to status IN ('pending', 'dispatched') (ACTIVE_DISPATCH_CONSUMER_SQL) and attachment consumers to potentiallyLiveRemoteAttachmentSql() (the complement of WORKER_SETTLED_STATES), which closes the race where a settled worker could still consume mail awaiting reroute. start_unknown / stop_unknown remain eligible, matching the existing uncertain-liveness contract.
• Widen batch revocation to every unacknowledged batch — fenceOutstandingMailboxDelivery is renamed to fenceUnacknowledgedMailboxDeliveries and now fences acknowledged_at IS NULL AND fenced = 0 rows instead of only view-visible ones. This is what lets historical adoption (adoptLegacyRunIfNeeded, no generation bump) revoke a batch, since delivery.fenced is then the only block on a late --ack.
• Dropped the redundant pre-read guard — check-worker.ts no longer re-reads readCurrentGeneration() before reading a delivery, relying on the atomic in-transaction check, and threads consumerSource: activeDispatch ? 'dispatch' : 'attachment' through both the ack and the create paths.
• Added exact lifecycle-fencing tests — mailbox-consumer-lifecycle-fencing.test.ts asserts consumer_fenced for create/ack after local completion/failure and remote stop/failure on a second connection, preserves unread state and generation, and verifies start_unknown / stop_unknown attachments stay deliverable.

The regressions are exact rather than theatre — they assert specific consumer_fenced codes, fenced: 1, null acknowledged_at, and unchanged generations — and the settlement paths in the it.each matrix genuinely exercise the new status / liveness filters.

  ^{｜ View workflow run ｜ Using DeepSeek Pro (free via Pullfrog for OSS) ｜ 𝕏}

[Tauri-EPO]

One question on the wake side of this, since delivery eligibility moves onto the messages view here.

Today mailbox-pointer-eligibility.ts excludes from the pointer only the types some waiter filters. The guide's coordinator wait is check --wait --types "worker_done,escalation,question", so a routine heartbeat never matches a waiter, gets a pointer, and wakes the coordinator for a message that carries no decision (#14910). In this design, does a heartbeat still earn a pointer, or does eligibility for the wake now depend on the message type as well?

Asking because #15173 (mine) changes exactly that predicate and I would rather rebase it onto the answer here than race this PR.

[pullfrog]

✅ No new issues found.

Reviewed changes — delta since the prior Pullfrog review at 0e70dbc (new head a4115b2).

• Kept deliveries.status and made v41 non-destructive — migrateV41 now only drops the unique constraint from idx_deliveries_one_outstanding (same name and predicate) and creates the outstanding_deliveries view plus AFTER INSERT trigger; no column is removed. An older binary opens the upgraded DB, sees a higher user_version, skips migration, and still resolves its status queries and expected index name. This resolves the one-way-migration gate raised at d008782.
• Derived objects rebuilt on every open — createTables now execs DERIVED_DELIVERY_SCHEMA_SQL, so a dropped view/trigger is recreated on reopen even though migrate early-returns on a v41 stamp; migrate drops both before the table-rebuilding steps and recreates them after.
• Status replaces the fenced column — DeliveryRow/DeliveryStatus revert to status, fencing writes status = 'fenced' for status = 'outstanding' rows, and the view filters status = 'outstanding' AND EXISTS(unread member).
• Nudge prefix and version-skew v41 requirements reverted — formatMessagePointer no longer adds [Orca orchestration notification], and the schema-version-skew probes return to the v40 object set.

I ran the affected suites locally against a4115b2: 928 passed / 10 skipped across 121 orchestration files, plus the focused migration, lifecycle-fencing, check-delivery-history, and CLI-output tests, and pnpm tc:node is clean. The downgrade regression test asserts the retained status column and non-unique index shape, and that a v40 target leaves the v41 stamp untouched.

ℹ️ PR description still describes the superseded column-drop design

The head commit reverses the approach (status retained, migration non-destructive), but the PR body still advertises the old one: the Notes section calls v41 "a one-way local database upgrade" with "the removed status column" and no rollback backup, ELI5/What-Changed say the duplicated waiting status is removed, and the "Why" list still claims nudges gain an [Orca orchestration notification] prefix that no longer exists in formatter.ts. The [ ] Database downgrade tradeoff accepted or resolved before merge checklist item is also still unchecked even though retaining status resolves that tradeoff. Updating the description before un-drafting would keep merge reviewers from gating on a limitation the code no longer has.

Technical details

# Stale PR description vs. head

## Affected sites
- PR body — "Notes" describes a one-way v41 upgrade with the removed `status` column and no rollback backup.
- PR body — "ELI5" / "What Changed" state the duplicated delivery waiting status is removed.
- PR body — "Why" item 6 and the testing section advertise the `[Orca orchestration notification]` prefix, absent from `src/main/runtime/orchestration/formatter.ts:112`.
- PR body — checklist `[ ] Database downgrade tradeoff accepted or resolved before merge` remains unchecked.

## Required outcome
- Description and checklist match the retained `status` column and the now downgrade-compatible v41 stamp, so merge is not gated on a resolved limitation.

## Suggested approach (optional)
- Rewrite the Compatibility note to mirror `docs/reference/orchestration-delivery-storage.md` and check the downgrade checklist item.

  ^{｜ View workflow run ｜ Using openrouter/deepseek/deepseek-v4.1-flash (free via Pullfrog for OSS) ｜ 𝕏}

[pullfrog]

Important

The new downgrade round-trip test is not registered in any CI lane — the sharded unit job excludes tests/e2e/cross-version-wire/**, and the dedicated cross-version-wire job runs an explicit five-file list that omits it. The compatibility evidence the PR body cites therefore never executes on a PR.

Reviewed changes — delta since the prior Pullfrog review at a4115b2.

• Added a historical downgrade round-trip test — orchestration-delivery-downgrade.unit.test.ts materializes the pre-v41 tree at aac38d698, creates a database, has current code upgrade it and advance past a fully-read heartbeat, then confirms pre-v41 code can still reopen, acknowledge both retained batches, and write a new batch that current code consumes.
• PR description updated to the retained-status design — the body no longer advertises the column-drop/one-way upgrade or the reverted nudge prefix, and the round trip is listed under Testing. The earlier informational note is resolved.

The test is genuinely falsifiable: the not.toBe(oldBatch.delivery.id) assertion fails if current code still replays a fully-read batch by stored status, and it passes locally in ~5.4s against the pinned checkout.

  ^{｜ Fix all ➔ ｜ Fix 👍s ➔ ｜ View workflow run ｜ Using openrouter/deepseek/deepseek-v4.1-flash (free via Pullfrog for OSS) ｜ 𝕏}

[pullfrog]

This test never runs in CI. unit-tests.yml:59 explicitly excludes tests/e2e/cross-version-wire/**, and the dedicated cross-version-wire job in pr.yml:655-660 runs an explicit five-file list that does not include this file. Add its path to that job's vitest run argument list — it is the only lane that checks out with fetch-depth: 0, so the pinned aac38d698 resolves.

Technical details

# New compatibility test is registered in no CI lane

## Affected sites
- `.github/workflows/unit-tests.yml:59` — `--exclude=tests/e2e/cross-version-wire/**` removes this file from the sharded `test` job.
- `.github/workflows/pr.yml:655-660` — the `cross-version-wire` job enumerates five `.unit.test.ts` files and omits `orchestration-delivery-downgrade.unit.test.ts`.

## Required outcome
- `orchestration-delivery-downgrade.unit.test.ts` executes in CI, so the v41 forward/backward-compatibility contract it encodes is actually enforced.

## Suggested approach
- Append `tests/e2e/cross-version-wire/orchestration-delivery-downgrade.unit.test.ts` to the `vitest run` list in the `cross-version-wire` job. Its `actions/checkout` already uses `fetch-depth: 0`, which `materializeReleaseCheckout` needs to resolve `aac38d698` (a confirmed ancestor of `origin/main`).