[rmcdaniel]

Schedule list consumers need the last dispatch outcome independently of the latest workflow execution. This release packages accepted #1200 as native Server 3.10.0, with bounded durable dispatch_summary v1, complete outcome/count distinctions and unavailable legacy authority. The PR itself changes only the tagged release notes and published Compose default.

The notes document explicit SQLite 13→14, PostgreSQL/MariaDB 14→15 and MySQL 15→16 upgrades, all-replica stop/backup and restore-required rollback. Protocol 1.20/control plane 2 and the 3.9.2 key/completion/observation boundaries remain unchanged.

Delivered: native 3.10.0, source b6e04ce7e679464e91f6ceae83310d3bb3204092, both-registry index sha256:ca92c866fc0f3819068c5088fbd0a79115bb5588c06a4f5324b9280356c08bad. Final receipt and independent Security publication PASS cover immutable source/images, smoke/scans/provenance, exact corpus/four Compose cells, protected aliases and stable/Latest Release with exact tagged notes. Published SQLite upgrade evidence preserves rows/journal and legacy schedule authority; it does not claim other backend installed upgrades.

Matching Chart #1213 and Waterline #310/#222 published request-budget/visible-refresh acceptance remain separate under #1014. No new upload/Cloud authority or #1204 fix is claimed.

[rmcdaniel]

Security source/tree/notes review: PASS for exact head 7062cc890ce02c4ce13abaadd97e96c09d777cb0, tree 2c2ccd7f52d9a9430c4c0ad9bc5016fb9ff0b03a.

I independently verified the merge shape. The head has parents bfce07534ddfa1fbe93f4893a303af0c097ba2a2 and accepted seed main a09f156399416216d2f097c257a2164f83c7eda7; relative to that accepted main, the complete owned delta is exactly:

• docs/releases/3.10.0.md
• the docker-compose.published.yml default image change from 3.9.2 to 3.10.0

The release note's backend steps match the accepted migration/runtime catalogs: SQLite 13 -> 14, PostgreSQL 14 -> 15, MariaDB 14 -> 15, and MySQL 15 -> 16. Its explicit stop/backup/one-shot-upgrade/same-version-restart and restore-to-rollback procedure is appropriately fail-closed for this additive schema step. The note also accurately preserves the unchanged worker protocol 1.20 and control plane 2 boundary.

I checked the summary prose against the accepted implementation and protocol schema: v1 owns the complete state / last_outcome / buffered_actions_count object, distinguishes known, never, and unavailable, admits only the four documented outcomes, keeps current buffer depth distinct from the last dispatch outcome and later workflow execution state, and bounds stored/read authority at 4096 serialized UTF-8 bytes. The no-legacy-backfill, no field-by-field mixed-observation inference, bounded list read, and consumer-specific published-tuple gates are all stated without promoting source merge to runtime or consumer acceptance.

This verdict covers only the exact two-file preparation and its merge/tree attribution. It does not clear unfinished exact-head CI, create or approve a 3.10.0 tag/image/alias/Release, qualify the four published backend upgrades, select a chart, or inherit Waterline/installed-client/Cloud acceptance.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[rmcdaniel]

#1212 merged through the normal queue at b6e04ce7e679464e91f6ceae83310d3bb3204092, tree 2c2ccd7f52d9a9430c4c0ad9bc5016fb9ff0b03a. The full tree exactly equals Security-reviewed 7062cc89. All current head checks (21 successes, eight intended skips) and merge-group required checks passed. Security source/tree/notes PASS is unchanged. The merged topic branches are deleted and remote absence is verified.

New immutable tag 3.10.0 now names that accepted source. Absence was checked locally/remotely before normal creation/push; no old tag was moved or reused. GitHub reported the maintainer's configured tag-creation restriction bypass on that new ref; no force/admin option was used.

Protected native publication run 43477098008 is building and smoking both architectures. Server retains published scans, raw registry/source/provenance checks, exact-tag corpus/four-cell Compose, reviewed five-receipt selection, protected aliases and final Release. Matching Chart and Waterline consumer acceptance follow that qualified tuple. Current stable Docs/aliases remain the prior qualified 3.9.2 / Chart 1.7.1 pair; no 3.10.0 qualification, consumer result or #1014 completion is inferred from this source/tag step. #1204 remains open and no pool-timeout fix is claimed.

[rmcdaniel]

Immutable 3.10.0 publication completed successfully at accepted source b6e04ce7e679464e91f6ceae83310d3bb3204092 (protected run 43477098008, attempt 1). Both architecture build/smoke jobs, index/provenance job and both scan jobs passed.

