GuidesPanduan
Run one event cycle with the fleetJalankan satu siklus acara dengan armada
A worked example: the proposals the fleet makes across one event week, the refusal it records, what the human seat decides, and what ends up in the log.Contoh nyata: usulan-usulan yang dibuat armada sepanjang satu minggu acara, penolakan yang dicatatnya, apa yang diputuskan kursi manusia, dan apa yang berakhir di log.
Updated October 2026 · 8 min read · Uses the event-operations pack and the seeded demo community
One event cycle is the easiest unit of work in the whole system to follow: from the first promotion draft to the recap. This guide walks a full cycle on the event-operations pack and the fictional seeded community, and shows three things — what the fleet proposes, what the human seat decides, and what ends up in the log.
What makes the cycle easy to read is that not one class is allowed to run on its own. Every proposal stops as a card. That is not a temporary limitation — it is the default shape of the system you are looking at today.
Seven phases, one sequence
Event phases run in a sequence, and a phase is only entered through its predecessor's verdict:
draft → scheduled → promoting → t-minus-7 → t-minus-1 → running → recap
So when one proposal is decided, the next phase can be entered and the next proposal can be made. If you reject a card, the chain stops there — and that is your choice to make.
What the fleet proposes
The fleet makes one proposal per phase. Each carries an action class, the role proposing it, and the text in both languages:
Step 1: run the cycle
The host runs one cycle and stops. Nothing is delivered, nothing is sent.
Step 2: decide each card
Each card waits for the human seat, and every verdict must carry a reason:
- approve — an authorisation is issued for that exact revision hash.
- edit — the text is replaced, the earlier approval goes stale, and a new revision queues.
- reject — the card is kept with your reason attached as a near-miss record.
Step 3: ask for the hand-off
Once a card is approved, you ask for the hand-off. The transport is asked to deliver, and it refuses — that is its behaviour in version 0. What comes back is the exact text you approved, the exact audience it was meant for, and the refusal code.
A channel draft — a promotion, a recap — comes back the same way, noted as having no individual recipient. You post it yourself.
Step 4: read the log
Every proposal, verdict, refusal, and authorisation is in the append-only log, sequence-numbered. The lines look like this:
#3 card c-2 created — draft.promote by event-ops (event:kopdar-12) #9 card c-2 approved by organiser #10 authorization a-1 issued for draft.promote (revision 7f3c…) #12 commit commit.individual-message by event-ops refused: class_unavailable
The fourth line is the most important one on this page: the refusal is recorded, with its code, just before the error is thrown.
Five proposals, one cycle
| Phase | Action class | What is proposed |
|---|---|---|
| promoting | draft.promoteevent-ops | A promotion draft for the event. |
| t-minus-7 | rsvp.chaseengagement | A chase for the RSVPs that never came back. |
| t-minus-1 | draft.reminderevent-ops | A day-before reminder to the people who did confirm. |
| running | nudge.no_showengagement | A one-to-one nudge to someone who registered but has not arrived. |
| recap | report.assembleevent-ops | The recap. Member names never enter an external report. |
Frequently asked questions
Why does every proposal become a card?
Because every class in the seeded scenario is a draft class. A draft class may write the message, but not act on it. The card is the only way that message can move, and the human seat is the only thing that can decide it.
What is the difference between approve, edit, and reject?
Approve binds the authorisation to that exact revision hash. Edit replaces the text, which makes the earlier approval stale and queues a new revision. Reject keeps the card with your reason attached as a near-miss record. A verdict with no reason is refused.
What happens after I approve?
An authorisation is issued for that exact revision, and the transport is asked to deliver it. In version 0 the transport refuses, and the hand-off comes back with the text, the audience, and the refusal. A channel draft comes back too, marked as having no individual recipient — you post it yourself.
Why did one attempt fail?
The fleet tried to send an individual message from the event-ops role. That action class is not in that role's toolset, so the runtime refused with class_unavailable — absent, not denied. No grant could have brought it back, and the refusal is in the log.
Did anything get sent?
No. Version 0 refuses to deliver. What comes back is a hand-off: the exact approved text, the exact audience, and the transport refusal that stopped it. You send it.
Run it yourselfJalankan sendiri
The hosted console runs the same control plane, on the same seeded community.Konsol terkelola menjalankan control plane yang sama, pada komunitas contoh yang sama.