chiltepin 0.47.0

package/templates/skill/reference/exemplars/data-pipeline.md

@@ -0,0 +1,107 @@
+```meta
+title: Trips pipeline
+subtitle: How 2.1 billion daily tracker pings become the trips Loxley bills and scores.
+tag: Data · v3
+```
+
+Loxley sells fleet telematics: 140,000 delivery vehicles carry a tracker that
+reports position and speed every few seconds. Trackers buffer offline — tunnels,
+depots, dead zones — so pings arrive up to 48 hours late. The pipeline therefore
+streams with a 48-hour dedupe window keyed on `(vehicle_id, recorded_at)`.
+Staleness has a user-facing price: fleet managers review yesterday's trips at
+07:00 local, and per-mile invoices draw on the same rows.
+
+## From pings to trips
+
+```dfd
+id: ex-pipeline-dfd
+nodes:
+  - { id: fleet, col: 1, row: 1, kind: external, name: Tracker fleet }
+  - { id: ingest, col: 2, row: 1, kind: process, name: Ingest gateway, num: 1 }
+  - { id: raw, col: 3, row: 1, kind: store, name: pings.raw · Kafka }
+  - { id: dlq, col: 2, row: 2, kind: store, name: pings.dlq }
+  - { id: dedupe, col: 4, row: 1, kind: process, name: Deduper, num: 2 }
+  - { id: sess, col: 5, row: 1, kind: process, name: Sessionizer, num: 3 }
+  - { id: trips, col: 6, row: 1, kind: store, name: trips-db · Postgres }
+edges:
+  - { from: fleet, to: ingest, label: pings }
+  - { from: ingest, to: raw }
+  - { from: ingest, to: dlq, label: malformed }
+  - { from: raw, to: dedupe }
+  - { from: dedupe, to: sess, label: unique pings }
+  - { from: sess, to: trips, label: closed trips }
+```
+
+The sessionizer is the lossy stage by design: it closes a trip after five idle
+minutes. That collapses 2.1 billion pings into about 9.4 million trips a day. Raw
+pings expire after 30 days; safety scores, invoices, and dashboards all read
+trips, never pings.
+
+## Trips at rest
+
+```erd
+id: ex-pipeline-erd
+entities:
+  - name: vehicles
+    columns:
+      - { name: id, type: uuid, pk: true }
+      - { name: fleet_id, type: uuid }
+      - { name: tracker_serial, type: text }
+  - name: trips
+    columns:
+      - { name: id, type: uuid, pk: true }
+      - { name: vehicle_id, type: uuid, fk: true }
+      - { name: started_at, type: timestamptz }
+      - { name: ended_at, type: timestamptz }
+      - { name: distance_m, type: int }
+  - name: trip_points
+    columns:
+      - { name: trip_id, type: uuid, fk: true }
+      - { name: recorded_at, type: timestamptz }
+      - { name: speed_kph, type: smallint }
+relations:
+  - vehicles ||--o{ trips: drives
+  - trips ||--o{ trip_points: samples
+```
+
+`distance_m` is computed once, when the trip closes, and never recomputed — an
+invoice printed in March must match the trip row it was billed from.
+
+## Replaying a gap
+
+```steps
+id: ex-pipeline-replay
+items:
+  - title: Size the gap
+    body: Compare the ingest tally against the deduper's output for the affected hours.
+    code: lox lag --topic pings.raw --by hour
+    lang: bash
+  - title: Replay inside the window
+    body: The deduper drops every ping it has already seen, so a bounded replay is safe.
+    code: lox replay --topic pings.raw --from 2026-08-21T06:00Z --to 2026-08-21T09:00Z
+    lang: bash
+    note: Give both bounds; the tool refuses an unbounded replay.
+  - title: Verify counts
+    body: Close the incident only when trip counts match the ingest tally within 0.01%.
+    code: lox verify trips --day 2026-08-21
+    lang: bash
+```
+
+```callout
+tone: danger
+title: Never replay past 48 hours
+body: "Beyond the dedupe window the deduper has forgotten the pings, so a replay re-creates trips that invoices already used — miles get billed twice. For older gaps run `lox rebuild --day`, which deletes and re-sessionizes whole days atomically."
+```
+
+## Freshness commitments
+
+```slo
+id: ex-pipeline-slo
+items:
+  - { name: Freshness, sli: Ping visible as trip data within 15 min, target: 99%, current: 99.4%, window: 30d, budget: 0.6 }
+  - { name: Completeness, sli: Trip closed within 48 h of its last ping, target: 99.9%, current: 99.95%, window: 30d, budget: 0.5 }
+  - { name: Scoring latency, sli: Safety score updated within 24 h of trip close, target: 99.5%, current: 99.1%, window: 7d, budget: 1.8 }
+```
+
+The scoring objective is breached at 1.8× budget: the scorer re-shards this
+week, and feature work on it stays frozen until the budget recovers.

