Migration and compatibility boundaries

MindRoom keeps substantive historical schemas and representations in named legacy modules. Historical-format production owners use legacy_<subject>.py beside their current owner, including one-time upgrades and recurring old-data readers. The current storage or lifecycle owner keeps its transaction, locking, validation, authorization, retry, and current-format processing. Small field defaults stay with their current model when extraction would add indirection without isolating a meaningful migration. Dependency-owned migrations and authoritative SaaS data remain under their existing owners.

This page maps every item from the migration audit to its current owner and disposition. It describes the current source rather than promising support for every earlier release.

Each legacy compatibility comment starts with # LEGACY_COMPAT: <short description of the legacy format>, followed by its release provenance, handling, and coverage. The marker also applies to documented defaults and compatibility notes kept beside current owners. Find all marked Python rules, including the SaaS backend, from the repository root:

rg -n -F 'LEGACY_COMPAT:' --glob '*.py'

Status terms

Named boundaries

The first fourteen rows were created or renamed by the migration-boundary isolation work. The remaining rows include existing focused boundaries and later audit additions.

Python provenance and regression coverage

Each historical Python boundary carries a source block naming its legacy format, last native old writer and replacement, current handling, and meaningful regression coverage. Those source blocks are authoritative for exact release details and test node IDs; this index groups boundaries that share a behavioral test surface. Last legacy release means the final stable tagged release whose native writer or typed model emitted the old representation, not the final reader that accepted it. Continued acceptance or reader removal belongs in Handling, separate from the writer cutoff and replacement release. When no stable tag contained an old native writer, the block uses an honest unreleased, unversioned external-input, or no-tagged-model classification; schema-based recovery likewise states that it has no single release cutoff.

This index intentionally excludes current authoring shorthands, protocol adapters, recovery rules, and caches that tolerate unknown versions because those are active interfaces rather than evidence of a retired native writer. Sparse publication, job, and failure fields in knowledge/index_metadata.py remain a current writer contract: the writer still omits optional values and the reader accepts those sparse in-progress and failed records. Dependency-owned schemas remain attributed to their dependency, and removed readers remain documented as removed rather than recreated only to obtain conversion coverage. The coverage delivered here is limited to Python owners, including the SSO route; inventoried SQL migrations, browser cleanup, and infrastructure setup below remain outside this implementation and carry no new annotation or test claim.

The explicit response attempt schema replaces ownership inference used by the last verified native writer, v2026.9.137. SQLite holds its startup writer transaction and PostgreSQL its schema advisory lock while the migration runs. Literal released SQL and JSON in response attempt migration tests cover both backends, rollback, repeated opens, inline result precedence, ordinary completed turns, and retained delivery debt. The migration assumes no active responses; current callers pass typed ownership independently of terminal recovery snapshots.

Journal, delivery, approvals, and sync

Journal IDs use J to avoid colliding with credential IDs.

Agent state, history, memory, and knowledge

Configuration and credentials

OAuth, Matrix state, and tools

Dependencies, SaaS, and deployment

These rows are checked manually because the original inventory used section headings rather than IDs.

Upgrade and reset limits

An incompatible format is different from a locked database, permission failure, missing key, full disk, or current-schema corruption. Migration owners reject those failures rather than converting them into deletion. The OAuth credential and sync-continuity stores reject unsupported versions; other owners retain their existing version policies. Several sparse readers deliberately ignore unknown fields or drop malformed reconstructible records.

Additional small compatibility branches stay with current readers. execution_preparation.py classifies structured stream status first and uses the old [cancelled] and [error] body suffixes (each preceded by one space) owned by legacy_streaming.py only through the streaming reader fallback. Interrupted visible replies are excluded; eligible in-progress text is cleaned before it is included in model context. external_triggers/replay_store.py supplies an empty threads map for replay stores written before thread keys existed.

A journal replacement must coordinate its generation binding with the next Nio baseline. Agno sessions may still contain current handled-turn recovery facts and historical run blobs, while Matrix keeps visible messages and state independently of local storage. Private storage moves require stopped primaries and absent managed workers, as described in Private Storage Migration. Usage discovery ignores verified historical primary and session aliases because their canonical directories are scanned separately; unverified symlinks still report incomplete coverage. The Nio cutoff abandons pre-durable pending transport work while preserving crypto material, as described in Nio 1.0 Upgrade. Dependency migrations use their dependency's schema and locking contract, and SaaS databases are never treated as reconstructible caches.