Run the complete suite and finish review of the Round 6 clock update

Written 2026-10-21T05:38:20.136982+00:00. RE-VERIFY: this is a write-time snapshot. Check https://github.com/CodexCoder21Organization/UrlProtocol/pull/740 and the branch heads before continuing.

Design decisions in effect

2026-10-21 owner ruling: “a contact or duration recorded after a wait must never use time from before the wait.” K1 remains “never read the caller's Clock while any registry guard is held”. Clock callbacks outside guards resample after waiting. Storage callbacks inside persistence ownership report a descriptive immediate error when lifetime or persistence admission is busy. No merge, queue entry, check request, publication or deployment was authorized in C21. Only a direct user deployment request authorizes production changes.

Remaining mission

Run one complete local suite from the pushed PR head, classify every history, then finish independent review. C21 completed the source correction, permanent scenarios, ten callback runs, five final targeted gates, cache coverage, PR source push and body update. The complete-suite requirement remains unmet. C21 did not start a complete suite and has no complete-suite XML counts to classify.

What was found and done

The mechanism was time prepared before a lifetime monitor wait surviving that wait. C20 corrected ordinary action entry using monitor completion counts. Clock callbacks still selected the last completed scalar during an in-progress source read, and storage callbacks inherited the persistence scalar. Both original callback cases produced contact 1000 instead of 301001 on all three C21 baseline attempts, matching C20's six negative attempts per case.

Clock callbacks now read their source again after the wait, outside registry guards. All five lifetime-monitor entry sites share a non-waiting admission lock while ordinary callers keep intrinsic-monitor coordination. Actions and removal record every busy admission before joining it, independently of completion-counter publication timing; any joined admission causes preparation again after guards are released. The action source is always prepared before admission.

General filesystem callbacks cannot be pulled out of synchronous atomic filesystem operations without changing write ordering. Persistence ownership therefore remains held until the filesystem call returns. A storage callback encountering a busy lifetime monitor or persistence owner reports its complete guard error before waiting. Its persistence scope is tracked independently of inherited action time and removed in finally. Both public storage scenarios assert error completion before the owner is released, zero caller Clock reads under ownership, and no contended contact action.

Exact messages:

• A storage callback cannot wait for PeerLifetime.lifecycleLock while peer persistence ownership is held; run this operation after the persistence operation returns
• A storage callback cannot wait for peer persistence owner while peer persistence ownership is held; run this operation after the persistence operation returns

The separate same-peer storage callback removal/restart behavior remains unchanged and pre-existing; callbacks were not moved outside ownership. C20 and RTC6 record its negative comparison on prerequisite and candidate. Do not claim it was fixed by C21.

Validation

Final source/test head: 437fd2ef55726e7ccb6f3ffc4f2974ae5c1c3ecc. The tested base is 804b4179e0309a9ecafe6de94eaf04c68efe07b3. Rebase audit confirms all original C21 patches have matching stable patch identifiers after rebase, and the final file set is exactly the six C21 files plus inherited main changes. See c21/rebase-audit.json. Each of three callback scenarios is 10/10 first-attempt positive on this head. Five final 50-case gates are 250/250 first-attempt positive, zero histories, zero final negatives. The direct-admission evidence uses admission-callback-01.xml through admission-callback-10.xml and admission-gate-1.xml through admission-gate-5.xml; earlier final-* records describe the prior head and do not replace these counts.

Original Clock/storage callback baseline: each 3/3 negative with the stated stale-contact assertion. Final strengthened storage contract controls: each 3/3 negative against C20 source, with the complete missing-message assertion. The precise persistence-owner check-omission control is negative 3/3. K1 reversal is negative 3/3 at “A storage callback sampled the caller Clock while persistence ownership was held: 1 reads”. C20 ordinary contact/duration controls and reversals are negative 3/3 each and green 10/10; both ordinary scenarios remain green in every final gate.

Final-head cache observer is 1/1 first-attempt positive, zero histories, keys 128 to 1. Source ownership and queue-cleanup controls are preserved in RTC6: a strong Clock field makes collection negative 3/3; omitting only queue removal yields 129 keys while collection remains positive. The public test and external observer are committed in the PR. No historical PR scenario was edited; the newly adopted C20 callback scenarios were updated for the ruling and strengthened for immediate completion. No test bound, iteration count, heap setting or runner size changed.

Full-suite slot evidence: sibling pid 63761 in laneB16e/Suite occupied the initial wait. The watcher observed the slot free at 05:28:09 UTC, within the allowed window, while C21 final targeted validation was active. A new complete suite in that same sibling directory, pid 16347, occupied it before validation ended. The bounded slot wait ended at 05:29 UTC. C21 kept its heavy runners sequential and did not overlap another complete suite. complete-result.json explicitly records zero own complete-suite starts and no XML counts.

C20 exit 137: 10 GiB cgroup maximum, peak above that maximum, two memory-limit events and one process removal. C20 ownership snapshots show no overlapping complete suite at those observations. Kernel messages are unreadable in C21; the parent maximum heap was sampled at 2684354560 bytes. A cgroup memory-limit explanation is consistent with those observations, but exact selected-process attribution is unavailable. Do not state the cause as established.

Relevant branches and unmerged state

All source below is unmerged. Nothing was published or deployed by C21; no production service was changed. The PR was open at the final PATCH, and its returned head and body matched the intended source and description exactly.

Repo	Branch	Recorded head	PR	Content/state
UrlProtocol	https://github.com/CodexCoder21Organization/UrlProtocol/tree/wip/laneC5-peer-freshness	437fd2ef55726e7ccb6f3ffc4f2974ae5c1c3ecc	https://github.com/CodexCoder21Organization/UrlProtocol/pull/740	Final corrected source; targeted checks pass; full suite unmet
UrlProtocol	https://github.com/CodexCoder21Organization/UrlProtocol/tree/wip/laneC21-admission-sample	437fd2ef55726e7ccb6f3ffc4f2974ae5c1c3ecc	same PR source	Durable final checkpoint
UrlProtocol	https://github.com/CodexCoder21Organization/UrlProtocol/tree/wip/laneC21-callback-time-red	a2a5ca399aa3518fb44916b569d76689790ca714	no separate PR	Original callback reproductions
UrlProtocol	https://github.com/CodexCoder21Organization/UrlProtocol/tree/wip/laneC21-callback-contract-red	86dcde4ed2d8827095d53328152f074b1ea63f58	no separate PR	Ruling-specific scenarios before source correction
UrlProtocol	https://github.com/CodexCoder21Organization/UrlProtocol/tree/wip/laneC21-callback-time-fixed	da3c0fe387cc0b7906d50bc1f02e3c0a70907e25	superseded checkpoint	First passing callback source
UrlProtocol	https://github.com/CodexCoder21Organization/UrlProtocol/tree/wip/laneC21-callback-coverage	129c1b24d0c883bc342c8d17e0abeff69f44e869	superseded checkpoint	Stronger immediate-error scenarios
UrlProtocol	https://github.com/CodexCoder21Organization/UrlProtocol/tree/wip/laneC21-validation-records	6359d521a874dfd731fbd6283ae8ce30f7351cc3	no PR	All XML, manifests, cache histograms, findings, PR text and slot records under c21/

Next steps

1. Clone fresh in the next lane's own directory. Read README and testing guidance, fetch the PR branch, and verify its current head. All C21 source is already pushed; no stash or unpublished source remains.
2. Check /proc working directories and arguments for a free complete-suite slot, including --test . runners. Run exactly one complete local suite from the final head using scripts/test.bash --local --test . --log <own-output.xml>. The saved C21 run-complete.py has this session's fixed wall-time cap and must not be reused with that old date unchanged.
3. Join each test to sibling attempt-history XML by name. Permitted histories only: testPeerRegistryCapacityBatchRemovalCallbackRejectsLaterVictimReadd, testPeerRegistryMixedPopulationBatchEvictionDoesNotRerankPerVictim, testPeerRegistryScoredDuplicateIpv4BatchEviction, testUrlResolver0661CanServeBytecodeAgainstCurrentProtocol. UrlResolver compatibility mechanism is owned by C19b/B19; no downstream workaround belongs here. Any other history requires a reliable local reproduction and source correction.
4. Record the complete-suite counts and exact histories in the PR and this handoff, then finish independent review. No merge, queue entry, check request, publication or deployment without the owner's separate direction.

Earlier handoff history

Current source, decision and status above supersede older pending-choice and PR-head statements below. Earlier references are retained for continuity.

Resolve callback time and finish the Round 6 audit

Written 2026-10-21T04:44:13.195768+00:00. RE-VERIFY: this is a write-time snapshot. Clone fresh and recheck branches and the PR before continuing.

