Track time in a memory ledger and name the session in every claim #28

Merged
geusebio merged 1 commit from docs/claim-line-and-memory-time-ledger into main 2026-08-18 10:45:11 +00:00
Owner

Two changes to the working agreement, both aimed at a tracker several worktree sessions write
to at once.

Time comes off a memory ledger, not Forgejo's stopwatch

One stopwatch per user, instance-wide, meant a second session's start silently stopped and
logged
the first — dumping its elapsed time, in full, onto whatever index that session had
walked away from. tea api /user/stopwatches reports only your own timers, so nothing could
see the collision coming or detect it afterwards.

Time is kept instead in time-ledger.md in the project's memory directory:

A row per stretch of work opened before the first read or edit of the index
Closed when you stop working that index including going into a CI wait — that is not working time
Summed at release tea times add <idx> <n>m, once, then the rows are stamped logged
Shared per project, not per checkout a session that dies mid-work leaves an open row another session can close and log

A claim names the host and session holding it

The ⏳in-progress label says someone is on it; the new claim comment says who:

⏳ claim host=MatthewcBookNeo session=c1953e1f-84db-48cc-85c2-997b43e05f7d pid=75701 since=2026-08-18T10:41Z

A claim naming this host is checkable — the session transcript's mtime says whether it is
still doing anything, ps says whether the process exists at all — so a claim whose session is
provably gone is taken immediately rather than waiting out a clock. The 24h stale rule stays
for claims from hosts you cannot inspect, and for claim lines that couldn't name a session.

Claims are read through the comments API, never tea comments list: that listing truncates a
body at ~80 characters in every output format including -o json, which eats pid= and
since= off the end of a claim line.

Skills

/issue-triage, /resolve-pr-conflicts, /ask-me-questions and /triage-loop drop their
scratchpad-timer overrides and defer to the convention, which now says what they were working
around. /resolve-pr-conflicts keeps its orchestrator-claims/worker-times split, and gains the
note that a dispatched Agent inherits the parent's session id and pid — so a fan-out writes
one identity, and one liveness check answers for all of its workers.

Verification

Round-tripped against the live tracker on Grey.ooo/Someones.Computer#861: claim line posted,
read back whole through /issues/861/comments, observed truncating at pid… through
tea comments list -o json exactly as documented, deleted by id, and confirmed gone. The
liveness check was run against this session's own transcript and pid. markdownlint clean
(the two findings in VCS.md are pre-existing, at lines 149 and 177, outside this diff).

Docs-only, so no draft — the whole gate that applies is the Markdown lint, and it was run.

Two changes to the working agreement, both aimed at a tracker several worktree sessions write to at once. ## Time comes off a memory ledger, not Forgejo's stopwatch One stopwatch per user, instance-wide, meant a second session's start silently **stopped and logged** the first — dumping its elapsed time, in full, onto whatever index that session had walked away from. `tea api /user/stopwatches` reports only your own timers, so nothing could see the collision coming or detect it afterwards. Time is kept instead in `time-ledger.md` in the project's memory directory: | | | |---|---| | A row per stretch of work | opened before the first read or edit of the index | | Closed when you stop working *that* index | including going into a CI wait — that is not working time | | Summed at release | `tea times add <idx> <n>m`, once, then the rows are stamped `logged` | | Shared per project, not per checkout | a session that dies mid-work leaves an open row another session can close and log | ## A claim names the host and session holding it The `⏳in-progress` label says someone is on it; the new claim comment says *who*: ```text ⏳ claim host=MatthewcBookNeo session=c1953e1f-84db-48cc-85c2-997b43e05f7d pid=75701 since=2026-08-18T10:41Z ``` A claim naming **this** host is checkable — the session transcript's mtime says whether it is still doing anything, `ps` says whether the process exists at all — so a claim whose session is provably gone is taken **immediately** rather than waiting out a clock. The 24h stale rule stays for claims from hosts you cannot inspect, and for claim lines that couldn't name a session. Claims are read through the comments API, never `tea comments list`: that listing truncates a body at ~80 characters **in every output format including `-o json`**, which eats `pid=` and `since=` off the end of a claim line. ## Skills `/issue-triage`, `/resolve-pr-conflicts`, `/ask-me-questions` and `/triage-loop` drop their scratchpad-timer overrides and defer to the convention, which now says what they were working around. `/resolve-pr-conflicts` keeps its orchestrator-claims/worker-times split, and gains the note that a dispatched `Agent` inherits the parent's session id and pid — so a fan-out writes one identity, and one liveness check answers for all of its workers. ## Verification Round-tripped against the live tracker on `Grey.ooo/Someones.Computer#861`: claim line posted, read back whole through `/issues/861/comments`, observed truncating at `pid…` through `tea comments list -o json` exactly as documented, deleted by id, and confirmed gone. The liveness check was run against this session's own transcript and pid. `markdownlint` clean (the two findings in `VCS.md` are pre-existing, at lines 149 and 177, outside this diff). Docs-only, so no draft — the whole gate that applies is the Markdown lint, and it was run.
Two changes to the working agreement, both aimed at a tracker several worktree
sessions write to at once.

Forgejo's stopwatch is no longer used. One stopwatch per user instance-wide
meant a second session's start silently stopped and logged the first, dumping
its elapsed time onto whatever index that session had walked away from — and
`tea api /user/stopwatches` reports only your own timers, so nothing could see
the collision coming or detect it afterwards. Time is kept instead in
`time-ledger.md` in the project's memory directory: a row per stretch of work,
opened before the first edit, closed when you stop (a CI wait is not working
time), summed at release and written once with `tea times add`. The ledger is
shared per project rather than per checkout, so a session that dies mid-work
leaves an open row another session can close and log rather than losing it.

A claim is now the `in-progress` label *and* a comment naming the host,
session and pid that hold it. A claim naming this host is checkable: the
session transcript's mtime says whether it is still doing anything, `ps` says
whether the process is there at all, and a claim whose session is provably gone
is taken immediately instead of waiting out 24h. The 24h rule stays for claims
from hosts you cannot inspect. Claims are read through the comments API, never
`tea comments list` — that listing truncates a body at ~80 characters in every
output format including `-o json`, which eats `pid=` and `since=` off the end
of a claim line.

The skills that claim and time indexes (`/issue-triage`, `/resolve-pr-conflicts`,
`/ask-me-questions`, `/triage-loop`) drop their scratchpad-timer overrides and
defer to the convention, which now says what they were working around.

Verified against the live tracker: claim line posted to #861, read back whole
through the API, truncated exactly as documented through `tea comments list`,
deleted, and confirmed gone.
Sign in to join this conversation.
No reviewers
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
Grey.ooo/agent-standards!28
No description provided.