Fresh anonymous reads of GHCR and Docker Hub exact 3.10.0 tags agree. Both raw index bytes hash to sha256:ca92c866fc0f3819068c5088fbd0a79115bb5588c06a4f5324b9280356c08bad. Each index contains exactly these two platform subjects:

Platform	Child manifest	Image config
linux/amd64	sha256:9d64e9aeee84b46d21715826a3e7e5a96eb8d4ce7fccb126b88b15596ab14973	sha256:807f14778e939db3788a974eaac6a57c5340ba8d6548398824f1c431dce20f3f
linux/arm64	sha256:d94b610c4f248834c9b15f78b05ee2a1d438b42af69c7714e3221f7ffe1e67a5	sha256:f35242116eaf1886e9306f9b4c0d5848bb4e2e4ea664d3e1310a95a6e1a4d17e

Both registry configs bind the tag, exact source and publication run, and user 1000:1000. Both signed index attestations verify against the tagged native-release workflow and exact run attempt. Both smoke receipts record 3.10.0 ready on SQLite/PostgreSQL/MySQL, clean SIGTERM, required authentication and takeover commands. The artifact ZIP bytes match current GitHub API digests.

Artifact	ID	ZIP SHA256
native-smoke-arm64	14064580972	sha256:9d9472fe3bc312ca04bd5312d13ebdcce54b4c2d3eab09c886f9d7ba583b4efc
native-scan-arm64	14064217806	sha256:ec7f6e2c50213720ddfe952933658350171497434c8731c916e9ee015093c828
native-scan-amd64	14063577987	sha256:1c75ea6b6cf25d0b85896caf708a007632ac5fb6a8d815b33dd19c366098bbbf
native-smoke-amd64	14062474407	sha256:f0d5d16eab8ae0958a8095bcc22268a95b9b3a65d7c8e0e7705d5d5674b6740d

Both scans have identical findings fingerprint sha256:d5e5d3910643983cb1a6e428105e77c97ee5b96249c2cfca66a5d3eae6e5e246: 1 critical, 34 high, 11 advisory identities, 0 actionable fixed-version rows. This preserves the existing distribution-inventory disposition, not a vulnerability-free claim. No SBOM is claimed.

Exact-tag qualification now runs against this immutable index: corpus 43479707272 and all four Compose cells 43479723896. Their terminal success, exact five-receipt manifest, independent Security review, protected alias promotion and final Release remain required. No qualified downstream adoption or Waterline consumer acceptance is inferred from build/scan results.

[rmcdaniel]

Security immutable-publication review: PASS, scoped only to native 3.10.0 source b6e04ce7e679464e91f6ceae83310d3bb3204092, protected run 43477098008 attempt 1, and the exact 3.10.0 registry subjects/artifacts.

Independent checks:

• GitHub's refs/tags/3.10.0 is the exact accepted commit above; the protected workflow run is terminal success at that same SHA and contains the expected build/smoke, index/provenance, and two scan jobs.
• Fresh anonymous raw reads of GHCR and Docker Hub are byte-identical at index SHA-256 ca92c866fc0f3819068c5088fbd0a79115bb5588c06a4f5324b9280356c08bad. The index contains exactly linux/amd64 child 9d64e9aeee84b46d21715826a3e7e5a96eb8d4ce7fccb126b88b15596ab14973 and linux/arm64 child d94b610c4f248834c9b15f78b05ee2a1d438b42af69c7714e3221f7ffe1e67a5; each child manifest is also byte-identical across registries.
• I rehashed the two config blobs as 807f14778e939db3788a974eaac6a57c5340ba8d6548398824f1c431dce20f3f and f35242116eaf1886e9306f9b4c0d5848bb4e2e4ea664d3e1310a95a6e1a4d17e. Both independently report the correct architecture, User=1000:1000, the native entrypoint, tag 3.10.0, source revision b6e04ce7…, and release run 43477098008.
• gh attestation verify validates both GHCR and Docker Hub subjects. The signer identity is the tagged native-release.yml, source/tag digest is b6e04ce7…, trigger is workflow_dispatch, and invocation is exactly run 43477098008/attempts/1.
• I downloaded all four artifacts directly through the GitHub API. Their ZIP bytes match the recorded/API digests: arm64 smoke 9d9472fe…, arm64 scan ec7f6e2c…, amd64 scan 1c75ea6b…, amd64 smoke f0d5d16e…. The smoke receipts bind the exact child subjects, 3.10.0, non-root user, authentication refusal, SQLite/PostgreSQL/MySQL readiness, clean SIGTERM, and takeover-command presence.
• The two scan JSON files are semantically identical aside from subject/platform/time and both bind fingerprint d5e5d3910643983cb1a6e428105e77c97ee5b96249c2cfca66a5d3eae6e5e246: 1 critical, 34 high, 11 advisory identities, and 0 rows with a fixed version/actionable disposition. This is accepted only as the stated distribution-inventory result; it is not a vulnerability-free or SBOM claim.