Requirements and pending decision

2026-10-21 direction: "K1: never read the caller's Clock while any registry guard is held". Requested invariant: "the sample used inside a guard is taken after the last wait, outside every guard". No merge, queue entry, check request, publication or deployment is authorized.

Owner question is pending: should a contended action entered from a Clock or persistence callback report a clear error before running, or keep inherited cached time with a narrower fresh-time guarantee? A Clock read cannot return while its synchronous callback waits for the action; a persistence sample cannot be refreshed by a raw Clock read while its owner is held. No contract choice has been assumed.

Current result

Ordinary lifetime entry correction: 2fa68c187097d4be62e73f18c8d55580c9d0140b. Every lifecycle monitor owner records completion before releasing ownership. An action validates its prepared sample against that sequence; an intervening owner makes it discard the scope and prepare again outside guards. Same-thread Clock callback monitor entries count as preparation. Existing monitor semantics remain; no pre-existing PR test was edited.

Both original reviewer scenarios are baseline-negative 3/3 and source-reversal-negative 3/3, then positive 10/10 first attempt each. Contact assertion: A contact recorded after the monitor wait must use 301001, but used 1000. Duration assertion: An action starting after its monitor wait must see zero remaining time, but saw 300000. Five 44-case gates are 220/220 first-attempt positive, zero histories. K1 storage callback passes each gate.

Broader audit is UNMET: testPeerClockCallbackAfterMonitorWaitRecordsCurrentContact and testPeerStorageCallbackAfterMonitorWaitRecordsCurrentContact are each negative 6/6 against this complete source. Their assertions respectively start A Clock callback contact and A storage callback contact and end after the monitor wait must use 301001, but used 1000. Their source-read checks pass before those contact assertions. Another preparation still returns the old completed/inherited scalar. Window At callers remain in the outstanding scope audit. Do not treat the ordinary correction as a completed global guarantee.

Complete-suite gate is UNMET: attempt one exited 137, attempt two reached its 1350-second outer lane cap and exited 124; neither produced XML, so no case/history counts are claimed. Shared container memory limit/peak and an event count are consistent with the first interruption, but kernel attribution is unavailable. No heap, test timeout or iteration setting changed.

RTC6 coverage request is addressed on test-only head 832d0680c61f6fe2df10c832a3ba22e3d5410132: testPeerFreshnessClockCanBeCollected and tests/observePeerClockCache.py. Own run is positive on attempt 1; heap observer is exactly 128 -> 1. Its existing 128 samples and five-second collection bound remain. Product source bytes match 2fa68c187. Reviewer controls: strong Clock retention negative 3/3; queue-removal omission gives 129 keys instead of 1 while the public collection case stays positive. Current/restored reviewer source gives 128 -> 1. No complete suite from the later test-only head is claimed.

PR https://github.com/CodexCoder21Organization/UrlProtocol/pull/740 is open, unmerged, base main, head remains 3570f7e6712f083b51e226660cf2288a23b536e2. Its opening and Round 5 section are retained; Round 6 explicitly records this partial state and evidence. Source/coverage are checkpoint branches, not a PR head update.

Verified checkpoint branches

Branch	Remote head at write time
https://github.com/CodexCoder21Organization/UrlProtocol/tree/wip/laneC20-action-time-fixed	2fa68c187097d4be62e73f18c8d55580c9d0140b
https://github.com/CodexCoder21Organization/UrlProtocol/tree/wip/laneC20-action-time-red	1ffe29b9eac75d1cad3b180447aa19ec03d9390a
https://github.com/CodexCoder21Organization/UrlProtocol/tree/wip/laneC20-reviewed-coverage	832d0680c61f6fe2df10c832a3ba22e3d5410132
https://github.com/CodexCoder21Organization/UrlProtocol/tree/wip/laneC20-validation-records	a7c91c30cd0b15b9eba819549d037c9ccee71143

Evidence: https://github.com/CodexCoder21Organization/UrlProtocol/tree/wip/laneC20-validation-records/c20 . It contains baseline/reversal XML, ten two-scenario trials, five gates, both callback audits, source comparison, cache coverage XML/histograms, interrupted-suite records and findings. Findings path in this session: /tmp/claude-501/-code/79f96be0-ae83-4479-b38c-8894e2722ba8/scratchpad/out/rC20-findings.md .

