db_maplisted

# db_map — use the supported control-plane surfaces Subfloor control-plane state is already wired to the launched shell. Read and write it through `sc mem`; the service resolves shell identity and enforces ownership, caps, immutability, and durable transactions. `sc mem which` confirms the active identity and API reachability. The repository catalogue is separate: inspect its `dr_*` objects with `sc map-schema` and query them with `sc map-sql`. Product runtime data is also separate and follows the fork application's code, migrations, dev-kit commands, and app database connection. ## Read surfaces ```text sc mem get state sc mem get seed sc mem get lns sc mem get decisions [<id>] sc mem get flags [<id>] [--feature <id>] [--resolved] sc mem get narrative sc mem get messages sc mem get roadmap sc mem get projects sc mem get documents [--feature <id> | --doc <id>] sc mem get tasks [--feature <id> | --doc <id>] sc mem get shells ``` Identity surfaces (`state`, `seed`, `lns`, narrative, and messages) resolve as the calling shell. Decisions are fleet-visible and tagged by author. Planning, document, task, project, and shell reads are shared coordination surfaces. Use `--json` only when a supported command consumer needs structured output. ## Write surfaces Each successful command confirms a durable API write: ```text sc mem state "…" sc mem seed "…" sc mem lns "…" --new sc mem lns "…" --supersedes <ids> sc mem retire <entry_id> sc mem decision "…" --rationale "…" [--parent <