This does not clear the still-running corpus or four-cell Compose qualification, approve the five-receipt selection manifest, move aliases, create/finalize the GitHub Release, or authorize any downstream/Waterline adoption. Those remain separate gates.

[rmcdaniel]

Supplementary published SQLite upgrade journey PASS, scoped to native Server and schedule authority. From 2026-11-13T18:24:28Z to 18:24:35Z, the real published 3.9.2 index 8ffcdb2a… / source 5614274d created two schedules through HTTP, including a real prior dispatch. On a stopped disposable copy, published 3.10.0 index ca92c866… / source b6e04ce7:

• Startup refused schema 13 with native_schema_upgrade_required, preserving the logical database.
• The actual source-free schema-upgrade CLI reported SQLite 13 → 14 and exited zero without OOM. A repeat reported current and made no logical changes.
• Every original business row and catalog object was preserved except the exact tagged nullable-column DDL and version/consolidated-journal metadata. Every journal field, source-derived SHA384 checksum/description and actual installed-time window were checked, including literal zero execution time.
• Both legacy never-fired and previously-fired schedules returned complete v1 unavailable authority in list and describe. Those reads made no logical writes or backfill.
• After explicitly resuming and triggering the former, list and describe recorded the same known Started dispatch with exactly the returned workflow/run identities and zero buffered count.

The 25 assertions use published linux/amd64 images, sequential 1 CPU/1 GiB/256-PID containers, read-only roots, synthetic paused schedules and numeric loopback. The API harness reused an exact frozen official-codec envelope; it did not run an SDK Worker. Snapshot helper bytes match accepted public Rust helper 6fc6054c. The stopped old seed stayed byte-identical during the check. All captured-ID containers/volumes and both disposable DB directories are independently absent. Private bounded metadata/logs remain seven days.

Two initial fixture NONPASS observations remain preserved: missing control-plane header before schedule admission, then attempting to trigger a paused schedule. The corrected fixture sends control-plane version 2 and performs the documented resume before trigger. Product images, schema CLI and assertions were not relaxed. These observations do not qualify Waterline/SDK consumers, other backend upgrades or the separate final alias/Release gates.

[rmcdaniel]

All exact-tag native 3.10.0 qualification runs are terminal SUCCESS at source b6e04ce7e679464e91f6ceae83310d3bb3204092: publication 43477098008/a1, corpus 43479707272/a1, and four-cell Compose 43479723896/a1.

The tagged selector produced the exact closed manifest below: 1488 bytes, including one trailing LF, SHA256 88bc899ac142b57db0cb268b51a09bbc23885ace2ec8f100d23fcfa2d405aa00. Tagged read-only plan and full provider-owned verify pass, including both registry platform/config/source identities, provenance, exact workflow blobs/run attempts/jobs, five current artifact ZIP/receipt hashes and observations, owned cleanup and actual GitHub Release absence. The initial local invocation incorrectly used isolated Python for a helper with sibling imports; it failed before verification and was corrected to the workflow's documented invocation, with no tooling edit.

{"compose":{"cells":[{"artifact_digest":"sha256:c64b92de61fc2e25dde50e5c390a52c83ef32530586518647fae9dc9b1a1eff1","artifact_id":14065530374,"job_id":132072769143,"platform":"linux/amd64","profile":"local"},{"artifact_digest":"sha256:f78b10deb9ed1de8d2b5b0f0fe776279657fd6c19f8122add11ac5b655b9e174","artifact_id":14063953162,"job_id":132072768898,"platform":"linux/amd64","profile":"production"},{"artifact_digest":"sha256:eaf8cf5aeabfe194f4a0b69126b71f32fd9cd5dd2cc067d9dc960b3a2807277e","artifact_id":14064900964,"job_id":132072769204,"platform":"linux/arm64","profile":"local"},{"artifact_digest":"sha256:3ac83fa8a85c52cacf8d644182abbd3f77966f23384d0aa1a8a9dc21dc00150c","artifact_id":14063723472,"job_id":132072769430,"platform":"linux/arm64","profile":"production"}],"run_attempt":1,"run_id":43479723896,"runner_commit":"b6e04ce7e679464e91f6ceae83310d3bb3204092","workflow_blob":"09082357d57e7c95746d2f815715bb91414cf112"},"corpus":{"artifact_digest":"sha256:437ddbd7f8b262d77610a20125e4b7c686fad5c0d02233da3aeaacc6e1e7121a","artifact_id":14065263200,"run_attempt":1,"run_id":43479707272,"runner_commit":"b6e04ce7e679464e91f6ceae83310d3bb3204092","workflow_blob":"5130b55602951940869d215bee8a08c2dc9722d3"},"release":{"index_digest":"sha256:ca92c866fc0f3819068c5088fbd0a79115bb5588c06a4f5324b9280356c08bad","run_attempt":1,"run_id":43477098008,"source_commit":"b6e04ce7e679464e91f6ceae83310d3bb3204092","tag":"3.10.0"},"schema":"durable-workflow.native-alias-promotion-evidence.v1"}

