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
I1505
A mutating capability leaves a durable event, and the ledger can be read back
Where it stands
devtask.issue- Readiness
- blocked 1 of its dependencies is not DONE
- Status
- BLOCKED
- Can start
- not now
- Milestone
- Milestone status
- ACTIVE
- Wave
1- Waiting on
- Holds back
- Behind it in all
2- Evidence
0of2
| In the way | Subject | Detail |
|---|---|---|
| issue | I1504 | I1504 is not DONE |
Moves
plan.transitionWhat it is
- Objective
- Give a capability of kind command one way to record what it did: append a ledger event whose name share/events.yaml declares, publish the same change to the execution stream, and add a read capability for the ledger so a surface can show history at all.
- Why
- R5 of the audit's root causes: there is no development history anywhere. The durable tier is a local ledger with its own vocabulary, the live tier is per-process and forgets on exit, and a run writes to neither. A development surface that cannot answer what happened yesterday is a dashboard of the current second. The two tiers also disagree by construction — the live channel works and streams frames, and it is a window onto a plane almost nothing writes to — so unifying what a mutation records is a precondition for any later page rather than a nicety.
- Now
- share/events.yaml declares event names. The ledger is written shell-side and has no read capability. Executions are remembered only in the process that accepted them, which the execution module states as its own decision.
- Wanted
- One mutation produces one durable event and one live frame, from one place in the code, and the durable half is readable through the registry like anything else.
- Done when
- unknown: the record declares no `completion`
- Risk
- Medium. Two writers of one history is the defect this issue exists to remove, so an implementation that adds a third record type has made it worse.
Acceptance
- A command capability's mutation appends an event whose name share/events.yaml declares
- The same mutation reaches the execution stream
- The ledger is readable through a capability, on every surface the registry projects
- A restart does not lose the durable half
- Validation
bin/majordomus-cli capabilities validatebash test/run.sh- Evidence required
mutation_leaves_an_eventledger_is_readable- Evidence present
- unknown: the record carries no `evidence` entries
Scope
- Touches
apps/majordomus-cli/src/capability/builtinapps/majordomus-cli/src/executionshare/events.yamllib/plan.shtest/cases- Not
A durable execution queue. Durability of the event record is not durability of the execution, and the second is a stated non-goal.A second vocabulary. The event names are share/events.yaml's, and this issue adds to that file rather than beside it.- Depends on
- Priority
- p1
- 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-09-11
- Started
- unknown: the record declares no `started_at`
- Verified
- unknown: the record declares no `verified_at`
- Completed
- unknown: the record declares no `completed_at`
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.