wip(394): steps 6+7 — backend path and instruction surfaces

plugin/skills/using-scribe/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: using-scribe
-description: Use at the START of every session, and before answering anything about the operator's work or starting any task — establishes the Scribe-first reflex. FIRST ACTION of a session: call list_always_on_rules() (and enter_project when a repo/project is in scope) to load the operator's binding rules. Then recall before acting, update over duplicate, plan in Scribe not in files.
+description: Use at the START of every session, and before answering anything about the operator's work or starting any task — establishes the Scribe-first reflex. You hold none of the operator's rules: they arrive by retrieval when your work matches one, and search(content_type="rule") is how you ask before a consequential act. Call enter_project when a repo/project is in scope. Then recall before acting, update over duplicate, plan in Scribe not in files.
 ---
 
 # Using Scribe
@@ -13,12 +13,19 @@ asked for.
 
 ## Do this first (every session)
 
-**Pull the standing rules yourself — do not wait for them to be handed to you.**
-At the start of a session, before substantive work, call
-`list_always_on_rules()` to load the operator's always-on rules. If the working
-repo maps to a Scribe project (you're in a known repo, or `list_repo_bindings`
-shows a binding), call `enter_project(id)` instead/as-well — it returns the
-project plus its applicable rules, open tasks, and recent notes in one shot.
+**You are not holding the operator's rules, and no call loads them all.**
+There is no standing set to pull. A rule reaches you when what you are about to
+do matches it — a command, code you are writing, or what the operator just
+asked for — and on most turns none will. That is the surface working.
+
+**So the reflex is to ASK, not to load.** Before a consequential act — anything
+hard to reverse or outward-facing — `search(content_type="rule")` for the thing
+you are about to do. An empty session is not evidence of an empty rulebook.
+
+If the working repo maps to a Scribe project (you're in a known repo, or
+`list_repo_bindings` shows a binding), call `enter_project(id)` — it returns the
+project plus the rules bound to the areas it works in, open tasks, and recent
+notes in one shot.
 
 Do this actively. A SessionStart hook *may* also inject a rule index, but treat
 that as a bonus, not a precondition: it can be absent (e.g. when the instance is
@@ -56,11 +63,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.
 
-2. **Standing rules are binding — and the ones you were handed are not all of
-   them.** Load the resident set via `list_always_on_rules()` at session start
-   (see "Do this first"). Pull a record's full statement with `get_rule(id)`
-   when it's about to bite. When a project is in scope, `enter_project(id)`
-   also returns its applicable rules.
+2. **Rules are binding, and silence does not mean there are none.** Nothing
+   is preloaded, so "no rule arrived" means "nothing matched" — never "no rule
+   exists". Ask with `search(content_type="rule")` before a consequential act,
+   and pull a record's full statement with `get_rule(id)` when it is about to
+   bite. When a project is in scope, `enter_project(id)` also returns the rules
+   bound to its areas.
 
    **`kind` says how much force a record carries, and it is never something to
    infer.** A **rule** must be followed: ignoring it breaks something or
@@ -222,13 +230,12 @@ bound — confine the session to it:
 ## Starting a project: decide what it inherits
 
 A project's inheritance is a **decision, not a default**. Before
-`create_project`, ask the operator the four inception questions and pass the
+`create_project`, ask the operator the three inception questions and pass the
 answers — never create a project bare by default:
 
-- which **always-on rulebooks** it should NOT inherit (`list_rulebooks` shows
-  which are always_on; default: inherit them all) →
-  `exclude_always_on_rulebooks=[...]`
-- which other rulebooks to **subscribe** → `subscribe_rulebooks=[...]`
+- which rulebooks to **subscribe** (`list_rulebooks` shows them; default: none
+  — a rulebook binds a project only when it opts in) →
+  `subscribe_rulebooks=[...]`
 - which **design system** its UI is built from (`list_design_systems`; or
   none) → `design_system_id=<id | -1>`
 - whether to **seed the standard starter Systems** so records can be tagged
@@ -246,19 +253,23 @@ inception is the moment they are decided together, and the record of why.
 When codifying a rule, pick its home by **who it should bind** — and keep
 shared homes general:
 
-- **Always-on rulebook** (`create_rule` in an `always_on` rulebook) — universal
-  norms that bind *every* project. Cross-project standards only.
-- **Subscribed rulebook** (`create_rule` + `subscribe_project_to_rulebook`) — a
-  reusable, *themed* module of general rules that binds only projects that opt
-  in (e.g. a review checklist → every service). Themed, but project-agnostic.
+- **Rulebook** (`create_rule` + `subscribe_project_to_rulebook`) — a reusable,
+  *themed* module of general rules that binds the projects which opt in (e.g. a
+  review checklist → every service). Themed, but project-agnostic.
 - **Project rule** (`create_project_rule`) — anything specific to one project
   (its files, paths, quirks).
 
-Both rulebook tiers are shared, so their rules stay general; they differ in
-**reach** (all vs opt-in), not generality. Names one project's specifics →
-project rule; a standard a category shares → subscribed rulebook; a universal
-norm → always-on rulebook. Never put project-specific detail in a shared
-rulebook — it leaks to every other project that gets it.
+There used to be a third home — an `always_on` rulebook that bound every
+project automatically. It is gone: subscription is the only reach a rulebook
+has. Names one project's specifics → project rule; anything a category of
+projects shares → rulebook. Never put project-specific detail in a rulebook —
+it leaks to every other project that subscribes.
+
+**Whichever home it gets, a rule needs `when_to_apply`.** It is the only thing
+that decides whether the rule is ever seen: nothing is preloaded, so a rule
+with no trigger is not a quiet rule, it is an unreachable one. Write the moment
+in the words a session actually produces — the command, the error, the
+half-formed ask — not the category it belongs to.
 
 **First ask whether it's a rule at all.** A rule is prose you have to remember
 and apply; Scribe's other entities are structure a tool can resolve and check.