The V2 pipeline is meant to advance only via its workflow_run chain
(03.1 -> 03.2 -> 03.3 -> 04.1), which [skip ci] does not affect. But 03.2 and
03.3 committed data/inventory.yaml WITHOUT [skip ci], so their bot pushes also
matched push: path triggers: 03.2 re-triggered itself (and 03.3 triggered it
backward) on data/inventory.yaml, and data/inventory.sql woke 05.1. That
redundant fan-out flooded the shared develop-git-write-lock group; with
cancel-in-progress: false GitHub keeps only one pending run per group, so
superseded runs were auto-cancelled (0 jobs, no logs) - e.g. run 29263339507.
Every other develop-pushing stage (03.1, 04.1, 05.1, 09) already carries
[skip ci]; this completes the pattern on the two stages that were missing it.
The workflow_run chain, schedule, and workflow_dispatch entry points are
unaffected.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Root cause of the recurring README-sync failure: 05.1 modified README.md in
earlier steps then ran `git pull`, which aborts on a dirty tree whenever a
concurrent bot commit advanced develop first. Rewrote its commit step as a
fetch → reset --hard → regenerate → commit → push retry loop (README is a pure
function of inventory, so a hard reset never loses data and eliminates the
merge-conflict / --ours/--theirs class entirely).
Also:
- 03.1/03.2/03.3: wrap the single-shot pull --rebase && push in a 5x retry loop.
- 07.1 PR Guardian: continue-on-error (advisory; keeps the comment, drops the
blocking red ❌ on AI false positives) + PR-scoped concurrency.
- 07.2 Markdown Linter: PR/branch-scoped concurrency with cancel-in-progress.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