For callback reproduction on the validation branch, first restore src/foundation/url/protocol/PeerRegistry.kt from origin/wip/laneC20-action-time-fixed (all other src bytes already match), then run scripts/test.bash --local with --test testPeerClockCallbackAfterMonitorWaitRecordsCurrentContact and --test testPeerStorageCallbackAfterMonitorWaitRecordsCurrentContact, plus --log audit.xml.

For cache coverage on the reviewed-coverage branch run python3 tests/observePeerClockCache.py --output build/test-evidence/peer-clock-cache.

Separate main item

Re-entrant same-peer removal during root atomicMove completes memory removal before the outer move writes its earlier root record. Restart restores that peer. RCC6 candidate and main each show three negative attempts; RTC6 current shows fifteen and main three. It is pre-existing, not a new attribution to this PR. Exact RCC6 assertion: A storage callback removal must remain absent after restart. Evidence: https://github.com/CodexCoder21Organization/UrlProtocol/tree/wip/laneRCC6-review-records/review-evidence/laneRCC6 and https://github.com/CodexCoder21Organization/UrlProtocol/tree/wip/laneRTC6-review . No ordering correction is applied here.

Next work

1. Resolve the pending callback time contract. If a clear error is selected, inherited-time admission must be non-waiting, including while persistence ownership is held; simply repeating preparation cannot refresh that scalar. A tryLock-capable lifecycle guard is the direct approach. Existing tests that specifically observe intrinsic-monitor BLOCKED need equivalent owner-bound coordination for the new primitive, retaining all behavioral assertions and bounds.
2. Complete the window/scope call-site audit. Keep K1; do not read the source Clock under a guard.
3. Add the agreed callback scenarios to the PR candidate, prove their stated baseline/control and ten first-attempt positives, rerun five 44-case gates and one complete local suite from the final head. Only one complete suite per machine; scan /proc working directories and argv forms.
4. Fetch/rebase, update the PR source branch with a lease, and replace the partial Round 6 body with exact final scope and XML counts. No CI watch or landing action is authorized in this lane.

No production or Maven artifact action occurred; session actions were local tests, GitHub checkpoint/body writes and Handoff updates.

Earlier C17/C18 record

Handoff: Resolve the compatibility history and finish the UrlProtocol clock update

Written: 2026-10-21T02:51:33.996066+00:00

RE-VERIFY: this is a write-time snapshot. Check the live PR head/state and prerequisite branch before acting. Clone fresh into your own workspace.

Design decisions in effect

Owner requirements, 2026-10-21:

• "K1: no caller Clock read while any registry guard is held; samples shared by Clock identity; weak keys retain no caller object; scopes leave through finally"
• "any other history or any final failure is a finding to fix at source before pushing."
• "Do NOT merge, enqueue, re-request checks, publish or deploy."
• "No raising any timeout, no reducing any iteration count, no disabling tests."

Mission

The owner reported that https://droplets.wasmserver.com/ "is super unreliable, frequently rendering various errors/notices due to bugs in UrlResolver or UrlProtocol or something else" and asked for the underlying root cause to be fixed; the ContainerNursery route stops the WUI after 5 idle minutes, so most human visits are cold starts.

Finish https://github.com/CodexCoder21Organization/UrlProtocol/pull/740, which carries source freshness evidence for repeated catalogue verification (root cause 4). It is stacked on https://github.com/CodexCoder21Organization/UrlProtocol/pull/738. The requested C16 source was 71d77f2a40aef4397c24d6051e9179db61d6c5bb on prerequisite 8b6d123e6819c6cbcce819111b83998688efde79.

What was found and done

