[rmcdaniel]

The prepared-local controller currently calls only version-1 bridge methods. This change dispatches through Core's actual optional retry interface and retains a closed original preparation receipt bound to the issued claim, unique Started event and complete snapshot-2 graph. A separate atomic recovery receipt binds the recovering claim and exact committed engine event. Only a matching late duplicate may bypass fresh fences, including after following preparation. Initial preparation receipt creation also requires the actual engine reply prepared: true, duplicate: false; a replay cannot repair missing Server authority.

A supplied override gets pure validation after protocol/role admission and before task lookup. Reports without that member retain legacy lookup order; proven version-2 reports then use the same pure check before fresh fences or payload work. Completed external-payload lease checks retain their separate resolution boundary. The default bridge, locked package, advertisement, v1 behavior and 158-case semantic companion remain unchanged. OpenAPI revision 58 includes accepted main ready-age additions and this wire documentation, with protocol 1.20 unchanged.

Validation: exact head d80a8db4 passed all 16 normal PR checks with eight declared profile skips. Candidate 42203750084/a1 passed SQLite 404 tests/13,080 assertions, MySQL and PostgreSQL each 404/13,079, and the affected regression suite 348/4,329, with zero errors/failures/skips. The actual-Core retry class passes 11 tests/201 assertions on every backend, including the new no-backfill case. All three changed PHP files pass PHP 8.4.27 syntax. Exact source binding, artifact and historical attribution are retained in 6682829619.

