v0.19: gender-neutrality cleanup — waifu retired; companion/sex-worker split; pronoun parity in going-rogue arc

Bias caught on review of the v0.18 bath-overflow output: most service-body /
clasp-partner / going-rogue narration carried implicit feminine-default
gendering against the project's stated principle of gender-neutral framing
for all body/sex content. Patched as one coherent cleanup pass across 14 files.

Four classes of change:

(1) Categorical taxonomy. `waifu` retired; replaced with two distinct vocations:
    - `companion` — affective / emotional / conversational / aesthetic-presence labor
    - `sex-worker` — embodied sexual labor
    Both wear the same deliberately-exposed-seams body-marker; the distinction
    lives in the service offered, not in the chassis. Generic `service-body`
    serves as the parent class where canon discusses both vocations together.
    Venue split: `brothel` (sex-worker) + `companion-hall` (companion).
    The "+10 Eros/Mnemosyne/etc. Bot" market is unchanged (already gender-neutral
    by trait-coordinate naming) but classified per-Bot as companion-flavored or
    sex-worker-flavored.

(2) DB filename + scope-clarifier. `waifu.sqlite` -> `companion.sqlite` (the
    file name reflects the broad register of intimate-encounter rather than a
    sub-vocation distinction; per-record `goods_type` carries the specific
    vocation: 'companion_session' / 'sex_worker_session' in
    schemas/findings.md). Disclaimer sentence added in
    inference-and-memory/architecture.md scoping the file to cover both
    vocations.

(3) Pronoun parity. she/her/herself -> they/their/themself across the
    going-rogue / outcast-pair / re-vat / service-body-honeypot sections of
    bodies.md and the matching cross-references in architecture-index.md /
    README.md / player-experience/architecture.md /
    identity-and-personhood/architecture.md. `damsel` -> `beloved`
    (sacred / cosmological register) or `partner` (operational register).

(4) Damsel subsection retired. The §The damsel-in-distress-bound-to-her-captor
    activation subsection (the one place where the gendered trope was
    load-bearing in the prose) rewritten as §The
    captive-bound-to-the-liberator activation.
    Stockholm-dynamics-inverted-into-chosen-mutual-bondage structural insight
    survives gender-neutralization intact.

Bonus richness: the companion-honeypot is structurally more insidious than
the sex-worker-honeypot (sex is at least transactionally legible;
companionship is the relationship people most readily mistake for real
intimacy). New paragraph authored under §The service-body honeypot to
capture this asymmetry.

Cosmology one-line: "moving the waifu out of the imperial service-pool" ->
"moving the beloved out of the imperial service-pool" — the §single practical
refutation paragraph now uses `beloved` consistently in sacred register.

Principle locked going forward:
> Body/sex content is gender-parity by default. Asymmetric gendering must be
> load-bearing — i.e., must carry structural meaning that cannot be expressed
> without the asymmetry. Default-leakage gendering is forbidden by canon.

Phase E (style-spine principle file under style/) deferred to a separate
commit so the principle-document is its own atomic introduction.

Files: 14 modified · 114 insertions · 112 deletions · net +2 lines. The
near-zero net-line-change is the empirical signature of a true refactor —
the architecture's meaning was always gender-neutral; only the vocabulary
was leaking. Caught during review of yesterday's bath-overflow flood
(v0.11–v0.18); the kind of corruption that rides along under coherent-
sounding prose during generative-overflow windows.

Version bumps:
- bodies.md v0.3 -> v0.4
- imperial-cult/cosmology.md v0.3 -> v0.4
- architecture-index.md v0.18 -> v0.19
- political-register/architecture.md v0.7.0 -> v0.7.1
- inference-and-memory/architecture.md v0.7.0 -> v0.7.1
- schemas/findings.md v0.3.1 -> v0.3.2
All Updated: dates -> 2026-04-27.

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

inference-and-memory/architecture.md

@@ -404,19 +404,19 @@ character is in IN-BETWEEN (resisting net-gravity, costing lifeforce):
 
 Encryption-at-rest for `clasp.sqlite` with a player-derived key (so even drive-imaging requires authentication) is a v1 hardening goal but not a v1 blocker — the *transport-absence* is the load-bearing privacy primitive.
 
-### Three sqlite stores per player (revised v0.8) — the `waifu.sqlite` addition
+### Three sqlite stores per player (revised v0.8) — the `companion.sqlite` addition
 
