a-session-proceeds-through-the-mesh — A session proceeds through the mesh: it finds the work, claims it once, runs it watched and stops when the intent is met

○PLANNED 0 of 10 issues done

ready

5

blocked

5

active

0

verify

0

done

0

cancelled

0

Problem

Realising an intent is still a sequence a person runs: /proceed names work but nothing claims it, starts it exactly once, fans it out, reports it or schedules the next step; a stuck or dead loop is found by a person; heavy work starves on one lock; idle servers and deleting pushes cost the machine minutes. The pieces exist as unpushed stacks (I2972-I2976, I3040, ADR 0177) and as Mission Control findings B1 to B6, and none of them is one path.

Outcome

A session asks /proceed what to do, receives one idempotent work order derived from intent_realization and the claim-aware plan, takes it under a mesh claim held by the run, starts it once, reports it and schedules its own next step until the intent is met; /watchdog wakes, hands over and reaps a stalled loop from deadlines; heavy work shares the machine through one slot.

Current state

Planned only. Records I4000 to I4009 and cases 4000 to 4009 exist as plan; no code is written by this milestone's planning pull request.

Desired state

Every satisfaction criterion of the intent is proved by its case; no new store, scheduler, journal kind or registry exists; every projection is generated.

Scope

• apps/majordomus-cli/src
• share/skills
• share/schemas
• docs
• .githooks
• test/cases
• .ai/repo/project

Out of scope

• Push assignment of work to peers before I3198
• Changing a profile automatically from inferred routing
• Editing a person's .claude/settings.json or personal commands

Acceptance criteria

• a fresh session in a supervised repository is told by /proceed which admissible work to take, derived from intent_realization and the claim-aware plan.next, with no question asked of a person
• two sessions asking for work at once never receive the same item: the item's mesh claim is taken in the handler before any worker starts, an overlap is refused with a reason, and the claim is released when the run ends
• a proceeding loop that stopped is detected from deadlines and events, woken, its handover published and resumed by another session, and reaped only by its owner or a seat after assess-before-deleting
• a stuck or silent session is signalled by a phase deadline and a liveness event, never by polling, and the signal names the claim, the holder and the overdue phase
• heavy work (pre-push, coverage, builds) takes one of N machine-wide slots with the disk floor read from rule data; a full queue answers a bounded wait naming its holders, and an idle serve and a deleting push cost the machine nothing
• a /proceed step on an intent whose realisation is met answers that it is done and schedules no next step
• an implement request runs once: a repeated executions.start with the same idempotency key answers the same execution id and a double click never starts two executions (Mission Control)

Validation

• majordomus plan validate
• majordomus intent validate
• majordomus generate --check

Risks

• The liveness substrate I3990-I3994 and the fencing epoch I3174 are other sessions' work; I4004 and I4009 name them and write none of them.
• The /proceed stack I2972-I2976 and I3040 is unpushed or unmerged; I4005 must build on it, and waits for it to land if it has not.

Issues

Each one is an execution contract with its own acceptance criteria, validation command and required evidence. The wave column is the layer of the dependency graph it sits in.

The graph

flowchart LR
    I4000["I4000<br/>A repeated executions.start with the same key answers one execution"]:::ready
    I4001["I4001<br/>The execution state machine has Authorizing, Claimed, Verifying, Refused and UnknownOutcome"]:::blocked
    I4002["I4002<br/>Worktree.create is a typed writing capability"]:::ready
    I4003["I4003<br/>Devtask.implement runs readiness, preflight, claim, worktree and one execution"]:::blocked
    I4004["I4004<br/>The executor takes the issue's mesh claim in the handler and releases it when the run ends"]:::blocked
    I4005["I4005<br/>Proceed.step answers one idempotent work order"]:::blocked
    I4006["I4006<br/>Machine.slot is a counting machine-wide slot for heavy work"]:::ready
    I4007["I4007<br/>An idle serve exits by itself after a bound"]:::ready
    I4008["I4008<br/>A push that only deletes refs runs no plan in the pre-push hook"]:::ready
    I4009["I4009<br/>/watchdog reads liveness and runs wake, handover, reap"]:::blocked
    I4000 --> I4001
    I4000 --> I4003
    I4000 --> I4004
    I4001 --> I4003
    I4002 --> I4003
    I4003 --> I4005
    I4004 --> I4003
    I4005 --> I4009
    classDef done stroke:#16a34a,fill:#dcfce7,color:#14532d,stroke-width:2px
    classDef active stroke:#2563eb,fill:#eff6ff,color:#1e3a8a,stroke-width:2px
    classDef verify stroke:#7c3aed,fill:#f5f3ff,color:#4c1d95,stroke-width:2px
    classDef ready stroke:#0891b2,fill:#ecfeff,color:#164e63,stroke-width:2px
    classDef planned stroke:#0891b2,fill:#ecfeff,color:#164e63,stroke-width:2px
    classDef blocked stroke:#b45309,fill:#fffbeb,color:#78350f,stroke-width:2px
    classDef cancelled stroke:#6b7280,fill:#f9fafb,color:#374151,stroke-width:2px
    classDef superseded stroke:#6b7280,fill:#f9fafb,color:#374151,stroke-width:2px

Canonical record: .ai/repo/project/milestones/a-session-proceeds-through-the-mesh.yaml. Read it back with majordomus plan show a-session-proceeds-through-the-mesh.