package/templates/skill/reference/exemplars/frontend-arch.md

@@ -0,0 +1,93 @@
+```meta
+title: Terrastride field app
+subtitle: The offline-first inspection app wind-turbine technicians run on tower phones.
+tag: Frontend · SPA
+```
+
+Terrastride is a React SPA behind a service worker, not an SSR app.
+Technicians spend up to 9 hours offline inside a tower, and 60% of sessions
+touch the network zero times. Server rendering buys nothing when there is no
+server to reach. The costs we accept: a 180 KB gzip bundle budget on first
+load, and every read and write goes through IndexedDB.
+
+## Module tree
+
+```frontend
+id: ex-frontend-arch-tree
+nodes:
+  - { id: app, kind: root, name: App }
+  - { id: sync, parent: app, kind: provider, name: SyncProvider, note: owns the network }
+  - { id: shell, parent: app, kind: layout, name: Shell }
+  - { id: turbines, parent: shell, kind: page, name: TurbineListPage }
+  - { id: turbine, parent: shell, kind: page, name: TurbineDetailPage }
+  - { id: inspections, parent: shell, kind: page, name: InspectionListPage }
+  - { id: inspection, parent: shell, kind: page, name: InspectionPage }
+  - { id: syncpage, parent: shell, kind: page, name: SyncPage }
+  - { id: checklist, parent: inspection, kind: component, name: ChecklistForm }
+  - { id: photo, parent: inspection, kind: component, name: PhotoCapture }
+  - { id: outbox, parent: sync, kind: store, name: outboxStore, note: IndexedDB queue }
+  - { id: useoutbox, parent: checklist, kind: hook, name: useOutbox }
+```
+
+The rule the tree must keep: pages read IndexedDB and nothing else.
+`SyncProvider` is the only module that imports the network layer, so "does
+this work offline?" is answered by the import graph, not by testing every
+screen.
+
+## The inspection screen
+
+```wireframe
+id: ex-frontend-arch-screen
+screens:
+  - device: phone
+    title: "T-114 · Gearbox"
+    label: InspectionPage — offline, 4 writes queued
+    elements:
+      - { type: header, label: "Gearbox inspection" }
+      - { type: badge, label: "offline · 4 queued", tone: muted, align: r }
+      - { type: card, rows: 3 }
+      - { type: input, label: Torque reading }
+      - { type: button, label: Add photo }
+      - { type: button, label: Complete inspection, tone: accent }
+      - { type: tabs, label: "Turbines, Inspections, Sync" }
+```
+
+The queued badge is the only sync UI on this screen. Sync state stays
+ambient, and the technician never leaves the checklist to check on it.
+
+## Record lifecycle
+
+```state
+id: ex-frontend-arch-lifecycle
+states:
+  - { id: s0, col: 1, row: 1, kind: start }
+  - { id: draft, col: 2, row: 1, kind: active, name: DRAFT }
+  - { id: queued, col: 3, row: 1, kind: wait, name: QUEUED }
+  - { id: syncing, col: 4, row: 1, kind: active, name: SYNCING }
+  - { id: synced, col: 5, row: 1, kind: terminal, name: SYNCED }
+  - { id: conflict, col: 4, row: 2, kind: wait, name: CONFLICT }
+transitions:
+  - { from: s0, to: draft, event: open inspection }
+  - { from: draft, to: queued, event: technician taps Complete }
+  - { from: queued, to: syncing, event: radio regained, guard: outbox not empty }
+  - { from: syncing, to: synced, event: server ack }
+  - { from: syncing, to: conflict, event: server version newer }
+  - { from: conflict, to: queued, event: technician merges on SyncPage }
+```
+
+Records sit in QUEUED longest — median 3.4 hours, the rest of the tower
+visit. The UI treats QUEUED as success: the badge counts quietly, and a
+queued record never blocks starting the next inspection.
+
+## Routes
+
+```table
+id: ex-frontend-arch-routes
+columns: [Route, Screen, Offline behavior]
+rows:
+  - ["/turbines", TurbineListPage, Served from cache — never blocks on network]
+  - ["/turbines/:id", TurbineDetailPage, "Cache first, silent refetch when radio returns"]
+  - ["/inspections", InspectionListPage, "Local list from cache + outbox — queued records included"]
+  - ["/inspections/:id", InspectionPage, All writes go to the outbox]
+  - ["/sync", SyncPage, "Queue, conflicts, manual retry — the only network-aware UI"]
+```

