Problem
Two failure classes that a reviewer needs are not reachable from any wiki page.
Both verified by inspection on 2026-08-13.
1. A flag/subcommand exists locally but not in the version deployed where the code runs
wiki/platforms/toolchains/version-management.md is the nearest page. Its
load-when covers version drift and pinning:
"Works on my machine" from tool-version drift; a project needs a pinned
language/tool version (.nvmrc, .python-version, .tool-versions); making CI use
the same versions as local; onboarding a machine reproducibly; a script/cron/CI
step can't find a version-managed binary; deciding where lockfiles fit
grep -n "flag\|option\|subcommand\|deployed" wiki/platforms/toolchains/version-management.md
returns nothing. So "I am adding --some-flag to a command that runs in CI"
routes nowhere, and the check — resolve the flag against the version actually
present at the execution site, not the authoring site — is not written down.
2. Two objects written non-atomically, with a reader that can observe the gap
grep -rl "sidecar\|write order\|partial write\|torn\|two objects" across
wiki/backend/common/storage/, wiki/infrastructure/, and
wiki/platforms/filesystems/ returns no page covering this. The DB layer has it
(transactions/, concurrency/distributed-locks.md), but at the object-storage
and filesystem layer there is nothing.
wiki/backend/common/storage/object-key-persistence.md is about which response
field to persist, not write ordering.
wiki/infrastructure/config/keys-ahead-of-their-consumer.md is adjacent but runs
the other direction (a config key added before its consumer).
Why these two
They are the two defect classes from
"Reviewing code is a skill"
that a frontier LLM reviewer missed:
aws s3 --progress-seconds proposed for a CI job whose AWS CLI predated the
flag — would have failed silently.- A tarball uploaded before its sidecar checksum: a reader that fails closed
breaks for every request between the two writes, and permanently if the job dies
in the gap.
The third class from the article — concurrent writers to a shared user-level
config file — is the class this repo hit itself with scripts/flush-lock.sh
(#77). Check backend/common/concurrency/ coverage before deciding whether it
needs its own page or a row on an existing one.
Scope
Related
Review-voice load-when coverage is uneven across domain indexes
(grep -ci review wiki/*/index.md): backend 6, infrastructure 6, frontend 5,
testing 5, qa 4, security 4, mobile 3, platforms 3, databases 0, debugging 0.
Worth a wiki-lint rule, but that is separable from this issue.
Source
Problem
Two failure classes that a reviewer needs are not reachable from any wiki page.
Both verified by inspection on 2026-08-13.
1. A flag/subcommand exists locally but not in the version deployed where the code runs
wiki/platforms/toolchains/version-management.mdis the nearest page. Itsload-when covers version drift and pinning:
grep -n "flag\|option\|subcommand\|deployed" wiki/platforms/toolchains/version-management.mdreturns nothing. So "I am adding
--some-flagto a command that runs in CI"routes nowhere, and the check — resolve the flag against the version actually
present at the execution site, not the authoring site — is not written down.
2. Two objects written non-atomically, with a reader that can observe the gap
grep -rl "sidecar\|write order\|partial write\|torn\|two objects"acrosswiki/backend/common/storage/,wiki/infrastructure/, andwiki/platforms/filesystems/returns no page covering this. The DB layer has it(
transactions/,concurrency/distributed-locks.md), but at the object-storageand filesystem layer there is nothing.
wiki/backend/common/storage/object-key-persistence.mdis about which responsefield to persist, not write ordering.
wiki/infrastructure/config/keys-ahead-of-their-consumer.mdis adjacent but runsthe other direction (a config key added before its consumer).
Why these two
They are the two defect classes from
"Reviewing code is a skill"
that a frontier LLM reviewer missed:
aws s3 --progress-secondsproposed for a CI job whose AWS CLI predated theflag — would have failed silently.
breaks for every request between the two writes, and permanently if the job dies
in the gap.
The third class from the article — concurrent writers to a shared user-level
config file — is the class this repo hit itself with
scripts/flush-lock.sh(#77). Check
backend/common/concurrency/coverage before deciding whether itneeds its own page or a row on an existing one.
Scope
skills/wiki-ingest(merge into an existing page beforecreating a new one, per the skill).
load whenlines must be written so a reviewer holding a diffreaches them, not only an implementer — the convention already exists, e.g.
backend/common/integrations/externally-owned-defaults.md: "…reviewing ormerging a PR that claims that default works…".
wiki/only. Independent of review: route the wiki from the diff, not only from the plan's intent #81/orchestrate: Phase 4 review is one sentence — give it a fixed four-lens pass #82/orchestrate: a confirmed review finding should emit an ★ Insight candidate (near-miss capture) #83/orchestrate: review comments to a worker must carry a failure scenario and a question, not a directive #84 — no shared files.Related
Review-voice load-when coverage is uneven across domain indexes
(
grep -ci review wiki/*/index.md): backend 6, infrastructure 6, frontend 5,testing 5, qa 4, security 4, mobile 3, platforms 3, databases 0, debugging 0.
Worth a
wiki-lintrule, but that is separable from this issue.Source