Appearance
Reference: find the exact fact
Use a reference to look something up, a guide to perform a task, an explanation to understand the model, and the runbook for an operating decision.
| Question | Owning destination |
|---|---|
| How does an objective become autonomous work and an outcome? | Work loop, autonomous ownership lookup |
| Who accepts results, coordinates correction and decides completion? | Planning and assessment, shared acceptance |
| Which YAML field/default or startup input? | Configuration lookup |
| Where should an agent retrieve a precise answer? | Question-to-owner map |
| What must the product do? | System specification |
| What must the cockpit show? | UI needs and exact contracts |
| Which routes/tools/schema fields exist? | Source-derived inventories |
| Which component owns an effect? | Architecture owner map |
| How do prompt references/tokens/retention work? | Prompt handling |
| Which current durable contract and historical change? | Durable format reference |
| Which validation gate/evidence? | Validation |
| Which isolated native quality pins, licenses and qualification limits? | Native quality prerequisites |
| How do I operate, diagnose or adopt state? | Runbook decision map |
The configuration guide, work tour and developer guide supply worked tasks. None replaces the linked contract or authorizes live effects. Source facts and historical evidence do not override repository policy or explicit owner instructions.
Source links open the repository on GitHub because deployed documentation serves only the built site, not the source checkout. HEAD/master links follow repository development; for an installed release, inspect the same path at its pinned commit or in its matching checkout rather than assuming the link identifies that release.