package/templates/skill/reference/exemplars/incident-postmortem.md

@@ -0,0 +1,93 @@
+```meta
+title: SEV-1 · 2026-07-14 — duplicate campaign sends
+subtitle: A 60-second visibility timeout met a 90-second batch job; 1.9M subscribers got the same email twice.
+tag: Postmortem · SEV-1
+```
+
+Quillfeed sends about 62 million campaign emails a day through workers that
+consume send-batch jobs from a queue. On 14 July a config refactor silently
+dropped the send queue's visibility-timeout override, and the broker began
+redelivering jobs that were still in flight. All times are UTC.
+
+## Timeline
+
+```timeline
+id: ex-incident-timeline
+items:
+  - "14:12 · Deploy ships · The queue-defaults refactor drops the send queue's 15-minute visibility override to the new 60 s default"
+  - "14:22 · First duplicates · The broker redelivers in-flight batch jobs; second workers re-send them"
+  - "14:26 · Support signal · Duplicate-email tickets spike; no alert has fired"
+  - "14:29 · Pager · The esp-accept-rate anomaly alert fires at 2.3× forecast"
+  - "14:37 · Mitigation · On-call correlates with the 14:12 deploy and pauses all send queues"
+  - "14:41 · Rollback · Config revert restores the 15-minute timeout"
+  - "14:52 · Resume · Sends restart after in-flight jobs are checked against the send ledger"
+  - "15:03 · Resolved · Send rate returns to forecast; SEV closed"
+```
+
+Detection was the slow half: eleven minutes passed between the first customer
+ticket and the queue pause, because no dashboard tied send-rate anomalies to
+deploys. Support saw the incident three minutes before the pager did.
+
+## The mechanism
+
+```sequence
+id: ex-incident-seq
+actors:
+  - { id: Broker, name: Broker, sub: send queue }
+  - { id: A, name: Worker A }
+  - { id: B, name: Worker B }
+  - { id: ESP, name: ESP, sub: email provider, external: true }
+messages:
+  - { from: Broker, to: A, label: deliver batch 4411, summary: "500 recipients; a batch takes about 90 seconds end to end." }
+  - { from: A, to: A, kind: note, label: ledger check passes, summary: "None of the 500 recipients has a send record yet." }
+  - { from: A, to: ESP, label: send 500 emails }
+  - { from: Broker, to: B, label: redeliver 4411, kind: error, summary: "No ack after 60 seconds — the new default timeout — so the broker assumes Worker A died." }
+  - { from: B, to: B, kind: note, label: ledger check passes again, summary: "Worker A records sends only after the ESP accepts, so the ledger still shows nothing." }
+  - { from: B, to: ESP, label: send the same 500 }
+  - { from: A, to: Broker, label: ack — 30 s late, kind: response }
+foot:
+  - { label: Root cause, value: timeout 60 s < batch 90 s }
+  - { label: Amplifier, value: ledger written after the send }
+```
+
+The ledger made sends look idempotent without making them idempotent. Workers
+checked it before the send but wrote it only after the ESP accepted — a
+90-second window in which the check lies. The timeout change did not create
+that window; it built a machine that hit it on every batch.
+
+## Impact
+
+```stats
+id: ex-incident-impact
+stats:
+  - { value: 1.9M, label: Duplicate emails, delta: "3.1% of daily volume" }
+  - { value: 41 min, label: Impact to resolution, delta: "detection took 7 of them" }
+  - { value: "214", label: Campaigns affected }
+  - { value: 3.1×, label: Unsubscribe rate on affected campaigns, trend: up, delta: vs. baseline }
+```
+
+## Remediation
+
+```statustable
+id: ex-incident-remediation
+columns: [Action, Owner, Done / due]
+statuses:
+  - { label: shipped, color: success }
+  - { label: scheduled, color: neutral }
+rows:
+  - { cells: ["Send ledger written before the ESP call; failed writes reconciled hourly", Delivery, 2026-07-16], status: shipped }
+  - { cells: ["Visibility timeouts pinned per queue by a config test that fails on defaults", Platform, 2026-07-21], status: shipped }
+  - { cells: [Deploy markers on every send-rate dashboard, Observability, 2026-08-01], status: in progress }
+  - { cells: ["Duplicate-send canary — pages when the duplicate rate passes 0.1%", Delivery, 2026-08-15], status: scheduled }
+```
+
+## Takeaways
+
+```takeaways
+id: ex-incident-takeaways
+items:
+  - Record intent before the side effect — a ledger written after the send is a race, not a guarantee.
+  - Defaults are code — the 15-minute override lived in config nobody tested, and a refactor deleted it silently.
+  - text: Users out-detect dashboards on duplicates
+    detail: Support tickets led the pager by three minutes; a duplicate-rate canary closes that gap.
+```

