Memory, tasks, and work receipts

Memory

Use note for durable facts, constraints, hypotheses, and open topics. Use decision only for an explicitly accepted decision and include its rationale.

Tasks

A task is a bounded piece of requested work. Its status and handoff fields are the current operational state. Updates use an integer version for optimistic concurrency control.

Work receipts

A receipt answers: which harness/session worked, what it completed, which Git state it used, what tests ran, and what should happen next. It is evidence from one execution, not a substitute for the task description.

Classification rule

Keep these categories separate:

• Open Topic: unresolved discussion or alternatives;
• Proposal: suggested solution not yet accepted;
• Decision: explicitly accepted direction;
• Task: work requested within a defined scope.

Index vs detail

Per ADR-0002, every memory and task carries two levels of text, not one:

• summary (required on memory_add/task_create, 1–280 characters) and tags (optional, up to 5, lowercase letters/digits/hyphens) — what a startup snapshot shows. Write summary yourself; it is never generated automatically, and it is not a truncation of the body — say what happened and why it matters, in one sentence.
• The full body/description/handoff_* text — unchanged, complete, fetched by id.

continuity_context, memory_search, and task_list return only the first level (id/title/summary/tags/structural fields). memory_get and task_get return the second, unabridged. This keeps a fresh session's startup read bounded regardless of how large individual entries grow — follow the id to memory_get/task_get for anything the summary doesn't answer.