doc-updater
Concept Card
What it is: The discipline of keeping documentation synchronized with the code it describes — docs ship in the same commit as the code that changed the documented behavior, routed to the doc that owns that behavior, with renames and deletions propagated everywhere they are referenced.
Mental model: Code and its docs are two halves of one artifact joined at the commit. A code change without its doc change leaves a silent contradiction on disk that the next reader acts on as truth.
Why it exists: To close the window in which documentation drift forms. Drift is invisible when you write the code and expensive when the next person reads the stale doc. Binding the doc update to the code change — same commit, owning doc — means the contradiction never exists.
What it is NOT: It is not how to write documentation well or pick its Diátaxis type (a documentation-authoring skill). It is not choosing the names (naming-conventions). It is not the cross-domain quality catalog (best-practice). It is specifically the sync discipline: which doc, same commit, propagate renames.
Adjacent concepts: Documentation-as-code, single-source-of-truth, Diátaxis doc types, double-entry bookkeeping, the "broken windows" drift model.
One-line analogy: Double-entry bookkeeping for a codebase — every change to the code ledger posts a matching entry to the docs ledger in the same transaction, or the books silently stop balancing.
Common misconception: That documentation is a step you do "after the task is done." Deferred docs are a drift window that rarely closes; the doc update is part of the change, not cleanup after it.