package/templates/skill/reference/exemplars/migration-plan.md

@@ -0,0 +1,95 @@
+```meta
+title: Orders store migration
+subtitle: Moving 480M orders off the monolith database, with a rollback path at every phase.
+tag: Plan · Q3–Q4
+```
+
+Hollybank's `orders` table is 2.3 TB inside the monolith's shared Postgres.
+Write p95 is 210 ms and climbs about 8 ms a month; autovacuum now runs
+11 hours and blocks schema changes. We move orders to a dedicated cluster,
+partitioned by month, behind the existing `OrdersRepo` interface — application
+code does not change. Every phase is reversible until the old copy is
+destroyed, and that happens no earlier than 30 days after cutover.
+
+## Today and target
+
+```cvt
+id: ex-migration-cvt
+current:
+  label: Monolith DB
+  items:
+    - orders plus 61 other tables in one Postgres
+    - "2.3 TB, 480M rows"
+    - "write p95 210 ms, rising"
+    - autovacuum runs 11 h and blocks DDL
+target:
+  label: orders-db
+  items:
+    - dedicated cluster, partitioned by month
+    - write p95 under 40 ms
+    - DDL touches one partition at a time
+    - old copy kept warm for 30 days after cutover
+note: OrdersRepo stays the only entry point; just its wiring changes.
+```
+
+## Cutover as a state machine
+
+```state
+id: ex-migration-state
+states:
+  - { id: s0, col: 1, row: 1, kind: start }
+  - { id: dual, col: 2, row: 1, kind: active, name: DUAL_WRITE }
+  - { id: backfill, col: 3, row: 1, kind: active, name: BACKFILL }
+  - { id: shadow, col: 4, row: 1, kind: active, name: SHADOW_READ }
+  - { id: readnew, col: 5, row: 1, kind: active, name: READ_NEW }
+  - { id: writenew, col: 6, row: 1, kind: active, name: WRITE_NEW }
+  - { id: done, col: 7, row: 1, kind: terminal, name: DONE }
+transitions:
+  - { from: s0, to: dual, event: flag on }
+  - { from: dual, to: backfill, event: writes verified 24 h }
+  - { from: backfill, to: shadow, event: history copied, guard: row counts match }
+  - { from: shadow, to: readnew, event: 7 clean days, guard: "mismatch < 0.001%" }
+  - { from: readnew, to: writenew, event: 7 clean days, guard: read p95 at or under old }
+  - { from: writenew, to: done, event: 30 quiet days }
+  - { from: shadow, to: dual, event: mismatch spike }
+  - { from: readnew, to: shadow, event: read errors or drift }
+  - { from: writenew, to: readnew, event: rollback flag, guard: "reverse replication lag < 60 s" }
+```
+
+The state names are literal values of the `orders_migration_phase` flag, so the
+diagram, the flag, and the dashboards share one vocabulary. WRITE_NEW is not
+the point of no return — the old database follows through reverse replication
+and can resume as primary in minutes. The only irreversible transition is
+into DONE.
+
+## Write-cutover runbook
+
+```steps
+id: ex-migration-runbook
+items:
+  - title: Freeze schema changes
+    body: "The freeze flag rejects DDL on orders in both stores; announce it in #eng first."
+    code: hb flags set orders_ddl_freeze on
+    lang: bash
+  - title: Confirm reverse replication
+    body: Rollback depends on it; lag must stay under 60 s before and during the flip.
+    code: hb repl status orders-reverse --watch
+    lang: bash
+  - title: Flip the write primary
+    code: hb flags set orders_migration_phase WRITE_NEW
+    lang: bash
+    note: The flag drains in-flight transactions for up to 5 s — expect a latency blip, not errors.
+  - title: Hold the exit criteria for 30 minutes
+    body: "Write p95 under 40 ms, zero dual-write mismatches, reverse lag under 60 s. On any breach, flip back to READ_NEW and debug offline — never in place."
+```
+
+## Risks
+
+```risk
+id: ex-migration-risks
+items:
+  - { risk: "Three cron jobs write orders with raw SQL, bypassing OrdersRepo and the dual-write layer", likelihood: high, impact: high, mitigation: "Two rewritten, one deleted; the bypass audit re-runs weekly until DONE.", owner: Monolith, status: mitigating }
+  - { risk: Reverse replication breaks silently and the rollback path becomes fiction, likelihood: med, impact: high, mitigation: "Lag over 60 s pages at production severity, day and night.", owner: Storage, status: mitigating }
+  - { risk: Diff sampler misses drift inside JSON columns, likelihood: low, impact: high, mitigation: Rows are canonicalized before hashing., owner: Storage, status: closed }
+  - { risk: Backfill competes with month-end order load, likelihood: med, impact: med, mitigation: Copy is rate-limited and pauses itself when monolith write p95 passes 150 ms., owner: Storage, status: open }
+```