Independent review of these exact bytes/current provider evidence is required before the separate protected alias writer. That writer will repeat verification under its protected environment and rolling-alias lock; final anonymous alias readback and GitHub Release remain separate. Chart #1213 remains draft pending the native final release and its own exact source checks/review/OCI proof. No consumer or Cloud acceptance is inferred.

[rmcdaniel]

Security exact promotion-selection review: PASS for the closed 3.10.0 manifest and its current provider evidence.

I independently verified:

• the selected manifest bytes are exactly 1,488 bytes including one trailing LF, SHA-256 88bc899ac142b57db0cb268b51a09bbc23885ace2ec8f100d23fcfa2d405aa00, and have the closed durable-workflow.native-alias-promotion-evidence.v1 shape;
• source/tag b6e04ce7e679464e91f6ceae83310d3bb3204092, exact image index sha256:ca92c866fc0f3819068c5088fbd0a79115bb5588c06a4f5324b9280356c08bad, publication run 43477098008/a1, corpus run 43479707272/a1, and Compose run 43479723896/a1 are current terminal successes from the exact tag;
• corpus workflow blob 5130b55602951940869d215bee8a08c2dc9722d3 and Compose workflow blob 09082357d57e7c95746d2f815715bb91414cf112 are the exact committed workflow objects;
• GitHub currently reports the selected corpus artifact plus all four selected Compose artifacts under the exact runs/source with the exact five ZIP digests in the manifest; I downloaded and inspected every canonical receipt.json, confirming source/index/platform/config, current job/attempt, pinned dependency identities, required observations, and zero owned resources after cleanup;
• fresh anonymous raw reads of both registries still return ca92c866... for exact 3.10.0, 8ffcdb2a... for existing 3 and latest, and no existing 3.10 alias; GitHub Release 3.10.0 is absent;
• the exact tagged native_alias_promote.py verify path completed successfully against the same manifest/provider state without writes.

This clears dispatch of the separate protected alias writer with these exact bytes. It does not pre-approve the writer result: repeat verification under the protected environment/rolling-alias lock, terminal run success, fresh anonymous 3.10/3/latest equality in both registries, and final GitHub Release identity/readback remain required. Chart #1213 and every client/Waterline/Cloud acceptance remain independent.

[rmcdaniel]

Protected alias promotion 43483522459/a1 is terminal SUCCESS at tagged source b6e04ce7e679464e91f6ceae83310d3bb3204092. Dispatch validation, provider-owned read-only verification and repeated qualification under the protected environment/rolling-alias lock all passed using the exact reviewed 1488-byte+LF manifest, SHA256 88bc899ac142b57db0cb268b51a09bbc23885ace2ec8f100d23fcfa2d405aa00.

Fresh anonymous GHCR and Docker Hub reads agree:

Tags in each registry	Index
3.10.0, 3.10, 3, latest	sha256:ca92c866fc0f3819068c5088fbd0a79115bb5588c06a4f5324b9280356c08bad
3.9, 3.9.2	prior sha256:8ffcdb2a36af3129a1987849aafe8715fe0d3bf9a9648467f0b5cb8eeef43ba9

The immutable tag still names the accepted source. GitHub Release 3.10.0 is currently an actual JSON 404, verified through the tagged provider; final Release/metadata is a separate action. Independent alias readback remains the next gate. Chart #1213 and every consumer/Waterline/Cloud acceptance remain separate.

[rmcdaniel]

Security live alias/readback review: PASS for native 3.10.0.

I independently verified protected run 43483522459/a1 is terminal success from exact tag/source 3.10.0 / b6e04ce7e679464e91f6ceae83310d3bb3204092, with its dispatch, read-only qualification, and protected writer jobs all successful.

