vendored-sync never fires for 4 of the files it checks (paths filter is narrower than the drift list)

[realmarcin]

The vendored-sync job in .github/workflows/label-correspondence.yaml runs scripts/check_vendored_sync.sh, which diffs this repo's vendored id↔label files against CultureBotAI/CultureMech at the commit pinned in scripts/.vendored_canon_ref. That is the mechanism that makes a one-copy edit to a shared file fail CI.

But the workflow sits behind a paths: filter that does not list most of the files the job exists to protect. A PR touching only the unlisted ones never fires the check.

Found while reconciling NEXT_TASKS.md on 2026-07-30. This is not the same gap as #278 — see the bottom.

Verified 2026-07-30

check_vendored_sync.sh compares these (FILES plus the MAPPED entry):

file	in trigger_paths?
scripts/validate_id_label_correspondence.py	yes
src/communitymech/schema/mech_shared.yaml	yes, via src/communitymech/schema/**
scripts/chem_formula.py	no
tests/test_id_label_empty_adapter.py	no
tests/test_id_label_unknown_prefix.py	no
tests/test_id_label_plausibility.py	no

Also unlisted, and worth deciding on: scripts/check_vendored_sync.sh and scripts/.vendored_canon_ref themselves. Editing the checker, or silently reverting the pin, does not fire the checker.

CommunityMech is in better shape than TraitMech here — its filter does cover mech_shared.yaml through the schema glob, which TraitMech's does not (TraitMech#184). The four unlisted files are common to all three spokes.

Severity

This is a PR-time hole, not an unguarded one. CultureMech's nightly vendored-fleet-audit.yml compares all four repos and still catches divergence within a day. The realistic failure mode is a vendored edit merging green and drift surfacing next morning against main — confusing to attribute, but not silent corruption.

The invariant is healthy right now: all three spokes pin the same .vendored_canon_ref = 6be694f3d6308ac0f4c2e0dcf196e2ff73f6468f, and the nightly audit has been green through 2026-07-30.

Fix

Extend trigger_paths to cover the full vendored set. Better than hand-listing: derive the filter from the same source check_vendored_sync.sh reads, so the two cannot drift apart — which is exactly the failure this issue is an instance of.

Worth doing as one cross-Mech sweep (the cross-mech-sync skill) rather than three independent PRs; TraitMech#184 and the MIM companion are the same gap.

conf/id_label_targets.yaml stays out of the vendored set by design — it is intentionally per-repo (different adapters, targets, exceptions) and is already in trigger_paths on its own merit.

How this differs from #278

#278 is about what is compared: check_vendored_sync.sh exists only in the spokes and has no canonical copy in the hub, so there is nothing to diff the checker against.

This issue is about when the comparison runs: even for the files that do have a canonical copy, the job does not fire on a PR that touches only them.

Both are real, neither subsumes the other, and fixing one leaves the other open. They will likely be fixed in the same PR, but they are separate defects.

Neither should be confused with the settled topology: CultureMech is the hub and claw/shared/idlabel/ is a passive mirror (claw#19, restated in claw#22 after claw#21 tried making claw canonical on 2026-07-22 and was reverted 2026-07-25). Do not repoint CANON_REPO or bump .vendored_canon_ref to a claw commit.

[realmarcin]

Fixed by #302, with a better approach than this issue proposed.

I suggested extending the paths: filter to cover the full vendored set. That leaves two lists to keep in sync — the filter and the checker's own FILES array — which is the same class of drift this guard exists to catch. It also cannot be automated: GitHub evaluates paths: from static YAML before checkout, so the filter can never read the checker.

#302 gives vendored-sync its own workflow with no filter at all, removing the failure class instead of managing it.