Continuity contract

HeyAira separates three durable layers:

Record	Use it for	Do not use it for
Memory	decisions, facts, constraints, proposals, open topics	task status or code contents
Task	goal, status, handoff, optimistic version	long conversation or test log replacement
Work receipt	attributable execution evidence and Git checkpoint	unverified claims or a second task description

Memory and Task each carry a required summary (1–280 characters, written by whoever calls memory_add/task_create) and optional tags — see Index vs detail.

Startup projection

continuity_context is a bounded recovery index. It returns project identity, recent active memory and open tasks as title/summary/tags (never the full body/description/handoff_* text — ADR-0002), and recent work-session receipts. work.unattended lists tasks needing interactive follow-up; workflow merge reminders and stalls are not included. Task indexes have no workflow field. task_get.workflow references the highest-revision stored workflow with {id, revision, phase, is_current}, even when retired, or is null if none exists. A versioned task read returns null; use workflow_get for workflow history. The task organization projection continues to reflect a current workflow when one exists.

It is not a conversation transcript and it is not a permission grant.

Identity projection

server_identity returns the configured resource, instance, environment, service revision, and authenticated project. The agent compares those values with its selected connection profile before any mutation.

Repository boundary

Git remains the source of truth for files, branches, commits, and pull requests. HeyAira stores references to Git state, not a repository copy.

Durable handoff

A handoff must state what was completed, what happens next, blockers, and the exact Git checkpoint when code was involved. The next agent should be able to continue using HeyAira and Git alone. Step-by-step procedure for closing a session and resuming in a new one: session-handoff.md.

Current versus historical memory

A correction is not effective merely because a newer note exists. Create a complete replacement, preserving unaffected facts, then use memory_supersede with a reason and an idempotency key. Only an interactive project owner/admin can make this transition. Search and startup exclude replaced entries by default. If a task names an old ID, memory_get returns a replacement notice and current content; follow that content instead of reinstating the old rule. Use include_history=true only for an explicitly historical investigation. Formal decisions and historical task contracts have their own lifecycle.