@erclx/canon 5.31.0 → 5.33.0

package/standards/architecture.md

@@ -1,127 +0,0 @@
----
-title: Architecture reference
-description: Shape and content rules for canon/ARCHITECTURE.md
-paths:
-  - 'canon/ARCHITECTURE.md'
-rule:
-  - "Add a decision here only when it fills one of the standard's slots, and write any other decision into the context entry for the domain it constrains. At the record's stated cap, merge or retire an entry before adding one."
----
-
-# Architecture reference
-
-Applies to `canon/ARCHITECTURE.md`. Describes the system shape and the decisions behind it, not a tutorial, setup guide, or implementation walkthrough. Pair it with `CLAUDE.md`: session behavior lives there, and the system's shape lives here. Update when a decision is made or a risk is resolved.
-
-## Scope
-
-Governs the system-shape document at `canon/ARCHITECTURE.md`: the overview, the decision entries, and the open risks.
-
-Does not govern:
-
-- Per-domain structure and narrative: `context.md`
-- Setup commands and install instructions: `readme.md`
-- Product scope, goals, and non-goals: `requirements.md`
-
-## What goes in
-
-- A high-level overview of how the system is structured and why
-- Key technical decisions as named H3 entries, each filling one of the five slots below: what was chosen and why over the alternatives
-- Risks and open questions still unresolved
-
-A decision belongs here only when it fills a slot:
-
-- Stack and runtime: the language, the runtime, and the major libraries the system is built on
-- Delivery: how the system's content or code reaches the place it runs
-- Enforced boundaries: a boundary the system checks mechanically, and what enforces it
-- Layout: how the project's top-level roots and context tiers divide what they hold
-- Build principles: a rule for how a behavior is built that changes work in more than one domain, stated in one sentence
-
-The slots come from a scale test. Ask whether the decision would still be in this file if the project were ten times its size. At that size an always-loaded file holding one entry per decision fits no context window, and what survives is the shape: the stack, the delivery, the boundaries, the layout, and the principles. A decision that fits no slot is a domain decision, and its home is that domain's `canon/context/<domain>.md` entry under `## Decisions`, however many domains its reasoning touches. Reach is not the test, since nearly every decision reaches a second domain.
-
-## What does not go in
-
-- How individual functions work line by line. The code carries its own behavior.
-- Full type definitions. They live in code. Reference the shape conceptually if needed.
-- A decision that fills no slot. It lives in the domain context entry it constrains, and this file carries at most one line pointing at it.
-- A measurement paragraph specific to one domain's own mechanism, even behind a slot decision. Route it to that domain's context entry and keep the choice, the alternative that lost, and one reason here.
-- The instances of a build principle. The principle takes one sentence here, and each instance lives in the domain entry where it applies.
-- The history of how a decision was reached or revised: rounds of candidates, a figure followed by its correction, a branch or change that moved a number. Cut it. Git and the change that introduced it keep the trail.
-
-## Sections
-
-Use `## Overview`, `## Key technical decisions` with one named H3 per decision, and `## Risks / open questions`. Name each decision and give the reasoning, especially for non-obvious choices. Skip entries where the rationale is self-evident.
-
-## Keeping it current
-
-- Rewrite a decision a later one changed rather than appending the change beside it. A reader should find the design that stands in one place, with the alternative that lost stated once.
-- Hold only what is open under `## Risks / open questions`. An entry leaves the section in the change that settles it, becoming a decision here when it fills a slot and moving to the domain context entry it constrains when it does not.
-- Carry an optional `reviewed: YYYY-MM-DD` frontmatter field naming the day someone last read the record whole for drift. Whoever finishes that review sets it as the review's last edit, and `canon records stale canonical` reads it to count the releases shipped since. A record with no field reads as never reviewed.
-
-## Verification anchors
-
-A decision's reasoning stays correct while the numbers it cites move. The anchor records what a measured claim was read against, so a reader can tell a number that was checked and held from one nobody has looked at since.
-
-- Close a decision entry whose reasoning cites a measured number with a trailing sentence naming the short commit SHA and the ISO date that number was read: `Measured at <short-sha> on <YYYY-MM-DD>.`
-- Name a commit, never a pull request number or a branch. A branch is gone after merge, and a pull request number resolves only on the forge.
-- Carry one anchor per figure. When a number is re-measured, rewrite the number and its anchor in place, and leave the old value to the change that moved it.
-- Point at a generated file that already records a figure and its commit, rather than copying the figure and anchoring the copy.
-- Anchor on the number alone. A decision citing none takes no anchor whatever its reasoning rests on, because a marker over a claim nobody can re-measure is one no reader can falsify.
-- Anchor a decision when writing it or when amending its reasoning. Leave an entry written before the rule unanchored rather than dating it by blame, which is archaeology for a marker nothing reads back.
-- Read an absent anchor as unchecked rather than as current. On an entry citing no number there is nothing to check. On one citing a number the number is due a read.
-- Do not edit a claim in the pass that first anchors it. The anchor states what the claim was measured against, so changing both at once leaves nothing to check the anchor against.
-- Refresh the anchor whenever the number is re-read, whether or not it moved. A confirmed number and an unread one are the same text without the date.
-
-## Revisit condition
-
-A decision says why it won and rarely says when that reason stops holding, so an entry can go stale while every word in it stays true. The revisit sentence names the finding that would show the harm the decision prevents has gone or moved.
-
-- Close each decision with one sentence of the form `Revisit when <finding>.` Name something a reader could notice, such as a platform release, a measured count crossing a line, or a dependency dropping a behavior.
-- Draft it from the harm the decision prevents, never from the mechanism it uses. A mechanism can keep working long after the reason for choosing it is gone, so re-checking it confirms the wrong fact.
-- Place the sentence after the reasoning and before any verification anchor, so the anchor stays the entry's last sentence.
-- Give a heading holding several principles one sentence, for the premise they share, rather than one per principle.
-- Adopt the requirement by stating the clause `Every decision closes with a revisit sentence.` in the record itself. The clause is the record's own, like the caps, so a checker reads it from the file and gates only a record that states it. A record stating none is reported and never gated.
-- A checker reads presence alone. A vacuous sentence passes it, so the sentence is only as useful as the finding it names.
-
-## Caps
-
-Every session pays for this file before any work starts, so a heavy read is a real cost. Weight comes from two places, too many decisions and decisions written too long, so the record caps both, and caps the open risks beside them.
-
-- State each cap in the record itself. A checker reads only these spellings, so a clause worded another way is reported and never gated:
-  - `This record holds at most <n> decisions.`
-  - `at most <n> words a decision`, counting a decision's prose below its heading, fenced lines left out
-  - `at most <n> risk bullets`, counting every list item under `## Risks / open questions`, nested ones included
-- The three can share one sentence, such as `This record holds at most 12 decisions, at most 150 words a decision, and at most 6 risk bullets.` Each cap is the record's own, so a record stating none is measured and never gated. The template and the seed a new project installs state all three, and a project loosens one by editing the number in its own record.
-- Set the decision cap near one decision per slot plus a small margin, the word cap near what one trade takes to state, about 150, and the risk cap at what a reader holds in mind at once, about 6.
-- At the decision cap, merge two decisions or retire one before adding another, and name which in the change that does it. Never pack two decisions under one heading, which the count cannot see.
-- At the word cap, cut a decision to the choice, the alternative that lost, the reason, and the revisit sentence. What it sheds is a mechanism or a measurement, which goes to the domain context entry it constrains, never under a second heading.
-- At the risk cap, drop what is no longer open before adding a risk.
-- Retire a decision by moving it to the domain context entry it constrains, not by deleting its reasoning.
-- The whole file's word count stays a report, read alongside the judgment, and never gates.
-- Yield to the paragraph weight checkpoint in `markdown.md`. A paragraph past the checkpoint is a defect no length guideline licenses.
-
-## Template
-
-The revisit sentence closes the reasoning of every decision. The anchor sentence follows it on a decision whose reasoning cites a measured number and is absent from one that cites none. Each heading below names a slot, so a record starts with one decision per slot and renames each heading to the choice it records.
-
-```markdown
-# Architecture
-
-## Overview
-
-This record holds at most 12 decisions, at most 150 words a decision, and at most 6 risk bullets. Every decision closes with a revisit sentence.
-
-## Key technical decisions
-
-### Stack and runtime
-
-What was chosen, the alternative that lost, and why. Revisit when <finding>. Measured at <short-sha> on <YYYY-MM-DD>.
-
-### Delivery
-
-### Enforced boundaries
-
-### Layout
-
-### Build principles
-
-## Risks / open questions
-```

