I2734 — A session joins the mesh at its start and leaves it at its end
The provider's start event opens the session on the mesh of the checkout's shared server as <provider>-<provider session>, with client, branch, head and the active task; the briefing names that id; a resume says it again; the end event closes it.
DONE wave 0 · p0 · implementation profile · parallel safe
Objective
The provider's start event opens the session on the mesh of the checkout's shared server as <provider>-<provider session>, with client, branch, head and the active task; the briefing names that id; a resume says it again; the end event closes it.
Why
On 2026-10-15 the owner asked why a new session did not join the mesh, report or start working, neither through direnv nor at session start, and why nothing enforces it. Measured: the start hook only printed the mesh's health (lib/capture.sh mj_capture_mesh_line); the only mesh session a Claude Code session got was its nameless board connection board-pN, with no intent and no claim, until the worker chose to announce. The milestone's first branches (I2285..I2292, 2026-10-10) never reached a pull request.
Current state
The start event prints one health line about the mesh and opens no mesh session; the end event closes none.
Desired state
Every provider session with a session id is on the mesh from its start event under a durable id the provider's payload names again, and off it at its end event, best-effort and never failing the event.
Scope
- lib/capture.sh
- test/cases/3066_a_session_joins_the_mesh_at_start.sh
- .ai/repo/project/issues/I2734.yaml
- .ai/repo/project/milestones/every-session-joins-the-mesh.yaml
Dependencies
None. This issue is a root of the graph.
What waits on this
- I2288DONE A task is on the mesh while it works
- I3303READY Codex's hooks draw its episodes and refuse an edit no claim covers, as Claude Code's do
Acceptance criteria
- A start event with a ready server whose mesh runs opens claude-code-<session id> on the mesh with client, branch and head
- The briefing names the mesh session id under the Mesh line
- A resume after majordomus start carries the active task and its title
- The end event closes the mesh session
- Without a server the start event opens the episode and names no mesh session
Validation
- bin/majordomus plan validate
- bash test/run.sh 3066_a_session_joins_the_mesh_at_start 54_session_lifecycle_hooks 1054_every_session_is_told_the_stream
Evidence required
- case_3066
Evidence
| covers | type | command | result | at commit |
|---|---|---|---|---|
| case_3066 | test | MJ_TEST_JOBS=4 bash test/run.sh 3066_a_session_joins_the_mesh_at_start 54_session_lifecycle_hooks 1054_every_session_is_told_the_stream | ok 3066_a_session_joins_the_mesh_at_start 11s; ok 54_session_lifecycle_hooks 71s; ok 1054_every_session_is_told_the_stream 4s (11-case run: 11 passed, 0 failed, 0 skipped) at 09c334079f5 with the executable of #1304; delivered by e81e054a5b7 via #1235/#1237 (b248f446eca) | 09c3340 |
Timeline
- started
- 2026-10-16T16:38:48Z
- verified
- 2026-10-16T16:38:53Z
- completed
- 2026-10-16T16:39:01Z
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/I2734.yaml. Read it back with majordomus plan show I2734.