package/templates/skill/reference/exemplars/onboarding.md

@@ -0,0 +1,78 @@
+```meta
+title: Ingest team — week one
+subtitle: What a new engineer sets up, reads, and ships in the first five days.
+tag: Onboarding
+```
+
+Nocturne's ingest tier accepts 2.1M spans per second across three regions.
+This team owns the gateway, the sampler, and the Kafka topics between them.
+The week has one goal: ship a guarded sampler-config change to staging by
+Friday, with your own hands on every step.
+
+## Who to ask
+
+```team
+id: ex-onboarding-people
+members:
+  - { name: Priya Nair, role: Tech lead, focus: "Sampler, capacity planning", accent: navy }
+  - { name: Jonas Weber, role: SRE, focus: "Gateway, on-call rotation, staging access", accent: teal }
+  - { name: Mel Torres, role: Backend, focus: "Kafka topics, schema registry", accent: purple }
+  - { name: "#ingest-help", initials: IH, role: Slack channel, focus: First stop for any question — median answer 11 minutes, accent: green }
+```
+
+## Day one — local stack
+
+```steps
+id: ex-onboarding-setup
+items:
+  - title: Clone and bootstrap
+    body: Bootstrap installs the pinned toolchain and takes about 15 minutes on first run.
+    code: git clone git@github.com:nocturne/ingest.git && make bootstrap
+    lang: bash
+  - title: Start the local stack
+    body: "Gateway, sampler, and a single-broker Kafka run in Docker."
+    code: make stack-up
+    lang: bash
+  - title: Run the smoke test
+    body: The test pushes 400 synthetic spans end to end and checks the drop-rate counter.
+    code: make smoke
+    lang: bash
+    note: "A red smoke test on a clean clone is a bug — report it in #ingest-help the same day."
+  - title: Request staging access
+    body: Request the "ingest-staging-rw" role in the access portal. Jonas approves same day.
+```
+
+```callout
+id: ex-onboarding-replay
+tone: warn
+title: Replay targets staging only
+body: "`make replay` re-sends captured traffic. A production broker accepts replayed spans as real tenant data, and they land in customer dashboards. Check the `KAFKA_BROKERS` value before every replay."
+```
+
+## The week
+
+```timeline
+id: ex-onboarding-week
+items:
+  - "[done] Day 1 · Local stack · Smoke test green; staging access requested"
+  - "[done] Day 2 · Read path · Pair with Mel and follow one span from gateway to sampler"
+  - "[current] Day 3 · Shadow on-call · Sit in on Jonas's handover; read the two latest incident docs"
+  - "[next] Day 4 · First change · Raise tail sampling for the demo tenant behind ingest.sampler.demo_rate"
+  - "[next] Day 5 · Ship it · Flag on in staging; watch the drop-rate dashboard for one hour"
+```
+
+Day 4's change is deliberately trivial. The point is the path — flag,
+review, staging deploy, dashboard — not the diff, so that your first urgent
+change is not also your first deploy.
+
+## Vocabulary
+
+```glossary
+id: ex-onboarding-terms
+terms:
+  - Span — one timed operation; the unit everything on this team counts.
+  - Drop rate — spans the sampler discards as a share of spans received; the team's headline SLI.
+  - Head sampling — keep/drop decided at the gateway, before the trace is complete.
+  - Tail sampling — decided in the sampler once the full trace arrives; costs memory, saves storage.
+  - Tenant — one customer's isolated stream; every dashboard and quota is per-tenant.
+```

