A snapshot: read at commit 707a04c7ce8 on 2026-10-18T00:06:01Z by majordomus 0.29.0. Nothing on this page is read again. See it live

I0802

Specify the session record before writing one

Where it stands

devtask.issue

Readiness: complete completion is recorded and every required evidence token is present
Status: DONE
Can start: not now
Milestone: M003
Milestone status: ACTIVE
Wave: 0
Waiting on: none
Holds back: I0803
Behind it in all: 7
Evidence: 1 of 1

Moves

plan.transition

What it is

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.
Now: 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.
Wanted: 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.
Done when: unknown: the record declares no `completion`
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.

Acceptance

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 present: schema_specified

Scope

Touches: docs/SCHEMAS.mddocs/CONTINUITY.mddocs/CONCEPTS.md
Not: Any implementationThe knowledge layerRetention policy, which its own issue settles
Depends on: none
Priority: p1
Profile: deep-work
Parallel safe: true
Owner: unknown: the record declares no `owner`

The work so far

Branches: none
Merged: none
Commits: 0
Trunk: master
Sessions: none
Created: 2026-09-04
Updated: 2026-09-04T15:46:06Z
Started: unknown: the record declares no `started_at`
Verified: unknown: the record declares no `verified_at`
Completed: 2026-09-04T15:46:06Z

Synchronisation

Adapter: scripts/github-sync
Repository: unknown: the derived plan's header carries no repository
External issue: unknown: a live GitHub state; this executable makes no network call, so only `scripts/github-sync --check` can answer it
State there: unknown: a live GitHub state; this executable makes no network call, so only `scripts/github-sync --check` can answer it

Findings

Nothing is wrong with these records.