api-layer-ensures-atomic-isolated-mutations

IN derived (depth 1)

The API layer enforces mutation safety through four mechanisms: context-managed load/save, per-function transaction scope, write-flag gating to prevent unintended persistence, and dict-only returns that prevent callers from holding live network references.

Summary

Each API function operates in complete isolation — it opens the database, does its work, and closes — with four interlocking safeguards that prevent data corruption: a context manager guarantees changes are loaded and saved as a unit, a write flag declared upfront controls whether any mutations actually persist, and all results are returned as plain dictionaries so no caller can accidentally hold onto or modify live internal state.

Justifications

SL — Each API safety mechanism prevents a different class of state corruption: stale reads, cross-function leaks, accidental writes, and reference escapes

Antecedents (all must be IN):

  • api-uses-with-network-context-manager — `api.py` uses a `_with_network` context manager to ensure load-operate-save atomicity for all network mutations.
  • transaction-per-function — Every API function opens the database, does its work, and closes — no shared state, no connection pooling, no long-lived sessions; each invocation is fully independent.
  • write-false-prevents-persistence — Functions using `_with_network(write=False)` can mutate the in-memory network (as `what_if_retract` does) but changes are never saved to SQLite; write-or-not is declared upfront and never conditional.
  • api-functions-return-dicts — Every public API function returns a `dict` (or `str` for markdown/compact), never a `Network` or `Node` object, ensuring JSON-serializability at the boundary for CLI, HTTP, and tool-call consumers.

Dependents

These beliefs depend on this one:

Details