I0802 — Specify the session record before writing one
Define the session object in docs/SCHEMAS.md and docs/CONTINUITY.md: what a session is, how it differs from a task and from a handover, the filename grammar of a closed record, the exact field list, which fields are computed from git, and the rule that the reference envelope is derived rather than accumulated.
DONE wave 0 · p1 · deep-work profile · parallel safe
Part of M003 — A session is a durable envelope, and knowledge is compiled from what is already canonical.
Objective
Define the session object in docs/SCHEMAS.md and docs/CONTINUITY.md: what a session is, how it differs from a task and from a handover, the filename grammar of a closed record, the exact field list, which fields are computed from git, and the rule that the reference envelope is derived rather than accumulated.
Why
Every other issue in this milestone writes or reads that file. Specifying it after implementing it is how a schema ends up describing one caller. The distinction that has to survive is the one the whole milestone rests on: a task is a unit of work, a session is an execution episode, and a handover is a deliberate package for whoever continues — three objects that are easy and expensive to conflate.
Current state
docs/CONTINUITY.md names six kinds of durable record and no session among them. docs/SCHEMAS.md documents current.yaml, the checkpoint and handover record shape, decisions.md, open-questions.md and the ledger.
Desired state
The session is the seventh kind, documented beside the others, with its mutable active record and its immutable closed record described separately, its field list given, and the derivation rule stated: the tasks, issues, checkpoints, handovers, decisions and questions of an episode are read out of the ledger between the session's own timestamps, never written into the session file by another command.
Scope
- docs/SCHEMAS.md
- docs/CONTINUITY.md
- docs/CONCEPTS.md
Out of scope
- Any implementation
- The knowledge layer
- Retention policy, which its own issue settles
Dependencies
None. This issue is a root of the graph.
What waits on this
Acceptance criteria
- The three-way distinction between task, session and handover is stated with the case each one gets wrong if conflated
- The closed record's filename grammar is given and shown to be lexicographically chronological, branch-safe and collision-safe
- Every field is listed with its source, and the computed ones are marked as never authored
- The derivation rule is stated, with the alternative it rejects and why
Validation
- bin/majordomus doctor
Evidence required
- schema_specified
Evidence
| covers | type | command | result | at commit |
|---|---|---|---|---|
| schema_specified | manual | bin/majordomus doctor | exit 0. CONCEPTS.md gains session and envelope to the vocabulary and a section naming what each of the three possible collapses loses; SCHEMAS.md documents the open record and the immutable closed record with the full field list, the filename grammar and the four properties it carries, and a table giving the identity used for each reference kind with the two weak ones marked as weak; CONTINUITY.md adds the seventh kind, the envelope-not-narrative rule, the derivation rule with the rejected alternative, and what a session is not | 3c9ba2f |
Risk
A schema written before the implementation can specify something the portable-shell floor cannot express. Each field has to be one that git, the ledger or a single-line YAML scalar can carry.
Timeline
- started
- —
- verified
- —
- completed
- 2026-09-04T15:46:06Z
Those three fields, the evidence above and the state of the dependencies are all the status is made of. There is no status field to disagree with them.
Canonical record: .ai/repo/project/issues/I0802.yaml. Read it back with majordomus plan show I0802.