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

I1503

A closed session is not closed a second time under the same identity

Where it stands

devtask.issue

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

Moves

plan.transition

What it is

Objective: Stop the session closer from writing a second record for a session that already has one, so that a session identity names one record and the index does not exclude every claimant of it.
Why: The identity collision it produces is not a cosmetic finding: the repository reported its state as `degraded`, and because every claimant of a contested identity is excluded, the session was absent from the registry whose whole purpose is to hold it. A record nobody can read is not a record. The data half of this was repaired — four files claimed majordomus://session/s-20260909152316-024f, three of them written the following morning thirteen and fifteen seconds apart by a closer re-closing a session closed the evening before, and each a strict superset of the committed one — but repairing data does not repair the writer, and the writer will produce the next collision.
Now: Fixed as data on this milestone's own branch: one record kept, the complete one, proved a superset by comparing commit sets rather than assuming it. The writer is unchanged. Nothing refuses a second closure of an already-closed session, and nothing in the commit path notices that two tracked records claim one identity — the collision was found by reading the server's diagnostics, not by a gate.
Wanted: Closing a session that is already closed is a no-op or a refusal, not a second record. A tracked tree in which two objects of any kind claim one identity fails a check before it is committed, rather than degrading the index of whoever reads it next.
Done when: unknown: the record declares no `completion`
Risk: Low. The failure mode to avoid is a closer that refuses a legitimate re-close after a crash and leaves a session open forever; the refusal must be specific to an identity that already has a complete record.

Acceptance

Closing an already-closed session does not produce a second record under the same identity
A tree carrying two objects that claim one identity is refused by a check, with both paths named
The repository's own diagnostics report no duplicate_identity on a clean tree

Validation: bin/majordomus doctorbash test/run.sh
Evidence required: second_close_is_refusedduplicate_identity_is_gated
Evidence present: second_close_is_refusedduplicate_identity_is_gated

Scope

Touches: lib.ai/repo/sessionstest/cases
Not: Deleting any session record. The repair that preceded this issue kept the complete record and deleted only the partial one it contains.The wider question of when an episode begins and ends, which ADR 0052 owns on a branch of its own.
Depends on: none
Priority: p0
Profile: implementation
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-11
Updated: 2026-10-14T07:58:34Z
Started: 2026-10-14T07:58:26Z
Verified: unknown: the record declares no `verified_at`
Completed: 2026-10-14T07:58:34Z

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.