Read the relevant section of docs/reference/specification.md before editing.\nState the current contract, the requested change, and any unresolved behavioral\nchoice. If the request intentionally changes a decided behavior, update the\nspecification rather than treating the old text as an implementation obstacle.
Before implementation, present every added, removed, or observably changed\npublic interface as a compact, separate review item. Give its exact signature,\ncommand or endpoint, inputs, defaults, output, errors and compatibility effect\nas applicable, then obtain the user's explicit approval. Do not infer approval\nfor an interface because it appeared inside a long specification or broader\nimplementation plan. A direct user request naming the exact interface change is\nexplicit approval for that change.
\nTrace the complete affected slice before editing:
\nKeep the Client and Server distributions independent; duplicate small boundary\nmodels when necessary instead of creating a shared runtime package. Preserve\nexplicit lifecycle actions and run_id fencing. Define idempotency, concurrent\nstate changes, uncertain transport outcomes, validation errors, and migration\nbehavior instead of relying only on the happy path.
Add focused tests at the lowest useful layer plus at least one real boundary test\nfor each changed public surface. Use independent SQLite connections for race or\ntransaction claims. Verify generated OpenAPI whenever endpoint schemas or errors\nchange.
\nFinish by checking the specification, implementation, tests, and user docs for\nthe old term or behavior. Run targeted tests during development and the relevant\nvalidation matrix from AGENTS.md before handoff.