doc-claims treated `release.sh` mentioned in prose exactly as it treated
`docs/qa/ClaudeReport.md`. The second asserts something about this repository;
the first is usually a reference to a script the template offers and this
project has not adopted yet -- scaffold.sh ships no scripts on purpose, and
TOOLS.md says so outright: "the table is a menu rather than an inventory here".
So every freshly scaffolded project began with a red doc-claims over documents
that were correct. That is the condition audit-gate.mjs argues about for npm
advisories: a gate that is red from the first day is one everybody learns to
ignore, and it takes the true findings with it.
Bare filenames are now reported and counted separately, and do not fail the run.
Paths still do. The strictness that matters is untouched, and I checked rather
than assumed: the finding this script was written for -- a comment claiming
tests/notice-security.test.ts pinned a security rule, for a file that had never
existed -- is a path, so it would still fail today.
Verified on a scaffolded project with a real commit, because doc-claims reads
git ls-tree HEAD and an uncommitted scratch repo has no HEAD at all: with no
commit it checks no paths whatsoever and reports a confident pass. My first
attempt at this verification did exactly that and had to be redone. The skill's
warning to commit before running a doc checker is about the review checker; it
applies here for the same reason.
This is part of #16, not all of it. A committed fresh scaffold still exits 1 on
four PATH claims -- docs/architecture/scripts, docs/architecture/githooks, and
docs/architecture/scripts/release.sh, named by DOC_TRUST_MAP.md, TOOLS.md and
WORK_CYCLE.md. Those are the same root cause and need the decision #16 asks for,
so the issue stays open.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
f5fd67b152