package/standards/memory.md

@@ -1,158 +0,0 @@
----
-title: Memory reference
-description: Filename and type prefix, frontmatter, the body shape per type, links between entries, and the lifecycle from write to retire
-paths:
-  - '.canon/memory/**'
----
-
-# Memory reference
-
-Applies to a memory entry at `.canon/memory/<type>-<slug>.md`. One file holds one rule or one fact, written at the end of the session that produced it and read by a session that holds none of it. Which surface owns a given fact is settled before an entry is written at all, and that routing is project policy rather than a shape rule.
-
-The folder is gitignored, and backed wherever a records remote is configured: `canon records push` and `canon records pull` protect it against the machine being lost there, refuse with `no-remote` where it is not, and protect nothing against an entry deleted before anyone has pushed. That is why the retire step below is a move rather than a cleanup: a retired entry stays readable regardless of push timing, where a deleted one is gone the moment nothing has captured it yet.
-
-## Scope
-
-Governs a memory entry under `.canon/memory/<type>-<slug>.md`: the filename and its type prefix, the frontmatter, the body shape each type carries, links between entries, and the lifecycle from the first write to retirement.
-
-Does not govern:
-
-- The per-domain entry a domain fact is routed to instead of memory: `context.md`
-- The feature plan a session executes, and its answer contract: `plan.md`
-- The task file tracking what is being built: `tasks.md`
-- Voice, rhythm, and sentence construction: the `write-human` skill
-- Headings, punctuation, word choice, and file references: `markdown.md`
-- Which facts a project captures at all, and where the folder sits, which are project policy
-
-## What a working entry looks like
-
-An entry works when a session holding none of the conversation that produced it can act on the rule from the file alone:
-
-- What is the rule or the fact, stated in one line?
-- What happened in a session to earn it, so a later reader can tell whether it still holds?
-- When does it fire next, and what does the reader do at that moment?
-- Does another surface already own this, which would make the entry a duplicate of something sessions trust more?
-
-An entry failing these is non-conforming even when it satisfies every shape rule below.
-
-## Types
-
-Four types, and the type decides both the filename prefix and the body shape.
-
-| Type        | Holds                                                                | Fires on                                    |
-| ----------- | -------------------------------------------------------------------- | ------------------------------------------- |
-| `feedback`  | a correction or a confirmed approach governing how the agent works   | explicit correction, or the same slip twice |
-| `project`   | a decision, constraint, or measured fact not derivable from the code | first disclosure                            |
-| `user`      | role, expertise, responsibilities, or working preferences            | first disclosure                            |
-| `reference` | a pointer to an external system, repository, or channel              | first disclosure                            |
-
-Hold a feedback entry to the higher bar. A first-occurrence slip is noise, and a folder that records every one of them buries the rules that were paid for.
-
-Write no entry for a fact another surface already owns. A fact about a domain belongs in that domain's entry, where sessions working the domain already read it, and the same fact in memory sits in a folder nothing opens. Memory keeps the residue, which is whatever the ownership test leaves rather than any one type.
-
-## Filename
-
-- Name the file `<type>-<slug>.md`, with `<type>` one of the four above and `<slug>` kebab-case naming the rule rather than the incident.
-- Write one rule per file. Two rules under one slug cannot be retired or promoted separately, and one of them always outlives the other.
-- Keep the prefix and the `category` field the same fact in two spellings. A prefix outside the four types reads as a fifth type to anything grouping the folder, and it silently belongs to none.
-
-## Frontmatter
-
-Every entry carries the three required fields, and a reviewed entry carries a fourth.
-
-```yaml
----
-title: A scope glob wide enough for a correct run can be wide enough for every wrong one
-description: Omit a declaration key whose only passing value admits the whole tree
-category: Project
-reviewed: 2026-09-26
----
-```
-
-- `title` (required): the rule stated as a line a reader can act on, in sentence case.
-- `description` (required): one line naming what the entry settles, so a reader scanning the catalog decides whether to open it.
-- `category` (required): the type in sentence case, which is what groups the catalog.
-- `reviewed` (optional): the `YYYY-MM-DD` date a review last read the entry and kept it. A review writes it and capture never does, so an entry without the field has never been reviewed. A rewrite of the entry carries the field through untouched, since dropping it sends a kept entry back to the front of the queue.
-
-Never write the filename stem as the `title`. The stem is a slug, and an entry titled with it reads as an unwritten file in every catalog that renders the field.
-
-Quote a `description` opening with a backtick or a colon. An unquoted one fails to parse and takes the whole folder's catalog with it.
-
-## Body
-
-A `feedback` or `project` body carries three parts in this order. Blank lines between them are optional and the three parts are not.
-
-- The rule or the fact, stated in one or two sentences as something to do rather than something that happened.
-- A `**Why:**` line naming the session signal that earned it. This is what a later reader tests the rule against when the tree has moved.
-- A `**How to apply:**` line naming the next moment the rule fires and what to do then.
-
-A `user` or `reference` body is a single sentence and carries neither marker. There is no rule to apply and no signal to date, so the two lines would be filler.
-
-Capture the pattern rather than the recovery. What was tried, what failed, and who noticed belong to the session that is ending, and a body carrying them is a story where the next reader needs an instruction.
-
-## Links
-
-Link a related entry as `[[name]]`, where `name` is the target's filename stem without the extension. Link freely: an entry sits flat at the top level and the links are the only structure among them. `review/` and `archive/` hold receipts and retirements rather than entries, so neither takes a link.
-
-- Place links inside the body part they support, not in a list of their own at the end.
-- A link naming an entry nobody has written yet is legal, and it marks a rule worth writing rather than a defect.
-- A bracketed token inside a code span is not a link. Backticked syntax from another language routinely reads as one.
-
-## Lifecycle
-
-- Check the folder for an entry on the same topic before writing a new one, and update that entry in place when one exists. Two entries on one rule disagree the moment either is edited.
-- Rewrite an entry the tree has moved under rather than appending a second passage narrating the change. A reader cannot tell which of two claims is current.
-- Never delete an entry. Retire one by moving it to an archive under its own name, because a bulk judgment made before the next push has no undo behind it, and moving keeps the record where deleting would not.
-- Treat the folder as a holding pen rather than a destination. An entry whose rule belongs on a durable surface is promoted there and retired here, and the rest is what the pen is for.
-
-The catalog is generated from sibling frontmatter rather than authored. Never hand-edit it, since the next regeneration discards whatever was added by hand.
-
-## Reading
-
-Nothing loads the pen into every session, and that is the design. An entry reaches a reader through one of three paths:
-
-- A review reads the pen in batches, taking entries in the order `canon records stale memory` reports: due entries first, those citing a path the tree no longer holds ahead of the rest, then the longest unreviewed.
-- A resuming session reads the entries matching the task it picks up.
-- Capture reads the catalog to find an existing entry on the same topic before writing a new one.
-
-An entry none of the three reaches is one the pen holds for a review to promote or retire.
-
-## Collecting a review receipt
-
-A review of the pen writes a receipt recording what it proposed per entry and what was decided. The receipt is collected once every item on it has resolved, and it is held while any item is still pending, since a pending item is decision state the next round reads back.
-
-Fold the declines before the receipt goes. A promoted entry survives in its target and in git and a retired one survives in the archive, so the one thing a receipt uniquely holds is the record that a rule was considered and turned down.
-
-- Fold into the entry the item was about, and only into that entry. A decline whose proposed target was another surface still lands here.
-- Fold a `feedback` or `project` entry alone. The decline belongs in the `**Why:**` line, which is what a later reader tests the rule against.
-- Fold nothing into a `user` or `reference` entry. Its body is one sentence carrying neither marker, and such an entry is declined for having no in-repo target, which its type already states. Writing that on the entry restates the type and breaks the body shape.
-- Record the decline by rewriting the entry, never by appending to it, per the lifecycle rule above.
-
-Which surface runs the collection is project policy. More than one may, so a collector finding no receipt has been beaten to it rather than misconfigured.
-
-## Anti-patterns
-
-- **The domain fact filed as memory.** It reads as a capture and lands in the one folder no session opens while working that domain.
-- **The incident narrative.** A body recounting what went wrong states no rule, so the next reader has to infer one and infers a different one.
-- **The entry titled with its own slug.** Every catalog rendering the field shows a filename where the rule should be.
-- **The duplicate written beside the original.** Two entries on one topic drift, and nothing says which is current.
-- **The first-occurrence capture.** A folder recording every slip buries the rules that repeated.
-- **The entry deleted on retire.** The folder has no history, so the judgment that discarded it cannot be reviewed or reversed.
-
-## Template
-
-```markdown
----
-title: <the rule, stated as a line a reader can act on>
-description: <one line naming what the entry settles>
-category: <Feedback|Project|User|Reference>
----
-
-<the rule or fact, in one or two sentences, as something to do>
-
-**Why:** <the session signal that earned it, with the measurement where one exists>
-
-**How to apply:** <the next moment it fires, and what to do then> See [[related-entry]].
-```
-
-A `user` or `reference` entry carries the same frontmatter and a single sentence in place of the three parts.

