Answers the order's two asks, verified independently:
1. "sjekken leser bare README.md" — FALSE against the current codebase.
inspectRepo has scanned every tracked .md file since 2026-07-27 (commit
816ba97), three weeks before this order. Reproduced the order's exact
scenario against a fresh clone of open/app-creator: CLAUDE.md:136 does not
fire, but not from the diagnosed cause — the cited link uses the `/.../`
elision this engine already treats as a documented placeholder convention
(the same "18/22 split" the FILE_URL_LEAK comment already describes), not
a leak. Injected a real (non-elided) file:// leak into the same CLAUDE.md
in the same clone: LINK-FILE-URL fired immediately, correct file:line.
No code change corresponds to this half of the order.
2. "bør regelen gjelde file://-lenker generelt, ikke bare /Users|home" — live,
unmeasured, answered here. Grepped every tracked .md file in the 21 of 22
registered repos with a local clone (llm-security-commons absent).
Positive control: the two real /Users/ leaks in ki-produktivitetsmodell's
CLAUDE.md were found, proving the query isn't silently empty. Result:
zero occurrences of any other root (no C:\, /private/, /var/, /tmp/) in
150 file:// hits across 12 repos — every other hit is a generic
placeholder already declined by the Users|home anchor. Recorded as a
RELEASE-ASSETS-shaped rejection in the code comment: no subject, not a
low rate. Widen the day a real one appears.
Closing the order with --no-commit: this resolves both halves, it does not
hand anything back for the sender to act on.