Files
jason.woltje 068d868a99 lead: commit rocko's untracked evidence (4471 files: queue-124 queue-129 queue-171 queue-178 queue-280 queue-31 queue-84 queue-85 queue-94)
Unclaimed files left in the canonical checkout. Inventory: canonical-cleanup-inventory.md (commit-as-evidence groups). detect-secrets scan clean on 2026-11-02: hits are sha256 pins, git object ids, test sentinels already in tracked tests and unit-file lines.
2026-11-02 15:05:15 -06:00

3.9 KiB

Row 124 — schema and activation notes (no live actions performed)

Base: 9098c33f7. Schema-current fixture is base packages/bus/schema.sql, copied to packages/bus/tests/fixtures/schema-3g.sql. SHA-256: a79b3dbe6f4dfba10871c01ad8513ea290071eb8d8af2b87be6db52dbcf23428. It is repository code, never a live database read.

3g to 3h

Exact DDL is packages/bus/src/migrations/3g-3h.sql in build.patch. Its SHA-256: 76168e4f9f6b427286ddb8402fd833acadb01d6325a85f60e9ccf8d42fe2d1d0. It creates usage_records and its three append-only triggers. No previous column, row, view or trigger changes. Records carry time, business, run, instance, provider/model, null account, delivered-message turn id, source, begin/end phase, known/unknown status, fixed reason, baseline usage metadata and the four nullable counter fields. Unknown counters are null. The unique business/run/turn/source/phase key makes replays idempotent. No transcript text is stored; cursor holds assistant usage identities and counters only.

Fresh schema SHA-256: bb2ba58175a111bb99681778911507846bef714a6d573f8a8af67580a3636950. Store exports 3h and follows the existing ordered registry. The future fixture now chains 3h→3i. Normal startup refuses an unmigrated 3g store.

usage-migration.test.mjs builds a 3g fixture from that pinned DDL, seeds every old evidence table including instance_names, takes an untouched database copy, and compares all prior columns/rows and sequence counters after migration. The untouched copy remains byte-identical; integrity and foreign keys pass. No seat ran any migration on the live store.

Mos's separate window

This is a procedure for Mos, not authorization for a seat to execute it. Public/ landing needs Mos's go (decision 123); activation is a later approved re-pin with downtime (decision 109).

  1. Mos arranges the idle/stop window and stops the stack through the authorized lifecycle entry. Seats never start, stop or restart bus or Console units.
  2. With the writer stopped, Mos makes and verifies a consistent backup of the full bus store (including any WAL state) and retains the previous pinned copy.
  3. Mos tests the new pinned copy's offline command against a copied backup first: node <new-copy>/packages/bus/src/migrate-schema.mjs /absolute/copied-dataRoot. The copied tree's permissions and its bus directory stay private. Verify bus schema 3h ready, evidence counts and the new empty usage table. Never point a seat's command at the live data root.
  4. In that same approved stopped-writer window Mos runs that offline migration against the intended live data root, then re-pins and starts the new copy. A failure leaves the writer stopped for inspection; there is no auto-migration.
  5. Jason or Mos enables the source through the existing human proof, retaining every other plug-in setting. Read mosaic plugins --business <business> --json for its current revision, then pass a fixture-shaped patch to the human writer: { "revision": "<current revision>", "plugins": { "usage-source": ["transcript"] } }. Use mosaic plugins set --file <human-created-patch> --business <business>. If another usage source is already enabled, retain its name in that list. The current loader reads settings at bus start; the authorized window must load the intended setting. Mos performs any required controlled bus restart after the switch, still within their approved window. No agent reads or changes Jason's file.
  6. Verify a fixture/test turn's accounting through mosaic usage --json and the separate Settings Token usage section, including an explicit unknown. No token-limit enforcement is claimed by this row.

Rollback is a stopped-stack restoration of the consistent backed-up store and previous pinned copy together. A previous 3g bus refuses a 3h database. Do not attempt a down-migration or retain only part of the accounting evidence. Mos owns the rollback decision and its evidence window.