package/standards/mermaid.md

@@ -1,64 +0,0 @@
----
-title: Mermaid reference
-description: Direction and layout, node and edge budgets, accessibility fields, label punctuation, and render verification for a Mermaid diagram
----
-
-# Mermaid reference
-
-Applies to every Mermaid fence, wherever it is written. A fence sits inside a document some other standard shapes, so this file reaches the drawing and stops at the fence markers.
-
-## Scope
-
-Governs the Mermaid attribute wherever a fence is written, naming no path because an attribute standard governs a drawing rather than a document type: direction and layout, node and edge budgets, the accessibility fields, how punctuation reaches a label, and how a rendered diagram is verified. It carries no template, since a fence has no document shape of its own and sits inside one another standard sets.
-
-Does not govern:
-
-- Which architecture view a figure draws and what question it answers: the `draft-figure` skill's architecture set
-- Language, word choice, punctuation, and formatting in the prose around a fence: `markdown.md`
-- Voice, rhythm, and sentence construction in that prose: the `write-human` skill
-- The mechanism behind any component a diagram draws: `context.md`
-
-## What a working diagram looks like
-
-A diagram works when a reviewer holding the rendered image, and nothing else, answers yes four times:
-
-- Did the declared direction hold?
-- Is every row of siblings free of a sequential reading the system does not have?
-- Is every convergence free of a crossing edge bundle?
-- Is it taller than wide, outside a sequence diagram?
-
-A diagram failing these is non-conforming even when it satisfies every shape rule below. The rules are the means. These four questions are the test.
-
-## Layout
-
-- Declare `flowchart TB` by default. Mermaid ignores a subgraph's direction whenever that subgraph links outward, and an architecture diagram links across its subgraphs as the normal case, so top-bottom is a declaration rather than a guarantee.
-- Restructure a diagram that renders diagonal or left-to-right. Repeating the direction keyword does not fix it.
-- Render a context, component, or pipeline diagram taller than wide. A `sequenceDiagram` is wide by construction and is exempt.
-- Do not let independent nodes render in a row. A row of siblings reads as a sequential chain and asserts a pipeline the system does not have.
-- Do not converge many edges on one node from one side. A crossing bundle is unreadable whatever it encodes.
-- Keep node labels short. Three or four words max. Detail goes in the paragraph below the diagram.
-- Use `<br/>` for a second short line on a node when the label is two ideas, never for a sentence.
-- Subgraphs are for grouping unrelated lanes such as offline versus online or browser versus server. Do not subgraph a single linear flow.
-
-## Budgets
-
-- Hold a diagram to roughly 5 to 10 nodes. Split it past 15.
-- Watch edge count harder than node count. It binds first, and a diagram whose edges outnumber its nodes is already too dense to read.
-- Treat a diagram that cannot be described in one sentence as two diagrams.
-- Warn rather than refuse on a budget, and name the split that would fix it. These numbers come from published Mermaid practice rather than from a measurement against a corpus, so a hard refusal on them will be wrong sometimes and unarguable when it is.
-
-## Labels
-
-- Apply the punctuation bans in `markdown.md` to node and subgraph labels. A label is not prose, so a check scoped to prose does not reach it, and reading the labels before shipping is the only gate they have.
-- Treat the prose around a fence and the text inside it as two surfaces. The paragraphs are prose and follow `markdown.md` and the `write-human` skill. The fenced block is not, which is why a check scoped to prose is the wrong thing to rely on for what sits inside it.
-
-## Accessibility
-
-- Give every diagram `accTitle` and `accDescr`. `accTitle` names what the diagram answers. `accDescr` states the structure in one sentence for a reader who cannot see the render.
-
-## Verification
-
-- Judge a diagram from its rendered image, not from its source. Direction, sibling rows, and edge bundles are visible only in the output.
-- Render to PNG. An SVG export reads back as markup with no recoverable spatial meaning.
-- Apply the four questions above as a reviewer, against the same render the author judged.
-- State which verification was skipped when no renderer is available. A diagram written without a render is still shippable, and one reported as verified without a render is not.

