@erclx/canon 5.30.0 → 5.32.0

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.>
-```

package/standards/wireframes.md

@@ -1,143 +0,0 @@
----
-title: Wireframe reference
-description: Shape and content rules for canon/wireframes/<surface>.md files
-paths:
-  - 'canon/wireframes/**'
-rule:
-  - 'Read it before adding or revising a surface.'
----
-
-# Wireframe reference
-
-Applies to per-surface entries under `canon/wireframes/`. Skip for `index.md`, which is regenerated by `canon indexes regen`.
-
-A wireframe file captures the spatial layout and interaction intent of one UI surface. It is not an implementation log. The check for any single line: would it still be true if the surface were rebuilt in a different framework? If not, it belongs in `canon/context/`.
-
-## Scope
-
-Governs per-surface wireframe entries under `canon/wireframes/`: layout, variants, on-screen copy, and interaction intent.
-
-Does not govern:
-
-- Tokens, typography, spacing, and the rest of the visual system: `design.md`
-- The mechanism behind a surface: `context.md`
-- Voice, rhythm, and sentence construction in wireframe prose: the `write-human` skill
-- Punctuation, formatting, and word choice in wireframe prose: `markdown.md`
-
-## What a working wireframe looks like
-
-A wireframe works when someone can rebuild the surface from it without opening the components:
-
-- What regions are on screen, by name, and where does each sit relative to the others?
-- Which states can a visitor reach, what triggers each, and where is its captured evidence?
-- What does its structural copy say, word for word, and where does its long-form content come from?
-- What was deliberately left off the surface?
-
-A wireframe that fails these is non-conforming regardless of whether it satisfies every section rule below. The sections are the means. These four questions are the test.
-
-## Transcription wireframes
-
-A wireframe regenerated from an already-built surface's own render code may carry what the sections below forbid: the source file and function, the class or token names driving each region, and pixel-exact geometry. Open the file by naming that source: the render function, the stylesheet rule, or the built file the block was read off. The citation is what separates a transcription wireframe from one that merely broke the rules below, since a role label with nothing behind it is unchecked and a class name traced to a real file and line is not.
-
-A drafted-ahead wireframe states intent in role terms because nothing exists yet to check it against. A regenerated one is checkable against the code it mirrors, and a role label standing in for the real class name would throw that check away. The two documents answer different questions, so one set of rules cannot govern both.
-
-Route detail the source citation does not already carry to `canon/context/` as usual: algorithms, event-handler code, workarounds, and rejected approaches stay out of the wireframe regardless of which mode it is written in.
-
-## Frontmatter
-
-- `title` (required): sentence case, names the surface (`Header`, `Section nav`, `Footer`).
-- `description` (required): one line on when and where the surface appears.
-
-Both fields feed `canon/wireframes/index.md` when regenerated.
-
-## Regions
-
-- Name every region the surface holds, in a bullet list ordered as a reader scans the page, each with where it sits relative to the others: `- Act pane: right of the answer from 1024 up, an overlay below 1024`. These names are the vocabulary plans, picks, and tests use, and the placement is what a list without a sketch would otherwise lose. Pixel sizes stay in `canon/DESIGN.md`.
-- Draw an ASCII block inside a `plaintext` fence only for a layout that is not built yet. Label regions with `←` annotations, show a region's role rather than its styling, and keep the proportions honest.
-- Remove the fence in the change that first captures evidence for the layout. The capture is the exact picture, and a sketch kept beside it drifts from it. A wireframe carrying both a sketch and an evidence folder for the same layout is non-conforming.
-- Give a layout that changes across a breakpoint its own entry under the list, named by what triggers it (`At 1024 and wider`), not by an arbitrary label. A wider gutter alone is not a new layout.
-- Keep one surface per file, indexed by `index.md`.
-
-## States
-
-- List every state a visitor can reach in one table: the state name, what reaches it, what it shows in words, and its evidence folder.
-- Name a state in plain kebab case (`answered`, `refused`) and name its evidence folder the same way, with no ordinal prefix. The table carries the reading order, so a state added in the middle renames nothing.
-- Keep the table and the evidence folders one-to-one. A state with no capture yet reads `not captured` in its evidence cell, which is the one exception, and it stays visible until the capture lands.
-- Add an H3 below the table only for a state that needs more than its row: what differs from the regions in words, and its own copy or behavior.
-
-## Copy
-
-- Carry short structural text verbatim, in the ASCII block or a short list below it: labels, headings, empty-state strings, and nav or footer copy. The wireframe is the source of truth for this text.
-- Cite the source file for long-form or article-body content instead of duplicating it. A lede sentence or a body paragraph pulled into an ASCII figure drifts the moment its source changes, and nothing checks a fenced block against prose elsewhere. A citation elsewhere in the file does not excuse the block itself from still carrying the duplicate. Trim the block once the citation exists.
-- Mark copy that is dynamic or templated so a reader does not treat a placeholder as final text.
-
-## Behavior
-
-- Describe interaction intent: what the visitor does and what changes on screen.
-- State the rule, not the mechanism. `The rail tracks the active section as the visitor scrolls` is intent. The scroll handler, throttle, and observer margins are not.
-- Keep it to a short list. A Behavior section longer than the regions and states is a sign implementation detail has leaked in.
-
-## Not on this surface
-
-- State what was deliberately left off, one bullet per exclusion, as a present-tense rule: `- No navigation rail`. This is the section that stops a draft from proposing what was already ruled out.
-- Keep the reason to a clause where one is needed. Cut the rounds that ruled it out.
-
-## What moves out
-
-- Which candidate beat which, and when: nowhere. Cut it, since git keeps the old text
-- Measurements such as contrast ratios and timings: `canon/DESIGN.md` for tokens and floors, the surface's context entry for the rest
-
-## What moves to canon/context/
-
-This section does not govern a transcription wireframe's citation of its own source. See `## Transcription wireframes`. Implementation detail that answers how the surface is built belongs in a `canon/context/` entry, not the wireframe:
-
-- Algorithms, event-handler code, and lifecycle ordering
-- Framework component names, props, and CSS class or token names
-- Pixel-exact spacing, timing constants, and observer thresholds
-- Workarounds and rejected approaches
-
-Reference the context entry from the wireframe by path when a reader needs the mechanism. The wireframe stays answerable on its own for layout and intent.
-
-## Maintenance
-
-- When a surface's layout or interaction changes, update its wireframe file in the same PR. A wireframe showing a defunct layout is worse than none.
-- When a state is added, removed, or renamed, update its row and its evidence folder in the same PR.
-- The Behavior and Copy prose around an ASCII block is prose and follows `markdown.md` and the `write-human` skill. The fenced block itself is not, so a check scoped to prose is the wrong thing to rely on for what sits inside it.
-
-## Template
-
-```markdown
----
-title: <Surface name>
-description: <when and where the surface appears>
----
-
-# <Surface name>
-
-<One paragraph: what the surface is for and what it covers.>
-
-## Regions
-
-- <Region>: <what it holds>, <where it sits relative to the others>
-- <Region>: <what it holds>, <where it sits relative to the others>
-
-## States
-
-| State   | Reached when | Shows      | Evidence                   |
-| ------- | ------------ | ---------- | -------------------------- |
-| <state> | <trigger>    | <in words> | `<evidence-root>/<state>/` |
-
-## Copy
-
-- <on-screen text, word for word>
-- <text the surface templates>: <marked so a reader does not read it as final>
-- <long-form content>: cited at <its source file>, not duplicated here
-
-## Behavior
-
-- <what the visitor does, and what changes on screen>
-
-## Not on this surface
-
-- <what was deliberately left out, as a present-tense rule>
-```

package/tooling/claude/seeds/.claude/memory/index.md

@@ -1,8 +0,0 @@
----
-title: Memory
-subtitle: Session facts with no owning surface, grouped by kind. Feedback is the working set.
----
-
-# Memory
-
-Session facts with no owning surface, grouped by kind. Feedback is the working set.

package/tooling/claude/seeds/canon/ARCHITECTURE.md

@@ -1,23 +0,0 @@
-# Architecture
-
-Authoring guidance: the architecture standard.
-
-## Overview
-
-This record holds at most 12 decisions, at most 150 words a decision, and at most 6 risk bullets.
-
-## Key technical decisions
-
-### Stack and runtime
-
-What was chosen, the alternative that lost, and why.
-
-### Delivery
-
-### Enforced boundaries
-
-### Layout
-
-### Build principles
-
-## Risks / open questions

package/tooling/claude/seeds/canon/wireframes/index.md

@@ -1,8 +0,0 @@
----
-title: Wireframes
-subtitle: Per-surface regions and states loaded on demand
----
-
-# Wireframes
-
-Per-surface regions and states loaded on demand