Documentation authority map
Rennet separates product intent, engineering contracts, accepted behavior, and planned work. This page names the authority for each kind of claim.
Authority order
Section titled “Authority order”Authority is scoped. Rule Zero sits above every source. Product intent, accepted behavior, current implementation, planned work, and engineering registers each answer a different question. Contracts and rulings owns this model if the two pages disagree.
Read authority by question, not by rank:
- For what Rennet is for, Product and vision wins.
- For what should land next, the GitHub issue queue owns priority and scope.
- For cross-cutting product and architecture decisions,
Contracts and rulings wins, and
it owns two narrower registers beneath it:
- Architecture contracts win on project context, immutable patchsets, invalidation, persistence, and publication mechanics.
- Dependency standard wins on package choice, versions, licences, toolchain ownership, and dependency overlap.
If any register disagrees with the product’s intent, that is a documentation bug to reconcile rather than a reason to pick whichever sentence is convenient.
Promoted OpenSpec specifications define accepted behavior. Code and tests show what the current implementation does. When they disagree, document the implementation as current and the accepted contract as planned, with an active tracking link.
What each page is for
Section titled “What each page is for”| Need | Source |
|---|---|
| What Rennet is for | Product and vision |
| What to build or land next | GitHub issues |
| Stable product and architecture decisions | Contracts and rulings |
| Runtime and persistence invariants | Architecture contracts |
| Allowed packages and tool ownership | Dependency standard |
| How lens boards are drafted, linted, and edited | The lens pipeline |
| How boards are stored and authored | How Rennet consumes @wboard/* |
| How model jobs are assigned | Model council |
| How context reaches models | Context assembly |
| How a review becomes an outbound artifact | Hand off and the exits |
| Accepted behavior for one capability | Promoted OpenSpec specifications |
| What the product does now | Current code and tests |
Separate current and planned claims
Section titled “Separate current and planned claims”Before describing behavior, check the current code, relevant tests, and resolved Nx configuration. Keep these categories separate:
- Current: the behavior implemented and tested on
main. - Accepted: the contract in a promoted OpenSpec specification.
- Planned: accepted behavior that is not implemented and has active tracking.
A planned page declares status: planned and a tracking URL in its frontmatter. Historical explanations do not belong in the documentation library.
Maintaining the map
Section titled “Maintaining the map”When code alters behavior or a boundary, update the page that owns the fact in the same change. Give each new authority a narrow scope here or fold it into an existing owner.
See the docs style guide and the good docs standard before adding a new section.