Three changes pushed straight to 1.0.x on 12 September: what they were and why

Three changes went to 1.0.x on 12 September 2026 without passing through this queue first. All three are done and green; this issue exists so the queue has a record rather than only the git log, and so anyone reading the commits later has the reasoning in one place.

1. The README now says the two reading routes carry different engines

38cd7dc (README) — the reading route is site configuration, and ADR-0002 describes that choice on the process boundary: the extension parses untrusted assets inside the web process, the service keeps that outside it. That axis is unchanged. What was missing is that the routes also differ in which C2PA engine a site ends up running, and not symmetrically:

• The service route runs whatever the site last built — c2pa-rs 0.90.22 as of September 2026.
• The extension route runs whatever ericmann/ext-c2pa has tagged, still its first and only release, v0.1.0 (16 July 2026), on c2pa-rs 0.89.0.

So an engine fix reaches the service route through a rebuild and does not reach the extension route at all until that project tags again. That matters for this module specifically, because it reads files other people uploaded: one fix in that range (CAI-12751, c2pa-rs 0.90.17) closed a case where an ingredient assertion could suppress a validation failure in the active manifest — a wrong Valid on exactly the kind of asset a queue worker here inspects.

Deliberately not a recommendation to pick the service route. Which route a site runs stays the site's decision; this only gives it a third thing to weigh.

2. composer check no longer dies on a fresh clone

ceb2979 (composer.json) — analyse now pins --memory-limit=512M. On a cold checkout PHPStan indexes Drupal core, and PHP's default 128M kills a parallel worker, so the run ends like this rather than with findings:

configured PHP memory limit: 128M
Increase your memory limit in php.ini or run PHPStan with --memory-limit
  while running parallel worker
[ERROR] Found 1 error
Result is incomplete because of severe errors.

Only the first analysis in a checkout is affected, which is exactly the one a new contributor runs.

Worth recording because the obvious reproduction does not work: after the first failure it passed at 128M, passed at 64M, and passed after phpstan clear-result-cache. The result cache is not where the indexed symbol table lives — wiping the whole tmpDir reproduces it every time. This project's CI was never affected; the runners have the headroom, so it was a local-developer-only gate.

3. cspell knows one more name

b598f8f (.cspell.json) — the cspell job had been failing since change 1 above, on ericmann, the account behind ext-c2pa that the new README paragraph names. Added to the words list beside mglaman and nyholm, which are there for the same reason.

Note for anyone watching this project's pipelines: cspell and eslint are allow_failure: true in the template, so a failing one leaves the pipeline reporting success while showing a warning only in the GitLab UI. It hid a genuinely red job across two pushes. Read job statuses, not the pipeline status.

Verification

Pipeline 958149 on 1.0.x: all nine jobs success, including both allow_failure ones. Locally:

On the process

These should have been issues first. Direct pushes to a dev branch with no release are normal for a maintainer, but the queue is where a project's history is supposed to be legible from the outside — and this project is published, so "only I read it" is already not true. Filing after the fact is the correction, not the pattern.