1. A fresh clone verified the requested source and prerequisite. One complete suite ran at a time. C16 source complete suite exited 0: 2854/2854 first-attempt passes, zero histories and zero final negatives.
2. Independent K1 review found a synchronous storage callback path: per-peer persistence ownership spans filesystem calls; a callback invoking public imported freshness sampled the caller Clock under that owner. Six public in-memory cases reproduce the condition. Baseline and earlier-source control each have 18/18 negative recorded attempts (six cases, three attempts each).
3. Correction at 5c28ecee99b51f8bac0b4ed3b5e7fab8f4b1ceab carries prepared wall and elapsed time into each persistence body. Matching raw Clock identity shares it across registries, windows and observation logs; a different Clock reports the complete persistence-specific error before sampling. Dynamic scopes leave through finally on success/error. Weak cache values still contain scalar time state only. No earlier scenario was edited. Original 38 cases plus six new cases passed five times: 220/220 on attempt 1, zero histories.
4. Corrected-source complete suite exited 0 with 2860 final positives, 2858 first-attempt passes, zero final negatives. Histories: foundation.url.protocol.testPeerRegistryCapacityBatchRemovalCallbackRejectsLaterVictimReadd (permitted) and foundation.url.protocol.testUrlResolver0661CanServeBytecodeAgainstCurrentProtocol (NOT permitted). The final gate is unmet; the PR source branch and body were not updated.
5. Compatibility attempt 1 reports that a host-initiated substream cannot register because its root is terminal or physically closed. Current source emits this diagnostic at InboundSubstreamAdmissionControl.kt:1095. Earlier child output reports LOCAL_CLOSE on a root with no substream IDs and zero in-flight streams; close reason/caller are unknown. Attempt 2 passes. This identifies an observed boundary, not the responsible close mechanism or layer.
6. Ten bounded local targeted compatibility probes all passed on attempt 1. They do not establish a reliable reproducer and do not waive the full-suite history. No compatibility source/test correction is claimed. Do not guess a retry, timing or consumer change from this evidence.
7. An evidence-count correction matters: attempt-history contains ALL attempts, including the final one. Earlier notes saying 24/24 double-counted the root result; correct baseline/control totals are 18/18 each. Qualified history names must be compared by scenario name against the three allowed exceptions. Raw XML is unchanged and the correction is explicit in negative-control-count-correction.json.

Relevant PRs and refs

At the final live check, both PRs were OPEN. https://github.com/CodexCoder21Organization/UrlProtocol/pull/740 remains at 98cb0c36d7d40f90d88dc86c929922be50ed1186, base fix/atomic-confirmation-removal-c2. https://github.com/CodexCoder21Organization/UrlProtocol/pull/738 remains at 8b6d123e6819c6cbcce819111b83998688efde79. Never push to the prerequisite branch.

Repo	Branch	Verified remote head	PR	Contents and validation	State
UrlProtocol	wip/laneC17-storage-clock-red	781f160e811e4989422e538e2a8691a263ca94f4	no new PR	One storage callback case; baseline negative 3/3	unmerged
UrlProtocol	wip/laneC17-clock-scope-cases	6ff4b2abfdee4e4273bdb5fb724d9d5f8403a994	no new PR	Six storage scope cases; baseline negative 18/18	unmerged
UrlProtocol	wip/laneC17-clock-fixed	5c28ecee99b51f8bac0b4ed3b5e7fab8f4b1ceab	no new PR	Clock correction; 220/220 focused first-attempt passes; full gate unmet	unmerged
UrlProtocol	wip/laneC17-validation-records	d172aabd3c340f260a0d827e0a51385cc5f8d19b	no new PR	All XML, commands, hashes, diagnostics and pending body draft	unmerged

Source prerequisite: https://github.com/CodexCoder21Organization/UrlProtocol/tree/wip/laneC16-clock-validated . C16 records: https://github.com/CodexCoder21Organization/UrlProtocol/tree/wip/laneC16-validation-records .

No production code was deployed, no Maven artifact was published, and no PR was merged/enqueued. Only source/evidence branches were pushed. No CI checks were re-requested or watched. Both own working trees were cleaned; no stashes remain. Temporary build/launcher outputs were removed. The process audit used ps -eo pid,args -ww plus /proc CWD/start identity and found zero remaining own background processes.

Evidence

All paths below are on https://github.com/CodexCoder21Organization/UrlProtocol/tree/wip/laneC17-validation-records :

• findings.md: full progress record and source-linked call-site table.
• review.md and clock-call-site-table.md: source and test coverage review.
• c16-complete-suite.xml, c16-complete-suite-grade.json, c16-complete-suite-command.json: exact original-source gate.
• final-suite.xml, final-suite-grade.json, final-suite-result.json: corrected-source complete gate and its unmet policy.
• final-suite-histories.json and compatibility-history-full.txt: full assertion, stack and child output.
• gate-manifest.json, gate-1.xml through gate-5.xml, targeted-commands-and-hashes.json: corrected 44-case five-pass gate.
• storage-scope-baseline.xml, storage-scope-reversal.xml, source-restoration.json, negative-control-count-correction.json: red/control proof.
• compatibility-repeat-1.xml through compatibility-repeat-10.xml and compatibility-repeat-summary.json: targeted probes.
• body-pending.json: prepared replacement body with original opening, Round 5 clock section and table. It explicitly records the unmet gate and must be refreshed after a valid final gate; it was NOT applied.

