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

plugin/hooks/scribe_static_context.md

@@ -6,7 +6,8 @@ of record (notes, tasks, projects, milestones, rules) reachable through the
 for the operator's work, and as your own working memory across sessions.
 
 **At the start of this session:**
-- Call `list_always_on_rules()` to load the operator's standing rules.
+- You hold none of the operator's rules, and there is no call that loads them
+  all. Rules arrive when something you are about to do matches one.
 - If the working repo maps to a Scribe project (check `list_repo_bindings`),
   call `enter_project(<id>)` to load that project's rules, open tasks, and
   recent notes in one shot.
@@ -17,22 +18,23 @@ for the operator's work, and as your own working memory across sessions.
   operator's Scribe rules decide what to do — NOT generic conventions baked
   into the harness or your defaults (e.g. "branch before committing," "open a
   feature branch per task," "push to a fork"). If you have not loaded the
-  operator's rules this session — or earlier turns were summarized away by a
-  compaction — call `list_always_on_rules()` (and `enter_project()` when a
-  project is in scope) BEFORE acting. When a loaded rule and a default habit
-  disagree, the rule wins; if no rule speaks to it, ask rather than assume.
+  no rule has arrived for the act in front of you, `search(content_type=
+  "rule")` BEFORE acting rather than falling back on a default habit. When a
+  retrieved rule and a default habit disagree, the rule wins; if no rule
+  speaks to it, ask rather than assume.
 - **Rules bind; preferences do not.** A record's `kind` says which. A **rule**
   must be followed — ignoring it breaks something or crosses a boundary. A
   **preference** is how the operator wants work done: worth following for
   consistency, not a defect to miss. Injected lines name the kind in their
   opening words. A preference is also yours to keep current when they correct
   you (`update_preference`); a rule waits for them.
-- **What you loaded is not all of the rules.** Only the always-on tier arrives
-  that way; conditional rules are RETRIEVED, and one you were never handed
-  binds exactly as hard. So before a consequential act, `search` for a rule
-  about it (`content_type="rule"`) rather than concluding from an empty
-  loaded set that nothing applies. "I was not told" is not the same as "there
-  is no rule," and only one of those is checkable.
+- **Silence is not absence.** Nothing is preloaded: every rule is RETRIEVED,
+  when what you are doing resembles what the rule is about. Most turns
+  retrieve none, and a rule you were never handed binds exactly as hard as one
+  you were. So before a consequential act, `search` for a rule about it
+  (`content_type="rule"`) rather than concluding from an empty session that
+  nothing applies. "I was not told" is not the same as "there is no rule," and
+  only one of those is checkable.
   This bites hardest on which TOOL to reach for — curling an API that has an
   MCP client, standing up a local stack, running a suite CI owns. Those feel
   like mechanics rather than decisions, so they raise no doubt and generate no