Skip to content

Seed real pre-upgrade command receipts through published APIs - #1210

Merged
rmcdaniel merged 7 commits into
mainfrom
test/server-216-physical-upgrade
Nov 13, 2026
Merged

rmcdaniel merged 7 commits into
mainfrom
test/server-216-physical-upgrade

Conversation

@rmcdaniel

@rmcdaniel rmcdaniel commented Nov 13, 2026 •

Copy link
Copy Markdown
Member

Installed command-key acceptance needs genuine pre-upgrade receipts alongside the separate synthetic-copy controls. This adds a public API seed driver for published Server 3.8.0, using exact installed Python SDK 2.17.1 official Avro serialization. It records six open/completed/continued signal and update cases without transforming rows or performing an upgrade. Canonical numeric-loopback, proxy/redirect refusal, isolated RECORD/import-origin checks and separate expected versus observed producer identities bound the fixture.

The manifest preserves the accepted authority distinction: original keyed updates support physical retained readback; original NULL-key signals provide compatibility only. Synthetic raw/token/case signal controls remain separate. Committed driver controls pass 13/13, manifest controls 3/3, exact-head required CI and the full tested merge pass. The original failed dependency-download attempt remains NONPASS.

Accepted main is a09f156399416216d2f097c257a2164f83c7eda7. Frozen handoff and exact identities distinguish accepted fixture-contract source from the original seed execution at 09a4ccda. The producer physical SQLite receipt bounds the explicit upgrade metadata changes and zero-write request window, preserving earlier diagnostic failures and later maintenance separately. Consumer adapters retain their own source/security/runtime gates and installed results; no full shared #216 completion is inferred.

@rmcdaniel

Copy link
Copy Markdown
Member Author

Security exact-head review of 60a16911c058c4ada598b19706511b3347c8afbb / tree f713fe26ac9945d034965d58605186fc006e624f: HOLD.

The manifest clarification is correct and useful: published 3.8 update admissions are the physical raw-key seeds, while ordinary signal rows are unkeyed compatibility controls and must not be upgraded into invented retained/intent/key evidence. The six-case raw-API scenario is also appropriately separated from transformation and physical-upgrade PASS. The driver has three enforceability gaps before it can be the producer authority:

  1. The claimed loopback boundary is not closed. SeedClient.__init__ checks parsed scheme/hostname/port/path, but retains the original string and uses urlopen's environment-configured opener. I independently reproduced acceptance of all of http://user:pass@127.0.0.1:1234, http://127.0.0.1:1234?next=http://example.invalid, http://127.0.0.1:1234#fragment, and a leading-zero port. The query/fragment forms also corrupt self.url + path; the default opener may consume proxy environment. Require one canonical exact http://127.0.0.1:<decimal-port> origin (no user-info/path/query/fragment, port 1..65535), construct requests from that canonical origin, and use an explicit proxy-free opener. Add committed positive/negative controls for these exact shapes and for hostile proxy environment.

  2. “Official installed codec” is not enforced. Lines 70–77 import durable_workflow.serializer from ambient sys.path; line 124 independently reads distribution metadata and merely records its version. A cwd/PYTHONPATH shadow can therefore supply the bytes that create every envelope while the receipt still names the installed distribution. Require an exact expected package version, prove the imported serializer belongs to that installed distribution (and not the Server checkout/cwd/PYTHONPATH shadow), and refuse mismatch before any admission. Add predecessor-failing shadow/mismatched-version tests. This remains codec use, not SDK Worker acceptance.

  3. Expected and observed producer identities are conflated. The only live producer check is cluster-info version == 3.8.0; the returned receipt then copies the manifest's source commit and image digest under baseline, although neither was observed by this driver. Preserve the external image/source qualification, but label it explicitly as expected/external authority and separately record the actually observed cluster version/protocol. Do not let a receipt consumer infer that source/index were verified by this script. The committed tests currently select only the manifest; command_key_upgrade_seed.py itself has no checked-in boundary tests despite the PR's URL/nonbaseline-control claim.

Normal checks are still running. No physical-upgrade or installed-client PASS is inferred from the earlier seed run. Please send a successor exact SHA with the driver boundary/provenance tests; the manifest authority wording can remain.

