feat(sync): detect signature drift in rsync and revert/drop

[mosheabr]

Summary

Adds a "Detect signature drift in rsync" step to sync-skills.yml that catches the case where the source-repo team edits skill content without refreshing skill.oms.sig. Recovery is automatic and safe:

• Existing skills: revert the catalog dir to its pre-rsync (signed) state. The signed copy stays live on main and across downstream channels (Skills.sh, Codex, Claude Code, Hermes, OpenClaw). The unsigned update is held until the source team re-signs.
• New skills (no prior version on main): drop outright — never land in a drift state.

Both write to /tmp/dropped-skills.txt with a sig drift: reason prefix. The sync PR body and the rolling missing-compliance tracker issue now partition drops into Missing artifacts / Signature drift / Orphan / Other sections so each failure mode has its own recovery path.

Why now

We've hand-cherry-picked three sync PRs this week (#226→#231, #232→#233, #234→pending) because source-repo teams edit skill content without re-running /nvskills-ci. The unsigned content keeps reaching the bot sync PR; landing it would propagate to Skills.sh + Codex + Hermes + OpenClaw within ~15 minutes and break crypto verification on the next sweep. Automating the drop turns this into a self-service flow: the source team gets pinged, the catalog never goes through a broken-crypto state.

How drift is detected

For each catalog dir the rsync actually targeted (recorded in /tmp/rsynced-skill-dirs.txt during the rsync loop, so we never path-parse):

1. Compute the set of files changed via git diff --name-only HEAD ∪ git ls-files --others --exclude-standard — captures both modifications/deletions and untracked additions.
2. Check whether the root $dir/skill.oms.sig is in that set (exact match via grep -Fx --, not regex — nested sig files like $dir/docs/skill.oms.sig don't mask a stale root).
3. If non-sig files changed but the root sig didn't → drift.
4. Existing skill (git ls-tree HEAD -- "$dir" non-empty) → revert via git checkout HEAD -- "$dir/" + git clean -fdx -- "$dir/". New skill → rm -rf.

Repo-owner visibility

The rolling missing-compliance tracker issue is now auto-assigned (mosheabr by default; configurable via CATALOG_TRACKER_ASSIGNEES secret as a comma-separated list). Every drift change generates a GitHub notification regardless of repo-watch state. Idempotent — re-asserts on each run so manual unassign can't permanently mute notifications.

Test cases the design has been validated against

1. Skill unchanged in rsync → skipped (no diff).
2. Skill content + sig both changed → no drift (both moved together).
3. Skill content changed, root sig unchanged → drift detected. Existing → revert; new → drop.
4. Stray nested sig refresh (docs/skill.oms.sig) → still drift (root path is what matters).
5. Multi-skill product with one drifted sibling → drift on that sibling only.
6. New skill under an existing product → correctly classified as new (doesn't false-revert siblings).
7. Rsync deletes SKILL.md without sig refresh → still caught (driver iterates exact rsync targets, not post-rsync find SKILL.md).
8. Catalog dir with whitespace → newline-safe loop handles it.

Bonus fix in this PR

The pre-existing grep -qx "- $product" at the "mark changed components" line parsed the leading - as a grep option, so the de-dup check silently always fell through. Fixed in both the new drift step and the existing compliance step (grep -Fqx --). Happy to split into a separate fix-bug PR if reviewers prefer.

Follow-ups (intentionally out of scope here)

1. Source-author notification. Auto-file a tracker issue on the source repo @-mentioning the PR author whose merge introduced the drifted content (resolved via git log -1 --pretty='%ae' -- <changed-files> on the source clone we already have during rsync). Anchored to commit identity, not a static contacts directory — survives team rotations. Tracked as backlog item CI Pipeline to verify skill counts match source repos #3.
2. True crypto verification. This step is a file-level heuristic (changed-set membership vs root sig). Cryptographic model_signing verify is the job of the "Verify Signed Skills" workflow in PR ci: add Verify Signed Skills workflow #78 — the two are complementary (this catches authoring mistakes at sync time; ci: add Verify Signed Skills workflow #78 catches cryptographic mismatches periodically).

Review history

4 rounds of Codex review on a private draft branch (mosheabr/skills-drafts#1) prior to raising upstream. All findings addressed before this PR opened.

Stats

• 1 file changed: .github/workflows/sync-skills.yml
• ~230 lines added / 30 modified
• 6 commits
• YAML validates clean

[mosheabr]

Thanks for the review @sayalinvidia — pushed commit 2cdb131 addressing #2, #3, and #4.

What changed

• Add Model Optimizer, Megatron Core, and Megatron Bridge to catalog #2 (MED) — bad assignee skipping tracker creation. Both branches now follow the same tolerant pattern: create the issue without assignees, then loop --add-assignee "$a" || warn with per-handle whitespace trim. A typo in CATALOG_TRACKER_ASSIGNEES no longer prevents the tracker from existing. (Noting your point that continue-on-error: true on the step prevents catastrophic sync failure, but losing the tracker defeats the feature — so still worth the fix.)

• CI Pipeline to verify skill counts match source repos #3 (LOW) — hardcoded personal fallback. Removed entirely. If CATALOG_TRACKER_ASSIGNEES is unset, we now skip assignment and emit ::warning title=Drift notifications inactive::. The warning surfaces in the workflow log every run until the secret is set. (Refined per Codex's catch that GitHub issue assignees must be individual users — team handles aren't valid — so the earlier "use a team handle" comment in my code was wrong.)

• Update TensorRT-LLM skill count from 4 to 20 #4 (LOW) — deleted-sig case. Added the inline comment in the drift loop noting that a rsync deleting skill.oms.sig alongside content edits registers as a sig change in git diff → drift NOT flagged here → falls through to the compliance step under missing artifacts: skill.oms.sig. Defense in depth.

On #1 (HIGH) — README version inconsistency

I want to flag this carefully because the answer turns out to be different than expected. The README table on main today doesn't have a Version column — PR #215 (commit 1104de0, 2026-06-01) replaced the prior Source | Version columns with a single Skills column that lists every catalog dir as a link. VERSIONS_FILE is declared in regenerate-readme.sh at line 33 but never consumed — the only other reference is the historical comment at line 76. /tmp/sync-versions.txt is currently dead-end output from the sync workflow.

So the exact "README will advertise the drifted upstream SHA against now-reverted content" risk you raised is anchored to the pre-#215 table shape, not the current one. I didn't apply the purge logic in this PR for that reason.

Two follow-ups I'd suggest in a separate small PR:

1. Remove the dead sync-versions.txt write at the rsync loop and the unused VERSIONS_FILE declaration in regenerate-readme.sh, so the next reader doesn't fall into the same stale-context trap.
2. If we ever bring the Version column back (or any other consumer of sync-versions.txt), the purge-on-drift logic you described becomes correct and should be added then.

Would appreciate a follow-up pass when you have a window — happy to walk through anything that's not obvious.