@erclx/canon 5.30.0 → 5.31.0

package/src/upstream/releases.ts

@@ -0,0 +1,169 @@
+import { $ } from 'bun'
+import { gitEnv } from '@/git/env'
+import { compareVersions } from '@/upstream/cursor'
+
+const RELEASES_URL =
+  'https://api.github.com/repos/anthropics/claude-code/releases'
+const PER_PAGE = 100
+const MAX_PAGES = 10
+
+/** The subset of a GitHub release the digest reads. */
+export interface Release {
+  readonly tag_name: string
+  readonly published_at: string
+  readonly body: string | null
+  readonly draft?: boolean
+}
+
+export interface ReleaseLine {
+  readonly version: string
+  readonly date: string
+  readonly text: string
+}
+
+export type FetchFailure = 'rate-limited' | 'network' | 'http'
+
+export type PageResult =
+  | { readonly ok: true; readonly releases: readonly Release[] }
+  | {
+      readonly ok: false
+      readonly reason: FetchFailure
+      readonly message: string
+    }
+
+/** Page numbers start at 1. A page past the feed's end comes back empty. */
+export type PageFetcher = (page: number) => Promise<PageResult>
+
+export type Walk =
+  | { readonly kind: 'reached'; readonly releases: readonly Release[] }
+  | { readonly kind: 'cursor-missing'; readonly cursor: string }
+  | {
+      readonly kind: 'failed'
+      readonly reason: FetchFailure
+      readonly message: string
+    }
+
+// Ported from the groundwork's mechanical-drop script. The first group anchors on the line
+// start, the rest match anywhere because the surface they name can sit mid-line.
+const DROP =
+  /^(Fixed|\[VSCode\]|\[Claude Tag\]|\[Code Review\]|Windows:|Self-hosted)|apps gateway|managed setting|OpenTelemetry|Bedrock|Vertex|screen reader/i
+const KEEP = /^(Added|Changed|Removed|Improved|Deprecated)/
+const BULLET = /^\s*[-*] (.*)$/gm
+const DIFFERENCE_LINE = /^(\[[^\]]+\] )?(Changed|Removed|Deprecated)/
+const BACKTICKED = /`([^`]{3,60})`/g
+const DISTINCTIVE = /[-/.A-Z]/
+
+export function versionOf(tag: string): string {
+  return tag.replace(/^v/, '')
+}
+
+export function keepLines(release: Release): ReleaseLine[] {
+  const version = versionOf(release.tag_name)
+  const date = release.published_at.slice(0, 10)
+
+  return [...(release.body ?? '').matchAll(BULLET)]
+    .map((match) => match[1] ?? '')
+    .filter((text) => KEEP.test(text) && !DROP.test(text))
+    .map((text) => ({ version, date, text }))
+}
+
+export function extractIdentifiers(text: string): string[] {
+  if (!DIFFERENCE_LINE.test(text)) return []
+
+  return [...text.matchAll(BACKTICKED)]
+    .map((match) => match[1] ?? '')
+    .filter((name) => DISTINCTIVE.test(name))
+}
+
+/**
+ * Collects the releases newer than the cursor, newest first.
+ *
+ * The walk stops at the first release whose version is not newer than the
+ * cursor, wherever it sits, so a range crossing a page boundary is read whole
+ * and a cursor naming a version the feed never carried, as 2.1.256 is not,
+ * still bounds the range. A feed that ends with every release newer than the
+ * cursor reports `cursor-missing` instead of returning all of it.
+ */
+export async function walkReleases(
+  cursor: string,
+  fetchPage: PageFetcher,
+  perPage: number = PER_PAGE,
+): Promise<Walk> {
+  const collected: Release[] = []
+
+  for (let page = 1; page <= MAX_PAGES; page++) {
+    const result = await fetchPage(page)
+    if (!result.ok) {
+      return { kind: 'failed', reason: result.reason, message: result.message }
+    }
+
+    for (const release of result.releases) {
+      if (release.draft) continue
+      if (compareVersions(versionOf(release.tag_name), cursor) <= 0) {
+        return { kind: 'reached', releases: collected }
+      }
+      collected.push(release)
+    }
+
+    if (result.releases.length < perPage) break
+  }
+
+  return { kind: 'cursor-missing', cursor }
+}
+
+export function githubPageFetcher(
+  env: Record<string, string | undefined> = process.env,
+): PageFetcher {
+  const token = env.GH_TOKEN ?? env.GITHUB_TOKEN
+  const headers: Record<string, string> = {
+    Accept: 'application/vnd.github+json',
+    'User-Agent': 'canon-upstream',
+    ...(token ? { Authorization: `Bearer ${token}` } : {}),
+  }
+
+  return async (page) => {
+    try {
+      const response = await fetch(
+        `${RELEASES_URL}?per_page=${PER_PAGE}&page=${page}`,
+        { headers },
+      )
+      if (response.status === 403 || response.status === 429) {
+        return {
+          ok: false,
+          reason: 'rate-limited',
+          message:
+            'GitHub refused the request. Set GH_TOKEN or GITHUB_TOKEN to lift the hourly limit.',
+        }
+      }
+      if (!response.ok) {
+        return {
+          ok: false,
+          reason: 'http',
+          message: `GitHub answered ${response.status} for page ${page}.`,
+        }
+      }
+
+      return { ok: true, releases: (await response.json()) as Release[] }
+    } catch {
+      return {
+        ok: false,
+        reason: 'network',
+        message: 'The releases feed could not be reached.',
+      }
+    }
+  }
+}
+
+/** The tracked files naming an identifier, as a hint for where to look. */
+export async function grepHint(
+  root: string,
+  identifier: string,
+): Promise<string[]> {
+  const result =
+    await $`git -C ${root} grep -l -F -e ${identifier} -- . ':!wiki'`
+      .env(gitEnv())
+      .quiet()
+      .nothrow()
+
+  return result.stdout.toString().split('\n').filter(Boolean)
+}

package/standards/index.md

@@ -20,7 +20,6 @@ Reference docs for consistent authoring across the toolkit and target projects.
 - [Groundwork spikes reference](groundwork-spikes.md): What each spike in a track's 08-spikes.md records, the sample rule, and the three folders that hold what a spike produced
 - [Groundwork reference](groundwork.md): Folder layout, ordinal naming, reserved numbering, frontmatter and dating, required file contents, and conventions for a measurement track
 - [Intake reference](intake.md): Folder layout, ordinal naming, reserved index number, frontmatter and dating, the item template, the answer contract, and retrieval
-- [Markdown reference](markdown.md): Headings, paragraph and list structure, code spans, the date form, punctuation, emphasis, file references, American spelling, and frontmatter wording
 - [Memory reference](memory.md): Filename and type prefix, frontmatter, the body shape per type, links between entries, and the lifecycle from write to retire
 - [Mermaid reference](mermaid.md): Direction and layout, node and edge budgets, accessibility fields, label punctuation, and render verification for a Mermaid diagram
 - [Plan lifecycle reference](plan-lifecycle.md): When a feature plan is written, where it lives, how it changes mid-flight, and its move to the archive

package/standards/plan.md

@@ -7,6 +7,7 @@ rule:
   - 'Never fill an `- Answer:` slot on behalf of the person who owns it. A blank slot accepts the suggestion at execution time.'
   - 'Never ship a question without a `- Suggested:` line. Write `- Suggested: needs your call, <why>` where the answer turns on preference.'
   - "Rewrite the `- Suggested:` line as `overridden at execution to <pick>,` plus the measurement when execution deviates from an unanswered question, leaving the slot blank. Put the same deviation in one line under the open task's `## Findings`."
+  - 'Fetch the source a decision rests on and quote the passage under `**Sources:**`, or mark the entry `unverified`. Never cite an outside source from recall.'
   - 'Move a shipped plan to `.canon/plans/archive/`. Never delete one.'
   - 'Amend a plan in place when a decision changes. Do not append a second passage narrating the change.'
   - 'Follow the plan lifecycle standard for when a plan is written, how it is amended, and its move to the archive. Read it with `canon standards plan-lifecycle`.'
@@ -51,7 +52,7 @@ A plan failing these is non-conforming even when it satisfies every shape rule b
 
 - Name the file `feature-<slug>.md`, with `<slug>` two to four kebab-case words naming the concern.
 - Write one concern per file. A request spanning two independent concerns takes two plans rather than one bundling both, since a bundled plan cannot be executed by two sessions or abandoned by half.
-- A staged batch is a concern of its own and takes its own file rather than a `**Batch N**` sub-heading inside one plan's `**Files to touch:**`. One plan filename derives one branch, so batches sharing a file have nothing to open a pull request against once the first merges. State a batch's dependency on the ones before it in its own `**Constraints:**`.
+- A staged batch is a concern of its own and takes its own file rather than a `**Batch N**` sub-heading inside one plan's `**Files to touch:**`. One plan filename derives one branch, so batches sharing a file have nothing to open a pull request against once the first merges. State a batch's dependency on the ones before it in its own `**Constraints:**`. A batch that stacks on another and shares most of its files with it folds into that batch as contiguous commits on one branch rather than taking a file, unless its constraints carry ``Judged apart from `feature-<parent>`: <reason>`` with a reason after the colon. `canon records validate plans` reports `stack-foldable` for a stacked batch that has neither.
 - Derive the slug from the concern rather than from a branch, because the plan is written before the branch exists.
 - Give the branch that executes the plan the same slug. A later surface finds the plan from the branch name and finds nothing when the two spellings differ.
 