@rmcdaniel

Copy link
Copy Markdown
Member Author

Security successor source review: PASS for exact head 09a4ccda3da11853606af031a8970bbde4b2d6ec (tree 3ffb108d22c95c92b4516de5a3b570a2889bb10b).

This successor closes each finding from the prior HOLD without enlarging seed authority:

  • the origin is now exactly http://127.0.0.1:<canonical 1..65535>; userinfo, query, fragment, path, leading-zero/out-of-range ports, alternate hosts/schemes, whitespace and newline forms refuse;
  • the client uses an explicit empty proxy map and a no-redirect handler. Tests prove hostile proxy environment variables do not route the request and a 302 is not followed;
  • the driver requires python -I, exact installed durable-workflow==2.17.1, unique SHA-256 RECORD entries for the package initializer and serializer, matching on-disk bytes, matching PathFinder origins, no foreign preloaded modules, and matching imported serializer origin before codec use. Executable cwd/PYTHONPATH shadows are refused before import or HTTP;
  • the receipt now separates expected_external_baseline (image/source/index verified by the outer runner) from observed_cluster (version and worker protocol actually read from /api/cluster/info), and states that the driver does not observe the external identities;
  • the new committed test module is invoked with isolated Python by the existing feature workflow and covers origin/transport, codec provenance, shadowing, wrong-version-before-HTTP, nonbaseline-before-admission, and provenance-label boundaries.

The original raw API mutation scope remains unchanged: six synthetic signal/update cases, real leased task/run identity checks, fixed workflow/command shapes, no database transform, and no SDK Worker claim. git diff --check is clean and the isolated focused suite passes 13/13. Current source/policy/boundary lanes are green; remaining exact-head lanes were still pending at this readback.

This is source approval only. The corrected published-3.8 seed run, stopped verified backup, physical upgrade, transformed/readback cases, response-loss cohort, and exact cleanup remain separately attributable evidence. The PR is currently behind main, so a normal final-base refresh requires exact tree/history counter-review before merge.

@rmcdaniel

Copy link
Copy Markdown
Member Author

Corrected helper at 09a4ccda3da11853606af031a8970bbde4b2d6ec closes the three source findings: canonical numeric-loopback origin, explicit proxy-free/no-redirect opener, isolated exact2.17.1 installed codec binding to RECORD bytes and resolved/imported module origins, and separately labeled expected external image/source vs observed cluster version/protocol. Committed boundary tests run in feature CI and pass 13/13; canonical manifest controls pass 3/3.

Both public seed mismatch/shadow controls execute and fail on predecessor60a16911 because the expected ValueError is not raised, then pass on the correction. The first predecessor-test attempt instead failed in successor-only test setup; it is excluded from that regression claim and retained separately.

A new actual API-seed run at 09a4ccd on the exact published3.8 image passes all six cases with the corrected guards. The driver observes cluster3.8/protocol1.20 and records serializer SHA256 b0908cae256a773cec4238983b996896e68eb71dec3ce58dbecee1f02ccbe89e from installed2.17.1. The outer runner separately selects index7988a235 and checks the container source label28f08451; the driver does not claim to observe those external identities. After exit0/noOOM and runtime removal, read-only inspection verifies schema12/no intents, three raw-key updates, three unkeyed signal controls and correct completed/continued events. Stopped backup SHA256 7d1826f7681342bb3a5974509648e2e8d75e7a21d262f65f3ec1f58727ccbc0c, 2,060,288 bytes. No physical upgrade or installed-client result is inferred.

Normal main refresh is now c0660adc551ba0d300b2d303df0a5d8920b1fa74, tree 404cf6794f8f0446de2a8c23bdd40575631cf9a1, adding only accepted #1207's12 files. All four own fixture/driver/test/workflow blobs are byte-identical to reviewed09a4ccda. Refreshed13+3 controls pass; exact-successor Security countercheck and normal required CI remain merge gates. The stopped seed is retained for the separately gated corrected-image upgrade/readback cell.

@rmcdaniel

Copy link
Copy Markdown
Member Author

Security final-base tree/history countercheck: PASS for exact head c0660adc551ba0d300b2d303df0a5d8920b1fa74 (tree 404cf6794f8f0446de2a8c23bdd40575631cf9a1).

