feat(guidance): an operator's ruling lives on the System it governs, and code is read as behaviour, not intent (milestone 444 steps 1-2, #4754 #4755)

A Librarian session contradicted a decision the operator had made 13 days
earlier. The ruling ("retry, then replace, never give up on a book") was
kept only as a quote in a work log, beside a session's reading of it that
capped replacements at 3. Three later sessions built on the reading, and one
carried the cap into an option as a "known cost", which the operator then
approved without being asked about it.

- writing-records.md: "A ruling goes on the System it governs". What a
  ruling is (the operator decided it; a later change could undo it), how it
  differs from a rule, and where it goes: a Rulings section at the end of
  the System description, one line each with who, when and the source
  record. Written the turn the operator decides; holds what is in force,
  not history; a charter line that contradicts a ruling is fixed in the
  same edit.
- using-scribe SKILL.md: reflex 1 says code tells you what a thing does,
  not what was wanted, and a limit read from code is unconfirmed until a
  System's Rulings says otherwise. Reflex 9 points to the ruling section.
- reporting-back: an option that carries existing behaviour says whose call
  it was (the operator's ruling, or a past session's never confirmed); one
  that contradicts a ruling is a Conflict.
- create_system / update_system docstrings: the Rulings section, and that
  description replaces the whole text.
- test_guidance_ownership: three topics pinned to their owners.
- Plugin version minted.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

plugin/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "scribe",
   "description": "Scribe for Claude Code: connects the scribe MCP server, adds the hooks that deliver live project state and relevant records at the right moment, ships the shared client-neutral Scribe skills (using-scribe, writing-plans, reporting-back, systematic-debugging, verification, brainstorming, reusing-code, shape-accounting), and syncs your saved Scribe Processes as skills (/scribe:sync).",
-  "version": "2026.10.01.1724",
+  "version": "2026.10.02.2259",
   "author": {
     "name": "Bryan Van Deusen"
   },

plugin/skills/reporting-back/SKILL.md

@@ -153,6 +153,15 @@ name.
 Before asking, check whether you can find the answer yourself — something that
 can be read or looked up is a fact to check, not a question to send.
 
+**An option carries assumptions, and the operator approves only what they can
+see.** When an option keeps or depends on existing behaviour — a limit, a
+default, a fallback already in place — say whose call that behaviour was: the
+operator's, citing the ruling ("you ruled this, #N"), or a past session's that
+nobody confirmed ("a past session chose this; you were never asked"). Choosing
+between options is not a decision about the assumptions they share, and an
+unlabelled one gets approved as if it had been asked. An assumption that
+contradicts a recorded ruling is a **Conflict**, not an option's fine print.
+
 ## Answers — the operator asked something
 
 | Kind | Sections |

plugin/skills/using-scribe/SKILL.md

@@ -52,6 +52,12 @@ Two constraints on *how* that's achieved:
    re-deriving it or opening a duplicate. When a project is in scope, pass its
    `project_id` so results stay scoped.
 
+   **Code tells you what a thing does, not what was wanted.** A limit, a
+   default or a fallback found by reading the work is a past session's choice
+   until a record says the operator made it. Before presenting one as a
+   safeguard or a known cost, read the `Rulings` on the System it belongs to;
+   when none speaks to it, call it unconfirmed rather than settled.
+
 2. **Rules are binding, and they reach you by retrieval.** No call loads the
    operator's rules and no standing set is handed to a session. A rule arrives
    when what you are about to do resembles what it is about — a command, the
@@ -227,6 +233,13 @@ Two constraints on *how* that's achieved:
    re-measurement, a reversed decision), pass the old id in `supersedes` so the
    stale record is demoted and labelled rather than left competing.
 
+   **What the operator decided an area must do is a ruling, and it lives on
+   that System** — a `Rulings` section in its description, written the turn
+   they decide. A quote in a work log reaches the next session only if a
+   search happens to match it; the description arrives with every record
+   filed there. [writing-records.md](writing-records.md) has the two tests and
+   the form.
+
 10. **A note that asserts a fact about someone else's software can carry its
    own check** (`verify_with`, `expires_when`), swept by
    `notes_due_for_verification`. Most notes should not: read