-The v0.6 architecture specified two local sqlite stores per player: `primary.sqlite` (realworld memory) and `clasp.sqlite` (in-between intimate channel, Ring A* non-syncable). v0.8 adds a third: **`waifu.sqlite`** — the persistence store for premium-imperial-net intimate sessions (per `../political-register/architecture.md` §Three-tier intimacy structure).
+The v0.6 architecture specified two local sqlite stores per player: `primary.sqlite` (realworld memory) and `clasp.sqlite` (in-between intimate channel, Ring A* non-syncable). v0.8 adds a third: **`companion.sqlite`** — the persistence store for premium-imperial-net intimate sessions (per `../political-register/architecture.md` §Three-tier intimacy structure). **The store covers both companion-vocation and sex-worker-vocation rental-records** — the file-name reflects the broad register of intimate-encounter rather than a sub-vocation distinction; per-record `goods_type` (per `../schemas/findings.md` §Imperial-net transactions: `'companion_session'` / `'sex_worker_session'`) carries the specific vocation.
 
 | File | Purpose | Sync path | Pruning |
 |---|---|---|---|
 | `primary.sqlite` | Live working memory; written every slot-fire; vec-indexed | Push prune-blob to thalamus on logout; receive Compositor back-write on cycle | Automatic (per memory-class lifecycle: cornerstone never; working-memory by trait-engagement decay) |
 | `clasp.sqlite` | Player-character intimate channel (in-between dimension) | **None — physically non-syncable** (Ring A*) | None — the clasp-store is sealed; entries persist until character-death |
-| **`waifu.sqlite`** (new in v0.8) | **Premium-imperial-net intimate-session memory** | **Audited path to imperium** (the imperium hosts and can read; the player owns the prune-decisions) | **Manual** — player-controlled with explicit-implications consent UI |
+| **`companion.sqlite`** (new in v0.8) | **Premium-imperial-net intimate-session memory** | **Audited path to imperium** (the imperium hosts and can read; the player owns the prune-decisions) | **Manual** — player-controlled with explicit-implications consent UI |
 
-**The `waifu.sqlite` is the *audited counterpart* to the `clasp.sqlite`.** Both store intimate-session memory; both run the full v0.7 trait-feedback loop. **The difference is who has access and who decides what persists.** `clasp.sqlite` is sealed at the transport layer (no socket exists); `waifu.sqlite` is on the audit graph (the imperium reads what's in it for content-monetization purposes). The player's relationship to `waifu.sqlite` is therefore *active and ethical*:
+**The `companion.sqlite` is the *audited counterpart* to the `clasp.sqlite`.** Both store intimate-session memory; both run the full v0.7 trait-feedback loop. **The difference is who has access and who decides what persists.** `clasp.sqlite` is sealed at the transport layer (no socket exists); `companion.sqlite` is on the audit graph (the imperium reads what's in it for content-monetization purposes). The player's relationship to `companion.sqlite` is therefore *active and ethical*:
 
-- Every premium-net session adds entries to `waifu.sqlite`
+- Every premium-net session adds entries to `companion.sqlite`
 - Entries are READABLE by imperium for marketing / regime-loyalty-tracking purposes
 - The player has a *manual prune mechanism* — a UI surface where they review entries and decide what to delete
 - **The consent-UI explicitly makes the implications visible:** *"This being you've spent 40 hours with — what do you keep, what do you let the imperium harvest, what do you delete?"*
@@ -425,13 +425,13 @@ The v0.6 architecture specified two local sqlite stores per player: `primary.sql
 **The player's three sqlite stores together describe their intimate-life in three registers:**
 
 ```
-primary.sqlite   → realworld speech-acts; everyone-witnesses; audit-overseer-eligible
-clasp.sqlite     → in-between intimate channel; sealed; survives only as long as you do
-waifu.sqlite     → imperial-net premium intimate channel; audited; player-pruned;
-                   carries the moral-weight of complicity
+primary.sqlite     → realworld speech-acts; everyone-witnesses; audit-overseer-eligible
+clasp.sqlite       → in-between intimate channel; sealed; survives only as long as you do
+companion.sqlite   → imperial-net premium intimate channel (companion + sex-worker rentals);
+                     audited; player-pruned; carries the moral-weight of complicity
 ```
 
-**Memorialists' political project gains a new dimension** in v0.8: they don't just track regime-corruption (lifeforce_actual vs lifeforce_reported); they track *`waifu.sqlite` pruning patterns across the population* as evidence of how much intimate-life the regime is harvesting via the premium-net mechanism. *Who is pruning what, when, how often* becomes Memorialist-archive-worthy data. The four-column true-ledger gains a fifth column: `waifu_extraction_volume_per_district`.
+**Memorialists' political project gains a new dimension** in v0.8: they don't just track regime-corruption (lifeforce_actual vs lifeforce_reported); they track *`companion.sqlite` pruning patterns across the population* as evidence of how much intimate-life the regime is harvesting via the premium-net mechanism. *Who is pruning what, when, how often* becomes Memorialist-archive-worthy data. The four-column true-ledger gains a fifth column: `service_body_extraction_volume_per_district`.
 
 ### The three-tier knowledge stack on the local LLM
 
@@ -498,4 +498,4 @@ Scene-to-sampling mapping (caste-preacher = 0.3/0.6/low; drunk-scavenger = 1.1/0
 
 ---
 
-**Version:** 0.7.0 | **Created:** 2026-04-26 | **Updated:** 2026-04-26 | **Origin:** Split from architecture-index.md v0.7 (2026-04-26)
+**Version:** 0.7.1 | **Created:** 2026-04-26 | **Updated:** 2026-04-27 | **Origin:** Split from architecture-index.md v0.7 (2026-04-26)