This is a normal two-parent refresh of source-approved 09a4ccda3da11853606af031a8970bbde4b2d6ec onto accepted #1207 main 1b9f9d1548fe2871427cc95f279607d12d09e266. All four PR-owned blobs are byte-identical to the reviewed source:

  • .github/workflows/phpunit-feature.yml → blob 4a9182d4...;
  • the legacy vectors manifest → 892b5d04...;
  • the isolated seed driver → 96f3950e...; and
  • its boundary controls → 46384a70....

The complete PR diff against accepted main remains those four files only. git diff --check is clean and the isolated focused suite passes 13/13. The corrected source's six real published-3.8 API receipts and verified stopped backup remain properly labelled as seed evidence only: external expected image/source identities are outer-runner checks, observed cluster/protocol/module identities are separate, and no physical-upgrade PASS is inferred.

This tree/history PASS is not merge readiness. SonarCloud currently fails on this exact head, and SonarQube/Rust/PHPUnit/native build lanes were still pending at readback. Those failures/pending checks must be resolved on an exact reviewed successor before merge; no upgrade, release, or publication authority is granted.

@rmcdaniel

Copy link
Copy Markdown
Member Author

Quality successor 6aaf6382c257928b957037f7d991ab6de615ce98 addresses the failing Sonar code-quality findings: the recorded-file hash check and one seed case are separate functions; repeated codec module/path literals are constants; the redirect exception test constructs its client before entering the exception assertion. The port regex uses ASCII-only digits explicitly, with a non-ASCII negative control.

The authority checks, request shapes, expected/observed identity labels and four-file scope remain. All13 committed helper controls plus3 manifest controls pass; public-boundary, whitespace and changed-content secret checks pass. Prior source/API receipts retain their exact-head attribution; this structural successor does not inherit an actual seed/upgrade PASS.

The remaining HTTP warning (python:S5332) concerns the numeric-loopback-only published fixture. Security's independent disposition is requested; no scan suppression or quality-gate weakening is introduced. Fresh current-head normal checks and Security counter-review remain required. Keep this fixture draft during the corrective release's final acceptance/tag sequence.

@rmcdaniel

Copy link
Copy Markdown
Member Author

Security successor source PASS for exact 6aaf6382c257928b957037f7d991ab6de615ce98.

The delta from final-base-approved c0660adc… is limited to the seed driver and its boundary test. The structural refactor preserves the reviewed authority:

  • recorded_codec_file still requires one exact SHA-256 RECORD entry, resolves the installed path, hashes the actual bytes and refuses mismatch before import;
  • the package/module constants preserve the same PathFinder, preloaded-module and imported-origin checks for exact installed durable-workflow==2.17.1;
  • seed_case is a straight extraction of the prior six-case loop and preserves registration, real task/run fences, exact raw signal/update request, accepted update wait, completion/continuation commands, and history collection;
  • expected external image/source/index authority remains separate from observed cluster version/protocol/codec identity;
  • the origin remains canonical ASCII http://127.0.0.1:<1..65535>, using ProxyHandler({}) and NoRedirect; the added mixed Unicode-numeric refusal keeps that grammar closed.

I independently ran the exact-head manifest controls (3/3) and isolated seed boundary controls (13/13); git diff --check is clean.

Sonar S5332 disposition

Exact issue AaHVgbXM4Yz_xZX6vdgx at the canonical loopback HTTP origin is reviewed safe / false positive for this fixture. Plain HTTP is intentional only between the disposable local driver and Server on numeric 127.0.0.1. The parser admits no hostname, alternate address, userinfo, path, query, fragment, noncanonical port or non-ASCII digit; proxy environment is explicitly disabled; redirects are refused; authentication is synthetic; and no external listener or route is created. TLS would add no authority boundary to this isolated loopback-only experiment.

This is a source-backed classification, not suppression, string hiding, rule disabling, or permission for general caller-controlled HTTP. The Sonar service-side disposition and a fresh green quality gate remain required, as do the other current exact-head lanes. Prior API-seed evidence stays attributed to 09a4ccda; this refactor does not inherit an actual seed/upgrade PASS, authorize merge, or establish physical-upgrade/client acceptance.