@@ -264,7 +277,8 @@ moment rather than on every turn:
   (`decide_project_inception` when `enter_project` returns `inception`).
 - [writing-records.md](writing-records.md) — before writing a rule, preference
   or lesson (where it goes, its `when_to_apply`, what already covers the
-  moment), and before giving a note a check.
+  moment), when the operator decides how an area must behave (a ruling), and
+  before giving a note a check.
 - [missed-retrieval.md](missed-retrieval.md) — a rule that missed the moment it
   governed, or keeps arriving where it doesn't apply.
 

plugin/skills/using-scribe/writing-records.md

@@ -2,11 +2,13 @@
 
 Part of the using-scribe skill. Read it before `create_rule`,
 `create_project_rule`, `create_preference` or `create_lesson`; when a lesson
-arrives that names the situation you are actually in; and before filling
+arrives that names the situation you are actually in; when the operator
+decides how some area of the work must behave; and before filling
 `verify_with` or `expires_when` on a note.
 
 ## Contents
 - Where a new rule goes — its home, its trigger, what already covers the moment
+- A ruling goes on the System it governs
 - A lesson grows each time it proves itself
 - A lesson names the rule it is an instance of
 - A note that asserts a fact can carry its own check
@@ -65,6 +67,52 @@ insight that costs time is a **lesson** (`create_lesson`), keyed to the
 situation it applies to so a later session meets it there. Both are first-class
 outcomes of noticing something, not what's left when a rule proposal fails.
 
+## A ruling goes on the System it governs
+
+A **ruling** is the operator's decision about what the work itself does in one
+area: how it behaves, what it must never do, which way a trade-off goes. It is
+not a rule. A rule governs how *you* work and reaches you when your work
+resembles it; a ruling governs what the *thing being built* does, and it has to
+reach every session working in that area, whatever words that session is using.
+
+Two tests, and it needs both:
+
+- **The operator decided it.** They said it, or approved it when it was put to
+  them as its own question. Approving an option is not approving every
+  assumption the option carried — only what it named.
+- **A later change could plausibly undo it.** "Failed work is retried until it
+  succeeds" qualifies. The name of the table that tracks the retries does not;
+  that is implementation, and it lives in the code and the logs.
+
+A choice a session made on its own is not a ruling, however sound. Keeping the
+two apart is the point: once code embodies a session's choice, it reads exactly
+like the operator's intent, and the next session builds on it as if it were.
+
+**Where it goes: a `Rulings` section at the end of the System's description**,
+one line each — the statement, who decided, when, and the record it came from:
+
+    Rulings
+    - Failed work is retried until it succeeds; no attempt limit. (Operator, 2026-09-19, #1234; restated 2026-10-02, #1290)
+
+The description arrives with every record filed under that System, so a ruling
+there reaches each session working in the area without having to win a search.
+A quote inside a work log does not: it surfaces only when a query happens to
+match it, and the passage that matches is usually the prose around it — often a
+session's *reading* of the ruling rather than the ruling.
+
+**When: in the turn the operator decides, before building on it.**
+`get_system(id)`, then `update_system(id, description=...)` with the whole
+description — the field is replaced, not appended to. Also when the operator
+corrects work that departed from something they had already said: that ruling
+existed and did not reach the work, and writing it where it will is half the
+fix. No System fits? The area is probably unnamed — create it.
+
+**It holds what is in force, not its history.** When a ruling is overturned,
+change or remove its line and cite the record that changed it; the work log
+keeps the history. If the charter above the section contradicts a ruling —
+usually a charter written before the decision — fix that sentence in the same
+edit. A stale charter line is a ruling nobody made, and it is read as one.
+
 ## A lesson grows each time it proves itself
 
 When one arrives and the situation it names is the one you are actually in, you