chore: sync .claude rules from rulesets (cross-project, todo-format)

2 files changed, 63 insertions, 0 deletions

diff --git a/.claude/rules/cross-project.md b/.claude/rules/cross-project.md
index 50bc34e2..ed4a19c5 100644
--- a/.claude/rules/cross-project.md
+++ b/.claude/rules/cross-project.md
@@ -39,6 +39,41 @@ Two acceptable outcomes:
 
 Don't assume which one was meant. Either guess is wrong half the time and the cost of asking once is one short turn.
 
+## Changing a Rulesets-Owned Synced File from a Downstream Project
+
+Some files in every project are owned by rulesets and overwritten by the
+template sync at each session start: workflows under `.ai/workflows/`, scripts
+under `.ai/scripts/`, rules under `.claude/rules/`, `protocols.org` — anything
+whose canonical home is `~/code/rulesets/`. When work in a downstream project
+needs one of these files to change, a local edit alone is a stopgap that the
+next sync reverts. The durable change happens only in the rulesets canonical.
+
+The process, every time:
+
+1. **Make the change locally** in the downstream project so it's usable
+   immediately.
+2. **Send rulesets a copy** of the edited file:
+   `inbox-send rulesets --file <edited-file>`.
+3. **Include an intro note** (a second `inbox-send rulesets --text` or
+   `--file`) covering what changed, why, and any companion files that need
+   reconciling, so the rulesets session can update the canonical and re-sync
+   without re-deriving the intent.
+
+Don't wait for the user to spell these steps out — recognizing that an edit
+targets a synced file and propagating it is the agent's job. The rulesets
+session applies its own value gate on arrival, so sending is a proposal, not
+a bypass.
+
+This doesn't conflict with the stop-and-ask rule at the top of this file:
+ask-first governs doing work inside another project's scope. Dropping a
+proposal in its inbox is the sanctioned alternative to that, so a proactive
+inbox-send needs no confirmation.
+
+Worked example: the 2026-06-12 `spec-create.org` decisions-as-TODO change —
+`.emacs.d` edited its local copy as a stopgap, sent the edited file plus an
+intro note naming the two companion workflows to reconcile, and rulesets
+updated the canonical the same evening.
+
 ## Recovery When It Goes Wrong
 
 If you do the work first and the boundary issue surfaces afterwards:
diff --git a/.claude/rules/todo-format.md b/.claude/rules/todo-format.md
index a8df76ad..b1fb57b8 100644
--- a/.claude/rules/todo-format.md
+++ b/.claude/rules/todo-format.md
@@ -5,6 +5,34 @@ Applies to: `**/*.org` (org-mode todo and inbox files)
 How task entries are structured in org-mode todo files (`todo.org`,
 `inbox.org`, any GTD-style org file). Same shape across every project.
 
+## Priority and Tag Scheme Header
+
+Every project's `todo.org` opens with a top-level section named
+`[Projectname] Priority Scheme` (e.g. `* Rulesets Priority Scheme`,
+`* Work Priority Scheme`), placed above the first `* <Project> Open Work`
+section. It declares two things so the rest of the file is legible without
+guessing:
+
+1. **Priorities** — what `[#A]` through `[#D]` mean for this project. At
+   minimum, what makes something `[#A]` (urgent / blocking) versus `[#D]`
+   (someday / watchlist).
+2. **Tags** — the tag vocabulary in use. Name each tag and what it marks.
+   For code projects the typical set is `:feature:`, `:bug:`, `:test:`,
+   `:refactor:`, plus the effort/autonomy tags `:quick:` and `:solo:`. A
+   project may add, drop, or rename tags to fit its work — the requirement
+   is that the set is declared, not that it matches a fixed list.
+
+The section is mandatory. A `todo.org` without it leaves `[#A]` and the tags
+undefined, so task-audit can't enforce a vocabulary, task-review can't grade
+against agreed semantics, and process-inbox can't file new tasks correctly
+(its Phase B.1 already checks for this scheme). Each project defines the
+scheme its own way; the floor is that priorities and tags are both spelled
+out under the header.
+
+When a project's `todo.org` lacks the section, add it before filing or
+grading further tasks — propose the priority semantics and tag set from the
+project's existing usage, and confirm with Craig.
+
 ## The Rule
 
 A todo entry has two parts: