Canon in the catalogue
One truth, in one place. Everything else points at it. A shared canon in the catalogue makes knowledge shareable, checkable and current.
The problem
Section titled “The problem”The same rule lives in many projects. The copies drift apart, and nobody knows which one holds.
The idea
Section titled “The idea”Keep one shared bundle in the catalogue, for example an architecture canon: layers, naming, the ADR pattern. Projects refer to it. They do not copy it.
What it gives you
Section titled “What it gives you”- One source of truth.
- New projects start with a frame of reference.
- Agents load the canon through
ctxand get the same rules every time. - Reviews measure against a fixed yardstick.
How okf does it
Section titled “How okf does it”A canon block has an owner. okf sync-insert materialises it in the consumer, so the consumer stays readable even without the catalogue. okf sync-status shows drift. okf sync-update pulls outdated blocks up to date. okf sync-export prints a block’s payload.
Both writing commands print a diff first and write only with --apply.
okf sync-statusokf sync-update --applyLimits
Section titled “Limits”- A canon needs a keeper.
- Too much canon sets hard. Only what is stable belongs in it.
- Project-specific rules stay local.
In short
Section titled “In short”The canon makes knowledge shareable, checkable and current. It is the base for context management and for a controlled tag vocabulary.
See also Canon blocks and Define canon knowledge.