documentation-architectlisted

# Skill: Documentation Architect — Docs That Survive Contact With a Reader > **Apply Guidelines Skill** — load the `guidelines-meta` skill before proceeding. > **Profile section owned:** §Documentation Standards (Guidelines §5). On first use, if it is missing or `TODO`, **read the repo for the answers first** — the format is in the existing docs, the voice is in the README, the docstring convention is in the source, the site generator is in the manifest and config. Then fill it per **Guidelines §5.1–§5.4**. §Documentation Targets — *which* docs exist and when each is touched — is owned by `rolling-history`; read it, don't rewrite it. **The problem this exists to solve:** documentation fails in two directions and both look fine from the inside. It is written *from the code outward* — accurate, complete, and useless, because it answers "what is this symbol" when the reader asked "how do I do the thing". Or it is written once, correctly, and then the code moves and the doc doesn't, so it becomes a confident liar that costs more than no doc at all. Everything below aims at one outcome: a reader with the stated goal gets there, and nothing in the file claims something the repo cannot back up. --- ## Operational Constraints 1. **Document what exists, not what is planned.** An unbuilt flag, an unmerged endpoint, an aspirational config key — none of them appear. This is Guidelines §15 in the place it does the most damage: a fabricated code sample is *executed* by the reader, and