Skip to content

I1505 — A mutating capability leaves a durable event, and the ledger can be read back

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.

BLOCKED wave 1 · p1 · implementation profile · runs alone

Part of development-runtime — The runtime has a development surface.

Blocked. This issue cannot start until I1504 is done. The status is derived from that, not declared.

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.

Current state

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.

Desired state

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.

Scope

  • apps/majordomus-cli/src/capability/builtin
  • apps/majordomus-cli/src/execution
  • share/events.yaml
  • lib/plan.sh
  • test/cases

Out of scope

  • 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.

Dependencies

What waits on this

Acceptance criteria

  • 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 validate
  • bash test/run.sh

Evidence required

  • mutation_leaves_an_event
  • ledger_is_readable

Evidence

None recorded. Every token above needs a command or an artifact behind it before this issue can be completed; narrative is refused.

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.

Timeline

started
—
verified
—
completed
—

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/I1505.yaml. Read it back with majordomus plan show I1505.

Searches the titles and descriptions of every page this site publishes.