repos_sync: ask a target repo's own layout lint before installing .claude/

[Jammy2211]

The hole

repos_sync.py --write creates exactly two top-level entries in every checked-out repo — .claude/ (hook + settings) and the CLAUDE.md pointer — and knew nothing about the target beyond "checked out, has an AGENTS.md".

A repo that lints its own layout has no way to know the write is coming. So the write breaks that repo's CI, and the breakage reads as the repo's fault rather than as this script's. That already happened once: PyAutoMemory's 498e1a8 landed a tracked .claude/ that was not in ALLOWED_TOP_DIRS, and both make validate and make test failed on arrival. It was fixed there, but the class stayed open for the next repo to grow a lint.

The guard

Before writing either entry, read the target's own allowlist — parse its layout lint with ast, never execute it — pull ALLOWED_TOP_DIRS / ALLOWED_TOP_FILES, and skip the repo when the entry is missing from the set its kind is governed by.

The lint stays the single authority. Its allowlist is read, never copied here, so a repo that allowlists .claude is covered again on the next run with no change on the Mind side and no per-repo registry to rot.

Not a key in repos.yaml

That was the obvious move and it is the wrong one. repos.yaml is identity-only by contract — its own header says "per-organ POLICY stays with the organ that owns it" — and a structure_lint: key is policy.

Detection is by convention instead (STRUCTURE_LINT_CANDIDATES), which leaves a real, bounded gap for a repo that lints from some other path. That gap is documented at the constant rather than papered over; extending the tuple is the fix if it happens.

Three things the guard is careful about

• Unreadable is not permissive — and not forbidding either. A computed or unparseable allowlist cannot be read without running the lint, so it never reads as an all-clear. It also does not block the write: "cannot tell" is not "forbids", and refusing on a guess would strand the common case. It is reported for a human.
• The write side and the drift side agree. check_session_hooks and check_claude_md_pointers exempt a repo the writers skip, or a deliberately-unwritten repo would read as permanent drift on every run. The new target-repo layout lints leg names it instead, so the skip is loud rather than silent.
• An entry already on disk gets a different message. That is the case that actually happened: a --write from before this guard left it behind, so the lint is failing now. Skipping the next write does not undo that, and the message says so rather than implying a write was declined.

Verification

Replayed against the real artifact, not just fixtures. Cloned PyAutoMemory read-only and restored its pre-fix allowlist: the guard flags exactly the two entries its own lint flags, with the same verdict, and --write declines instead of re-breaking it. Against the current allowlist it is silent.

• 212 tests pass — 15 new, fictional fixtures only (tests/** is KEEP-copied into the public template), each failure mode driven with input that trips it
• repos_sync.py --check clean on all 13 legs
• --write idempotent, no stray changes
• lifecycle.py check OK
• The Tenant Firewall Gate checks out Brain/Heart/Hands beside Mind and runs the full drift check; none of those four repos has a layout lint, so the new leg is a no-op there

Implements draft/maintenance/pyautomind/repos_sync_target_repo_lint_awareness.md, filed in the first commit of this PR.

---

🤖 Generated with Claude Code

https://claude.ai/code/session_01Uvjb6PqUDyYJa3vXjnVHht

---

Generated by Claude Code