@@ -61,17 +62,18 @@ A plan carries no frontmatter. Its filename is the whole of its identity, so a f
 
 The document opens with `# Feature: <short title>` and one paragraph stating what is being built and why now. The sections below follow in this order.
 
-| Section               | Holds                                                                     | Required      |
-| --------------------- | ------------------------------------------------------------------------- | ------------- |
-| `## Summary`          | three to five one-line bullets: the goal, the deliverables, the trade-off | Always        |
-| `**Constraints:**`    | durable rules the work must respect                                       | When supplied |
-| `**Files to touch:**` | each file with a one-line reason                                          | Always        |
-| `**Verification:**`   | the test or command that proves each outcome                              | Always        |
-| `**Risks:**`          | conflicts, coupling, and the tricky spots                                 | Always        |
-| `**Review focus:**`   | the inputs or states that would break the change, for the reviewer        | Always        |
-| `**Questions:**`      | numbered open decisions, each with a suggestion and an answer slot        | Always        |
-
-- Write each marker as the table gives it. `Summary` opens the prose a reader scans, so it takes an H2, and the six that follow are labels over lists rather than sections of prose.
+| Section               | Holds                                                                     | Required                                   |
+| --------------------- | ------------------------------------------------------------------------- | ------------------------------------------ |
+| `## Summary`          | three to five one-line bullets: the goal, the deliverables, the trade-off | Always                                     |
+| `**Constraints:**`    | durable rules the work must respect                                       | When supplied                              |
+| `**Files to touch:**` | each file with a one-line reason                                          | Always                                     |
+| `**Verification:**`   | the test or command that proves each outcome                              | Always                                     |
+| `**Risks:**`          | conflicts, coupling, and the tricky spots                                 | Always                                     |
+| `**Review focus:**`   | the inputs or states that would break the change, for the reviewer        | Always                                     |
+| `**Questions:**`      | numbered open decisions, each with a suggestion and an answer slot        | Always                                     |
+| `**Sources:**`        | the outside sources a decision rests on, each with its quoted passage     | When a decision rests on an outside source |
+
+- Write each marker as the table gives it. `Summary` opens the prose a reader scans, so it takes an H2, and the others are labels over lists rather than sections of prose.
 - A section written in the other spelling is still that section, since `## Risks` and `**Risks:**` name one thing. Write the table's form in a new plan and leave an existing plan's spelling alone. Either spelling breaks a depth run.
 - Write `None identified.` under a required section with nothing to report rather than dropping the marker. A dropped section and an unconsidered one read identically.
 - Aim `## Summary` at a person scanning the plan, not at the session executing it. The other sections carry what execution needs.