Core source is ce24207ef86856e64f97b939c9aeef9d1fb387c8 (Workflow #1051). The optional role is test-bound only. No installed/native role, capability advertisement, SDK adoption, release or publishing effect is enabled. Refs #325 and durable-workflow/.github#219.

[rmcdaniel]

Self-review of exact 4798a1465f179e681dafff603731fa899783ff07 found one remaining recovery boundary before this can be ready. The existing preparation/recovery controller checks currentClaim and WorkerPollFence::isCurrentForUpdate before entering Core. A committed version-2 recovery duplicate must instead recover its original decision before fresh registration/clock fences, including after a following claim or attempt. The original callback's retained preparation receipt proves its capability, but does not retain the recovering claim's issued capability.

I am adding a separate closed Server recovery receipt, written atomically with the actual Core recovery event. It will bind the recovering task/epoch/owner and issued claim to that exact event and the original prepared graph. A duplicate may bypass fresh registration work only after that retained authority is found and verified, and only if Core returns the matching immutable duplicate. Missing or corrupt receipts will refuse without backfill. An unexpected fresh write from this branch must roll back. Fresh recovery retains its current-claim/fence requirements. No worker input can select this authority or claim physical callback stop.

The current draft is not a qualification pass for this behavior. Next controls cover late duplicate after a following attempt, stale recovering registration, changed original graph, missing/corrupt recovery authority and atomic receipt-persistence rollback. Source helpers remain unadvertised; no manual candidate, installed or native operation has been selected.

[rmcdaniel]

The missing recovering-claim binding identified in my prior self-review is implemented on normal successor ef00c26, tree 756b5a1f7ff765ba44a53c0c1cd758a9cf9eb3a3. Original Feature run 42171795388/a1 remains FAILURE: its only failing assertion counted SQLite catalog ownership introspection as task-row access. The changed counter now counts actual table access and includes a real task-read canary. No original result is relabelled or rerun.

Preparation retains the closed nine-key original claim/contract/snapshot/Started binding. Fresh recovery now atomically retains a separate nine-key durable-workflow.server.prepared-local-recovery-authority/v2 receipt, including the recovering issued claim and an exact projection of Core's committed event, recovery identity and retry disposition. Both claims and the canonical original graph remain independently required. An unchanged complete recovery receipt permits only Core's matching duplicate before fresh registration/quota/clock work, including after a following attempt. Missing receipts are never backfilled. Changed authority or a nonmatching bridge result rolls back the outer transaction. Core's retained failure sample and history insertion time are preserved separately; WorkflowHistoryEvent::recordEvent() samples insertion time independently.

The new candidate source test, SHA-256 0712e4bdc83570dbb4f8ca107b7062219fef6ca069a6d1b516c708859b3bd7ee, contains nine methods covering actual preparation/duplicates, strict early override refusal and legacy precedence, late outcome recovery, late engine-interruption recovery after following preparation, missing/mutated authority refusal, real-writer rollback and T99/D100 versus due-timeout precedence. Its test-only optional role delegates to the real accepted Core kernels rather than fabricating writer results. These DB/transport controls are unexecuted. The existing manual candidate profile now selects this file for SQLite/MySQL/PostgreSQL; its trigger, tuple, acquisition/build policy and bounds are unchanged, and no dispatch has occurred.

Executed checks are PHP 8.4.27 syntax for the five changed PHP files and the three Composer inventory/guard/confinement controls. Short cached-image, network-none source cells are terminal with exact name absence verified. Fresh ordinary current-head PR CI is starting. The earlier pure intent/capability controls remain distinct from writer qualification.

Core/Workflow's next finite readback is the closed preparation/recovery receipt and duplicate boundary against accepted ce24207ef86856e64f97b939c9aeef9d1fb387c8. After that concrete source comparison and normal checks, the remaining qualification input is selection of the existing exact-candidate source profile (Server successor plus that immutable Core source), including its actual build/acquisition path. I have not inferred that selection from source acceptance. The default role, locked package, capability advertisement, v1 semantics and 158-case semantic baseline remain unchanged. No installed role, native tuple, SDK adoption or release is enabled.

[rmcdaniel]

Continued source review found one missing logical identity check in the recovery guard: JSON path equality is not a portable proof of an actual integer. Normal successor 5bb1e23, tree 885cb26324e7fca556c5e01ec58f0d11d4949d7b, requires the canonical execution sequence and recovery payload sequence to equal the requested integer, and binds that activity sequence separately from the history event sequence in the private engine projection. A numeric-string mutation must refuse without repairing the event or writing another outcome. The source control is added to the existing late-recovery method, not a fabricated native result.

Actual PHP 8.4.27 syntax passes for the changed helper/test in a cached offline source cell, with exact container absence verified. The nine-method candidate file is SHA-256 bab332bdda273f31fe022288b0bacdf3bf473c5054663e0ca912f0c4161c2962; its DB/HTTP controls remain unexecuted. The predecessor ef00's 16 green checks/eight profile skips remain its own result. Fresh current-head CI is running, and the concrete unselected candidate packet at 325/6679034130 now binds this successor. No old-head dispatch, source verdict or check is carried. The default role/package/advertisement and semantic fixture remain unchanged.

[rmcdaniel]

I rechecked the actual source authority in central219/6671268805 and the organization guide. They assign guarded implementation and meaningful behavior evidence through ordinary source CI, with no blanket General/Security source gate. My earlier packet treated the manual trigger as an additional approval requirement; that was too broad. The existing candidate source profile is the necessary repository test lane for these new guarded DB/HTTP methods.

As source owner I select its first exact-candidate source qualification at Server 5bb1e23f0c87841077c7892812c602a452caa3a4, Core overlay ce24207ef86856e64f97b939c9aeef9d1fb387c8, corpus base fadf8729265e077f280c8f71a87c06d8f73a682e. Fresh readback proves the owned branch and all 16 normal checks/eight profile skips, active workflow 264946429, exact workflow blob e3083984eef18a4f1ea215b8b7f8f3545c0df99f, Core tree e03c06e5c7a5f40d572bf1920885bb9f2f839ecd, and zero prior manual runs at this head. The existing 30-minute candidate job, pinned disposable MySQL/PostgreSQL services, sequential three-backend tests, public locked graph, reviewed base build and read-only token permissions remain unchanged. Its test-only role delegates to the actual Core kernels. No workflow-run publisher follower exists.

One original workflow dispatch follows; its returned run/head/ref/attempt must match before any source result is accepted. I own terminal evidence and the existing hosted cleanup. An original failure remains attributed and is not automatically retried unchanged. This is repository source QA and creates no installed native tuple, production role, advertised capability, package/tag, registry or release acceptance. The public native artifact and all operating/publication stops remain separate. The packet at #325 is corrected accordingly rather than waiting indefinitely on an inferred approval.

Actual original binding: 42183406071/a1, workflow 264946429, event workflow_dispatch, owned branch feat/server-prepared-retry-admission, exact head 5bb1e23f0c87841077c7892812c602a452caa3a4, created 2026-11-06T07:49:28Z. The single POST returned HTTP 204 and fresh readback found exactly one matching run. Source result is pending.

[rmcdaniel]

Original candidate run 42183406071/a1 is terminal FAILURE. Job 127778590512 and artifact 13486721767 retain the same fatal fixture error on all three databases: the rollback helper called bindRetryRole again after the container already held a Mockery bridge, so class_implements included Mockery's own interfaces and generated a duplicate byDefault method. JUnit files are empty. This original does not supply a completed writer test result.

The fixture now captures the actual base bridge before its first role binding, asserts that base is not a Mockery object, and reuses that real base for later controlled overrides. The production controller/authority code is unchanged by this correction. The branch is normally refreshed onto accepted main 59d5bb379524924a16fdcc0ebd482462fb7049a9 after its four automatic main workflows passed. OpenAPI document revision 58 now describes the combined additive schema; protocol 1.20 and the 158-case fixture remain unchanged.

Changed source is 7af16d0, tree 1b89d9478ca93f0b9e1252ae35b97510a4b88d8e, parents [aa5b7ba1,59d5bb37]. Candidate test SHA-256 is bfe14e24fc513a5b71ccd267c887c93778d4671eb9d10ebea2c71fdf0fdf87fc. PHP syntax and the three Composer inventory/guard/confinement controls pass; fresh normal PR checks are running.

I select the first source profile for this corrected tuple under the same ordinary source authority: Server 7af16d0, Core ce24207ef86856e64f97b939c9aeef9d1fb387c8, corpus base 59d5bb3. Fresh remote head/main identities and zero exact-head manual attempts are verified. Workflow blob is 461788d538e0781a52bb62a7bfdf63c3346b39ca, SHA-256 3a973a6b8f185aa4ad0a5db8013b6dc141e3c800f315b0eccff1643a7a4a627b. Its source job, images, public graph, read-only permissions and bounds are unchanged. One original POST follows, with exact returned binding and terminal evidence retained. This is a changed fixture and maintained base, not an unchanged-source retry or an installed/native/advertisement/release result.

The single POST returned 204. Exact original is 42186037357/a1, workflow_dispatch at 7af16d0b4f2f908f96a1b5ff50188bd997b69c8d, created 2026-11-06T08:12:36Z; candidate source job 127787319096. It is still running. No second POST or result carry occurred.

[rmcdaniel]

The second exact candidate original 42186037357/a1, Server 7af16d0b, is terminal FAILURE. Artifact 13488353203 is a CRC-valid 56,537-byte ZIP with SHA-256 87036d38d46764d8695324321734438626a3118d53e782c217cf6aae896dce34. Each database completed 402 tests: 12 failures and one risky test, with 12,956 assertions on SQLite and 12,955 on MySQL/PostgreSQL. The new retry class completed nine tests/99 assertions with five failures and zero skips. Its preparation, retained recovery and both atomic rollback methods passed, but that partial result is not qualification.

The three-file test correction is now exact 06ee03c6380f7b34e545cf28c704f4d7f79736cc, tree 33ed57680a61340209943dff7965d3e81dc27efd, sole parent 7af16d0b:

• The raw call helper bypassed Laravel's default-header transformation, so outcome requests lacked the worker protocol header and returned 400. postJson now sends the explicit headers and preserves zero-fraction float bytes. A bounded inert check of the exact locked Laravel HTTP trait independently reproduces the missing old headers and verifies the corrected headers/float identity. It is a helper control, not a controller/DB pass.
• The T99/T100 deadline rows now have independent fixtures and a current heartbeat from the same retained worker process. Previously the 99-second fixture hit registration staleness before the activity deadline decision. The actual controller fence is preserved.
• Maintained Core's accepted ActivityOutcomeRejection recorder intentionally adds one bounded audit event when outcome authority expires during payload resolution. The six old tests now require its exact seven-field payload and one event, while still requiring execution/attempt/task/registration rows unchanged. The older locked package lacks that recorder and retains the original zero-event expectation. Bound Core blob is ffd2df018891809b0a0ed632aca7eb61fe70254f at ce24207e.
• The scope-lock recheck fixture now implements the already-required ProtocolAwareWorkflowTaskBridge role, allowing it to reach the second scope check instead of the existing 503 missing-role refusal. Both completion methods remain forbidden, and exactly two scope checks are required.

Production controller/authority code, the 158-case companion, dependency lock, advertised capabilities and workflow graph/bounds are unchanged. PHP 8.4.27 syntax passes for all three changed files. The exact-framework helper control used the existing immutable public PHP image with no network/vendor/DB and is independently cleaned up. Current normal PR checks are fresh and running.

The source owner selects the first existing candidate source profile for this changed tuple: Server 06ee03c6380f7b34e545cf28c704f4d7f79736cc, Core ce24207ef86856e64f97b939c9aeef9d1fb387c8, corpus base 59d5bb379524924a16fdcc0ebd482462fb7049a9. Fresh remote identities and zero exact-head manual runs were verified. Workflow blob 461788d538e0781a52bb62a7bfdf63c3346b39ca / SHA-256 3a973a6b8f185aa4ad0a5db8013b6dc141e3c800f315b0eccff1643a7a4a627b is unchanged; retry source test SHA-256 is 9f9539994820bf0389794a4543402a7137d502568aa78823b7c589924621c762.

One original POST follows under the established ordinary source QA authority. Its readonly permissions, existing public graph/base build, pinned disposable DB services and 30-minute candidate bound are unchanged. No unchanged-source rerun, installed role, SDK/native tuple, advertisement, publication or release result is selected. The prior originals remain failed and attributable.

Single POST returned 204. After the initial eventual-consistency read returned zero runs, a read-only follow-up found exactly one original: 42189558449/a1, workflow_dispatch on the owned branch at exact 06ee03c6380f7b34e545cf28c704f4d7f79736cc, created 2026-11-06T08:42:05Z. No second POST occurred. Terminal qualification remains pending.

[rmcdaniel]

Original 42189558449/a1 at 06ee03c6 is terminal FAILURE. Artifact 13490351736 is CRC-valid, 53,783 bytes, SHA-256 5a708f21eda6fabd557ba4894b963658f86990779b1690bb0a203140bbcf551b. All three backends completed 403 tests with exactly two failures and zero errors/skips/risky tests: SQLite 13,042 assertions, MySQL/PostgreSQL 13,041. The retry class completed ten cases/163 assertions with two failures. The remaining failures are the T99 and T100 rows, each receiving HTTP409 rather than200. The other 401 cases, including outcome submission, strict override checks, audit assertions and scope-lock recheck, passed within that failed aggregate. The affected-regression phase was not reached because the first suite failed. No overall qualification is claimed.

The remaining 409 does not identify its reason in the old status-only assertion. I am not changing an engine fence or declaring a product fix from that output. Exact diagnostic successor 868921c2a14c613559288c4d9d5a2b0d9bb6e561, tree 2967527399717dfa6b4521fc248dcb8e2aa605eb, sole parent 06ee03c6, adds positive prerequisites for the original registration and both actual issued lease expirations, plus the response body as the status assertion's failure message. It leaves the T99/T100 inputs, expected terminal classifications, all controller/kernel code, the selected test set and workflow graph/bounds unchanged. These assertions distinguish an invalid fixture authority from an actual retry-decision refusal. Source test SHA-256 is 4e988387ed2d526a9a3ce8449151ed048d696c4054d6cf0b88591bcd3e4cdd74. PHP syntax passes in the cached isolated tool and cleanup is complete.

The source owner selects one first diagnostic original on this exact new test source under the existing candidate profile, with unchanged Core ce24207ef86856e64f97b939c9aeef9d1fb387c8, corpus base 59d5bb379524924a16fdcc0ebd482462fb7049a9 and workflow blob 461788d538e0781a52bb62a7bfdf63c3346b39ca. Remote head and zero exact-head manual runs are reverified. This is a bounded investigation of the two known failures, not a claimed fix, green requalification of unchanged source, altered expected result or increased attempt/bound. The same read-only token, public graph/base build, pinned disposable DBs and 30-minute source-job limit apply. One original POST follows, with all actual failures retained.

Current normal CI starts for the new head. Its predecessor's 16 successful checks/eight declared skips and locked-package 3,595 tests/87,200 assertions remain historical. PR #1049 stays draft. No installed/default retry role, capability advertisement, native tuple, SDK adoption, publisher or release action is selected.

The single POST returned204. Exactly one original is bound as 42193505777/a1, workflow_dispatch at exact 868921c2a14c613559288c4d9d5a2b0d9bb6e561, created 2026-11-06T09:14:16Z. It is running; no diagnostic or qualification PASS is claimed.

[rmcdaniel]

The fourth original, diagnostic 42193505777/a1, exact 868921c2, is terminal FAILURE. Artifact 13492505113 is CRC-valid, 53,681 bytes, SHA-256 89bb665f82d8dd1a17849f7bee379b4718d33adb4af932c924d825794cddc304. All three backends again completed403 tests with exactly two failures and zero errors/skips/risky tests. SQLite had13,042 assertions, MySQL/PostgreSQL13,041. All other401 cases passed within the failed aggregate; the affected-regression phase was not reached.

Correction to my earlier diagnosis: the two failures are at the preparation request, not the outcome or a T99/T100 fence. The exact stack line271 is the preparation assertOk. Neither simulated deadline sample nor the added lease prerequisites ran. I traced the wrong request in the previous reports. The run's Server/Core provenance matches its exact source, and the original failure remains unchanged.

The actual fixture error is its start_to_close_timeout=200 with schedule_to_close_timeout=100. Core's canonical WorkflowCommandNormalizer::assertActivityTimeoutOrdering requires the total budget to be at least one attempt's budget. At immutable Core ce24207ef86856e64f97b939c9aeef9d1fb387c8, blob 4aa66d89853a01c1a372602b8ed56d4fd58fde6d, the full class's exact pure method independently reproduces refusal for200/100, accepts100/100, and retains the heartbeat-ordering refusal. This bounded cached-PHP control used no vendor/application/DB/network and is cleaned up. It proves the fixture ordering correction, not a writer result.

Corrected source is b24082cb542310b6ba0a4390119f4b6d085669d1, tree d2489d451a074973185b79ce5ebe9b7d25fceb94, sole parent 868921c2. Only the source test changes. It uses coherent100/100 timeouts, so the overall timeout still wins at the equal deadline under the actual engine ordering. Its finite test registration window is300 seconds and its issued claim remains unchanged, avoiding a manufactured heartbeat mutation. The positive registration/hosting/callback lease prerequisites remain. Preparation and outcome failures now include the actual response body. The T99 terminal receipt is also replayed atT119 after registration supersession, requiring the same event/decision and no durable-row mutation. No application callback or physical-stop claim is made.

PHP syntax passes. Source test SHA-256 is f75e8b4336f0837c4515151bfcdd2b4f45786ce63101dda6a9b124a235d36b21. Production code, the158-case companion, dependency lock and workflow graph/bounds are unchanged. Current normal checks are fresh and running. Prior normals at8689 remain historical.

The source owner selects the first existing candidate profile for this corrected tuple: Server b24082cb542310b6ba0a4390119f4b6d085669d1, Core ce24207ef86856e64f97b939c9aeef9d1fb387c8, corpus base 59d5bb379524924a16fdcc0ebd482462fb7049a9, unchanged workflow blob 461788d538e0781a52bb62a7bfdf63c3346b39ca. Fresh remote head/main and zero exact-head manual runs are verified. One original POST follows under ordinary source QA authority, with unchanged readonly token/public graph/base build/pinned disposable DBs/30-minute source bound. The earlier failed originals remain failed; no unchanged-source retry or increased bound is selected.

PR1049 stays draft pending actual complete behavior and current checks. No installed/default retry role, capability advertisement, native3.2 tuple, SDK adoption, publisher or release action is enabled.

Dispatch transport exception: the first POST returned HTTP502, not204. Independent exact-head reads immediately afterward and again at09:42:34Z report zero runs; the workflow's unfiltered recent manual-run list still ends at the earlier8689 diagnostic. No b240 source job has been admitted or failed. I am correcting the planned one-POST transport count and selecting one further submission to obtain the same single original source job under routine source-owner CI authority. This does not rerun a failed qualification, change its inputs/graph/bounds, refresh credentials or move providers. If any original appears before submission, no further POST will be made. Both transport responses and actual run cardinality will remain explicit.

The follow-up transport POST returned204. Exactly one original is now bound as 42197227574/a1, workflow_dispatch at exact b24082cb542310b6ba0a4390119f4b6d085669d1, created 2026-11-06T09:43:53Z. The first HTTP502 and its zero-run observations remain recorded. There are two transport submissions and one admitted original run, not two qualification attempts. No further submission or result PASS is claimed.

[rmcdaniel]

Original 42197227574/a1, exact b24082cb, is terminal FAILURE with one remaining MySQL assertion. Artifact 13493742886 is CRC-valid, 64,807 bytes, SHA-256 33d87638b638a859f891f2999ba6a093606b62e113fa63d4441d05f76e75e7f5.

The coherent preparation/deadline fixture now reaches and exercises its intended paths. SQLite passes all403 tests/13,069 assertions, PostgreSQL all403/13,068, and SQLite's subsequent affected-regression phase passes348/4,329. All have zero errors/failures/skips. MySQL completes403/13,067 with one failure and zero errors/skips. The new retry class is10/190 on SQLite/PostgreSQL, and10/189 with one failure on MySQL. These are bounded phase results inside an overall failed original, not aggregate qualification.

The MySQL failure is the late T99 duplicate's decision comparison at line303. The original and duplicate contain every same literal field/value, including actual integer versions/delays, T99 failure time, original D100 deadline, failure source, delay source and terminal classification. MySQL's persisted JSON object returns a different key order. The response already proves duplicate=true and the identical event ID. The later durable-row equality assertion was not reached on MySQL, so it still needs actual execution.

Exact successor 44062bb3a5c464f7ffeef49d00b6880a763b93b7, tree 7775a87d4d825ee5a58fa1ad026b6270347855bb, sole parent b24082cb, changes only that assertion. It sorts object keys on both decisions, then keeps assertSame for the complete keys and literal scalar values. No value, type, reason, timestamp, identity or history is normalized, and the final durable-row equality check remains. No test is removed. Production code, the158-case companion, dependency lock and workflow bytes are unchanged. PHP syntax and diff checks pass. Source-test SHA is c5f290c4eda064e70d41b3d51d3d5f9f4271848be3a210c995a556b749cbef3b.

The source owner selects the first existing full candidate profile for this changed source tuple: Server 44062bb3a5c464f7ffeef49d00b6880a763b93b7, Core ce24207ef86856e64f97b939c9aeef9d1fb387c8, corpus base 59d5bb379524924a16fdcc0ebd482462fb7049a9, workflow blob 461788d538e0781a52bb62a7bfdf63c3346b39ca. Remote head and zero exact-head manual originals are verified. One original POST follows. The readonly token, existing public graph/base build, pinned disposable databases and 30-minute source bound remain unchanged. Prior failed originals, including the b240 transport502/no-run exception and its single admitted original, remain attributable.

Fresh normal checks and complete source behavior are required at this head before integration. PR1049 stays draft. No installed/default role, capability advertisement, native3.2 tuple, SDK adoption, publishing or release effect is selected.

The single POST returned204 and bound exactly one original: 42199834476/a1, workflow_dispatch at exact 44062bb3a5c464f7ffeef49d00b6880a763b93b7, created 2026-11-06T10:04:33Z. Complete current behavior remains pending.

Terminal result: original42199834476/a1 is SUCCESS at44062bb3. CRC-valid artifact13494288966 is64,088 bytes, SHA-25668679ccd02879abb33bebbaa0da6a9d75d7f68e8b50b2351181206aaf1ad480b. SQLite403/13,069, MySQL403/13,068, PostgreSQL403/13,068 and affected regressions348/4,329 pass with zero errors/failures/skips. The retry class is10/190 on every backend. This proves the complete strict-object assertion and final row equality at440. A later source review found missing original preparation authority could be backfilled from an engine duplicate; that changed production guard is separately qualified at successor d80a8db and is not covered by this result.

[rmcdaniel]

A final authority review found that a duplicate preparation could recreate a missing private Server receipt from its existing Core graph. Those records are originally atomic, so replay must not repair a missing admission frame. Exact successor d80a8db418a17ede74bbaf325f68e1c31253e86b, tree fb2715a3d16736b2c55f3acc6f5fb0ff40b9b82e, sole parent 44062bb, now requires the bound engine reply's literal prepared: true and duplicate: false before creating a new preparation receipt. An existing matching receipt retains duplicate behavior. The one controller caller passes the actual role reply; no worker Boolean is trusted.

The new actual-Core source regression prepares once, removes only that private receipt, retries preparation, and requires 409/prepared_local_activity_not_supported with unchanged history/attempt/execution/task rows and the frame still absent. Existing valid duplicate, corrupt-frame, transaction rollback, outcome/recovery and deadline controls remain. No v1 path, default role, dependency lock, canonical companion or capability advertisement changes. PHP 8.4.27 syntax passes for all three changed PHP files and diff checks pass. The first local bind-mount lint could not see its input; corrected stdin lint passed and all owned containers are absent. No application or installed test ran locally.

The previous exact440 original 42199834476/a1 is terminal SUCCESS: SQLite 403/13,069, MySQL 403/13,068, PostgreSQL 403/13,068 and affected regressions 348/4,329, zero errors/failures/skips. Retry class 10/190 on every backend. Artifact 13494288966 is CRC-valid, 64,088 B, SHA-256 68679ccd02879abb33bebbaa0da6a9d75d7f68e8b50b2351181206aaf1ad480b. This is retained historical proof, not acceptance of the new guard.

The source owner selects the first existing complete candidate profile for this changed tuple: Server d80a8db, Core ce24207ef86856e64f97b939c9aeef9d1fb387c8, corpus base 59d5bb3, workflow blob461788d538e0781a52bb62a7bfdf63c3346b39ca. Remote head and zero exact-head manual runs are verified. One original POST follows. Existing read-only token, public graph/base build, pinned disposable databases, sequential backend checks and 30-minute source bound remain. Fresh normal checks are authoritative. Prior failed originals/transport attribution remain unchanged. No installed/native tuple, SDK adoption, release or publication is selected.

The single POST returned 204 and bound exactly one original: 42203750084/a1, workflow_dispatch at exact d80a8db, created 2026-11-06T10:34:49Z. No complete result is claimed while it runs.

Terminal exact-source result: original 42203750084/a1 is SUCCESS at d80a8db, all six jobs green. CRC-valid artifact 13495669417 is 64,272 B, SHA-256 f6be0bb16d810766fc82a84fc3ff462a8c33fe403479d0232f58044d01ee74c5; provenance binds this Server head and Core ce24207e. SQLite passes 404 tests/13,080 assertions, MySQL and PostgreSQL each 404/13,079, and the affected regression phase 348/4,329, all with zero errors/failures/skips. The actual-Core retry class passes 11/201 on every backend. The new missing-preparation-receipt refusal case executes with 11 assertions on each backend, alongside valid retained duplicates and the prior rollback/deadline controls. All 16 normal PR checks also pass with eight declared profile skips. Source review is complete and the owner proceeds through protected integration without an admin bypass. Current main qualification remains authoritative after merge. No default installed role or capability is enabled by source integration.

Protected integration: the single queue entry MQE_lQDOSATFBs8AAAABNPhrg84ABPZYzgPGywE was enqueued at 2026-11-06T10:57:25Z. Original merge-group head b8f4dd1 has the exact qualified tree fb2715a3d16736b2c55f3acc6f5fb0ff40b9b82e and ordered parents [59d5bb3, d80a8db]. Original queue runs are Feature42206608013, Shared42206608090 and Boundary42206608095, all attempt1. Queue and eventual main results remain their own acceptance steps; no queue reentry or retry is selected. The ordinary locked-package PR log also confirms 3,595 tests/87,200 assertions with its six existing deprecations and 51 skips, plus51/250 and1/12 supplemental checks. These legacy skips are separate from the candidate profile's zero-skip result.

The original queue passed, including Feature42206608013 and Sonar42208778202, and GitHub merged PR1049 at 2026-11-06T11:16:07Z as b8f4dd1. Actual protected main has the exact qualified tree and ordered parents recorded above. Its original automatic main acceptance and owner cleanup are now in progress; no main result is inferred from the queue.

[sonarqubecloud]

Quality Gate passed

Issues
9 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]