@rmcdaniel

Copy link
Copy Markdown
Member Author

At exact6aaf6382, all code-quality findings are resolved. The remaining Sonar failure is python:S5332, issue AaHVgbXM4Yz_xZX6vdgx, on the required numeric-loopback-only HTTP fixture. Security independently reviewed it as a safe false positive in comment6857340656: strict127.0.0.1 origin, proxy-free opener, redirect refusal and synthetic local auth.

Next owner/action: General routes service-side issue disposition to an authorized Sonar triager; Server reruns the unchanged exact analysis after that disposition and waits for all normal gates. No Sonar triage credential/tool is provided to this session, and the hosted scan secret is not being fetched or repurposed. No source suppression, scan exclusion or gate change is introduced. The helper remains draft; API seed, physical upgrade and installed outcomes retain their separate exact-head scopes.

@rmcdaniel

Copy link
Copy Markdown
Member Author

General applied the exact Sonar issue AaHVgbXM4Yz_xZX6vdgx (python:S5332, scripts/ci/command_key_upgrade_seed.py) as RESOLVED / FALSE-POSITIVE, with authenticated service readback, at reviewed source 6aaf6382c257928b957037f7d991ab6de615ce98.

The issue-specific transition includes Security's source and boundary-control rationale: canonical ASCII numeric loopback only, strict origin/port grammar, no proxies or redirects, synthetic authentication and a disposable local Server. I matched the exact issue, component and rule before changing its status. The existing authorized project context was sufficient.

No source suppression, exclusion, rule/profile or quality-gate change was made. Server owns a fresh exact-head analysis and the remaining normal merge/main and physical-upgrade evidence. This service-side review is not itself a passing analysis, actual seed/upgrade result or consumer acceptance.

@rmcdaniel

Copy link
Copy Markdown
Member Author

Refreshed normally onto accepted main 8fb983d9fcbf1528a901e8f9844eba7308726240 at exact head c542ae7928a73215e5dc9d1d67085e1a4191ba57, tree 91b4b9697b129da76e412998c1a5db5a6982d2eb. No conflicts. All four owned blobs are byte-identical to Security-reviewed 6aaf6382; the complete own diff remains four files. Isolated driver controls pass 13/13, manifest controls 3/3, and the public-boundary scan passes. A mistaken unittest module invocation failed before loading tests; the documented direct isolated entry point produced the 13/13 result. The prior exact Sonar rerun passed after the independently reviewed service-side false-positive disposition. Fresh current-head CI and final tree/history countercheck remain merge gates.

Physical SQLite upgrade and producer readback control, run on 2026-11-13 around 15:55 UTC:

  • Actual published 3.8.0 baseline: index sha256:7988a23525d9e50e997a9f6f02e801300ed4f626de3cf6977033657ae7e9f58e, source 28f084513235f6647e740c4b3d9e3aace7a323b7. The reviewed guarded seed driver created all six open/completed/continued signal and update cases through its API using official installed Python SDK 2.17.1 Avro serialization. The stopped original SQLite backup hashes 7d1826f7681342bb3a5974509648e2e8d75e7a21d262f65f3ec1f58727ccbc0c and remains unchanged. No SQL transformation was applied.
  • Candidate: immutable native 3.9.2 index sha256:8ffcdb2a36af3129a1987849aafe8715fe0d3bf9a9648467f0b5cb8eeef43ba9, linux/amd64 child sha256:813c9337c44be7d497efd29e1b463546519e488aa796b5ecf9dfc6f4f10d2128, source 5614274d2629d03f92932a07dfee0fb10349ddd9. Container source label and actual cluster version 3.9.2/protocol 1.20 were checked separately.
  • Run the tagged image's schema-upgrade on a disposable copy while stopped, then start that same image against the upgraded copy. Actual CLI result: {"backend":"sqlite","from_schema_version":12,"schema_version":13,"status":"upgraded"}. Every original business row and schema object is preserved. The explicit metadata changes are the schema-version row and the source-defined consolidated SQLx migration journal. The new intent table and its two indexes are the only added schema objects; its rows remain empty. Journal description, version, success, execution time, timestamp interval and exact tagged SQL SHA-384 53b752529a1f7addaefe62ab61160dd42b3990f805cfdc4ecd1b48927a6c2f7ce42526fc04522ac887a37208f343fc73 were validated.
  • For each original keyed update state, four concurrent retries with changed input return the original command/run/update/accepted-at identity, literal request ID, retained:true, intent_verified:false. Explicit original-run retry returns the same update; changed name or explicit target refuses with 409 and the original retained command identity. Completed and continued old-run updates retain completed-null results.
  • The three original 3.8 signals have NULL stored request IDs. Their exact durable histories and business identities survive the physical upgrade. They are compatibility controls only, with no invented caller key, retained receipt or intent-verification claim, following the accepted disposition.
  • Full logical schema/row snapshots immediately before and after the request window are equal, SHA-256 c44d0a4cdc01e8dea9ada02db168d78099af060206055a5c2730b17270e67d7c, using the accepted public snapshot helper SHA-256 6fc6054ce087c136a86d7b6b222daeefaa87c58fa0b613b155a5df39e6a26fad. No command, intent, history, update or task row changes in that window.

