docs(6207): migrations 0101, 0105, 0106, 0108, 0120, 0121 drop citations and the operator quote

0121 keeps the ARM_BORN date beside the constant it justifies.

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

alembic/versions/0101_drop_rulebook_subscriptions.py

@@ -4,12 +4,12 @@ Revision ID: 0101
 Revises: 0100
 Create Date: 2026-09-15
 
-Milestone 414. A rule lives in a rulebook topic, where it is GLOBAL, or on one
-project, and retrieval reads that home directly (step 1). Subscriptions were
-the last thing that pretended a rulebook reached some projects and not others,
-and after milestone 394 they changed nothing a session received — only what a
-project's rule LISTING showed. Operator, 2026-09-15: "we have global and
-project scoped rules, we don't need the subscriptions now."
+A rule lives in a rulebook topic, where it is GLOBAL, or on one project, and
+retrieval reads that home directly. Subscriptions were the last thing that
+pretended a rulebook reached some projects and not others, and with no
+always-on tier they changed nothing a session received — only what a
+project's rule LISTING showed. Global and project-scoped rules cover what
+subscriptions were for.
 
 WHAT GOES
 
@@ -19,8 +19,8 @@ WHAT GOES
     there is nothing to mute; a project that departs from a global rule writes
     a project rule with an ``overrides`` relation, which says why.
   - The ``subscribe_rulebooks`` key inside ``projects.inception.choices``, and
-    the ``exclude_always_on_rulebooks`` key milestone 394 left behind in the
-    same place. Both describe decisions that can no longer be made; a stored
+    the ``exclude_always_on_rulebooks`` key the retired always-on tier left
+    in the same place. Both describe decisions that can no longer be made; a stored
     record carrying them would be read back as a choice the product offers.
 
 IRREVERSIBLE, AND THE DOWNGRADE SAYS SO

alembic/versions/0105_note_usage_events_carry_the_reading_project.py

@@ -1,20 +1,19 @@
-"""note_usage_events records WHICH project the reader was in (#4196, #3735)
+"""note_usage_events records WHICH project the reader was in
 
 Revision ID: 0105
 Revises: 0104
 Create Date: 2026-09-20
 
-Milestone 385. `RetrievalLog` has carried `project_id` from the start, so
+`RetrievalLog` has carried `project_id` from the start, so
 "this record was SURFACED on project B" has always been answerable. The usage
 table never had one, so "this record was OPENED on project B" never was — and
 the two cannot be joined to recover it, because there is no session identity
 server-side (see the NoteUsageEvent docstring, which rules that out on
 purpose).
 
-That gap sits exactly on the question milestone 385 exists to answer. A
-lesson's whole claim is that it reaches a session on a project it was not
-written on; step 8's acceptance is "retrieved on a different project, at the
-moment it applies, AND opened". Surfacing cross-project: answerable. Opening:
+That gap sits exactly on the question lessons exist to answer. A lesson's
+whole claim is that it reaches a session on a project it was not written on:
+"retrieved on a different project, at the moment it applies, AND opened". Surfacing cross-project: answerable. Opening:
 answerable. Both at once: not, until this column.
 
 WHICH PROJECT THIS IS, because the name is ambiguous and the wrong reading

alembic/versions/0106_rule_usage_events_carry_an_outcome.py

@@ -1,10 +1,10 @@
-"""rule_usage_events carry an outcome, not just a read (#4212, milestone 419)
+"""rule_usage_events carry an outcome, not just a read
 
 Revision ID: 0106
 Revises: 0105
 Create Date: 2026-09-20
 
-Milestone 419's first step. `rule_usage_events` can say a rule was SURFACED
+`rule_usage_events` can say a rule was SURFACED
 and that it was PULLED. It cannot say what happened next, so these two
 sessions leave identical telemetry:
 
@@ -19,9 +19,9 @@ the system.
 TWO NEW EVENT VALUES, AND NO CHECK MIGRATION. `event` was created in 0094 as
 plain `sa.Text()` with no constraint — checked in the migration itself, not
 assumed from the model — so `applied` and `departed` join `surfaced` and
-`pulled` without a DROP/ADD pair. Rule 36 governs CHECK-whitelisted columns
+`pulled` without a DROP/ADD pair. That pair is for CHECK-whitelisted columns
 and this is not one; noted explicitly because the next reader will reach for
-rule 36 here, and should be able to see in one place why it does not bite.
+it here, and should be able to see in one place why it does not apply.
 
 THE THIRD STATE IS DERIVED, AND THAT IS NOT A SHORTCUT. Read-and-silently-
 unchanged is the absence of an outcome, and it has to be: an agent that knew
