chore(deps): merge main into Dev_new_gui to unblock the release sync (#13654)

[mrveiss]

Important

Merge this with a merge commit, not squash. The whole point is to make main an ancestor of Dev_new_gui. Squashing discards the second parent, and Sync Dev_new_gui → main will refuse exactly as it does today.

Thinking Path

Sync Dev_new_gui → main failed on dispatch:

::error::main has 4 commit(s) not in Dev_new_gui. Resolve divergence manually first.

main is 194 commits behind and 4 ahead. The four are dependabot merges #13515, #13523, #13524 plus a merge commit. Dependabot opens against the repository default branch — main — while every other PR targets Dev_new_gui, so dependency updates land where nobody develops and the sync jams.

My first read was that main's bumps were entirely superseded, because Dev_new_gui leads on all 28 differing direct dependencies in autobot-frontend/package.json and autobot-slm-frontend/package.json, and on autobot-slm-backend/requirements.txt (fastapi>=0.141.1 vs 0.140.1).

That was wrong, and worth stating plainly: the dependabot security bumps were in transitive lock entries, not direct dependencies. Comparing package-lock.json rather than package.json showed main genuinely ahead on four packages, plus cryptography.

What Changed

A real merge of origin/main into Dev_new_gui. Conflicts in autobot-frontend/package.json, autobot-frontend/package-lock.json, requirements-ci/security.txt, all resolved to Dev_new_gui's side, then main's genuine upgrades applied on top:

Package	Dev_new_gui	main	Result
cryptography	49.0.0	50.0.0	50.0.0
fast-uri	3.1.4	3.1.5	3.1.5
hono	4.12.31	4.13.0	4.13.0
undici	8.9.0	8.10.0	8.10.0
nanoid	3.3.16	3.3.17	3.3.17

nanoid is the one that needed care: it lives in autobot-frontend/package-lock.json, which I had resolved with --ours. That silently discarded the bump. It is restored here by copying main's version/resolved/integrity triple.

Dev_new_gui's PyJWT[crypto]>=2.8.0 line from #13411 is preserved — main does not have it.

Verification

The decisive check, across every package-lock.json in the repository:

packages where the merged tree is BEHIND main: 0

Merge commit has two parents, so main becomes an ancestor:

$ git log -1 --format="%p" | wc -w
2

Direct-dependency comparison that produced the initial (incorrect) read, kept here because it is still true and still relevant — Dev_new_gui leads on all 28:

dev newer   apexcharts: main=^5.16.0  dev=^6.6.1
dev newer   jsdom: main=^29.1.1  dev=^30.0.1
dev newer   @testing-library/jest-dom: main=^6.9.1  dev=^7.0.0
...

After this

The sync is unblocked once. Dependabot will target main again on its next security update and the divergence returns. #13654 lists the three options — pointing dependabot at Dev_new_gui, changing the default branch, or scheduling the sync — and notes that changing the default branch would also fix the misleading "20 vulnerabilities on the default branch" banner, at the cost of altering Closes #N behaviour this project already works around.

Model Used

Opus 5

Closes #13654

[mrveiss]

Blocked — this approach cannot pass a required check

No commit trailers fails, and it is a required check. It is not a flake and not fixable inside this PR.

The check scans every commit the PR adds:

while IFS= read -r sha; do ... done < <(git rev-list "${BASE_SHA}..${HEAD_SHA}")
pattern='^[[:space:]]*Co-authored-by:|Generated with \[?Claude|noreply@paperclip'

Merging main necessarily brings its commits into that range, and all three dependabot merges carry the banned trailer:

212b8cd2b  chore(deps): bump the npm_and_yarn group ... (#13524)
             Co-authored-by: dependabot[bot] <...@users.noreply.github.com>
50a012eb3  chore(deps): bump the pip group ... (#13523)
             Co-authored-by: dependabot[bot] <...@users.noreply.github.com>
e554aac80  chore(deps): bump the npm_and_yarn group ... (#13515)
             Co-authored-by: Martins Veiss <...>
             Co-authored-by: dependabot[bot] <...@users.noreply.github.com>

A merge commit's whole purpose here is to put those commits in the ancestry, so the conflict is structural: the thing that unblocks the sync is the thing the check rejects. I have marked this draft rather than trying to force it through.

The check's own suggested remedy — git filter-branch to strip trailers and force-push — would rewrite commits that are already on main, the default branch. I am not doing that unasked.

Options, all needing a decision

A. Scope the trailers check to commits authored for the PR. e.g. git rev-list --no-merges "${BASE_SHA}..${HEAD_SHA}" combined with skipping dependabot[bot], or scanning only first-parent commits. Rationale: the guard exists to stop authored trailers being introduced, not to re-litigate upstream history already merged into main. Narrowest change, but it edits a required guard.

B. Drop the merge entirely. Land the five security bumps on Dev_new_gui as an ordinary PR (no merge commit, no trailers), then change the sync workflow's guard from "main has commits not in Dev_new_gui" to a content/tree comparison, so it permits the push once main's content is contained. Touches the release-sync guard instead of the trailers guard. Verified safe on content grounds: the merged tree here is behind main on zero packages.

C. Rewrite main. Strip the trailers from the three commits and force-push the default branch. Not recommended — it rewrites published history on the branch dependabot and the vulnerability banner both key off.

Not affected

The dependency analysis in this PR stands regardless of which option is chosen. Dev_new_gui was genuinely missing five security upgrades — cryptography 50.0.0, fast-uri 3.1.5, hono 4.13.0, undici 8.10.0, nanoid 3.3.17 — and those need to land on Dev_new_gui under any of the three options. Option B lands them directly.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[mrveiss]

Unblocking this — the failure is the trailers guard, not the diff

No commit trailers is a required context and is what has held this since 2026-08-05. Three of the nine commits trip it, and all three are authored by dependabot[bot], which stamps Co-authored-by: dependabot[bot] on its own security bumps.

The guard cannot distinguish that from a human co-authorship claim, so a sync carrying dependabot commits can never pass — which means security fixes strand on main permanently. That is the mechanism behind #13667's js-yaml/nanoid advisories reddening Security Scan on every PR, and behind #13526/#13499/#13622 all showing as conflicting.

#13726 narrows the guard to skip bot-authored commits — scoped to the author, not the trailer text, so a human commit carrying Co-authored-by: still fails exactly as before. Simulated against this PR's exact range:

commits scanned:            9
offending after exemption:  0
=> guard would PASS

Once #13726 lands, this needs an update-from-base and a re-run; no changes to the sync itself. The remaining Security Scan red is #13667 and is not a required context.

Deliberately not done: rewriting the three commits to strip trailers. That would rewrite dependabot's authorship on security bumps and break SHA parity with main, to work around a rule that was never aimed at bots.