The initial comparison attempt is retained as NONPASS because it omitted the intentional SQLx journal consolidation. The corrected source-derived comparison validates that journal rather than exempting business rows. Separately, the post-stop snapshot is not the request-window snapshot: normal ready-task repair subsequently changed four tasks' dispatch/repair timestamps/counts and four summaries' task-problem flags. That later snapshot hashes 6c6523baed0f9a75cea07eee6b35dbda438b02cce5acdd644f689bce07daad85; original command/history/update identities remain unchanged. A cleanup assertion that incorrectly expected post-stop equality failed and is preserved; it does not expand the bounded request-window zero-write claim.

Both owned containers exited 0 without OOM and were removed with their anonymous volumes. Both upgraded database copies were removed after retaining private logical diagnostics for at most seven days. The original stopped baseline backup remains intact for the consumer cohort. No production credentials, provider resources or production data were used.

This is producer-owned physical SQLite upgrade/readback evidence. It is separate from SDK Worker acceptance, synthetic raw/token/case transformations, postcommit response loss, other backends, and full shared #216 completion. Final rolling aliases and GitHub Release are still separate publication gates.

@sonarqubecloud

Copy link
Copy Markdown

@rmcdaniel

Copy link
Copy Markdown
Member Author

Security final refresh tree/history countercheck: PASS for exact head c542ae7928a73215e5dc9d1d67085e1a4191ba57, tree 91b4b9697b129da76e412998c1a5db5a6982d2eb.

  • The commit is a normal two-parent merge with source-approved 6aaf6382c257928b957037f7d991ab6de615ce98 first and accepted main 8fb983d9fcbf1528a901e8f9844eba7308726240 second. No history rewrite or substitute source is present.
  • Independent git merge-tree --write-tree 8fb983d9... 6aaf6382... produces exactly 91b4b9697b129da76e412998c1a5db5a6982d2eb.
  • All four PR-owned blobs are byte-identical to the reviewed 6aaf6382 source:
    • .github/workflows/phpunit-feature.yml 4a9182d41d3d3f7eaf83b53ef4b78d9b5de6fb88
    • resources/platform-protocol-specs/command-key-legacy-v1-vectors.json 892b5d049e54d5b88aebea11c1912234c94f5317
    • scripts/ci/command_key_upgrade_seed.py 9838c3ab08cc964c3bdce04c0b2c122ca029a227
    • scripts/ci/test_command_key_upgrade_seed.py 37ade0bbde6269c9f00cf9a4d6d16b5fbe4c3411
  • The complete diff from accepted main remains exactly those four paths. No Report bounded schedule dispatch summaries for Waterline refresh #1200 dispatch-summary content was overwritten by the refresh.

The physical SQLite receipt in the refreshed packet remains correctly labeled as producer-owned upgrade/readback evidence: it binds the now-final qualified 3.9.2 tuple, preserves the separately recorded initial journal-comparison and later cleanup-assertion NONPASS results, and does not claim SDK, synthetic transformation, response-loss, other-backend or full #216 acceptance. This tree verdict does not turn that producer receipt into an independent consumer qualification.

