ci(release): forward-merge 3.0.x → main silently drops all 3.0.x changes since allowlist landed

[bokelley]

Symptom

`main` is 465 commits behind `3.0.x`. Every push to `3.0.x` triggers `forward-merge-3.0.yml`, the run reports success, and `peter-evans/create-pull-request` logs `Branch 'forward-merge/3.0.x' no longer differs from base branch 'main'` — so no PR is opened, despite the obvious divergence.

Started showing this no-op behavior around 2026-05-08 15:05 UTC, immediately after PR #4264 landed (`ci(release): backport storyboard-schema.yaml forward-merge allowlist to 3.0.x`). Before that the workflow was failing loudly on conflicts; after it, the workflow auto-resolves everything and the merge commit ends up identical to `main`.

What's happening in the run

From run 25602530744 (push of `5d2e7be` HMAC fix to `3.0.x`, 2026-05-09 13:40):

```
CONFLICT (content): .github/workflows/training-agent-storyboards.yml
CONFLICT (content): package.json
CONFLICT (content): static/compliance/source/universal/runner-output-contract.yaml
CONFLICT (content): static/compliance/source/universal/storyboard-schema.yaml
CONFLICT (content): static/schemas/source/core/error.json
CONFLICT (content): static/schemas/source/enums/error-code.json
CONFLICT (content): static/schemas/source/protocol/get-adcp-capabilities-response.json
Automatic merge failed; fix conflicts and then commit the result.

Auto-resolved divergent metadata

```

Auto-resolution runs and the workflow exits success. But the resulting tree matches `main` HEAD exactly — meaning the non-conflicting changes from `3.0.x` (the actual docs/schemas/skills patches) are being dropped along with the conflicts.

Impact

• v3.0.5 through v3.0.9 patches are NOT in `main`. The 3.1.x line on `main` is missing every 3.0.x fix from the past week.
• Confirmed missing examples: HMAC RFC 9421 framing fix (feat(scripts): Stage 0.3 — insert-missing-rows phase (#4159) #4287), account-discovery MUST propagation (docs(accounts): propagate account discovery MUST to overview #4304), and ~30+ others.
• The 3.1.x line silently regresses against 3.0.x on every patch.

Hypothesis

The auto-resolution step likely does a `git reset --hard origin/main` (or equivalent) after determining all conflicts are in the allowlist, instead of only touching the conflicted paths. That would explain the all-or-nothing behavior — when there are any allowlist conflicts, the entire merge is reset to main, dropping non-conflict changes.

Repro

Push any commit to `3.0.x` that touches files in the allowlist (e.g., bumping `package.json`). Workflow reports success, no PR opens, `main` remains untouched.

Fix direction

Inspect the bash block in `.github/workflows/forward-merge-3.0.yml` that runs after `Automatic merge failed`. The allowlist resolution should:

1. `git checkout --ours ` (or `--theirs`) per allowlisted path only
2. `git add ` for those paths
3. `git commit` — preserving the rest of the merge
4. NOT touch the working tree globally

Backfill

Once the workflow is fixed, all queued 3.0.x patches (5/3 onward) will land in a single forward-merge PR — manageable as one review cycle.

Severity

P1.

[bokelley]

Triage

Classification: Bug
Bucket(s): infra / agents
Status: ready-for-human

Root cause (from workflow inspection): git checkout --ours -- "$f" takes the entire file from main whenever any conflict region is detected in an allowlisted file. The inline comment for storyboard-schema.yaml says this was safe because "3.0.x's clean-merged additions are above the conflict region and merge automatically" — but that guarantee has broken down as more 3.0.x patches accumulated in those same files. Every new conflict region (anywhere in the file) now causes --ours to wholesale overwrite 3.0.x's legitimate content, not just the divergent section. The allowlist entries for schema/compliance source files (error.json, runner-output-contract.yaml, storyboard-schema.yaml, get-adcp-capabilities-response.json) are the likely culprits — they carry real 3.0.x patch content that is being silently discarded.

My take: The allowlist is correct in scope but --ours-per-whole-file is too blunt once a file has accumulated multiple conflict regions. This is a .github/workflows/ change the routine cannot make. Two immediate actions needed: fix the per-file resolution strategy, then run a manual backfill merge.

@bokelley, two paths:

Option A — narrow the allowlist to metadata-only files (recommended):

# Remove content files from the --ours block; let them fail loud
# so real 3.0.x patches are caught and resolved manually.
# Keep only true metadata (package.json, CHANGELOG, dist/*, .changeset/*, index.json).
- .github/workflows/training-agent-storyboards.yml|static/compliance/.../runner-output-contract.yaml|static/compliance/.../storyboard-schema.yaml|static/schemas/.../core/error.json|static/schemas/.../protocol/get-adcp-capabilities-response.json)
-   git checkout --ours -- "$f"
+ # (remove these entries; workflow fails loud → human resolves)

Option B — surgical per-region resolution instead of whole-file checkout:

# For each content-file conflict: apply --ours only to the known
# divergent region (e.g. CANONICAL CHECK ENUM block at EOF),
# leaving 3.0.x's other changes intact.
git merge-file -q --ours -- "$f"  # or manual region-scoped patch

Backfill after fix: git checkout main && git merge origin/3.0.x --no-ff then resolve manually — expected to surface the real 3.0.x-vs-main content conflicts that have been silently eaten.

---

Triaged by Claude Code. Session: https://claude.ai/code/session_01UZLVg7UKQ6WAiB12qdywUy

---

Generated by Claude Code