package/standards/requirements.md

@@ -1,79 +0,0 @@
----
-title: Requirements reference
-description: Shape and content rules for canon/REQUIREMENTS.md
-paths:
-  - 'canon/REQUIREMENTS.md'
----
-
-# Requirements reference
-
-Applies to `canon/REQUIREMENTS.md`. Describes what the product does and why, not how it works. Update when scope changes, goals shift, or a non-goal is promoted to a feature.
-
-## Scope
-
-Governs the product-scope document at `canon/REQUIREMENTS.md`: problem, goals, non-goals, MVP features, distribution, and constraints.
-
-Does not govern:
-
-- Rationale for a technical choice: `architecture.md`
-- Execution order across the work the scope generates: `board.md`
-- Per-domain structure and narrative: `context.md`
-
-## What goes in
-
-- The problem being solved and for whom
-- User-facing goals stated as outcomes, not implementation
-- Explicit non-goals that prevent feature creep. Mark deferred items "(deferred)" so they read as paused, not excluded. A non-goal resting on how an outside tool, an installer, or the model behaves may close with one `Revisit when <finding>.` sentence, and a non-goal resting on scope alone takes none.
-- MVP features as a numbered list: feature name and one-line description
-- Hard constraints that shape every decision
-
-## What does not go in
-
-- Implementation details, API names, or internal component references
-- Anything that describes how a feature is built rather than what it does
-- Measured results, such as scores, benchmark figures, or token counts. They move on every run and this file changes least. Name where the results live instead.
-- Content another canonical doc owns, such as the stack list, which the stack-and-runtime slot of `canon/ARCHITECTURE.md` holds, or the rules of this standard itself
-
-## Sections
-
-Use `## Problem`, `## Goals`, `## Non-goals`, `## MVP features`, and `## Constraints`. Add `## Distribution` when the rule below applies. Add `## Worldview` when the project holds beliefs that shape every decision, and keep a belief there only when it changes a decision, since a padded worldview turns into a second goals list. Add `## Premise` when the project exists to answer a question, stated as the question and what would count as an answer, never as the answer measured so far. Drop a section rather than pad it with filler.
-
-## Length
-
-This file loads into every session, so its weight is paid before any work starts. Cap it by stating the clause `This record holds at most <n> words.` in the record itself, where a checker reads it and counts every word below the frontmatter. The cap is the record's own, so a record stating none is measured and never gated. The template and the seed a new project installs state it at 600, and a project loosens it by editing the number in its own record. At the cap, cut a goal or a constraint that no longer changes a decision before adding one.
-
-## Lifecycle
-
-Once every entry in the MVP list, or in a later scope section, has shipped, delete the section. Git keeps the old text, and the document states the project as it stands. Do not annotate an entry as shipped and leave it in place. While any entry is unshipped, do not renumber the list or append to it.
-
-The record may carry an optional `reviewed: YYYY-MM-DD` frontmatter field naming the day someone last read it whole for identity drift. Whoever finishes that review sets it as the review's last edit, and `canon records stale canonical` reads it to count the releases shipped since. A record with no field reads as never reviewed.
-
-Later scope arrives as a new section rather than as an extension of the MVP list. Name the section for what it delivers and state its entries as outcomes, the same way the goals are stated. Nothing sequences either list into versions. Work reaches the board as discrete tasks under `tasks.md`, and `board.md` orders them by readiness, so a section here states what is wanted and never when it lands.
-
-## Distribution
-
-Include `## Distribution` only when the project ships to consumers outside its own repository. An internal service or a monorepo application has nothing to put in it, and a section every project is told to fill is one most projects pad. Place it after `## MVP features`.
-
-State each entry as an outcome the consumer reaches, never as the mechanism that delivers it. A registry name, a manifest format, a version scheme, or a release tool is implementation and belongs in `canon/ARCHITECTURE.md`. Distribution pulls harder toward mechanism than any other section, which is why the rule is repeated here.
-
-## Template
-
-```markdown
-# Requirements
-
-This record holds at most 600 words.
-
-## Problem
-
-## Goals
-
-## Non-goals
-
-## MVP features
-
-1. Feature: description
-
-<!-- ## Distribution: include only when shipping outside the repository -->
-
-## Constraints
-```