@@ -29,8 +29,8 @@ it was ignoring a rule would not be ignoring it. There is no honest way to ask
 for that event, so nothing here tries. `applied` and `departed` are reported;
 the third state is what is left over when a rule was pulled and neither
 arrived. A schema that offered an `ignored` value would collect nothing and
-read as though it had measured something, which is the #3311 failure — a
-statistic that cannot vary being mistaken for a finding.
+read as though it had measured something — a statistic that cannot vary
+being mistaken for a finding.
 
 `detail` CARRIES THE WHY OF A DEPARTURE, and is the reason this is a column
 rather than two more bare event strings. A departure without its reason is

alembic/versions/0108_trigger_leaves_the_stored_title.py

@@ -1,17 +1,16 @@
-"""trigger_leaves_the_stored_title — a snippet's and lesson's title is its name (milestone 427)
+"""trigger_leaves_the_stored_title — a snippet's and lesson's title is its name
 
 Revision ID: 0108
 Revises: 0107
 Create Date: 2026-09-23
 
 Snippets and lessons stored their title as `subject — trigger`, because the
-join is what makes these kinds rank on the situation they apply to (#2485) and
+join is what makes these kinds rank on the situation they apply to and
 the stored title WAS the embedded one. Every surface that shows a title then
 showed the trigger too: menu lines, lists and search rows ran to 1,500–3,000
 characters, and an injected repeat spent all of it again.
 
-The trigger's home is `data` (decision #4157), and since this milestone the
-join happens at embed time (`embeddings.document_title`). This revision
+The trigger's home is `data`, and the join happens at embed time (`embeddings.document_title`). This revision
 rewrites the rows already stored.
 
 EXACT-SUFFIX, READ FROM THE ROW'S OWN MIRROR. A title is only rewritten when

alembic/versions/0120_family_canon.py

@@ -1,5 +1,5 @@
 """family canon — platforms, family ideas, the adoption ledger and its decision
-log (milestone 463 step 1)
+log
 
 Revision ID: 0120
 Revises: 0119
@@ -13,7 +13,7 @@ reason), or owed. These tables hold that.
 - `platforms` — a GLOBAL catalog, the canonical_systems shape: no owner, slug
   is the match key. Seeded with generic technology names only. Nothing here
   names an app, a repo or a house convention: the catalog ships to every
-  install (rule 115).
+  install.
 - `project_platforms` — which platforms a project is (declared / detected /
   rejected). Membership is what makes "is this in family?" a lookup.
 - `family_ideas` — a NOTE's family state. No new record type: any notes row
@@ -39,7 +39,7 @@ branch_labels = None
 depends_on = None
 
 # One place per whitelist, so each CHECK and the model's tuple cannot drift
-# (rule 36: a new value later means DROP + ADD CONSTRAINT in one migration).
+# (a new value later means DROP + ADD CONSTRAINT in one migration).
 _MEMBERSHIP = ("declared", "detected", "rejected")
 _IDEA_STATUSES = ("candidate", "canon", "retired")
 _ADOPTION_STATUSES = ("unassessed", "adopted", "variant", "exempt", "owed")

alembic/versions/0121_retire_report_preference.py

@@ -1,4 +1,4 @@
-"""retire the report_preference arm's rows (milestone 500 step 4)
+"""retire the report_preference arm's rows
 
 Revision ID: 0121
 Revises: 0120
@@ -6,8 +6,8 @@ Create Date: 2026-10-09
 
 The fixed-question arm that searched for completion-report preferences when a
 task closed is gone: the reply shapes and the preferences mounted beside them
-now arrive on the moments (milestone 500 step 3). Its rows go with it (rule
-22 — no legacy to preserve), because each one would otherwise mean something
+now arrive on the moments. Its rows go with it (there is no legacy to
+preserve), because each one would otherwise mean something
 different once the arm is no longer registered:
 
 - `retrieval_logs` / `retrieval_judgments` — a source missing from the
@@ -21,11 +21,10 @@ different once the arm is no longer registered:
 - `settings` — the arm's floor and budget keys, which nothing reads.
 
 COST IS BOUNDED BY AN INDEX, NOT BY THE TABLE. A migration runs at boot
-against the live tables, which CI never has (lesson #5221). `retrieval_logs`
+against the live tables, which CI never has. `retrieval_logs`
 and `retrieval_judgments` are indexed on `source`. `rule_usage_events` is not,
-so its delete is also bounded by `created_at` (indexed): the arm shipped with
-milestone 409 step 4, decided 2026-09-14, so no row of it predates
-`ARM_BORN`, and the scan covers weeks rather than the table's whole history.
+so its delete is also bounded by `created_at` (indexed): no row of the arm
+predates `ARM_BORN`, and the scan covers weeks rather than the table's whole history.
 
 Not reversible: the arm is not coming back, so neither are its rows.
 """