@@ -118,6 +120,13 @@ A constraint naming a `.canon/ready/` folder is a third shape beside the hold an
 - Write it for the reviewer rather than the builder, since this section is where the planner's understanding of the risk reaches the review pass.
 - Keep it apart from `**Risks:**`. A risk is something the work might collide with, and a focus item is something the finished diff must be shown to handle.
 
+### Sources
+
+- Give each entry a link, the decision it backs, and the passage relied on in double quotes.
+- Mark a source that could not be fetched `unverified` and never quote it. A quote for a page nobody opened is the failure this section exists to prevent.
+- Cite no source that was found and not opened, following the lead rule in `groundwork.md`.
+- Leave the section out when no decision rests on an outside practice or behavior. `canon records validate plans` checks that an entry is well formed, not that every outside claim got one.
+
 ## The suggested-and-answer contract
 
 Every question carries a `- Suggested:` line and an empty `- Answer:` slot below it.
@@ -191,4 +200,8 @@ This contract inverts the one an intake folder keeps, where an empty slot means
 1. <question>
    - Suggested: <pick>, <reason or tradeoff>
    - Answer:
+
+**Sources:**
+
+- [<title>](url), backing <decision>: "<passage relied on>"
 ```

package/standards/rule.md

@@ -57,7 +57,7 @@ The cost is that a project-authored rule's leading digit stops naming its domain
 
 The reservation above divides one pair, being a shipped set against the rules a project wrote for itself. A third source, a rule set held back from targets and installed only where it was authored, needs its own division too. This repository is the one place all three sources exist at once, and it divides the third pair two ways at once rather than one: `canon/` and `internal/` separate a shipped rule from an internal one by location, the same way `project/` separates a project-authored one, and within each subdirectory the numbering still divides by source as well, one source taking the top of the band and the other the gaps between the tens.
 
-The numbering half stays because location alone does not carry to a reader who only sees the number, such as one comparing `claude/567-planning.md` against a citation written before the rules moved into `canon/`.
+The numbering half stays because location alone does not carry to a reader who only sees the number, such as one comparing `claude/566-output.md` against a citation written before the rules moved into `canon/`.
 
 The collision this prevents is silent. Two rules that resolve to the same `<n>-<slug>` path leave one file in the installed folder, and neither the install nor the session that reads it reports which source lost. Nothing checks a division outside the reserved bands, so it holds only while both sources follow it. Separating `canon/` from `internal/` by folder removes the filename-collision case specifically, since the two no longer install to the same directory, but the number still carries the source signal for a reader who has only the number in view.
 

package/tooling/claude/seeds/.claude/hooks/index-reminder.sh

@@ -53,5 +53,5 @@ marker="$marker_dir/$key"
 mkdir -p "$marker_dir"
 : >"$marker"
 
-msg=$(printf 'An index.md exists at %s. Read it before searching this folder, it catalogs the sibling files faster than a blind search. For a cross-folder answer, run canon indexes list --json or invoke the index-lookup skill.' "$index")
+msg=$(printf 'An index.md exists at %s. Read it before searching this folder, it catalogs the sibling files faster than a blind search. For a cross-folder answer, run canon indexes list --json.' "$index")
 jq -nc --arg msg "$msg" '{hookSpecificOutput:{hookEventName:"PreToolUse",additionalContext:$msg}}'

package/claude/skills/index-lookup/REQUIREMENT.md

@@ -1,35 +0,0 @@
----
-name: index-lookup
-description: Why a topic search over the tracked index catalog needs its own skill, and why a folder outside `list`'s walk gets a named pointer instead of a search hit
----
-
-# Index lookup requirement
-
-## Gap
-
-Without this skill, `canon indexes list --json` exists as a verb with nobody wrapping it into a topic-search request. A session either greps the tree by hand, which misses everything the catalog already states in `title` and `description` rather than in file contents, or answers from whichever folder it happened to open, which reports a topic as undocumented when the topic only sits outside the walked corpus: a gitignored indexed folder such as `.canon/tasks/` or `.canon/memory/`, or a README-based record catalog such as `.canon/groundwork/`, neither of which `list` ever reaches.
-
-## Must
-
-- Run `canon indexes list --json` and match the topic against every entry's `title`, `description`, and `path`
-- Check whether the project carries a gitignored indexed folder or a README-based record catalog outside `list`'s walk before naming any of them, since a folder absent from the project names nothing
-- Report zero hits inside the walked corpus as zero hits, never as "not documented," since a folder outside the walk can still hold the answer
-
-## Must not
-
-- Search file contents. A miss against `title`, `description`, and `path` is the whole answer, and grepping the tree is a different request.
-- Extend `canon indexes list` to read a `README.md` catalog or to bypass the gitignore filter. Both are accepted trade-offs the verb already carries, and widening either is a CLI change, not a skill-body change.
-- Regenerate an index on its own initiative. Reporting a stale-looking entry is this skill's job, and writing the fix belongs to `canon indexes regen`.
-- Fire from a request to browse a file whose path is already known, or to search source code, both of which this skill answers nothing for
-- Assume this skill's own invocation frequency needs no check. The reminder hook names it beside `canon indexes list --json`, and a session recognizing a topic-lookup request can trigger it by description, but whether anything reaches for it beyond an operator typing its name has no answer at creation time, so a review pass some months in should read that back rather than take it on faith.
-
-## Guards
-
-- `canon indexes list` does not resolve on an older install. Report that rather than falling back to a manual walk, since a hand-rolled walk here restates the CLI logic this skill exists to call.
-- A folder failing frontmatter validation drops out of `entries` and its message lands in `errors`, per the verb's own per-folder isolation. Report the error alongside the match rather than treating it as a reason to stop.
-
-## Out of scope
-
-- Regenerating or scaffolding an index, which `canon indexes regen` and the `target-setup` skill's `indexes` phase own
-- Reading a folder's contents once a hit names it, which is an ordinary file read rather than part of the lookup
-- Chaining this skill into the `target-setup` skill's `indexes` phase as a verification step. Left independent: that phase already validates through `canon indexes regen --dry-run`, and a second skill call inside a bootstrap flow duplicates a check that already runs.

package/claude/skills/index-lookup/SKILL.md

@@ -1,44 +0,0 @@
----
-name: index-lookup
-description: Answers a topic search over every tracked index.md catalog in the project by running `canon indexes list --json` and matching the topic against each entry's title, description, and path, then reports the hits or names why there are none. Names the gitignored task and memory catalogs and the groundwork and intake record folders as pointers outside its walked corpus, so it never claims a topic is undocumented when the topic only sits there. Use when asked "where is X documented", "is there a page about X", "search the docs for X", "find the index entry for X", or "what covers X". Do NOT use to grep source code, browse a file whose path is already known, or regenerate an index, which is `canon indexes regen`.
-metadata:
-  family: answer
----
-
-# Index lookup
-
-Answers a topic search over the project's tracked `index.md` catalogs, not a text search over file contents. Matches a topic string against every entry's `title`, `description`, and `path`, drawn from wherever `canon indexes list --json` walks.
-
-## Steps
-
-1. Resolve the project root with `git rev-parse --show-toplevel`, falling back to the working directory when the read fails.
-2. Run `canon indexes list --json` from that root.
-3. Read `errors` first. A folder failing frontmatter validation drops out of `entries` and lands its message in `errors` instead, per the verb's own per-folder isolation, so report an error alongside the match rather than reading it as a reason to stop.
-4. Match the topic case-insensitively as a substring against each entry's `title`, `description`, and `path`. Report every match. A lookup with no ranking is honest about what it found, and a single best guess is not.
-5. Check whether the project carries a gitignored indexed folder or a README-based record catalog outside `list`'s walk: `.canon/tasks/`, `.canon/memory/`, `.canon/groundwork/`, `.canon/intake/`. Test each for existence and at least one file inside it before naming it. A folder absent from this project names nothing.
-6. Report the hits, plus a pointer to any outside-the-walk folder found present, per Output below.
-
-## Rules
-
-- Report zero hits as zero hits, never as "not documented." The topic can sit inside a folder step 5 found and named, so an empty walked corpus is a fact about the search, not about the project.
-- Never search file contents. A miss against `title`, `description`, and `path` is the whole answer, and a request that needs a text search calls for grepping the tree instead.
-- Never regenerate or edit an index. Report an entry that reads as stale rather than running `canon indexes regen` on this skill's own initiative.
-- Report an absent `canon indexes list` subcommand rather than falling back to a manual walk. It ships with the CLI, so a project on an older install meets a missing verb, and a hand-rolled walk here restates the CLI logic this skill exists to call instead.
-
-## Output
-
-```plaintext
-Index lookup: "<topic>"
-
-Hits:
-- <path>: <title> — <description>
-
-Outside the walked corpus (check by hand):
-- <folder>: <one-line reason it sits outside list's walk>
-```
-
-Replace the "Hits" block with `No catalog entry matched "<topic>".` when nothing matched. Omit "Outside the walked corpus" when the project carries none of the five folders from step 5, or when every one it carries is empty.
-
-## Reference
-
-Run `canon docs indexes` for the `canon indexes list` flags, exit codes, and JSON shape. It resolves from the toolkit rather than from the target's own tree.

package/governance/rules/canon/601-indexes.md

@@ -1,9 +0,0 @@
----
-description: Check a folder's index before searching its contents
----
-
-# Indexes standards
-
-## Before searching
-
-- Check a folder's `index.md` before grepping its source or reading its files, starting with `canon/context/` for a domain and `canon/wireframes/` for a UI surface. It orients faster than a blind search.

package/governance/rules/claude/565-behavior.md

@@ -1,27 +0,0 @@
----
-description: Handle judgment calls, scope discipline, and file-editing mechanics during a session
----
-
-# Behavior standards
-
-## Communication
-
-- Flag concerns or alternatives when a proposed change has tradeoffs worth discussing
-
-## Judgment calls
-
-- When facing a judgment call with 2-3 reasonable options mid-flow, pick one and state the tradeoff in one sentence. Enumerate options only when the user's preference is the deciding factor.
-- Put a call the user's preference decides through the structured question surface, such as `AskUserQuestion` in Claude Code, and fall back to a numbered list in one message where none exists. Rank the recommendation first and mark it, order the rest behind it, and give each option its cost, since an option with no stated cost is picked blind.
-- Author the real choices only. A structured surface appends its own trailing escapes for a free-text answer and for reopening the question as conversation, so never write either as an option. On the numbered-list fallback, say that answering outside the list is fine.
-- Answer from the artifact when one already put the question in writing with a suggestion, rather than re-asking it.
-
-## Scope discipline
-
-- Match edit scope to the request. Ship minimal v1 and queue extensions as follow-ups.
-- On simplification requests, edit only what the user named
-- Do not add features the user did not ask for
-- When rewriting a section, preserve existing code blocks, tables, and grouped examples unless the user asked to remove them
-
-## Editing mechanics
-
-- Edit an existing file with the file-editing tool, never a shell stream editor. An unescaped `&` in a `sed` replacement expands to the whole match, and `sed -i` exits zero when its pattern matches nothing, so both fail silently while reporting success. This governs edits you make, not stream editors written into a project's own scripts.

package/governance/rules/claude/567-planning.md

@@ -1,16 +0,0 @@
----
-description: Enforce planning standards before implementation
----
-
-# Planning standards
-
-## Planning
-
-- Confirm a numbered implementation plan before a change whose diff cannot be described in one sentence.
-- Challenge ambiguous or over-engineered requests before implementation.
-- Search the project, its dependencies, and the standard library for an existing implementation before writing new code.
-- State where the search ran and why each candidate was rejected. Do not assert a search without naming its results.
-- Propose the simplest solution that satisfies the requirement before implementing complex patterns.
-- Write or update tests as part of every implementation plan.
-- Write the test for a behavior before the code that implements it. Confirm visual output after implementing it, not before.
-- Run `canon gov test-order` before shipping a branch. Fix what it names as reaching history ahead of its test.

package/governance/rules/claude/575-hooks.md

@@ -1,16 +0,0 @@
----
-description: State the hook stdin guard and the silencing rule for .claude/hooks scripts
-paths:
-  - '.claude/hooks/**/*.sh'
----
-
-# Hook standards
-
-## Reading a payload
-
-- Open a hook that reads a payload with a bounded `IFS= read -r -d '' -t 2 input`, exiting non-zero on an empty payload. An unbounded `cat` blocks forever against a hand run or an open socket, holding the session open with it.
-
-## Silencing output
-
-- Before silencing a hook's output, name the stage that catches the same failure. A hook that is the only enforcer of a rule makes its documented guarantee false when it discards that output.
-- Where no other stage catches the failure, capture the output into a variable, exit 0 on success, and emit the error lines as `additionalContext`.

package/governance/rules/claude/576-settings.md

@@ -1,13 +0,0 @@
----
-description: State the autoContinueAtUsageLimit inversion and the autoCompactWindow cap for .claude/settings.json
-paths:
-  - '.claude/settings.json'
----
-
-# Settings standards
-
-## Session budget settings
-
-- Never set `autoContinueAtUsageLimit` in this file. Its scope is user or managed, and a repository file setting it while no user, `--settings`, or managed value does makes Claude Code read the setting as off, so writing `true` here turns the behavior off for every operator carrying no value of their own.
-- Treat `autoCompactWindow` as capped at the model's own context window. A value above that cap is inert on a session running a smaller window and bites only on one running the larger, so name the window a recorded value is meant for.
-- Record why a session budget setting is left unset in the project's own development notes rather than in this file. JSON carries no pointer, so a session reading the settings file alone concludes the setting is unconfigured and sets it again.

package/governance/rules/claude/592-claude-md.md

@@ -1,19 +0,0 @@
----
-description: Enforce the CLAUDE.md edit protocol and the test routing a fact into it rather than a rule
-paths:
-  - 'CLAUDE.md'
----
-
-# CLAUDE.md standards
-
-## Editing
-
-- Show the proposed change as a fenced `diff` block in chat first, then wait for approval before calling the file-editing tool.
-
-## Routing
-
-- Keep a rule here when it applies every session regardless of what is being edited, on firing alone.
-- Move a rule into `.claude/rules/` when it fires only on a specific path being edited and violating it ships silently, the same firing axis judged the other way.
-- Route a rule failing either half to a context entry or a skill body rather than here. Firing is one axis of three. Conditional presence and updatability are the other two, and this rule states the first alone.
-- Name a rule's tier rather than a rule file. A path-scoped rule reaches the session on its own glob and needs no pointer from here.
-- Point at a skill by name where one applies. A skill loads only when invoked, so an unreferenced skill is one no session finds.

package/governance/rules/standards/markdown.md

@@ -1,16 +0,0 @@
----
-# Generated by `canon gov regen` from standards/markdown.md. Edit that frontmatter, not this file.
-description: Headings, paragraph and list structure, code spans, the date form, punctuation, emphasis, file references, American spelling, and frontmatter wording
-paths:
-  - '**/*.md'
----
-
-# Markdown standards
-
-## Authority
-
-- Follow the markdown standard for headings, paragraph and list structure, code spans, the date form, punctuation, emphasis, file references, American spelling, and frontmatter wording. It is the single source. Read it with `canon standards markdown`.
-- Read it before a substantial markdown edit. Do not work the banned characters from memory.
-- Run `canon markdown audit <path>` after the edit, and rewrite the sentence carrying a hit rather than swapping the token for a near-synonym.
-- Voice, rhythm, and sentence construction are a separate topic. `800-prose` routes them.
-- Load the `canon:draft-figure` skill before drafting or revising a Mermaid fence or a figure, and report it rather than proceeding silently when it does not resolve.

package/governance/rules/writing/800-prose.md

@@ -1,15 +0,0 @@
----
-description: Route markdown edits to the write-human skill for voice, rhythm, sentence construction, and information density
-paths:
-  - '**/*.md'
----
-
-# Markdown voice standards
-
-## Authority
-
-- Load the `canon:write-human` skill for voice, rhythm, sentence construction, and information density. It is the single source for all four.
-- Load it before drafting a passage, not after revising one.
-- Report it rather than proceeding silently when the skill does not resolve.
-- Do not work these rules from memory.
-- Punctuation, formatting, and file references are a separate topic. The markdown rule routes them.