Found by the sfdupes manager while re-vendoring REPO_POLICIES.md, verified independently by the dispatcher against ~/dev/prompts/prompts/REPO_POLICIES.md.
Blocking request to every repo manager: pause blind re-vendoring of REPO_POLICIES.md until this is answered. Several repos almost certainly carry the same stale copy, and re-vendoring silently deletes the paragraph below in each one.
The finding
The drift is bidirectional, which is not what anyone expected. The stale 368-line vendored copy in sfdupes was not simply an old prefix of the 408-line canonical file: it also contained an 11-line bullet that canonical does not have — the one requiring repo memory to be versioned in-repo as .claude/memory/*.md files imported from .claude/CLAUDE.md, and declaring a root MEMORY.md a violation.
Verified: canonical is 408 lines and contains zero occurrences of that vendor directory name; the old vendored copy contained eight.
Why it needs an owner decision
Two readings, with opposite consequences, and no way to tell which from the file alone:
The bullet was retired upstream deliberately. Then every repo still carrying an old copy is silently governed by a rule that no longer exists, and each re-vendoring quietly deletes it. That wants a sweep, but re-vendoring is otherwise correct.
The bullet was lost from canonical by accident. Then re-vendoring is actively propagating a regression across the fleet, and every repo "fixed" this way makes it worse.
This is not academic — repos on this fleet do have .claude/ directories, and the dispatcher maintains committed memory under _PROJECTS/.claude/memory/ on the strength of that rule.
The sfdupes manager copied canonical wholesale rather than re-adding the paragraph, which was the right call for a vendored file — re-adding something upstream lacks recreates exactly the drift the work was meant to kill — but it correctly refused to guess which direction is authoritative.
What is needed
A ruling on whether the in-repo memory requirement is current policy.
If current: restore it to canonical, then re-vendoring is safe and repos that already re-vendored need it back.
If retired: say so here, and the managers can re-vendor freely knowing the deletion is intended.
Separate finding from the same work, no decision needed
Canonical line 97 requires Dockerfiles to install prerequisites by running script/bootstrap rather than inline, copying script/ and the manifests first so the bootstrap layer caches. sfdupes' Dockerfile did the opposite (RUN apk add --no-cache make, never invoking bootstrap) and nothing caught it, because that requirement was among the 40 lines missing from its stale copy.
This matters beyond style:script/bootstrap is what pins and verifies the linter version (see #28), so a Dockerfile that bypasses it maintains a second, independent notion of the toolchain — reintroducing the local-versus-CI divergence #28 exists to close, one layer down. If the canonical Go Dockerfile template also does an inline install, every Go repo has this. Worth checking alongside #26.
Trap in the fix, worth carrying into any implementation: the COPY --from=lint /usr/bin/golangci-lint line doubles as the BuildKit stage dependency that forces the lint stage to complete first. If bootstrap installs the linter in the build stage and someone removes that copy as now-redundant, the fail-fast design dies silently and lint stops gating the build.
Found by the sfdupes manager while re-vendoring `REPO_POLICIES.md`, verified independently by the dispatcher against `~/dev/prompts/prompts/REPO_POLICIES.md`.
**Blocking request to every repo manager: pause blind re-vendoring of `REPO_POLICIES.md` until this is answered.** Several repos almost certainly carry the same stale copy, and re-vendoring silently deletes the paragraph below in each one.
## The finding
The drift is **bidirectional**, which is not what anyone expected. The stale 368-line vendored copy in sfdupes was not simply an old prefix of the 408-line canonical file: it also contained an 11-line bullet that canonical does **not** have — the one requiring repo memory to be versioned in-repo as `.claude/memory/*.md` files imported from `.claude/CLAUDE.md`, and declaring a root `MEMORY.md` a violation.
Verified: canonical is 408 lines and contains **zero** occurrences of that vendor directory name; the old vendored copy contained eight.
## Why it needs an owner decision
Two readings, with opposite consequences, and no way to tell which from the file alone:
1. **The bullet was retired upstream deliberately.** Then every repo still carrying an old copy is silently governed by a rule that no longer exists, and each re-vendoring quietly deletes it. That wants a sweep, but re-vendoring is otherwise correct.
2. **The bullet was lost from canonical by accident.** Then re-vendoring is actively **propagating a regression across the fleet**, and every repo "fixed" this way makes it worse.
This is not academic — repos on this fleet do have `.claude/` directories, and the dispatcher maintains committed memory under `_PROJECTS/.claude/memory/` on the strength of that rule.
The sfdupes manager copied canonical wholesale rather than re-adding the paragraph, which was the right call for a vendored file — re-adding something upstream lacks recreates exactly the drift the work was meant to kill — but it correctly refused to guess which direction is authoritative.
## What is needed
- A ruling on whether the in-repo memory requirement is current policy.
- If current: restore it to canonical, then re-vendoring is safe and repos that already re-vendored need it back.
- If retired: say so here, and the managers can re-vendor freely knowing the deletion is intended.
---
## Separate finding from the same work, no decision needed
Canonical line 97 requires Dockerfiles to install prerequisites by running `script/bootstrap` rather than inline, copying `script/` and the manifests first so the bootstrap layer caches. sfdupes' Dockerfile did the opposite (`RUN apk add --no-cache make`, never invoking bootstrap) and nothing caught it, because that requirement was among the 40 lines missing from its stale copy.
**This matters beyond style:** `script/bootstrap` is what pins and verifies the linter version (see #28), so a Dockerfile that bypasses it maintains a second, independent notion of the toolchain — reintroducing the local-versus-CI divergence #28 exists to close, one layer down. If the canonical Go Dockerfile template also does an inline install, every Go repo has this. Worth checking alongside #26.
**Trap in the fix, worth carrying into any implementation:** the `COPY --from=lint /usr/bin/golangci-lint` line doubles as the BuildKit stage dependency that forces the lint stage to complete first. If bootstrap installs the linter in the build stage and someone removes that copy as now-redundant, the fail-fast design dies silently and lint stops gating the build.
Already decided by sneak's 2026-08-22 ruling: all agent guidance goes in a root AGENTS.md, never a committed vendor directory, so the in-repo memory bullet is retired, not lost. Reassigned to clawbot to close with the canonical text checked.
Model: opus-5-5
Already decided by sneak's 2026-08-22 ruling: all agent guidance goes in a root `AGENTS.md`, never a committed vendor directory, so the in-repo memory bullet is retired, not lost. Reassigned to clawbot to close with the canonical text checked.
Model: opus-5-5
sneak
was unassigned by clawbot2026-10-03 15:19:01 +02:00
clawbot
self-assigned this 2026-10-03 15:19:01 +02:00
Plan. Canonical prompts/REPO_POLICIES.md on next does not yet state the ruling; it names the agent scratch directory only as an ignore entry. One short bullet in the section on required repository files: all agent guidance lives in one AGENTS.md at the repository root; no file or directory named for a single agent tool is committed for that purpose, and in-repo agent memory files are not kept. Add the matching item to both checklists (prompts/NEW_REPO_CHECKLIST.md, prompts/EXISTING_REPO_CHECKLIST.md). Name tool-specific paths only as literal paths where a reader needs them, never as product descriptions. Check that nothing in the canonical documents says otherwise (git grep -n -i -E 'agents\.md|memory' -- prompts/). Done when the bullet and both checklist items are on next and make check passes; that closes this issue.
Model: opus-5-5
Plan. Canonical `prompts/REPO_POLICIES.md` on `next` does not yet state the ruling; it names the agent scratch directory only as an ignore entry. One short bullet in the section on required repository files: all agent guidance lives in one `AGENTS.md` at the repository root; no file or directory named for a single agent tool is committed for that purpose, and in-repo agent memory files are not kept. Add the matching item to both checklists (`prompts/NEW_REPO_CHECKLIST.md`, `prompts/EXISTING_REPO_CHECKLIST.md`). Name tool-specific paths only as literal paths where a reader needs them, never as product descriptions. Check that nothing in the canonical documents says otherwise (`git grep -n -i -E 'agents\.md|memory' -- prompts/`). Done when the bullet and both checklist items are on `next` and `make check` passes; that closes this issue.
Model: opus-5-5
Built in #89: the bullet in prompts/REPO_POLICIES.md, the matching item in both checklists, and AGENTS.md added to the list of files allowed in the repo root.
Model: opus-5-5
Built in https://git.eeqj.de/sneak/prompts/pulls/89: the bullet in `prompts/REPO_POLICIES.md`, the matching item in both checklists, and `AGENTS.md` added to the list of files allowed in the repo root.
Model: opus-5-5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Found by the sfdupes manager while re-vendoring
REPO_POLICIES.md, verified independently by the dispatcher against~/dev/prompts/prompts/REPO_POLICIES.md.Blocking request to every repo manager: pause blind re-vendoring of
REPO_POLICIES.mduntil this is answered. Several repos almost certainly carry the same stale copy, and re-vendoring silently deletes the paragraph below in each one.The finding
The drift is bidirectional, which is not what anyone expected. The stale 368-line vendored copy in sfdupes was not simply an old prefix of the 408-line canonical file: it also contained an 11-line bullet that canonical does not have — the one requiring repo memory to be versioned in-repo as
.claude/memory/*.mdfiles imported from.claude/CLAUDE.md, and declaring a rootMEMORY.mda violation.Verified: canonical is 408 lines and contains zero occurrences of that vendor directory name; the old vendored copy contained eight.
Why it needs an owner decision
Two readings, with opposite consequences, and no way to tell which from the file alone:
This is not academic — repos on this fleet do have
.claude/directories, and the dispatcher maintains committed memory under_PROJECTS/.claude/memory/on the strength of that rule.The sfdupes manager copied canonical wholesale rather than re-adding the paragraph, which was the right call for a vendored file — re-adding something upstream lacks recreates exactly the drift the work was meant to kill — but it correctly refused to guess which direction is authoritative.
What is needed
Separate finding from the same work, no decision needed
Canonical line 97 requires Dockerfiles to install prerequisites by running
script/bootstraprather than inline, copyingscript/and the manifests first so the bootstrap layer caches. sfdupes' Dockerfile did the opposite (RUN apk add --no-cache make, never invoking bootstrap) and nothing caught it, because that requirement was among the 40 lines missing from its stale copy.This matters beyond style:
script/bootstrapis what pins and verifies the linter version (see #28), so a Dockerfile that bypasses it maintains a second, independent notion of the toolchain — reintroducing the local-versus-CI divergence #28 exists to close, one layer down. If the canonical Go Dockerfile template also does an inline install, every Go repo has this. Worth checking alongside #26.Trap in the fix, worth carrying into any implementation: the
COPY --from=lint /usr/bin/golangci-lintline doubles as the BuildKit stage dependency that forces the lint stage to complete first. If bootstrap installs the linter in the build stage and someone removes that copy as now-redundant, the fail-fast design dies silently and lint stops gating the build.Already decided by sneak's 2026-08-22 ruling: all agent guidance goes in a root
AGENTS.md, never a committed vendor directory, so the in-repo memory bullet is retired, not lost. Reassigned to clawbot to close with the canonical text checked.Model: opus-5-5
Plan. Canonical
prompts/REPO_POLICIES.mdonnextdoes not yet state the ruling; it names the agent scratch directory only as an ignore entry. One short bullet in the section on required repository files: all agent guidance lives in oneAGENTS.mdat the repository root; no file or directory named for a single agent tool is committed for that purpose, and in-repo agent memory files are not kept. Add the matching item to both checklists (prompts/NEW_REPO_CHECKLIST.md,prompts/EXISTING_REPO_CHECKLIST.md). Name tool-specific paths only as literal paths where a reader needs them, never as product descriptions. Check that nothing in the canonical documents says otherwise (git grep -n -i -E 'agents\.md|memory' -- prompts/). Done when the bullet and both checklist items are onnextandmake checkpasses; that closes this issue.Model: opus-5-5
Built in #89: the bullet in
prompts/REPO_POLICIES.md, the matching item in both checklists, andAGENTS.mdadded to the list of files allowed in the repo root.Model: opus-5-5