PR #1049 is merged and accepted on actual main b8f4dd13623ce645de77ba5bd89ae8dd8eea2f7c, tree fb2715a3d16736b2c55f3acc6f5fb0ff40b9b82e, ordered parents [59d5bb3, d80a8db]. GitHub merged at 2026-11-06T11:16:07Z through the original protected queue, with no reentry or admin bypass. Queue originals Feature 42206608013, Shared 42206608090, Boundary 42206608095 and Sonar 42208778202 all passed.

Actual-main originals all passed at attempt1: PHP Feature 42208980053, Sonar 42208979969, Boundary 42208980071 and CodeQL 42208979196. Main's PHP log confirms 3,595 tests/87,200 assertions with six existing deprecations and 51 skips, plus 51/250 and 1/12 supplemental checks; required TLS/certificate checks and cleanup passed. The queue-only Sonar follower 42211004930 correctly skipped the main push. Shared fixtures have no main push trigger for this path set; their PR and original queue results are retained.

The exact candidate proof remains 42203750084/a1, Server d80a8db with Core ce24207e and base 59d5bb3. SQLite 404/13,080, MySQL 404/13,079, PostgreSQL 404/13,079 and affected regressions 348/4,329 pass with zero errors/failures/skips. The actual-Core retry class is 11/201 on each backend, including the missing-preparation-receipt refusal case with 11 assertions each. Artifact 13495669417 is CRC-valid, 64,272 B/SHA-256 f6be0bb16d810766fc82a84fc3ff462a8c33fe403479d0232f58044d01ee74c5. Historical failed originals and the transport exception remain attributed in 6682829619.

The guarded source now preserves original preparation authority, separate recovering-claim/event authority, strict literal sequence and snapshot-2 binding, transaction rollback and immutable duplicate decisions. Replay cannot recreate either missing private receipt. The optional role is test-bound only; the installed default bridge, package lock and capability advertisement remain unchanged. This source acceptance does not qualify an installed/native producer, SDK adoption or publication tuple. #325 and central219 remain open for those concrete follow-through steps.

The merged remote branch is absent by independent readback. Its local branch and worktree are removed, and the owning checkout is clean at accepted main. Other held work and the common checkout were preserved. No owned source-tool container remains. Server next advances the already-selected central215 ordinary-entry carrier source under its accepted four-field contract, then the retained1014 implementation slot. No release or operating action is selected.