Skip to content
Cockpit0.29.0
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

I1501

An execution a person starts is an execution the server can see

Where it stands

devtask.issue
Readiness
complete completion is recorded and every required evidence token is present
Status
DONE
Can start
not now
Milestone
Milestone status
ACTIVE
Wave
0
Waiting on
none
Holds back
none
Behind it in all
0
Evidence
2 of 2
A move writes the repository: it stamps one field of this issue's record and appends one event to the ledger, and a commit will carry both.
The same moves from a terminal

majordomus plan start I1501

majordomus plan verify I1501

majordomus plan done I1501

What it is

Objective
Make `majordomus-cli run` reach the server that serves this repository, so that the execution plane a surface shows and the execution plane a person uses are the same plane — or record the decision that they are not, and stop every surface from implying otherwise.
Why
F2 of the audit's failure table, and the one that decides whether an execution history can exist at all. `run` builds a registry in its own process, executes there, streams to its own terminal and exits; the server's execution store is a different store in a different process. Measured rather than read: with a run in flight, the server reported 0 count, 0 active and 0 remembered throughout, and an earlier run that produced a named succeeded execution was never seen by the server either. The consequence is exact — /cockpit/executions can only ever show work started through that server by executions.start, everything a developer actually runs is invisible to it, and docs/EXECUTIONS.md's live channel, which genuinely works and streams frames, is a window onto a plane almost nothing writes to. Combined with non-durability, which the execution module already states as its own decision, the execution history a development surface needs does not exist anywhere today.
Now
Two disjoint planes. The registry declares executions.start, executions.cancel and executions.events; all three operate on the accepting process's own store. `run` is a CLI path that never contacts a server, and nothing in the output of either side says the other exists.
Wanted
A run either registers with the repository's server, so that one execution history exists, or refuses to imply that it did. Whichever is chosen is stated where a reader of the execution surface meets it, not only in a design document.
Done when
unknown: the record declares no `completion`
Risk
Medium. Making `run` depend on a server changes the cost and the failure modes of the most-used command in the executable, and a checkout with no server must keep working. The safe shape is that the server is used when one is already serving this repository and never started for a run.

Acceptance

  • An execution started by the CLI while a server is serving the repository is visible in that server's execution list, or the CLI says plainly that it is not and why
  • The claim is proved by polling the server while a run is in flight, not by reading the source
  • No surface describes an execution history that no writer reaches
Validation
bash test/run.sh 100_execution_planebin/majordomus-cli capabilities validate
Evidence required
run_is_visible_to_the_servermeasured_while_in_flight
Evidence present
run_is_visible_to_the_servermeasured_while_in_flight

Scope

Touches
apps/majordomus-cli/src/executionapps/majordomus-cli/src/capability/builtin/executions.rsapps/majordomus-cli/src/commandsdocs/EXECUTIONS.mdtest/cases
Not
A durable queue, retries or a scheduler. The execution module states it has none by decision; convergence of the two planes does not reopen that.Making the server execute on the caller's behalf when no server is running. A checkout with no server must still be able to run a capability.
Depends on
none
Priority
p0
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-11
Updated
2026-10-14T16:47:12Z
Started
2026-10-14T16:47:04Z
Verified
unknown: the record declares no `verified_at`
Completed
2026-10-14T16:47:12Z

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.