feat: give the corpus an entry point and an honest description

[retr0h]

Adds two requirements to the documentation capability, and the tasks to apply them.

Added here rather than as a separate change because documentation is still in flight — a new change carrying a ## MODIFIED delta against it would apply to a capability the corpus does not hold yet, and orphan. That is the failure correct-documentation-drift nearly hit against module-dependencies.

The README promises something the corpus does not hold

What survives is openspec/specs/ — the current description of how osapi-io behaves, kept honest by every change that passes through.

It is not that. Of six capabilities, five govern how work is done:

Capability	Governs
code-architecture	package layout, coverage, CI, labels, workflow naming
justfiles	the shared recipe modules
go-library-standards	ignore files, badges, examples
module-dependencies	module paths, replace directives
non-library-standards	which files a repository carries
sdk-standards	the SDK's contract — the only one about behavior

A reader could learn all forty-five requirements, know our linting rules, and still not know that osapi has three processes or what a provider is.

The gap is sequence, not intent — every change so far has been repository standardization, which produces rules about process. The capabilities queued next (routing, API design, provider semantics, domain completeness) are about behavior. It will never fully match, because package maps and request flows stay in the repositories by a decision this capability already records. So the README is corrected to say what the corpus is: the rules the software is held to, with the reasoning in the archive.

There is no way in

openspec/ holds six capability directories and eleven archived changes, and no top-level document. Nothing says where to start or which capability governs what. Survivable at six; not at twenty.

The requirement asks for a map, not a summary — naming each capability and what it covers, saying what the corpus is, pointing at the archive for reasoning. A summary would restate the requirements and drift from them; a map stays true as long as the names do.

The second requirement asks each ## Purpose to state what the capability governs and why that ground needs governing. A capability that opens with its first requirement teaches a reader who already knows the domain, and no one else.

Tasks 4a.1–4a.3 apply it; 5.4 verifies the map names every capability.

🤖 Generated with Claude Code

[github-actions]

Thank you for contributing to this project! 😊🕹️