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

I0806

Make the session rules doctrines, with retention and archiving

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: 4
Waiting on: none
Holds back: I0813
Behind it in all: 3
Evidence: 1 of 1

Moves

plan.transition

What it is

Objective: Finish the session rules: the record and lifecycle rules are declared in share/standard/majordomus/ and dispatched by doctor and watch; what remains is a reference to a record that does not exist, retention over a declared cap, and policy-driven archiving that never deletes and never overwrites.
Why: A rule enforced by an inline check in one command is the declared-but-not-wired failure this tool measures in other people's repositories. Every enforced rule here is declared in the registry and dispatched from it, or it is not enforced.
Now: Measured on master 4090b2b8ae, 2026-10-08. Two session rules are declared in share/standard/majordomus/rules and dispatched by doctor and watch: majordomus.session-records (validator session_records, test/cases/63_session_records.sh) and majordomus.session-lifecycle (validator session_lifecycle, test/cases/54_session_lifecycle_hooks.sh), landed in e9ffa54f1c. Doctor reports an episode left open past session.stranded_after. Not on master: the policy (.ai/repo/policy.yaml since bd7cb2a579) carries retention caps for checkpoints, handovers and the ledger and none for sessions; share/allow/policy.txt lists no session retention key; majordomus.retention-caps does not report sessions; lib/session.sh has no archiving. history --rotate remains the precedent for retention that archives rather than deletes and refuses to overwrite an existing archive.
Wanted: The session rules that exist stay declared and dispatched. The policy carries a session retention cap and whether archiving is enabled, its keys are in the policy allowlist, and majordomus.retention-caps reports sessions alongside checkpoints and handovers. A session naming a checkpoint that does not exist is reported, naming both. Archiving happens only when a command asks for it.
Done when: unknown: the record declares no `completion`
Risk: An open session is normal for most of its life, so the staleness rule has to be advisory. A blocking check on an open session would refuse work during the episode it is meant to describe.

Acceptance

majordomus.session-records and majordomus.session-lifecycle appear in the rule list with a validator that exists, and doctor proves each reaches the command that claims to run it
A malformed closed record fails doctor and drifts watch, and the finding carries a reproduce command
A session naming a checkpoint path that does not exist is reported, naming both
Archiving moves records without deleting them and refuses to overwrite an existing archive
A session left open longer than the policy allows is reported by watch and does not block anything

Validation: bash test/run.sh 63_session_recordsbin/majordomus doctorbin/majordomus watch
Evidence required: session_doctrines_wired
Evidence present: session_doctrines_wired

Scope

Touches: share/standard/majordomus/share/allow/policy.txtshare/skeletonlib/session.shlib/doctor.shlib/watch.sh.ai/repo/policy.yamltest/cases/63_session_records.sh
Not: Any background or automatic maintenanceDeleting a record under any circumstance
Depends on: I0805
Priority: p1
Profile: implementation
Parallel safe: false
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-10-14T19:35:58Z
Started: 2026-10-14T19:34:23Z
Verified: 2026-10-14T19:35:35Z
Completed: 2026-10-14T19:35:58Z

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.