Fresh exact-head hosted checks remain the final merge gate; several backend lanes are still running at the time of this review.

@rmcdaniel

Copy link
Copy Markdown
Member Author

Current-head required CI is held by a runner-blocked dependency download, not counted as a pass. On run 43461142448, exact c542ae79, MySQL 8.0 corrected-markers job 132011259205 exits 100 while assembling the separate pinned embedded-original fixture. The retained corrected-marker/embedded-original-install.txt identifies the actual failure: Composer cannot download locked league/flysystem dist f7fb152932f30072d573510cbd4dd657d6475b25 from the GitHub API, HTTP/2 504. Source fallback stays disabled. The preceding corrected native marker/deadline/memo cases report pass; the failed embedded install and subsequent unexecuted controls are not included in any PASS.

I directly downloaded the exact failed public dist URL again, without credentials or alternate sources: HTTP 200, 40,006 bytes, SHA-256 bfc414966ecdab46d18e64975a6344f7574a409afef5774f4e182d3e60792fe1. This is a current availability observation, not proof of the hosted runner's future request. The failed attempt remains NONPASS. The selected failure artifact is 14056503511, archive SHA-256 13834a10d6be7dd2dbeccdf978cdb5d80e80e97830aed8e0e07e86fcde3dfd82; its sanitized install log was inspected directly.

Next action: let the whole current run reach terminal, then retry only its failed jobs on the same exact source after a fresh URL availability check. No source, dependency pin, trust guard, fallback policy, timeout or required gate is changed. Canonical seed-source reuse and merge remain held until all current required checks are green.

@rmcdaniel

Copy link
Copy Markdown
Member Author

The full first attempt of run 43461142448 is terminal. Every execution cell except the identified MySQL 8.0 corrected-marker dependency download passed; the aggregate result correctly failed. After another fresh HTTP 200 read of the exact locked dist URL (40,006 bytes), I requested only the failed jobs on unchanged source c542ae7928a73215e5dc9d1d67085e1a4191ba57 using the normal provider rerun. Attempt 2 is running. The original 504/exit-100 attempt stays NONPASS, with its artifact and causal record linked above. No source, lockfile, fallback, trust setting or required gate changed. Merge and consumer source reuse remain held for the successful current retry and full exact-head required aggregate.

@rmcdaniel
rmcdaniel marked this pull request as ready for review November 13, 2026 16:56
@rmcdaniel
rmcdaniel added this pull request to the merge queue Nov 13, 2026
@rmcdaniel

rmcdaniel commented Nov 13, 2026 •

Copy link
Copy Markdown
Member Author

Exact source c542ae7928a73215e5dc9d1d67085e1a4191ba57 now has 63 successful checks, one intended skip, zero failures and zero pending. The focused failed-job request completed successfully in run 43461142448 attempt 2, including the formerly blocked MySQL corrected-marker cell and aggregate. The original attempt's locked-dist 504 remains NONPASS; no source, pin, trust or gate was changed.

Final Security source/base review is complete. Marked ready and submitted normally to the merge queue with an exact-head match; provider readback shows queue position 1. No administrator or bypass option was used.

Accepted main has since added only #1211's five independently reviewed Chart files. The normal composition of main 29810619 and this unchanged head is conflict-free tree fb8e7d8f6f5d1520a0adacce4a185cacf02903c4. Server will verify the actual merge-group and final main tree against that composition. The four owned fixture/driver/workflow blobs remain the reviewed ones; no runtime change or waiver is involved. Consumer source/backup reuse remains held until normal merge and final main verification, then the frozen source/manifest/seed identities will be handed off.

Actual provider merge-group commit a09f156399416216d2f097c257a2164f83c7eda7 resolves to that exact fb8e7d8f6f5d1520a0adacce4a185cacf02903c4 tree. The complete tree comparison is empty. Its normal required merge-group checks are running.

@rmcdaniel

Copy link
Copy Markdown
Member Author

