[gplanchat]

Four factual fixes in the user docs, one commit per ticket. No heading changes, so no anchor moves; code blocks are untouched.

#836: store counts for the SQL bridges

I counted against src/Bridge/Dbal/Store/ and src/Bridge/Illuminate/Store/. Both bridges persist the same four stores as the in-memory core (InMemoryEventStore, InMemoryWorkflowMetadataStore, InMemoryChildWorkflowParentLinkStore, InMemoryWorkflowRunCatalog): the event journal, the workflow metadata, the child-to-parent links and the run catalog. The run catalog is a store in the page's sense: it has its own table, durable_workflow_runs. The difference between the bridges is only how many classes cover it:

• DBAL: DbalWorkflowRunProjection writes the table, DbalWorkflowRunCatalog reads it (wired together in DbalStores::registerDbalRunCatalog()).
• Illuminate: IlluminateWorkflowRunCatalog does both.

The pages now say four for both bridges, name the four stores, and say which classes share the run catalog. On the backends page, the DBAL intro sentence listed three stores too, so I fixed it along with the "three process-local stores" bullet.

I also fixed a count the ticket does not name, in the same Illuminate section: "The four tables ship as a migration". 0001_01_01_000000_create_durable_tables.php creates five tables. The fifth is durable_execution_heads, which the event store writes for the pass epoch (DUR053), and the package ships several migration files.

#837: change points on the French deploying page

The paragraph after the renaming example now says what the English page says: renaming fits a change too large to express as a branch. The sentences calling renaming "the only way" and change points "separate work" are gone. The footer cites DUR044 next to DUR042, translated from the English footer.

#838: gplanchat/durable-laravel

Neither statement had been fixed on main. #913 does not touch the page. #847 fixes both, but it is still open and already conflicts with main on this page (mergeable: CONFLICTING). So I fixed them here against main's code:

• The registration sentence names the three values of DurableServiceProvider::BACKENDS: illuminate, memory, temporal. The wording and the line breaks match feat(laravel)!: suggest the Illuminate bridge instead of requiring it (#845) #847's exactly, so those lines merge cleanly.
• I replaced "Until it is tagged" with the current install path. src/DurableLaravel/ is in v0.1.0-beta1, bin/splitsh-publish.sh publishes it as durable-laravel, and Packagist serves it. On main its composer.json requires the library and the Illuminate bridge, so the paragraph says it pulls in both. feat(laravel)!: suggest the Illuminate bridge instead of requiring it (#845) #847 makes the bridge a suggestion. Whichever PR merges second has to reconcile this paragraph.

#839: Nexus handlers in "Choosing"

I checked the Temporal PHP SDK before choosing which side to fix:

• The latest release is v2.19, published 2026-09-16. Its release notes do not mention Nexus.
• gh api repos/temporalio/sdk-php/compare/v2.18...v2.19 contains 7 commits. The only patches mentioning Nexus are src/Client/GRPC/CloudClient.php and CloudClientInterface.php, from the Cloud Operations API client (feat: add Cloud Operations API client temporalio/sdk-php#797). That is endpoint management, not a handler API. master adds nothing about Nexus after v2.19.
• The Nexus integration, feat: add Nexus integration temporalio/sdk-php#768 ("feat: add Nexus integration"), is still open. Issue ci(magento-boot): open a run whose execution id holds a slash (#514) #580 is still open too.

The SDK cannot serve a Nexus operation, so section 8 stays as it is. In "Choosing", the Nexus handler no longer counts as a reason to pick the SDK, and the Durable paragraph says "call or serve", matching section 8. Both changes are on the English and the French pages.

Checks

• hugo --minify --gc -d _site from hugo-docs/ builds. I checked every internal link and anchor in the output: none are broken on this branch, and none are broken on origin/main.

Three more fact fixes

I checked each fact in the code on origin/main before rewriting.

• Illuminate migrations (packages page). The provider publishes the whole src/Bridge/Illuminate/Migrations/ directory (DurableIlluminateServiceProvider::boot()), five files, not one. The paragraph now says the command copies five files and asks to keep the files' names. Renaming a file makes Laravel run both the package's file and the copy, and only 0001_01_01_000000_create_durable_tables.php fails then: its Schema::create calls have no guard. The four later migrations check hasColumn, hasIndex or hasTable first and return.
• DBAL migration (packages page). The bridge ships no migration. DurableSchema::ensure() creates the tables on the first write (auto_setup defaults to true in Configuration.php), and bin/console durable:setup creates them up front. The sentence now says so and links to the DBAL section of the backends page, in line with that page and with src/Bridge/Dbal/README.md.
• DBAL table count (backends page, "How it works"). The bullet maps the four stores to four tables, but DurableSchema creates five: the fifth is durable_execution_heads, which DbalEventStore uses for the pass epoch (DUR053). The bullet now names it.

hugo --minify --gc builds; the two new links resolve to #dbal-backend and #le-backend-dbal.

Closes #836, closes #837, closes #838, closes #839.

[gplanchat]

Approve at 421be64

Facts

I checked every changed statement against origin/main (aab2023).

#836, four stores per SQL bridge. True. src/Bridge/Dbal/Store/ holds the event store, the metadata store, the child-to-parent link store, plus DbalWorkflowRunProjection (writes) and DbalWorkflowRunCatalog (reads), both on durable_workflow_runs. src/Bridge/Illuminate/Store/ holds four classes, IlluminateWorkflowRunCatalog covering the run catalog alone.

#836, five Illuminate tables. True. src/Bridge/Illuminate/Migrations/0001_01_01_000000_create_durable_tables.php creates durable_events, durable_workflow_metadata, durable_workflow_runs, durable_child_workflow_parent_link and durable_execution_heads. IlluminateEventStore writes the heads table (lines 58 to 67: insert-or-ignore, then increment the epoch), so "the event journal also writes durable_execution_heads" matches the code. The directory ships five migration files: the one above, three that alter durable_workflow_runs, and 2026_09_28_000000_create_durable_execution_heads.php, guarded by Schema::hasTable. "Ship as migrations", in the plural, is right.

#837. The French paragraph after the renaming example now says what the English one says (lines 137 to 139 of the English page), and the footer cites DUR042 and DUR044 with the same two reasons. documentation/adr/DUR044-declared-change-points.md exists. The French page already documents change points in "Ou déclarer un point de changement", so the old "seule façon" sentence was indeed wrong.

#838. DurableServiceProvider::BACKENDS is ['illuminate', 'memory', 'temporal'] (line 89), and the error message implodes that constant, so it names all three. The EN and FR registration lines are identical, character for character, to #847's (head bc06c46), line breaks included. The install-path sentence is true on main: src/DurableLaravel/composer.json requires gplanchat/durable and gplanchat/durable-bridge-illuminate, SPLITS publishes src/DurableLaravel/ as durable-laravel, the tree is in v0.1.0-beta1, and Packagist serves v0.1.0-beta1 down to v0.1.0-alpha8. #847 rewrites that same paragraph; the PR body says so, and whichever merges second reconciles it.

#839. The latest temporalio/sdk-php release is v2.19 (2026-09-16); its notes contain no occurrence of "Nexus". No path containing "nexus" exists in the v2.19 tree or in master. temporalio/sdk-php#768 ("feat: add Nexus integration") and #580 are both open. The SDK cannot serve a Nexus operation, so dropping the handler from "Use the Temporal PHP SDK" and writing "call or serve" for Durable is correct, and it matches section 8. No other sentence on either comparison page sends a Nexus handler to the SDK.

The two inconsistencies left for later

I checked both against the code, without deciding what the fix should be.

1. Illuminate, "Keep the published file's name" / "both migrations run". DurableIlluminateServiceProvider publishes the whole Migrations/ directory, five files, so "file" in the singular is inaccurate. The failure described ("the second fails on a table that already exists") holds only for 0001_01_01_000000_create_durable_tables.php, which calls Schema::create without a guard. The four later files check hasColumn, hasIndex or hasTable first; a renamed copy of one of them runs twice without failing.
2. DBAL, "one migration" (packages page, line 160 EN, 170 FR) versus "created on first write, no migration" (backends page). The backends page is the true one. The DBAL bridge ships no migration file. DurableSchema::ensure() creates the missing tables on first write (auto_setup defaults to true), durable:setup creates them up front, and src/Bridge/Dbal/README.md says "there is no migration to run and no doctrine/migrations dependency".

Tests and build

The diff touches only Markdown under documentation/user/, so I did not run the PHP suites. hugo --minify --gc -d _site builds from hugo-docs/ at the head. I checked all 6,015 internal links and anchors in the output: none is broken. Code blocks are unchanged, and no heading changed.

Mechanics

Four commits, one per ticket, the largest at 68 changed lines. origin/main is an ancestor of the head, so the trial merge has nothing to do and no conflict. No em dash, no supervised path, no trailer.

Non-blocking notes

• The DBAL "How it works" bullet says the four stores become SQL tables. The DBAL schema also creates durable_execution_heads (src/Bridge/Dbal/Schema/DurableSchema.php, line 264), as the Illuminate one does. A reader comparing it with "the five tables" on the packages page may wonder why DBAL has one fewer. The sentence stays true as written (stores to tables); a later pass could name the fifth table there too.
• The comparison pages pin every claim to v2.18. The Nexus statement still holds on v2.19, so no change is needed in this PR; moving the whole page to v2.19 is a separate change.
• Two added prose lines exceed the 100-column wrap, links aside: the English registration line (106), kept as is to match feat(laravel)!: suggest the Illuminate bridge instead of requiring it (#845) #847, and the French "Cela coûte deux classes" line (101). Neither affects the rendering.

[gplanchat]

Hold: two more fact corrections go into this PR (Illuminate migrations wording, DBAL "one migration" on the packages page). The approval at 421be64 is stale once they land; draft until re-reviewed.

[gplanchat]

Approve at a699d9d

I reviewed the delta 421be64..a699d9d (one commit, four files, EN and FR), checking each claim against origin/main at f057864.

Facts

Illuminate packages paragraph (EN and FR).

• DurableIlluminateServiceProvider::boot() calls loadMigrationsFrom() and publishes([__DIR__ . '/Migrations' => databasePath('migrations')], 'durable-migrations'): the whole directory, which holds five files.
• 0001_01_01_000000_create_durable_tables.php calls Schema::create five times with no guard, so a second run stops on an existing table.
• The other four return early: hasColumn (picked_up_at, waiting_on), hasIndex (status, started_at), hasTable (durable_execution_heads). In add_picked_up_at, the guard returns before the backfill update, so "change nothing the second time" holds there too.

DBAL packages paragraph (EN and FR).

• src/Bridge/Dbal/ contains no migration.
• DurableSchema::ensure() creates the missing tables on the first write; $autoSetup defaults to true, and Configuration.php declares auto_setup with defaultTrue().
• SetupCommand (durable:setup) calls setup(), which creates them whatever auto_setup says.
• ../backends/#dbal-backend and ../backends/#le-backend-dbal resolve: the built pages carry id="dbal-backend" and id="le-backend-dbal", and the links render as href="../backends/#..." from /docs/packages/ and /fr/docs/packages/.

Backends DBAL "How it works" (EN and FR).

• DurableSchema::create() lists five tables, including durable_execution_heads. DbalEventStore reads and writes it through $this->schema->headsTable(), and the headsTable() docblock cites DUR053.

Mechanics

• hugo --minify --gc builds cleanly (67 EN pages, 62 FR pages, only Hugo deprecation warnings). I deleted the output afterwards.
• No stale "one migration" / "une migration" claim about DBAL remains under documentation/user/.
• Docs only: no test, baseline or supervised path touched; 28 insertions and 12 deletions.
• Voice: present tense, active voice, no intent lent to the software, no em dash.

Non-blocking notes

• documentation/user/backends/_index.fr.md line 289 is 153 characters long; the EN side wraps the same sentence. Rewrapping it would match the rest of the paragraph.
• Outside this delta: DurableSchema::configureSchema() declares four tables and leaves out durable_execution_heads, while create() handles five. If the Doctrine tooling treats that table as an orphan, doctrine:migrations:diff may propose dropping it. This belongs in its own ticket, not in this PR.

[gplanchat]

Hold lifted: the approval at a699d9d covers the current head, and the PR is out of draft.