List the named projects in the central store (~/.continuity/projects). Read-only; writes nothing. Use it when the user names a project you have not seen, or to check whether central mode holds any state at all. Inside a repo that has .continuity/ this is usually irrelevant — that state is found from the working directory.

Create or initialize a named project in the central store. Creates a directory and an initial git commit. Safe to call on a name that already exists: existing claims are left untouched, so it is effectively idempotent. For central mode only — hosts with no project directory. Inside a git repo, state belongs in the repo instead, which the continuity init CLI sets up.

Return the current project state as a deterministic projection: mission, milestone, next step, frozen constraints, active decisions each annotated with the reason it replaced its predecessor, rejected alternatives, parked conflicts, and open questions. Read-only; writes nothing. Call this FIRST when starting work on an ongoing project and honour it — frozen items and rejected alternatives are authoritative, not suggestions. No model runs in this path, so the same state always yields the same text. Output is budgeted to roughly 16KB and states explicitly when it had to trim.

Append a decision the user has settled. Writes one markdown file plus a git commit; nothing is overwritten or removed, so a mistaken entry is corrected by superseding it rather than by editing. The decision then appears in every future resume context. Capture autonomously as you observe it — no permission needed — but only for things a future session could not re-derive; skip restatements and progress narration.

Set or replace the project's mission — the single line rendered at the top of every resume context, which is what a fresh session reads first. Creates it if none exists. Replacing an existing mission REQUIRES a reason, and supersedes rather than overwrites: the previous mission is archived as a claim with the reason, because a strategic pivot is exactly what someone asks 'why did this change?' about later. Setting the identical text is a no-op. Use this rather than capture with type mission; use create_project instead only when the project does not exist yet.

Append a constraint that future work must respect. Same persistence as record_decision: one file, one commit, append-only. A constraint is a boundary rather than a choice — 'ids stay short and typeable' rather than 'we chose X'. Use freeze_claim only if the user wants it to become unchangeable.

Append an alternative that was considered and rejected, together with the reason. It is then listed under 'Do NOT revisit' in every future resume context, which is the point: it stops the same idea being re-proposed months later. Append-only, like the other record_* tools.

Append an open question, risk, milestone or next action. These are recorded with status 'open', so they keep surfacing in the resume context until closed with resolve_claim. Only one milestone and one next_action show at a time — recording a new next_action does not retire the old one, so supersede it via capture when direction changes.

Apply a BATCH of claim operations in one call, through the reconciler. Prefer this over several record_* calls when a turn produced more than one thing. The reconciler enforces what you should not be trusted to enforce yourself: a near-identical claim is skipped rather than duplicated, superseding archives the old claim with the reason instead of deleting it, and anything that would contradict a FROZEN claim is parked as needs_review for a human rather than applied. Append-only: nothing is removed, so the worst case is a claim you later supersede. Call resume_context first so you know existing ids and which claims are frozen.

Mark a claim frozen: an invariant that must never change. This is the one deliberate lock in the model, so call it ONLY when the user explicitly asks for something to be locked — never on your own initiative. Once frozen, autonomous capture can no longer supersede it: a contradicting claim is parked for human review instead. Overriding it later requires resolve_claim with unfreeze, which is also an explicit human decision. Idempotent: freezing an already-frozen claim changes nothing.

Close a claim, recording WHY. Two uses. (1) A claim parked as needs_review by the reconciler: action 'accept' makes it win, superseding whatever it conflicted with, or 'reject' turns it into a guardrail so it is never re-proposed. (2) An open risk, question or next_action that has been dealt with: action 'close' moves it to resolved, or done for a next_action or milestone. The reason is mandatory — a claim that simply vanishes from the resume context teaches a future session nothing. Nothing is deleted; closing archives. Accepting a claim parked against a FROZEN one additionally requires unfreeze, because breaking a frozen invariant is the user's decision: ask them first.

Explain a claim's history. Read-only; writes nothing. Returns the claim's current title and status, then one line per predecessor it replaced with the reason recorded at the time, then its closing reason if it has been resolved. A claim that replaced nothing says so explicitly ('supersedes nothing — original decision') rather than returning an empty result, so a blank answer always means the lookup failed, never that the history is empty. Accepts a claim id or a unique substring of its title; an ambiguous substring returns the candidate ids instead of guessing, and no match says so. Call it before re-opening anything that looks settled — the answer is often that it was already decided, reversed once, and why, which is the difference between a considered change and re-litigating a closed question.