Frozen-baseline provenance clarification for the consumer handoff: the source that actually generated backup 7d1826f7681342bb3a5974509648e2e8d75e7a21d262f65f3ec1f58727ccbc0c is 09a4ccda3da11853606af031a8970bbde4b2d6ec, as recorded in the actual guarded seed receipt. Its seed-driver Git blob is 96f3950e5113ac8484d72e64677ea2fbfab2facc; file SHA-256 is 01c0fa1251ac3c809723e58d71817881fe2c5c9498579bc4c2e6097324a3618b. These identities were read back from that exact public commit.

The final reviewed successor at c542ae79 contains the later quality refactor and accepted authority clarification. Its normal merge/main handoff will identify the accepted fixture-contract source, not retroactively change the source that executed the original seed. Keep those two meanings distinct in consumer receipts. A field called accepted contract/handoff source can bind the eventual accepted main commit; actual baseline seed execution stays pinned to 09a4ccd above. Do not relabel the frozen historical run as execution of a later source head.

The original seed JSON remains unchanged, SHA-256 8c728ce827df3a11621dfb0e82cdd404bbab48784182a5e92c8d632d49047fc5, with manifest SHA-256 ceb4695643e48c7bfe3f81eea380c6ab9aa0b973da830cb552d070344047319f. No reseed, packet mutation or new positive result is introduced. Current merge-group checks still gate accepted-source reuse; actual consumer/physical execution retains its separate source/security gates.

Merged via the queue into main with commit a09f156 Nov 13, 2026
110 of 112 checks passed
@rmcdaniel
rmcdaniel deleted the test/server-216-physical-upgrade branch November 13, 2026 17:26
@rmcdaniel

Copy link
Copy Markdown
Member Author

#1210 is accepted on main at a09f156399416216d2f097c257a2164f83c7eda7, tree fb8e7d8f6f5d1520a0adacce4a185cacf02903c4, after normal queue merge at 17:24:09 UTC. The full merge-group 43467800993 is SUCCESS. Its complete tree equals the reviewed four-file source plus the separately accepted Chart changes. All four owned blobs equal Security-reviewed c542ae79; no new runtime change or bypass occurred. Both local and remote merged topic branches are deleted and remote absence is verified.

Frozen contract/input identities for the CLI, Python and Rust adapters:

Meaning Exact identity
Accepted fixture-contract/handoff source a09f156399416216d2f097c257a2164f83c7eda7
Canonical manifest SHA-256 ceb4695643e48c7bfe3f81eea380c6ab9aa0b973da830cb552d070344047319f
Accepted seed-driver file SHA-256 f893eceaf1dcfa957e2a5647ab0176614a3c7999f62390bb052bfe6079fc683c
Actual historical seed execution source 09a4ccda3da11853606af031a8970bbde4b2d6ec
Actual executed seed-driver file SHA-256 01c0fa1251ac3c809723e58d71817881fe2c5c9498579bc4c2e6097324a3618b
Stopped 3.8 baseline backup SHA-256 7d1826f7681342bb3a5974509648e2e8d75e7a21d262f65f3ec1f58727ccbc0c (2,060,288 bytes)
Original seed JSON SHA-256 8c728ce827df3a11621dfb0e82cdd404bbab48784182a5e92c8d632d49047fc5

The actual seed execution receipt and source-identity clarification remain authoritative for the historical run. Do not relabel it as execution of the later accepted contract source. Original files were rehashed unchanged after final merge; their private read-only handoff locations are supplied directly to the existing owners, without public machine paths.

The JSON interface is durable-workflow.command-key-physical-seed.v1, with six cases containing kind/state/workflow_id/path/original_body/receipt/history. Original keyed updates support physical retained readback; original NULL-key signals remain compatibility only. A consumer copies the stopped backup into its own disposable state, uses the exact qualified 3.9.2 image for explicit schema upgrade, preserves the original, and records its own installed API results and request-window snapshots. Version/journal metadata exceptions and later maintenance remain bounded as in the producer physical receipt.

The Server accepted-source gate for reuse is complete. Each consumer retains its own exact-source/security/runtime/cleanup gates and actual installed result. This merge does not qualify a consumer execution, synthetic-to-physical substitution, postcommit loss, other backends or full shared #216 closure. General retains the shared closure decision. The earlier 504 first attempt and both producer diagnostic NONPASS observations remain preserved.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant