Document an existing system (the scan)

§ 1Purpose

Populate a WAD from a real codebase: mechanical probes first, then a targeted interview for what code can't say.

§ 2Prerequisites

• A scaffolded WAD inside (or beside) the repository
• Read access to the code, CI config, and IaC

§ 3Flowchart

§ 4Steps

Work the scan-checklist rows top to bottom — repo layout → CI/build → entry points → externals → data layer → infrastructure → personas/governance → standards → SOPs. Cheap, high-signal sources come first; each row says what to read, what blocks to emit, and what to ask when the source is silent.

For each row: read the sources, write the blocks, wcl check, render. Anything machine-derivable that will drift (pipelines, dependency edges, schemas) should be extracted, not hand-copied — write the extractor now (see the write-an-extractor process) so the fact stays true next month.

Code cannot tell you: support contacts, approval chains, off-repo infrastructure, security posture, or why anything is the way it is. Leave those blank for the next step — a scanned WAD full of plausible inventions is worse than an empty one.

Run a targeted mini-interview from the question bank, restricted to what the probes couldn't fill — and back-fill the load-bearing decisions as adrs (“why is it like this?”). Still-unanswered items become open-question lines in an article.

Serve the book with --comment, have the user walk it against reality, fix data from the comments, and record the reviewed revision as the diff baseline.