feat(rules): preferences are writable, and their drift arrives (#3895)

Milestone 399 step 5. Steps 1-4 put preferences into the backend: a kind
column, an inverted write path, a third register in the injected block, a
delivery slot. Nothing the operator could touch. Rule 27 forbids leaving it
there, and here it matters more than usual, because the UI is the only
guard against the risk the milestone named up front — an agent misreads one
session, rewrites a preference, and follows the rewritten version forever
while the operator never sees the moment it changed.

Four things ship.

A preference is DISTINGUISHABLE. `kind` reaches the client (the server has
always sent it in rule_brief) and a preference carries a chip. Force is the
one thing a list of instructions must not leave the reader to infer, and a
row that renders identically to a rule teaches the opposite of both facts
about a preference: it does not bind, and a session may rewrite it.

A preference is WRITABLE. The editor gains the kind as a first-class choice
with the test beside it — what happens when someone does not do this — and
says plainly, when preference is chosen, that sessions rewrite these
without asking and every rewrite is kept.

DRIFT ARRIVES. `GET /api/rules/drift` returns one row per rewritten
preference carrying its latest rewrite: what it said, what it says now, and
the record named by `arose_from_id` that taught the change. Both texts ride
along so the list shows the diff without a call per row. The new pane sits
beside the staleness sweep, because drift belongs to no one rulebook, and
it answers a question the operator would not have thought to ask.

REVERSION IS ONE ACTION, and this is the carve-out worth arguing with.
Milestone 323 refused a one-click restore for rules — "a binding
instruction should not be revertible in one click", because a silent revert
erases the only record of why the rewrite happened. That reasoning turns on
the rewrite being the operator's own decision. A preference's is not: the
agent makes it mid-work without asking, so reverting is a veto over someone
else's edit rather than an undo of your own, and a veto costing more than a
shrug is not supervision. The route refuses anything but a preference (409),
and nothing is erased: the restore goes through update_rule, so it snapshots
too and the history GAINS the revert. An integration test pins that, because
it is the whole basis for the exception.

Tested against real Postgres — every claim is about which rows come back
and in what order, which a stand-in session cannot judge.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01821k5B3Ysecp9fNYs92Kuy

frontend/src/components/rules/RuleEditorSlideOver.vue

@@ -4,7 +4,7 @@ import { useRulebooksStore } from "@/stores/rulebooks";
 import { useCanonicalSystemsStore } from "@/stores/canonicalSystems";
 import RuleHistoryPanel from "@/components/rules/RuleHistoryPanel.vue";
 import RuleHomePicker from "@/components/rules/RuleHomePicker.vue";
-import type { Rule } from "@/api/rulebooks";
+import type { Rule, RuleKind } from "@/api/rulebooks";
 
 const props = defineProps<{ ruleId: number | null; topicId: number | null }>();
 const emit = defineEmits<{ close: [] }>();
@@ -14,6 +14,11 @@ const canon = useCanonicalSystemsStore();
 const title = ref("");
 const statement = ref("");
 const whenToApply = ref("");
+// Defaults to `rule`, matching the server's column default. The safe
+// direction is the one that binds: a preference mislabelled as a rule is
+// followed too faithfully, where a rule mislabelled as a preference is one a
+// session may quietly rewrite.
+const kind = ref<RuleKind>("rule");
 const systemIds = ref<number[]>([]);
 const why = ref("");
 const howToApply = ref("");
@@ -70,6 +75,7 @@ async function load() {
       title.value = r.title;
       statement.value = r.statement;
       whenToApply.value = r.when_to_apply || "";
+      kind.value = r.kind;
       systemIds.value = (r.systems ?? []).map((sys) => sys.id);
       why.value = r.why || "";
       howToApply.value = r.how_to_apply || "";
@@ -80,6 +86,7 @@ async function load() {
     title.value = "";
     statement.value = "";
     whenToApply.value = "";
+    kind.value = "rule";
     systemIds.value = [];
     why.value = "";
     howToApply.value = "";
@@ -98,6 +105,7 @@ async function save() {
     title: title.value,
     statement: statement.value,
     when_to_apply: whenToApply.value,
+    kind: kind.value,
     // Always sent, so clearing the last area actually clears it — the server
     // reads a list as "these ARE the areas now".
     system_ids: systemIds.value,
@@ -140,7 +148,7 @@ watch(() => props.ruleId, load);
   <div class="backdrop" @click="save">
     <aside class="slide-over" @click.stop>
       <header>
-        <h2>{{ isCreating ? "New rule" : "Edit rule" }}</h2>
+        <h2>{{ `${isCreating ? "New" : "Edit"} ${kind === "preference" ? "preference" : "rule"}` }}</h2>
         <button v-if="!isCreating" class="trash" @click="remove" aria-label="Delete">🗑</button>
         <button class="close" @click="save" aria-label="Close">×</button>
       </header>
@@ -148,6 +156,34 @@ watch(() => props.ruleId, load);
         Title
         <input v-model="title" placeholder="e.g. dev is home" />
       </label>
+      <fieldset class="kind">
+        <legend>What kind of instruction is this?</legend>
+        <label class="kind-opt">
+          <input v-model="kind" type="radio" value="rule" />
+          <span>
+            <strong>Rule</strong> — must be followed. Ignoring it breaks
+            something or crosses a boundary. It changes when you change it.
+          </span>
+        </label>
+        <label class="kind-opt">
+          <input v-model="kind" type="radio" value="preference" />
+          <span>
+            <strong>Preference</strong> — how you want work done. Ignoring it
+            costs consistency, not correctness, and <em>Scribe updates it as
+            the work teaches it</em>.
+          </span>
+        </label>
+        <p class="field-note">
+          The test is what happens when someone does not do it. Something
+          breaks — a rule. The tenth time goes differently from the ninth — a
+          preference.
+        </p>
+      </fieldset>
+      <p v-if="kind === 'preference'" class="kind-drift">
+        Sessions rewrite preferences without asking, which is what makes them
+        stay current. Every rewrite is kept, and
+        <strong>Recent changes</strong> lists them with what taught each one.
+      </p>
       <label>
         Statement <span class="required">*</span>
         <textarea v-model="statement" rows="3" placeholder="The actionable instruction (1-2 sentences)." />
@@ -267,6 +303,17 @@ watch(() => props.ruleId, load);
 </template>
 
 <style scoped>
+.kind { border: 1px solid var(--fs-border-color); border-radius: var(--fs-radius-md); padding: var(--fs-space-3); margin: var(--fs-space-3) 0; }
+.kind legend { font-size: var(--fs-size-tiny); text-transform: uppercase; letter-spacing: var(--fs-tracking-tiny); color: var(--fs-text-tertiary); padding: 0 var(--fs-space-2); }
+.kind-opt { display: flex; align-items: flex-start; gap: var(--fs-space-2); margin-bottom: var(--fs-space-2); font-size: var(--fs-size-body-sm); line-height: var(--fs-leading-body); }
+.kind-opt input { margin-top: 0.2rem; accent-color: var(--fs-accent); flex: none; }
+.kind-drift {
+  margin: 0 0 var(--fs-space-3); padding: var(--fs-space-2);
+  font-size: var(--fs-size-tiny); line-height: var(--fs-leading-body);
+  color: var(--fs-text-secondary);
+  background: var(--fs-accent-soft); border-radius: var(--fs-radius-sm);
+}
+
 .backdrop {
   position: fixed; inset: 0;
   background: rgba(0, 0, 0, 0.4);