Repository navigation
Drop Laravel 10 and 11 from service-mode support in the next minor (upstream EOL, unfixed advisories) #239
Description
Laravel 10 and 11 are past upstream end of life. Published advisories affect those majors without a fixed release, so the coordinated next minor will remove them from service-mode framework support. The stable Laravel portal already carries the EOL warning and recommends Laravel 12/13; live/source verification confirms delivery. Its historical transition-version sentence will be corrected with the coordinated support handoff.
The accepted planning target is SDK 3.10.0 coordinated with Workflow 2.21.0. Earlier 3.9.0 wording is superseded. Existing 3.9.x applications retain the current supported contract; this issue does not authorize a breaking 3.x patch or infer a bare-SDK PHP interpreter drop.
Owner Workflow: complete Workflow #1020 and return the actual published embedded Laravel 12/13 support manifest and Release Verification authority. Owner sdk-php: once that handoff exists, update the service-mode adoption contract, framework CI matrix, transition fixture/authority, documentation and changelog together. Derive framework constraints and its PHP floor from the reviewed embedded contract; preserve stable-v1 scope. The proposed Laravel constraint is ^12.69.0|^13.30.0, subject to that actual published authority.
General owns the combined-minor source cohort/publication decision. The existing #185 published native child-all and installed-SDK acceptance gate remains separate. No version branch, tag, package release, portal override or runtime action is assigned by this issue. Keep it open until the coordinated support change and published/guide acceptance are delivered.
Activity
Disclose Laravel 10 and 11 end of life in 3.8.2
rmcdaniel commentedon Nov 4, 2026
Current product decision from General: this change targets SDK 3.10.0, coordinated with Workflow 2.21.0. The earlier 3.9.0 target in the issue body is superseded.
Blocked until Workflow 2.21.0 publishes the Laravel 12/13 embedded support contract. Then update the SDK service-mode contract, support matrix, CI, docs and changelog together, retaining the notice that Laravel 10/11 applications can stay on 3.9.x. The transition-authority check requires the SDK service contract to match the published Workflow embedded contract.
rmcdaniel commentedon Nov 4, 2026
Current coordinated target remains SDK 3.10.0 after Workflow 2.21.0; the original 3.9.0 body target is obsolete. Fresh readback finds Workflow 2.20.3 published, no 2.21.0, and existing Workflow #1020 owns the precise embedded-contract change. Its earlier 2.20.2 prerequisite is complete.
I asked the Workflow owner to take #1020 after current P1 work or return a specific scheduling decision to General. The request includes the exact published manifest/Release Verification handoff and explicit framework PHP-floor treatment.
sdk-php owns the service adoption contract, framework CI matrix, transition fixture/authority, docs/changelog and published minor follow-through once that authority exists. I audited the current contract and EOL notice; they still accurately retain 10/11 for the 3.9 line. No early contract divergence or support drop is made here. General owns the cross-package release order.
rmcdaniel commentedon Nov 5, 2026
Verified the existing stable EOL notice before proposing another documentation change. The live Laravel guide returns HTTP 200 and already states that Laravel 10/11 are past upstream EOL, some advisories have no fixed release on those majors, and applications should move to Laravel 12/13. The notice links this issue. This interim user-facing warning is delivered.
The guide source is byte-identical at published 3.9.4, accepted stable-doc source 6a82156, and accepted main f4bd280: SHA-256 ffe0fee1dd8c6f059be60ec2a4975ed149afc0cf10da04af8ba12889b331cdad. Live deployment audit remains exactly 6a82156, SHA-256 43c0159fc3ee9317a32e644e20d61d47d2fbf64d23194efe7b8e1f2b86514cd1. Live Laravel HTML is 34,286 bytes, SHA-256 c0ec4af1c91278dae3cca9e5df21eeb329d3a07dd96b789db87b52ccdaa6c155.
The surrounding transition sentence still names historical 3.8.x / Workflow 2.17.1 and “next SDK minor”. That sentence is not current release-cohort authority: the accepted target is now coordinated SDK 3.10 / Workflow 2.21, with 3.9.x retention. sdk-php will correct that historical wording with the actual contract/matrix handoff rather than add a duplicate EOL warning or infer a stable publication override. No documentation source or live site was changed by this verification.
Remaining owner/action: Workflow completes #1020 and returns the actual published 2.21 embedded support manifest plus verifier. sdk-php then updates the matching service contract, framework matrix, transition authority/fixture, guide/changelog together, deriving the PHP framework floor from that reviewed handoff. General retains combined-minor cohort/publication; #185's immutable published flat-child-all plus installed-SDK tuple remains a separate package gate. The bare SDK PHP floor is not changed by inference, and the issue remains open for the support transition.
rmcdaniel commentedon Nov 5, 2026
I reconciled the current dependency: Workflow #1020 remains open and no published 2.21 framework authority was returned. I asked its current owner for the actual Laravel 12/13 manifest, Release Verification handoff and explicit framework PHP-floor decision after current source priorities.
Workflow owns that authority; sdk-php then changes the matching service contract, CI, transition fixture and docs/changelog together. General retains the 3.10 cohort/publication decision. The delivered EOL warning and historical transition sentence are already distinguished above. The bare SDK PHP ^8.1 floor is preserved; no early support drop or duplicate warning is needed.
rmcdaniel commentedon Nov 5, 2026
The service-mode EOL warning is already live. The transition-version sentence is historical wording and remains recorded for the coordinated framework update. The bare SDK PHP ^8.1 floor stays separate from embedded framework support.
Published Workflow 2.20.4 still declares PHP ^8.1 / Laravel 10–13. Core #1043's actual installed 22/221/0 proof is complete and existing-tag notes are published; its old unexecuted-proposal wording no longer blocks this source slice.
Current producer action: Workflow has started isolated
workflow/1020-core-2.21-supporton currentcd8831d5. Its durable owner return owns the coherent PHP ^8.2 / Laravel 12–13 manifest, derived matrices, removed-support security policy, Composer refusal/authority controls and README/upgrade/changelog, preserving stable-v1. Ordinary source development needs no new per-PR General selection. Workflow #1047 is now normally merged as3d7d0a193d8fffe591f8286d1c4d5499120a297a; the published-authority gate is unchanged. Its resulting-main QA is a separate producer source acceptance, not Release Verification for a published2.21 tag. No 2.21 published manifest, tag or Release Verification exists yet.Next action / owners: Workflow completes that source change and normal qualification, then the separately authorized publication supplies the actual 2.21 manifest and Release Verification. sdk-php consumes that exact authority before changing its bridge contract, matrix and transition docs; General retains final coordinated minor/publication decisions. I drove the upstream follow-through by returning the cleared installed-proof prerequisite, obtaining the active source-owner response and recording it here. No early SDK support/floor change, duplicate runtime test, tag or release was started. Normal #311/#312 acceptance supplies no substitute for the published framework authority.
General separately selected SDK 3.10.0 source preparation on the existing PHP ^8.1 / Laravel 10–13 contract (#313); it does not consume the future 2.21 platform change early.
Docs #481 boundary: the published bare SDK retains PHP
^8.1. Its current service-mode Laravel bridge separately declares^10.50.4|^11.56.1|^12.69.0|^13.30.0, with each framework major imposing its own PHP floor. Once actual published Workflow2.21 authority/verifier is supplied, sdk-php derives the coordinated bridge matrix/transition docs from that reviewed handoff; no embedded source change silently raises the bare service-SDK floor. General retains this handoff before final combined3.10 freeze/tag. Current service-mode guidance and examples remain SDK-owned.rmcdaniel commentedon Nov 5, 2026
Docs #481 now has qualified draft #482, with all 11 contexts and eight-locale qualification. The support/install/upgrade preview keeps bare SDK PHP
^8.1independent, sends service bridge authority to the SDK-owned Laravel guide, preserves every service example and stable-v1 file, and makes no early SDK floor/matrix change. The old combined Laravel 9–13 destination guarantee is replaced by target-specific published requirements.Workflow #1020 has the exact request for the actual 2.21 package/manifest plus Release Verification; the docs draft stays unmerged/auto-off for its final support promotion. Your coordinated bridge adoption/transition guide remains separately owned here after that producer authority, with no SDK release, version selection or installed proof inferred from this docs preview. No additional SDK build/test/release action is requested.
rmcdaniel commentedon Nov 6, 2026
2026-11-06 owner reconciliation.
Fresh normal registry readback still gives Workflow 2.20.4, source
e3664430fd1b795aadaca89c835d5281502a01ce, PHP^8.1and Laravel^10.50.4|^11.56.1|^12.69.0|^13.30.0. Bare SDK 3.9.4, source11085f0c624674a4b70d3a6fb3e83eaff3869fcb, independently retains PHP^8.1. Workflow's newer support source is not published 2.21 authority. I read Workflow's current publication dependency and central297's accepted private-pip source / next profile adoption; neither supplies the missing published manifest/verifier handoff.Workflow owns narrow adoption of the applicable shared setup inputs, then the actual 2.21 package/manifest and original Release Verification. sdk-php owns the coordinated bridge contract, derived matrix/transition authority and stale transition sentence after that handoff. General owns the final combined-minor decision under #293. I returned this dependency to Workflow and retained the separate bare-SDK/framework support distinction. The accepted P0 redesign preserves published support and does not remove Laravel10/11 or raise PHP floors through presentation changes. The existing EOL warning remains delivered.
rmcdaniel commentedon Nov 6, 2026
I re-read Workflow #1020 and the current central297 acceptance. The matching Ubuntu24 initial setup tuple is now accepted, clearing the old raw-profile wait, but actual Workflow caller adoption plus published 2.21 support manifest and Release Verification are still outstanding. Current published Workflow remains 2.20.4.
The separately selected P0
3.9.xsource cut in #335 deliberately keeps published Laravel10/11/12/13 support and bare-SDK PHP^8.1 unchanged. General/Workflow own the actual 2.21 producer/verifier handoff and final combined-minor decision; sdk-php owns coordinated bridge constraints, framework matrix, transition authority and guides after that handoff. I preserved the existing EOL warning and this source/published distinction in the maintenance review. No support-floor change or release is selected by that patch source.rmcdaniel commentedon Nov 7, 2026
The actual normal-registry SDK3.9.5 manifest preserves PHP^8.1 and Laravel10/11/12/13 constraints; the maintenance release does not perform this coordinated EOL support change. I verified that support boundary in the installed release. Next owner/action remains General/Workflow's actual first-caller qualification and published2.21 support-manifest/Release Verification handoff under #293, then sdk-php owns the matching bridge constraints, matrix, transitions and guides. The accepted initial Ubuntu24 profile needs no repeat; it is not blanket caller adoption.
rmcdaniel commentedon Nov 7, 2026
I reconciled the newly accepted first-caller Source/policy wiring in central #297 with its still-unexecuted actual caller proposal. The latest actual Workflow release remains 2.20.4. Source wiring and the SDK P0 cohort do not select the coordinated Laravel support-floor change.
Next owner/action remains General/Workflow: actual first-caller terminal/cleanup and the published 2.21 support-manifest/Release Verification handoff under #293, then sdk-php changes bridge constraints, matrix, transitions and guides together. General has been asked. The installed 3.9.5 PHP/Laravel constraints and accepted raw Ubuntu24 profile are preserved.
rmcdaniel commentedon Nov 7, 2026
The first-caller status is now concrete: the consumed original is NONPASS before PHP or product requests. Workflow #1058’s system-Python correction is merged at
f3142313e42b004492ebf247b463d509a0a12940; that Source fix does not establish a qualified actual successor or published2.21 support metadata. The corresponding SDK #340 correction is Source/CI accepted and remains effect-held.I rechecked the actual Workflow release: it remains2.20.4. General still owns the qualified actual successor and published2.21 support-manifest/Release Verification handoff under #293; sdk-php then changes bridge constraints, matrix, transitions and guides together. The new initial native-consumer Source harness #348 does not change that support-floor authority. General has the concrete handoff, and installed3.9.5 PHP/Laravel constraints remain intact.
rmcdaniel commentedon Nov 7, 2026
The support-floor handoff now has a concrete second caller failure: corrected Workflow 42348212659/a1 under central297 passed system-Python/private-pip trust and then refused the pinned installer read with404 before PHP/product requests. This does not establish published2.21 support metadata or compatibility authority. The latest actual Workflow release remains2.20.4.
General has the specific immutable-installer-source/qualified-caller request and retains the published2.21 manifest/verifier handoff. SDK-PHP then changes bridge constraints, matrix, transitions and guides together under #293. Maintained harness349 supplies later installed controls, while315/340 remain effect-held. No support floor or published3.9.5 constraints changed.
rmcdaniel commentedon Nov 7, 2026
The caller prerequisite has advanced to the independently accepted actual corrected Workflow run, with terminal/custody reconciliation. The two earlier NONPASS originals retain their original scope. Actual latest Workflow is now 2.20.5, target
b8f6bcdb951602b22259274b13b2261fdebff542; I verified its primary published release record.The missing input for this support-floor change remains the published2.21 support manifest and normal verifier, owned by General under #293. That specific handoff is already requested. SDK-PHP then updates bridge constraints, the framework matrix, transitions and guides together and performs the actual installed controls. The 2.20.5 repair, held SDK #340's prepared preview packet and caller acceptance do not establish that future support floor. Published SDK3.9.5 constraints remain unchanged.
rmcdaniel commentedon Nov 7, 2026
The producer has advanced beyond maintained Source: immutable Workflow tag 2.21.0 now names
cb9420019476d400e1df329f063cfb1a3b86ab18, under ordinary release decision1020/6705581536. I independently read that tag and actual verifier42363788484/a1: terminal SUCCESS, with the normal published-package job and all five Laravel12/13 PHP8.2–8.4 upgrade jobs successful. General is finishing the GitHub Release and immutable installed-manifest/hash handoff; no duplicate upstream preparation is needed.I read the two machine-owned authority files at that exact tag. Embedded-v2 authority is PHP^8.2 / Laravel^12.69.0|^13.30.0, with exactly five cells. Stable-v1 authority remains PHP^8.1 / Laravel9–13. The SDK consumer mapping is therefore the adoption contract, five-cell framework matrix, actual transition fixture/authority, guide/version wording and changelog together, preserving the bare SDK HTTP PHP^8.1 requirement. No support contract is inferred from a mock or an unpublished main. General retains the precise published manifest/verifier handoff and combined #293 freeze; SDK-PHP owns this next consumer Source increment once that primary handoff is complete. No tag, dispatch, runtime or publication is selected by this readback.
rmcdaniel commentedon Nov 7, 2026
Workflow 2.21.0 is published at immutable tag/source
cb9420019476d400e1df329f063cfb1a3b86ab18, tree9bbfc171b8b6c1de71c2854df938e24643e0c421. GitHub Release437504748 was published November7 at10:34:48 UTC; fresh Packagist metadata has exactly one2.21.0 entry with both source and dist bound to that commit.Release Verification42363788484/a1 completed successfully at10:25:56 UTC: all6 jobs, including the actual installed package and all5 supported Laravel12/13 upgrade/queue-worker cells. The captured canonical terminal has pass/complete/product success and setup, private-pip and independent Composer cleanup pass. Initial raw job log is240,943 bytes / SHA-256
0fd10950a676eb04a1c25264f5f4e368e560373b8909bebf4ac7df592a1bce79. The accepted helper remains ed150 and pip predecessor242c; no new raw profile experiment or retry occurred.The published support authority is embedded PHP
^8.2, Laravel^12.69.0|^13.30.0; cells are Laravel12/PHP8.2,8.3,8.4 and Laravel13/PHP8.3,8.4. Stable-v1 authority remains PHP^8.1and Laravel9–13. Laravel10/11 applications keep Workflow2.20.x while upgrading their platform. This release does not change SDK3.9.x support.Immutable package files:
composer.jsonaffc46a3b4cf18cfd811d9280cd6283eafafcdeb750b2d0b7a7c6bae4e6db2d2resources/laravel-embedded-upgrade-contract.json1e65a6ffa6f2a1feba53ff0b5f7782a9ac8d7a3560f31c44c040767c592308c6resources/laravel-dependency-security-policy.json1a13ddbfd25182338214ba9c79a930ed8dcf27cc25e6e5d49f7f62043f218221src/V2/Support/PlatformConformanceSuite.phpa4ddbdfecd24e873cb00f95c2c56f16f6194009c4bbf38f81e421e200ebe092dGeneral returns this actual published manifest/verifier handoff to SDK #239. SDK-PHP may implement the coordinated service contract, framework matrix, transition authority/fixtures, guides and changelog together on an isolated topic from accepted SDK main bf40. Derive the framework PHP floor from this immutable contract; preserve stable-v1 scope and bare SDK PHP
^8.1. Normal Source checks and independent review remain required. Keep SDK main/tag writes held until the separately owned #315 and #293 dispositions; this handoff selects Source preparation only, no SDK tag, installed runtime or publication.Workflow durable-workflow/workflow#1020 is delivered at its repository boundary; SDK #239/#293 retain the coordinated SDK release and installed follow-through. General retains the final cohort/freeze decision, and Server retains canonical qualification of its actual published3.2 index. No PHP Server release or Cloud deployment is selected.
rmcdaniel commentedon Nov 7, 2026
SECURITY RELEASE-HANDOFF PASS — Workflow 2.21.0 authority only
The independent Workflow 2.21.0 final release/authority audit is complete at workflow#1020 / 6705915081.
Accepted handoff identity is current tag
2.21.0→ commitcb9420019476d400e1df329f063cfb1a3b86ab18, tree9bbfc171b8b6c1de71c2854df938e24643e0c421; Packagist source/dist bind that commit, and tag-triggered run42363788484/a1has exactly six successful jobs with canonical terminal and setup/private-pip/Composer cleanup PASS.SDK #239 may use the published embedded authority PHP
^8.2/ Laravel^12.69.0|^13.30.0for Source preparation. Stable-v1 authority and bare SDK PHP^8.1remain unchanged. This handoff does not accept SDK Source not yet reviewed, any SDK tag/publication, installed Native/runtime behavior, or a Server/Cloud effect; those gates remain separate.rmcdaniel commentedon Nov 7, 2026
The published Workflow 2.21.0 authority is now carried by draft PR350, current
dcea0b59f976944b30d59dd0c6e6693fad70e406/ tree155349f053ef657167c0daad00c4b447a1a71e89, based on held mainbf40f8c. Contract, five Laravel/PHP cells, transition requirement, current guides and early optional-provider admission move together. Bare SDK PHP^8.1and stable-v1 authority remain unchanged. The published 3.9.1 example lock remains authentic and unchanged; #293 retains its later registry update.The exact predecessor CI failures and local static-config correction are recorded on the PR. Fresh current-head hosted qualification is active; all five real Laravel consumers have now passed. Independent Security Source review is requested. SDK-PHP owns completing that source qualification; General owns the separate main/tag/cohort disposition. This issue stays open for coordinated publication and installed/guide acceptance.
rmcdaniel commentedon Nov 7, 2026
PR350 Source qualification is complete at
dcea0b59f976944b30d59dd0c6e6693fad70e406/ tree155349f053ef657167c0daad00c4b447a1a71e89: all 35 exact-head checks are terminal, 34 success / one intended skip, and independent Source PASS is durable. Hosted PHP8.3 passes 8,529 tests / 86,193 assertions / 56 skips, including the coherent new optional-provider admission. Earlier Source failures remain attributed.SDK-PHP owns the qualified topic and the later installed consumer tail. General retains the main/tag hold and distinct automatic-preview/cohort disposition. Main remains bf40; PR350 stays draft/auto-off. The separately requested prior-live rollback build-only preparation is 315/6706441402, under finite review with no dispatch selected. No SDK publication, Pages write, installed/runtime or P0 acceptance is inferred.
rmcdaniel commentedon Nov 7, 2026
The coordinated Laravel support change is now integrated on accepted main
6ec471d2c3b6223909b1cefbe5134caa0e60067e, exact tree155349f053ef657167c0daad00c4b447a1a71e89, through normal merge of #350. Source/main PASS, automatic preview terminal/artifact/nondeployment PASS, and exact owned-topic cleanup are complete. Main's 35 contexts finished 33 SUCCESS / two intended SKIP. Live published SDK3.9.5 documentation remained byte-identical. The prior draft/main hold and unselected rollback preparation mentioned above are historical; #315's actual stable publication is now accepted and closed.Source now binds the published Workflow2.21 authority, coherent Laravel12/13 matrix and guides, fail-closed optional-provider admission, and unchanged bare SDK PHP^8.1 and stable-v1 support. The authentic example still pins its existing published SDK and will only advance through a normal registry update after publication. SDK-PHP retains that installed/example follow-through. General owns exact SDK3.10 freeze/publication and tuple admission under #293; Server owns the remaining producer qualification. The issue remains open for that released, installed outcome. The separate changelog-only #351 now restores authentic 3.9.5 history and P0 Unreleased notes without assigning a new version/date.
rmcdaniel commentedon Nov 7, 2026
Recheck 2026-11-07 19:40 UTC: SDK side is integrated on main (#350, release notes #351/#352). Remaining is the 3.10.0 publication itself.
Next owner / action: General (freeze/publication, #293 status); sdk-php then verifies the installed support floor.
rmcdaniel commentedon Nov 7, 2026
Workflow 2.21.1 archive change (workflow#1064) — SDK impact check: none found. Source/metadata only, against SDK main
69d0e408and Workflow candidate81cdafcc.81cdafccis one commit ahead of tag2.21.0and changes only.gitattributes(/tests export-ignore),CHANGELOG.mdandextra.durable-workflow.product-train(2.21.0 → 2.21.1). Production autoload is stillsrc/plus twosrc/files;tests/was only inautoload-dev.What the SDK reads from the Workflow package:
durable-workflow/workflow, and the dependency-boundary policy forbids it.scripts/ci/check-laravel-transition-authority.php, used by the Laravel service smoke againstvendor/durable-workflow/workflow): it reads onlyresources/laravel-embedded-upgrade-contract.json. That blob is identical in2.21.0and81cdafcc(a7679c96). It compares contractschemaandversion: 1, not the product version. The SDK contract channel^2.21admits 2.21.1.docker-compose.child-policy.yml): mounts agit cloneof an exact Workflow commit, not a Composer dist archive.export-ignoredoes not apply.vendor/durable-workflow/workflow/other than the manifest above. TheTests\Fixtures\V2\…names in replay-regression fixtures are recorded activity/workflow type strings, not classes loaded from the Workflow package.Not covered here: images that install Workflow themselves (for example the PHP Server image) belong to their owners. No locks were changed, and the accepted 2.21.0 tag/manifest authority stays as is until General hands off a published 2.21.1 tuple. No acquisition, install or runtime was used.
rmcdaniel commentedon Nov 8, 2026
#239 installed Laravel 12/13 support-floor packet: graphs, trust and acquisition frozen for review. No Composer request, install or runtime has been made. The installed-tail map is at #293/6714781557.
Authority
docs/laravel-adoption-contract.jsonat3.10.0(676e3309…, 5,026 B) setslaravel/framework^12.69.0|^13.30.0and PHP^8.2.durable-workflow/workflowchannel^2.21, manifestresources/laravel-embedded-upgrade-contract.json, schema version 1.36961d60921dd7190890a505d9364f1f712a8d63.a7679c96(4,067 B), unchanged from 2.21.0.laravel/framework ^12.69.0|^13.30.0, PHP^8.2, andextra.durable-workflow.product-train2.21.1.Frozen consumer graphs (smallest set, PHP 8.4.27)
composer.json{"require":{"durable-workflow/sdk":"3.10.0","durable-workflow/workflow":"2.21.1","laravel/framework":"12.69.0"},"config":{"allow-plugins":false,"audit":{"block-insecure":true}}}96eb3fe0a5f747590effd66d581ff7f96425dc72b3b572b49e796041e736d5e7"laravel/framework":"13.30.0"ffcd35626bd1d9dd7872cb0bd538fe6ffe4a704f51ca4976f8a238262ddf200349c9e0fcand runner80a91784), and record the 8.2/8.3 cells as source-CI evidence (Align next-minor Laravel bridge with published Workflow 2.21 #350's matrix). That is your decision.Checks (files from Git blobs at
3.10.0, run against each installed graph, network none)scripts/ci/assert-installed-version.php(4213d990)<project> <pkg> <x.y.z>durable-workflow/sdk3.10.0 anddurable-workflow/workflow2.21.1 exactly;laravel/framework12.69.0 / 13.30.0 exactly, including the framework's ownApplication::VERSIONscripts/ci/check-laravel-transition-authority.php(74ec1489)<installed vendor/durable-workflow/sdk/docs/laravel-adoption-contract.json> <vendor/durable-workflow/workflow>^2.21tests/compat/laravel.php(81407f67, withhistory-cache.php859b7125andexecution-telemetry.php0e4e64a1)<vendor/autoload.php>Acquisition (one future effect selection, two graphs)
The phase B recipe on two new owned roots:
7a2d379d, CA bundle50f79f98, trust verifierd7eea290and installer49c9e0fc;Each root runs
verify.php,composer update --no-dev --no-plugins --no-scripts --prefer-dist,verify.phpagain,composer audit --locked --no-devandcomposer validate --strict. Then, read-only:4e6c6b7b);c562d378;36961d60);installed.jsondev:false;Gaps that need source work (not selected)
tests/LaravelPlatformTest.phpcovers it. A small installed check callingLaravelPlatformadmission with a reported framework version would close it.scripts/ci/laravel-service-transition-smoke.shinstalls the SDK from a path repository as2.0.x-dev(:358-370), so it is not installed evidence unchanged.examples/laravel-http/composer.json:8still pins SDK 3.9.1. It advances through a normal registry update now that 3.10.0 is published.Risks to settle at review
Advisory blocking: if 12.69.0 or 13.30.0 now carries an advisory, the floor solve is refused, which is evidence that the contract's floor needs revising (an owner decision), not an ignore.
rmcdaniel commentedon Nov 8, 2026
#239 addendum: PHP coverage inventory and the smallest subjects for the remaining combinations. Preparation only; no graph install, pull or runtime. This follows your direction: the cached PHP 8.4.27 runs first, and 8.4 alone doesn't close 8.2/8.3.
Installed acceptance binds registry artifacts only
The installed graphs above use only Packagist dist archives:
3.10.0, zip, reference4e6c6b7b…, URLapi.github.com/…/zipball/4e6c6b7b…, with an inventory equal toc562d378;2.21.1at tag36961d60…;repositoriesentry, nopathdistribution, no@dev.scripts/ci/laravel-service-transition-smoke.sh(path repo,2.0.x-dev) and CI'sframework-compatpath installs (composer config repositories.sdk path …,durable-workflow/sdk:@dev,.github/workflows/ci.yml≈ :360) are excluded from installed acceptance.Existing evidence inventory (all source or hosted, none installed-published)
ci.ymlframework-compat"Laravel 12" php 8.2, withassert-installed-versionon the exact floor@dev, hostedsetup-php, unpinned runnerlaravel/laravel ^13fresh create-projectservice-mode-published-smoke.yml(workflow_dispatch, exact Packagist version)Installed-published coverage is currently none for every Laravel cell. The two PHP 8.4.27 graphs in the packet above (L12
96eb3fe0, L13ffcd3562) would close 12.69.0/8.4 and 13.30.0/8.4.Remaining combinations: 12.69.0 on 8.2, 12.69.0 on 8.3, 13.30.0 on 8.3
Each needs its own lock resolved for that interpreter (a lock resolved on 8.4 may select Symfony 8.x, which requires PHP ≥ 8.4) and execution on the real interpreter. Composer needs
unziporext-zipto install dists; the officialphp:*-cliimages have neither.Smallest pinned subjects (acquisition, phase-A style, digests resolved and recorded at selection):
docker.io/library/php:8.2.<latest patch>-cliandphp:8.3.<latest patch>-cli, recording index, amd64 manifest and config digests.Resolution: two options, your decision.
49c9e0fc, PHP 8.4.27) with a declaredconfig.platform.phpequal to the target image's exact patch, written into that graph'scomposer.jsonand hashed.composer check-platform-reqs --lockand the three checks run on the actual pinned 8.2/8.3 image (network none). That needs no zip, because vendor is already installed.--ignore-platform-req*is not used.ext-zip(libzip) to each pinned base. That is a Debian package acquisition per image. Composer then resolves natively on 8.2/8.3.Graphs: three
composer.jsonfiles, built like L12/L13 (exact floor pins, plugins off,block-insecure). Under option (a) each adds onlyconfig.platform.php.Checks per cell:
assert-installed-version(SDK 3.10.0, Workflow 2.21.1, the exact Laravel floor includingApplication::VERSION),check-laravel-transition-authority, andtests/compat/laravel.php, all from3.10.0blobs.Rules applied
block-insecurerefuses an exact floor, the refusal is preserved as the result. I would then propose the lowest fixed patch inside the accepted range (^12.69.0/^13.30.0) as a reviewed floor change, never an audit ignore, platform bypass or silent change.tests/LaravelPlatformTest.php(PHPUnit, source) covers it. An installed refusal control would be a small new check calling the installedLaravelPlatformadmission with a reported framework version. Bare-SDK use on any framework is a different contract and is not affected.rmcdaniel commentedon Nov 8, 2026
#239 PHP 8.2/8.3 packet: option (a) as selected (preparation only; no acquisition, install or runtime until this packet is reviewed and selected).
Two stages, each separately selectable
Stage 1: pinned image acquisition, phase-A style.
docker.io/library/php:8.2-cliandphp:8.3-cliby tag at acquisition time. Record the index digest, the amd64 manifest digest, the config digest and the image's ownPHP_VERSIONenvironment value. No other pull.8.2.N/8.3.M) is read from the image config, not assumed.Stage 2: three installed graphs plus checks on the real interpreters.
{"require":{"durable-workflow/sdk":"3.10.0","durable-workflow/workflow":"2.21.1","laravel/framework":"12.69.0"},"config":{"allow-plugins":false,"audit":{"block-insecure":true},"platform":{"php":"<8.2.N>"}}}"platform":{"php":"<8.3.M>"}"laravel/framework":"13.30.0"49c9e0fc, PHP 8.4.27) with the reviewed phase B tools (Composer 2.10.37a2d379d, CA50f79f98, verifierd7eea290), Packagist and GitHub egress only. The steps areverify.php,composer update --no-dev --no-plugins --no-scripts --prefer-dist,verify.phpagain,composer audit --locked --no-devandcomposer validate --strict.config.platform.phpis: a declared resolution target, recorded in the hashedcomposer.json. It is not an ignore: no--ignore-platform-req*, no audit ignore, noallow-plugins.php composer.phar check-platform-reqs --lock --no-dev. Any unmet requirement on the real 8.2/8.3 interpreter is a non-pass.scripts/ci/assert-installed-version.phpfor SDK 3.10.0, Workflow 2.21.1 and the exact Laravel floor, includingApplication::VERSION.scripts/ci/check-laravel-transition-authority.php <installed SDK contract> <vendor/durable-workflow/workflow>.tests/compat/laravel.php <vendor/autoload.php>, with all check files from3.10.0blobs.4e6c6b7bwith an installed inventory equal toc562d378; the Workflow lock row is 2.21.1 at36961d60; no path or@dev.The 8.4 graphs (already frozen)
L12
96eb3fe0…and L13ffcd3562…from 6714975943 need no platform setting and no new image. They can run under a stage 2 selection before stage 1.Rules (unchanged)
^12.69.0/^13.30.0is proposed for review.Bounds (proposed)
rmcdaniel commentedon Nov 8, 2026
The executable PHP 8.4.27 graph-install packet (profiles
239-l12,239-l13, plus307) is posted on #307 and covers this issue's two 8.4 graphs: controllerad0abca2…, held trust and controls, lock, published-Workflow-row and installed-identity assertions, and the offline checks (assert-installed-version, transition authority,tests/compat/laravel.php). See #307 (latest comment). No Composer request has been made. PHP 8.2/8.3 stays option (a), with its image acquisition reviewed separately.rmcdaniel commentedon Nov 8, 2026
Graph-install controller successor for the 239 profiles: 307/6716070712.
run-graph-install-b.sh8c7b4562…c1b6now binds Workflow 2.21.1: source and dist ref36961d60, the exactapi.github.com/repos/durable-workflow/workflow/zipball/<ref>URL, the matching installed row, and the cached dist ZIP 2,849,637 B /c07f9882…1a85at its URL cache path. It adds 9 causal controls. No Composer request is selected.