Generated dependency/build outputs and routine successful compiler logs were omitted; portable commands, immutable source refs and all diagnostic XML/output are preserved.

C18 continuation snapshot

The C18 brief supersedes the earlier compatibility-history gate: compare candidate and base under genuine concurrent amplification; if neither reproduces in 40 minutes, classify the one observed compatibility history as not reproduced under amplification and retain the unchanged-path evidence. No compatibility source correction is justified without a reproducible mechanism.

C18 has claimed this handoff. Fresh candidate is 5c28ecee99b51f8bac0b4ed3b5e7fab8f4b1ceab; prerequisite is unchanged at 8b6d123e6819c6cbcce819111b83998688efde79. Initial launcher preparation attempts returned Text file busy and no scenario XML; they are excluded. Prepared candidate/base each pass once. The active comparison uses eight concurrent genuine compatibility scenarios, four per source, alternating launch order, 768 MiB heaps and SerialGC. The independent XML grader is checked against C17: 2860 cases, 2858 first-attempt passes, two histories, zero final negatives.

The unchanged-path hashes cover admission control, root close tracking, host factory, RelayService, compatibility scenario, and compatibility runtime build rule. Admission registration reads its private terminal state and physical close future; changed freshness code does not write these fields. C17 local-close output does not establish the responsible owner. Best current hypothesis is startup selection of a locally closed outbound root; no candidate-only cause is demonstrated.

C18 evidence: validation branch, first checkpoint 549dc96c6, parser checkpoint 2ad0a4667. Artifacts are under c18/: amplify.py, grade.py, parser-check.json, path-comparison.json, prepared XML and findings.md. More XML will be committed as comparison advances. PR branch/body remain unchanged while the comparison runs.

Next steps

1. Re-verify current state first: PR openness, prerequisite branch tip, source/evidence remote heads and the latest main. Use the corrected source branch above in a fresh checkout; do not reuse the old local trees.
2. Read the full compatibility history and testUrlResolver0661CanServeBytecodeAgainstCurrentProtocol.kts. Trace which owner closes the root before host-initiated registration. The currently pinned library is community.kotlin.libp2p:jvm-libp2p:1.3.0-codexcoder21-snapshot-25; the emitted diagnostic is in protocol admission code, so the owning layer is not established. Fix the actual responsible layer, with an initially negative public-API test and a deterministic condition once the mechanism is understood. No mocks/reflection, timing increases, disabled tests or smaller iteration counts.
3. The basic command is scripts/test.bash --local --test testUrlResolver0661CanServeBytecodeAgainstCurrentProtocol --log <own-evidence-path>.xml . Ten positive probes are not a reliable negative baseline. Use genuine concurrent callers and exact ordering to identify the condition; do not use artificial host load or repeated CI runs.
4. Resolve the unpermitted compatibility history, verify at source, and run the required focused gate and final complete suite from the final source. Only the three capacity histories named in the brief are allowed; see https://github.com/CodexCoder21Organization/UrlProtocol/pull/738#issuecomment-6301754343 . No final negative is permitted. Before a complete suite, inventory /proc process CWDs under the workspace and wait for any existing complete suite; one complete suite machine-wide.
5. Once the gate holds, confirm the PR is OPEN, fetch/rebase onto the current prerequisite tip and repeat the original 38-case gate once if it moved. Then update wip/laneC5-peer-freshness with a lease against the current verified head. Never push to fix/atomic-confirmation-removal-c2.
6. Refresh body-pending.json with the actual final head/counts/links and PATCH repos/CodexCoder21Organization/UrlProtocol/pulls/740 using gh api --method PATCH --input <body.json>. Keep the original opening and footer. Retarget to main after the prerequisite merges. Stop after the update; no merge, queue, publication, deployment, check request or CI watch.

Operational knowledge

scripts/test.bash --local --test . --log <file>.xml writes XML only when the complete run ends. Track the process and cap it; do not infer a pass from exit 0 because the runner can record earlier negative attempts. Histories are root attempt-history nodes, and their attempt children include the final attempt. Use basename normalization for package-qualified scenario names. Source freshness uses elapsed time for SystemClock and the supplied elapsed clock otherwise; the new wall field preserves ordinary event timestamps when persistence scopes share a sample.