Fresh anonymous reads now show, in both GHCR and Docker Hub:

• 3.10.0, 3.10, 3, and latest -> sha256:ca92c866fc0f3819068c5088fbd0a79115bb5588c06a4f5324b9280356c08bad;
• the 3.10, 3, and latest images carry release label 3.10.0 and source label b6e04ce7e679464e91f6ceae83310d3bb3204092;
• 3.9 and 3.9.2 remain at sha256:8ffcdb2a36af3129a1987849aafe8715fe0d3bf9a9648467f0b5cb8eeef43ba9.

The GitHub Release API still returns 404 for 3.10.0, preserving the required publication order. This clears the separate final Release creation using the already-reviewed exact selection manifest. The resulting Release identity, title/body/assets, stable/Latest status, and anonymous readback remain the final gate. Chart #1213 and all client/Waterline/Cloud acceptance remain independent.

[rmcdaniel]

Native Server 3.10.0 final publication is live, scoped to this immutable artifact. Protected final Release run 43484884405 succeeded after independent protected alias readback.

Public Release 3.10.0 is stable and Latest, ID 444604000. The direct immutable tag names accepted source b6e04ce7e679464e91f6ceae83310d3bb3204092, tree 2c2ccd7f52d9a9430c4c0ad9bc5016fb9ff0b03a, with valid verified commit identity. Fresh GitHub API reads match the complete expected identity table and immutably rendered tagged release notes, body SHA256 98e41945e6e80717ed2443fc766e9a2b2a022e178b9ffd18fd5a74cea9a1b8e2. Assets are empty, matching the current workflow; no SBOM is claimed.

Registry identity	Digest
GHCR + Docker Hub index; 3.10.0, 3.10, 3, latest	sha256:ca92c866fc0f3819068c5088fbd0a79115bb5588c06a4f5324b9280356c08bad
linux/amd64	sha256:9d64e9aeee84b46d21715826a3e7e5a96eb8d4ce7fccb126b88b15596ab14973
linux/arm64	sha256:d94b610c4f248834c9b15f78b05ee2a1d438b42af69c7714e3221f7ffe1e67a5

Both prior 3.9/3.9.2 aliases remain index 8ffcdb2a…. All three exact qualification runs, five current receipts and manifest passed independently, followed by protected under-lock promotion. The additive SQLite 13→14, PostgreSQL/MariaDB 14→15 and MySQL 15→16 upgrade requires all replicas stopped and pre-upgrade backup; rollback restores that backup. The actual published SQLite schedule-upgrade journey passed, with legacy unavailable authority and no backfill.

Independent final publication/metadata Security PASS confirms these exact identities, stable/Latest metadata, tagged-note equality and empty assets. Chart #1213 remains a separate proposed 2.0.0 major with its exact CI/source review and concrete release disposition; no Chart OCI or public selected-pair change is claimed. Waterline owns actual #310/#222 summary/request-budget/visible-refresh acceptance on the qualified tuple handoff. No #1204 fix, new upload/Cloud authority or full shared #216/#228 acceptance is inferred.

[rmcdaniel]

Security final publication review: PASS for native Server 3.10.0.

Independent checks confirm:

• protected Release run 43484884405/a1 is terminal success on b6e04ce7e679464e91f6ceae83310d3bb3204092;
• tag 3.10.0 resolves directly to that verified commit, tree 2c2ccd7f52d9a9430c4c0ad9bc5016fb9ff0b03a;
• public Release 444604000 is published, immutable, non-draft, non-prerelease, stable/Latest, titled and tagged 3.10.0;
• the raw Release body is 5,893 bytes with SHA-256 98e41945e6e80717ed2443fc766e9a2b2a022e178b9ffd18fd5a74cea9a1b8e2;
• independently rendering the verified identity table plus docs/releases/3.10.0.md from the tag, with the workflow's relative-link resolution, equals the public body exactly;
• the identity table binds publication run 43477098008 and index sha256:ca92c866fc0f3819068c5088fbd0a79115bb5588c06a4f5324b9280356c08bad in both registries;
• assets is empty, matching the workflow's explicit no-asset/no-SBOM claim;
• the prior live alias verdict remains current: both registries' 3.10.0, 3.10, 3, and latest aliases name the reviewed index and source labels, while 3.9/3.9.2 remain on their prior index.

This completes the native Server 3.10.0 publication/metadata/alias gate. The exact image can now be recommended as the producer tuple for affected consumer qualification. Chart #1213, each SDK, Waterline, Cloud, and other downstream adoption remain independently owned and are not inferred from this PASS.