package/standards/wiki.md

@@ -1,77 +0,0 @@
----
-title: Wiki reference
-description: Folder split, frontmatter, naming convention, and sourcing for a wiki reference page
-paths:
-  - 'wiki/**/*.md'
-rule:
-  - 'Read it before drafting a page. Do not work the placement criterion or the naming convention from memory.'
----
-
-# Wiki reference
-
-Applies to each authored page under `wiki/`. Skip for `index.md` at any depth, which is a hand-maintained catalog rather than a reference page, and carries `subtitle` rather than `description`.
-
-## Scope
-
-Governs each authored page under `wiki/`: which folder it belongs in, its frontmatter, its filename, and how it cites the subject it documents.
-
-Does not govern:
-
-- Voice, rhythm, sentence construction, and information density: the `write-human` skill
-- Headings, punctuation, word choice, and file references: `markdown.md`
-
-## What a working wiki page looks like
-
-A page works when a reader who has never opened it settles two things without asking anyone:
-
-- Which folder holds it, decided from the subject alone rather than from where it happened to get written
-- Where the content came from, so a claim can be checked against its owner rather than against this repository
-
-A page failing either is non-conforming even when it satisfies every shape rule below.
-
-## Placement
-
-- Write a page here only when its subject is owned outside this repository. Route anything about how this repository works to `docs/`, `canon/context/`, or a skill body instead.
-- File the page under `wiki/claude/`. A subject Anthropic does not own, whether a third-party tool or a vendor-neutral concept, is out of scope for this folder split. Route it to `docs/` or a skill body instead of adding a second wiki folder for it.
-
-## Frontmatter
-
-- `title` (required): sentence case, naming the subject
-- `description` (required): one line naming what the page covers
-
-## Naming
-
-- Name a page by its kebab subject alone. The vendor folder it sits in already names the vendor, so a prefix repeats the folder.
-- The `codebase-layout` skill carries the same rule for every folder in a project, beyond the wiki.
-
-## Sourcing
-
-- Close the intro paragraph with a `Source:` sentence naming the owner. Link the canonical page where one exists, and name the owner alone where the subject has no single URL.
-- Link a docs page in its fetchable form, `https://code.claude.com/docs/en/<page>.md`, so a session reads the live text rather than a copy.
-- Fetch current information through the `claude-code-guide` agent when the subject is Claude Code. Do not work from training knowledge.
-- Propose an addition or correction and wait for confirmation. Do not write to a wiki file unasked.
-
-## Shape
-
-- Keep a page thin: the `Source:` sentence, an orientation paragraph, and lesson sections. The source owns the reference detail and a paraphrase of it falls behind within days.
-- Apply the lesson test per section: keep a fact about the subject only when the source page does not state it. Such a fact is a gotcha this project hit, a constraint it relies on, or how it uses the feature.
-- Read the current source before keeping or cutting a section. A fact kept from memory is the drift this shape exists to prevent.
-- Send a session that wants reference detail to the source and fetch it live. The page answers orientation and lessons only.
-- Leave a page with no lessons as the source link and the orientation paragraph. A catalog routes a reader by page, so the stub stays.
-
-## Template
-
-```markdown
----
-title: <Subject>
-description: <one line naming what this page covers>
----
-
-# <Subject>
-
-<What the subject is and why it matters, in a short orientation.> Source: <owner, with a link to the canonical page where one exists>.
-
-## <Lesson>
-
-<A fact the source page does not state.>
-```