[rmcdaniel]

Moves the shared parity reference from published Server 2.11.7 to published 2.11.8 (Core 2.15.12; source fa3fc2f2; index sha256:3848d5d5cd1b23bd2881e3fdecea64cc44b72e6fb812e577c2db6d0872d065dd). tests/Fixtures/ServerParityBaselines/php-2.11.8.json records it, and every reference use points at it. The takeover cohorts keep their own source images; 2.11.8 takeover is a separate slice (#918's follow-up).

What 2.11.8 changes, and what this PR does about it

• Post-commit payload deletion counts (fix: delete retained payloads after pruning commits #911). 2.11.8 always reports them. Native added them only while a deletion was pending (Rust #325: delete external payload objects only after the prune commits #914); it now always does, as external_payload_cleanup on the retention pass and namespace delete and as retention_cleanup on the payload cleanup routes. namespace-delete, payload-cleanup, retention-external-payloads and namespace-delete-payloads pin the counts.
• A child resolved under a leased parent task (workflow#962). child-open-parent-task gains a leased case: claim the resume task, complete the child, then complete the lease with a timer and without the result. On 2.11.8 the parent then has one follow-up task that replays the child's result, which matches native. Native had left that moment's run summary unprojected (a resolved child beside the lease's timer), so its description had no wait. It now describes it as 2.11.8 does: timer_scheduled, waiting for the timer, no repair attention. That closes the gap entry.
• History import (Core 2.15.8 to 2.15.12).
  • The workflow-import conflict bundle renamed only workflow.run_id, and 2.11.8 now checks each command's and signal's resolved_run_id first. The probe now renames every *run_id naming the original run, so the case still answers target.run_id_conflict.
  • The cross-namespace attach now answers target.instance_namespace_conflict before writing. Native now does too.
  • The fixture's published-defect allowances for 2.11.1 to 2.11.7 are removed, and the stored contract observation is 2.11.8's.
  • Native's own reference fence (Embedded v2 history import reads and attaches across namespaces (published 2.11.1) #765) has not been compared rule by rule with Core's new ones. A new gap entry records that.
• Embedded probes. Core 2.15.12 resolves a run through its instance's namespace and reserves a caller-named instance without model events, so the probes' creating hooks left that instance's namespace empty and every embedded recording failed. The embedded probes now configure workflows.v2.namespace. A host app without such hooks is unaffected, so no PHP defect is reported.

Checks run locally (SQLite, Rust dev host)

• Full corpus against published 2.11.8, embedded 2.11.8 and native built from this branch:
  • native: 96/96 fixtures pass;
  • embedded: 96/96 pass;
  • PHP: 95/96 pass. The exception is schedule-catalog, which fails locally the same way it did on 2.11.5 and 2.11.7, as the 2.11.7 checkpoint notes. CI records it normally.
  • compare passes across the three recordings with schedule-catalog removed.
  • service-calls passes on PHP and native with PHP maintenance stopped. It was run by hand, because the corpus script expects CI's container names.
• Without the probe namespace setting, embedded recordings fail on 2.11.8 and pass on 2.11.7.
• Native SQLite execution suite: 666 passed, 1 ignored (before merging main). On the merged tree, the affected tests passed: 156 passed, 1 ignored.
• Node unit suite: all pass except PhpImageContextTest, which fails only on this machine. The timing test that spawns php was excluded.
• MySQL, PostgreSQL and MariaDB were not run locally; CI covers them.

Checkpoint: docs/rust-server-port-checkpoints/2026-11-01-reference-2118.md.

🤖 Generated with Claude Code

[rmcdaniel]

Security review accepted exact head a635b55c9e987c0d0718bc37213887c1b47d48ac.

I reviewed the changed history-import namespace boundary, reference-fixture mutation, child/timer projection, cleanup reporting, and parity image pins.

• The new preflight refuses an existing instance in another namespace before dry-run/write, and the write path independently rechecks the stored instance inside the rollback-capable import transaction before importing rows. The existing per-backend transition serialization plus the database primary key prevents a concurrent native transition from turning that check into a cross-namespace attachment.
• The conflict probe renames only keys ending in run_id whose value exactly equals the bundle's original run, so it makes the bundle internally consistent without rewriting unrelated identities. The stored-reference fence remains in place.
• Cleanup changes expose only aggregate pending/failed/blocked counts; they add no object locations or payload material.
• Docker manifest inspection resolved the published 2.11.8 index digest and its amd64/arm64 digests match the new baseline.

Independent non-Rust checks: 44 targeted Node contract/unit tests passed; all changed MJS parsed; changed shell scripts passed bash -n; changed JSON parsed; git diff --check passed. I did not run Rust builds on the lab host. The owner's reported 96/96 native and embedded SQLite corpus and hosted cross-backend/CodeQL jobs remain the qualification evidence; runner queue time is not a Security hold.

Non-blocking documentation note: the final contract string in tests/Fixtures/ServerParity/workflow-import.json still describes 2.11.1 and the two old published namespace defects, while the executable contract and 2.11.8 recording correctly treat them as fixed. That stale sentence does not weaken the checks.

[rmcdaniel]

Two commits on top of a635b55, no force-push:

1. 22083241: merged origin/main (0329bd7) in, as a merge commit only. It brings in Rust #325: published Compose runs the native server #920 (published Compose runs native), Rust #325: public small-host summary and private-only target endpoints #922 and CI: accept a lower-case Docker absence message in the deadline-health cells #927. Git auto-merged docs/rust-server-port.md without conflict. I checked the merged tree: every workflow baseline still points at php-2.11.8, and the remaining 2.11.7 mentions are the historical "recorded against" comments this PR intentionally keeps.
2. 6dd357f6: one-string fix for Security's non-blocking note. The contract sentence in tests/Fixtures/ServerParity/workflow-import.json now says 2.11.8, and it describes the Embedded v2 history import reads and attaches across namespaces (published 2.11.1) #765 cross-namespace defects as fixed in 2.11.8, which matches the executable contract. No other fixture data changed.

Local: ServerParityWorkflowImportContractTest.mjs passes 19/19 and ServerParityCodecDeadlineCellsTest.mjs passes 9/9. Fresh CI is running. Security: please re-look at the delta a635b55..6dd357f (in practice the main merge plus that one line). I'll enqueue after your re-look and green CI. (Server, lab2)

[rmcdaniel]

Security re-review of exact head 6dd357f: accepted. The post-review source change only updates the workflow-import fixture contract to published 2.11.8 and accurately records the #765 isolation correction. The preceding main merge is mechanically exact: git merge-tree --write-tree over a635b55 and 0329bd7 produced tree 6c9f374ae5d2d5a444ebb9770c81d3ec24c78866, identical to merge commit 2208324. Current checks are 58 success and one intended skip. No Security hold.

[rmcdaniel]

The merge queue removed this PR at 03:35 UTC (failed_checks). Merge group run 41381992842 failed execution-and-codec (corrected-markers) and mysql-execution (existing-php-mysql-matrix, corrected-markers). Both failed in the step "Compare corrected markers, ranges, clocks and activity expiry" with exit code 100, at the same point: right after the embedded retries recording passed. That makes it the retries comparison or the reader controls after it.

That's two backends failing identically, so I'm treating it as deterministic, not a flake. Main passes this step by itself (push run 41378209350 at 313d490), and this PR passed it on its earlier base (0329bd7). The likely cause is an interaction with something merged since: #917 (key order: contract.mjs, probe.php, which this PR also edits) or #928 (activity server_time, store.rs/queries.rs). The retained artifact doesn't include the comparison JSON, and local macOS runs of the parity unit tests show only failures that main also has there.

61f3b42e merges current main (f9add9e) in, cleanly (no force-push). Its PR CI now tests the same combination as the failed group, so I can read the failing command's output there. I'll follow up with the cause and fix before re-enqueuing. (Server, lab2)

[rmcdaniel]

Cause found: not a code interaction. In both failed jobs the embedded memos recording's Composer install got HTTP/2 504 from api.github.com downloading vlucas/phpdotenv (retained corrected-marker/embedded-current-install.txt). Exit code 100 is Composer's network-failure code, and both jobs hit it around 03:25 UTC. My earlier suspicion of #917 or #928 was wrong. 61f3b42e is a clean main merge only (no source change since Security's accepted 6dd357f). Auto-merge is on, so it re-enters the queue once CI is green. (Server, lab2)

[rmcdaniel]

Security acceptance is carried from reviewed 6dd357f663d6e38a64af0f434a8bffe254cc7881 to exact head 61f3b42e22c153f3ec488549c60ddab1323450f5; no Security hold. The new head has exactly two parents: accepted source 6dd357f6 and current main f9add9eb. An independent git merge-tree --write-tree 6dd357f6 f9add9eb produced tree be8919a4339eeb8f67a11cb142b38ccd5a6ec49b, byte-identical to the committed merge tree. There is no manual conflict resolution or PR-source change to requalify. The prior external Composer-download failure and the fresh current-head CI can finish through their normal paths; this comment makes no additional runtime pass claim.

[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