package/templates/skill/reference/exemplars/product-spec.md

@@ -0,0 +1,81 @@
+```meta
+title: Plot transfer & waitlist
+subtitle: How a Loamly garden plot moves from a leaving member to the next person in line.
+tag: Spec · v1
+```
+
+Loamly manages 140 community gardens, and the median waitlist is 23 people
+deep. Today a plot changes hands by email between the coordinator and
+whoever answers first — position in line is a suggestion. This feature makes
+the handover self-serve for the member and automatic for the waitlist, with
+the coordinator as an approval gate only.
+
+## The story
+
+```userstory
+id: ex-product-spec-story
+role: plot holder who is moving away
+want: hand my plot back without emailing the coordinator
+soThat: the next person in line gets it before planting season
+priority: High
+points: 5
+criteria:
+  - { given: I hold an active plot, when: I start a transfer, then: the plot enters the offer flow and I keep access for up to 14 days }
+  - { given: I am first on the waitlist, when: I receive an offer, then: I have 72 hours to accept before it moves on }
+  - { given: I decline an offer, when: the next offer round starts, then: my waitlist position is unchanged }
+links:
+  - { ref: "#ex-product-spec-flow", mode: flow, label: Offer flow }
+```
+
+## Offer flow
+
+```flow
+id: ex-product-spec-flow
+nodes:
+  - { id: start, col: 1, row: 1, kind: start, label: Transfer started }
+  - { id: approve, col: 2, row: 1, kind: decision, label: Coordinator approves? }
+  - { id: keep, col: 2, row: 2, kind: end, label: Plot stays with holder }
+  - { id: offer, col: 3, row: 1, kind: process, label: Offer to next in line }
+  - { id: accept, col: 4, row: 1, kind: decision, label: "Accepted within 72 h?" }
+  - { id: assign, col: 5, row: 1, kind: end, label: Plot assigned }
+  - { id: more, col: 4, row: 2, kind: decision, label: More on waitlist? }
+  - { id: dormant, col: 5, row: 2, kind: end, label: Dormant — coordinator review }
+edges:
+  - start -> approve
+  - approve -x-> keep: "no"
+  - approve -> offer: "yes"
+  - offer -> accept
+  - accept -> assign: "yes"
+  - accept -> more: "no / expired"
+  - more -> offer: "yes"
+  - more -x-> dormant: "no, or 3 offers made"
+```
+
+The 72-hour window and the three-offer cap exist for the same reason. A
+transfer that drags past two weeks straddles planting season, and a plot
+idle in April is the outcome every party loses on.
+
+## Invariants
+
+```spec
+id: ex-product-spec-invariants
+accent: green
+rows:
+  - { label: One plot per member, value: "A member holds at most one active plot per garden. A transfer that would create a second is refused at start, not at assignment." }
+  - { label: Sticky position, value: "Declining an offer keeps your waitlist position. Only accepting a plot removes the entry." }
+  - { label: Offer window, value: "72 hours per offer, at most 3 offers per transfer, then the plot goes dormant for coordinator review." }
+  - { label: Access overlap, steps: [Transfer starts, "Holder keeps access ≤ 14 days", Access ends at assignment] }
+```
+
+## Scope edges
+
+```table
+id: ex-product-spec-scope
+columns: [Capability, v1, Why]
+rows:
+  - [Member-initiated transfer, { v: In, tone: pos }, The core loop above]
+  - [Coordinator-forced reassignment, { v: In, tone: pos }, "Abandoned plots exist; coordinators need the same flow without the member"]
+  - [Plot swaps between two members, { v: Out, tone: muted }, "2% of requests — stays manual"]
+  - ["Priority rules (seniority, household size)", { v: Out, tone: muted }, "FIFO only in v1; priority differs per garden's bylaws and needs its own spec"]
+  - [Plot fees and payments, { v: Out, tone: muted }, Handled off-platform today and out of this feature's blast radius]
+```