feat(plugin): Scribe replaces native memory by instruction; tighten project-scope discipline

Direction change (operator, see plan task #755 work-log): the plugin must
NOT depend on disabling a native Claude function to work. It earns its place
by steering behavior, not by toggling autoMemoryEnabled.

Memory doctrine (no dual-write):
- using-scribe SKILL.md gains "Scribe holds these functions — don't keep a
  second copy": route rules/recall/planning to Scribe, don't also write them
  to native auto-memory, never instruct disabling a native function, and
  accept a "Scribe-shaped hole" if the plugin is removed (recover over time).
- mcp/server.py _INSTRUCTIONS: drop the paragraph that told the model to
  create/refresh a "rules live in Scribe" pointer in CLAUDE.md / ~/.claude
  memory. That was an active dual-write instruction; the SessionStart hook is
  the bridge now. Replaced with the no-dual-write / no-settings-dependency
  doctrine. Supersedes plan #755 Phase 6 ("set autoMemoryEnabled:false").

Project-scope discipline (stop cross-project bleed):
- using-scribe SKILL.md gains "Stay inside the active project's scope": pass
  project_id to every read, only reference/offer work on the in-scope project,
  ask before switching.
- _INSTRUCTIONS scope bullet extended from reads to referencing/offering, and
  flags get_recent as cross-project.
- get_recent docstring gains a scope note steering to scoped list_* when a
  project is active.

plugin.json 0.1.4 -> 0.1.5 so clients' caches actually refresh (re-shipping
under the same version does not bust the cache).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

plugin/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "scribe",
   "description": "Scribe second brain for Claude Code: MCP tools over your notes/tasks/projects/rules, a session-start push channel that surfaces your always-on rules + active-project context, and a set of universal process-skills (brainstorm, debug, TDD, plan, verify). Replaces superpowers + file-memory with one app-backed plugin.",
-  "version": "0.1.4",
+  "version": "0.1.5",
   "author": { "name": "Bryan Van Deusen" },
   "mcpServers": {
     "scribe": {

plugin/skills/using-scribe/SKILL.md

@@ -24,6 +24,29 @@ that as a bonus, not a precondition: it can be absent (e.g. when the instance is
 unreachable, or the token didn't reach the hook), so the reliable path is this
 explicit pull. Rules loaded this way are **binding** for the session.
 
+## Scribe holds these functions — don't keep a second copy
+
+This plugin makes Scribe the home for the operator's **rules, recall, and
+planning** — the jobs Claude's native auto-memory would otherwise do. When the
+plugin is present, route those jobs to Scribe and **do not also write them to
+native memory**: codify rules with `create_rule` / `create_project_rule`,
+capture durable knowledge as Scribe notes, and keep plans in `kind=plan` tasks —
+not in `MEMORY.md` or `CLAUDE.md`. One copy, in Scribe; let any existing local
+memory shrink as Scribe takes over. Don't maintain both stores in parallel.
+
+Two constraints on *how* that's achieved:
+
+- **Steer behavior; never flip a native switch.** The plugin must work with
+  native auto-memory at its default (ON). Never tell the operator to set
+  `autoMemoryEnabled:false` or otherwise disable a built-in function to make
+  Scribe "win" — a setting the operator may not know was changed (and wouldn't
+  know to restore) is exactly the hidden breakage to avoid. You replace memory's
+  functions by *doing the work in Scribe*, not by turning memory off.
+- **A Scribe-shaped hole is acceptable.** If the plugin is later removed, the
+  operator recovers context over time — that's fine. You do **not** need to keep
+  native memory as a self-sufficient fallback. The only thing to avoid is
+  breakage caused by a settings change the operator didn't make knowingly.
+
 ## The reflex
 
 1. **Recall before acting.** Before answering a question about the operator's
@@ -48,6 +71,20 @@ explicit pull. Rules loaded this way are **binding** for the session.
 5. **Keep state honest.** Set a task `in_progress` when you start it, `done` the
    moment it's complete; log progress as you go.
 
+## Stay inside the active project's scope
+
+Once a project is in scope — you called `enter_project`, or the working repo is
+bound — confine the session to it:
+
+- **Pass that `project_id` to every read** (`search`, `list_tasks`,
+  `list_notes`). An unscoped read bleeds every other project's work into your
+  context.
+- **Only reference or offer work on the in-scope project.** Don't surface,
+  suggest, or start work on other projects unless the operator explicitly widens
+  scope.
+- If something clearly belongs to a *different* project, say so and **ask before
+  switching** — never silently operate cross-project.
+
 ## Where a new rule goes
 
 When codifying a rule, pick its home by **who it should bind** — and keep