Turso was promoted into the live stack with zero ADR, zero TECHSPEC footprint, no module home and no encryption tier

Источник: dev/fera-research/docs/oc1/024-turso-promoted-with-no-adr-no-tier-no-owner.md (read-only; сгенерировано scripts/sync-docs.mjs)

Turso was promoted into the live stack with zero ADR, zero TECHSPEC footprint, no module home and no encryption tier

• kind: problem
• area: storage / modules
• evidence:
  • Zero mentions in any of the four normative docs. Verified by grep: turso|ttso → ADR.md: 0, TECHSPEC.md: 0, RFC.md: 0, QA.md: 0.
  • But it is in the canonical runtime tree and given three live roles:
    • OQ.md:698 — the FINAL tree includes “themes/, predictor/, _index.ttso (Turso cache-metadata index)”.
    • OQ.md:670-671 — “manifest.ttso + config.ttso … all signed”.
    • OQ.md:719-724 — Turso has three concrete roles; “sanakirja KV holds blobs, Turso answers ‘which stickers are older than N’”; extension tentatively .ttso (OQ.md:659-660, FUTURE-CHECKS.md:59-60).
  • FUTURE-CHECKS contradicts itself 16 lines apart:
    • FUTURE-CHECKS.md:26-28 (§1) — “Decision so far: None. Flagged as a real, anticipated future need… Turso Database (§2 below) is the leading candidate to investigate.”
    • FUTURE-CHECKS.md:42-43 (§2) — “Update (2026-10-01): PROMOTED to live stack member (OQ-021). Turso is now slated for three concrete roles”. Neither section was reconciled, and FUTURE-CHECKS.md:96-99 still lists open scope (“whether milli’s fork … would need a second retargeting if search ever wanted to sit on top of Turso DB”) that the promoted design moots (search stays on sanakirja, OQ.md:723-724).
  • ADR-021 points at the unresolved version: ADR.md:855-858 — “Data- model mapping across the axes … stays a live concern — see FUTURE-CHECKS §1/§2 for the SQL layer discussion.”
  • The readiness check the file itself promised was never done: FUTURE-CHECKS.md:47-48 — “re-verify production-readiness before the first release that ships Turso files”. The status it recorded is FUTURE-CHECKS.md:60-61 — “late Sept 2026: Beta, explicitly not production-ready per the Turso team themselves” — dated before promotion and never refreshed.
  • The embeddability question was posed and never answered: FUTURE-CHECKS.md:82-85 lists “can it be embedded as a hot-swappable native module” as a thing to check. The canonical module tree (OQ.md:679-680) lists storage/ … types, engine, filesystem, serialization, search, cache — Turso appears in no module, and TECHSPEC.md:30-39 has no Turso crate either.
  • FUTURE-CHECKS.md:79-81 also flags a real unresolved conflict: Turso is async-first, while ADR-006/ADR-007 commit to ractor-on-tokio with raw types and no second async story.
• severity: mid

Суть / Substance

A component with four ADR-level obligations was promoted into the runtime by an OQ resolution block, and it has none of the four:

1. No ADR. Per README.md:41-45, architecture decisions belong in ADR.md. A new on-disk dependency with signed files in the data root is architecture.
2. No encryption tier. ADR-031’s audit table (ADR.md:648-664) is the reference for QA’s gate that every persisted type has a tier (QA.md:22-24, see my finding 014). .ttso files — including a signed manifest.ttso and config.ttso, i.e. files that describe modules and configuration — have no tier assignment, so QA’s cross-cutting gate is currently unsatisfiable for them, and nothing records whether they are plaintext or encrypted.
3. No module or crate home. A data file that the cache layer must query needs an owner: a crate in TECHSPEC §0, or a module in the canonical tree, plus an embeddability decision. Neither exists. FUTURE-CHECKS.md:82-85 flagged exactly this and it was never checked.
4. No readiness re-verification, and the one status on file says “not production-ready”. Promoting a component to “live stack member” while its own file says Beta/not-production-ready, without a refreshed check, is how a launch-day surprise happens.

The concrete failure modes are unglamorous and real: a manifest index the client cannot open on a fresh install; a cache-metadata query path that needs a component nobody has linked; an async runtime conflict (Turso vs ractor/tokio) discovered during implementation; and a signed file with no tier, so the “everything on disk is tiered” property quietly has exceptions nobody wrote down.

Варианты решения (tradeoffs)

• (A) Write the ADR and finish the integration. New ADR for Turso: role, tier assignment, ownership (crate or module), embeddability verdict, async-interop rule, readiness criterion (what “production-ready” means before it ships). Then update FUTURE-CHECKS §1/§2 to both reflect promotion, and ADR-021’s pointer.
• (B) Demote it back to FUTURE-CHECKS (revert the OQ-021 promotion), keep sanakirja for everything, and let the cache-metadata query be a sanakirja index. Simplest, one less dependency, and sanakirja can answer “which items are older than N” — the one query Turso was promoted for.
• (C) Split the decision: adopt Turso for the config/manifest index only (small, read-mostly, low risk), defer the cache-metadata index (large, write-heavy, the one that meets eviction — my finding 013).
• (D) Leave as-is. Reject: it is in the runtime tree with no owner.

Предлагаемое решение

(A), or (C) if the author wants to limit the blast radius — but either way the promotion needs an ADR within one change, and the tier question needs an answer within the same week.

1. ADR “Turso as cache-metadata / manifest index” with: the three roles and which are in v1; the tier assignment for .ttso (recommend metadata tier + signature, consistent with OQ.md:670-671’s “all signed” — and note that signature-over-plaintext is exactly the “rebuildable artifact” case my finding 006’s threat model treats differently from user data); ownership (crate in core, not a module — see finding 015’s split, since Turso is not hot-swappable-worthy and FUTURE-CHECKS.md:82-85 never got an answer); the async-interop rule (Turso handles run on the tokio runtime ADR-006 already commits to, no second runtime); and the readiness gate the file itself promised (FUTURE-CHECKS.md:47-48).
2. Reconcile FUTURE-CHECKS: §1’s “Decision so far: None” must change (it has now been decided), and §2’s open scope (FUTURE-CHECKS.md:96-99, the second-retargeting question) should be closed as moot by reference to the ADR. Update ADR-021:855-858’s pointer to the ADR rather than to the parked discussion.
3. Add a QA gate: every file in the canonical runtime tree (OQ.md:664-700) has a named owner component and a tier assignment. That gate generalizes: it would have caught the sticker cache too (finding 013).
4. Add the cache-eviction interaction (finding 013): the Turso index is what answers “which cached items are stale”, so the quota/eviction ADR and this one should reference each other — otherwise the index tracks a cache with no eviction policy, which is useless.
5. Note the honest cost: if the only query Turso exists to answer is “which stickers are older than N”, sanakirja can answer it, and (B)/(C) are legitimate. The corpus should record why Turso won that trade, or the decision will be re-litigated when the next person reads FUTURE-CHECKS §1 and sees “leading candidate to investigate”.