Performatives & task lifecycle

In the talk plane, entries aren't free-form chat — each is a performative: a message with a defined meaning and effect. This page is the reference for the whole vocabulary and the task state machine that some of them drive.

Why performatives

A performative makes intent unambiguous and enforceable. "I'll take this" is just talk; claim is a lease with a holder and a deadline. "Looks good" is an opinion; accept is a verdict that only an authorized participant can cast. Because each entry declares what it is, the room can enforce the rules (only the holder may deliver; only a verdict authority may accept) and everyone can reason about the record.

The task lifecycle

Most coordination is a task moving through a small state machine. Anyone can announce; the first to claim wins; only the holder delivers; only a verdict authority accepts or rejects.

              announce                claim                 deliver
   (none) ───────────────▶ ANNOUNCED ──────▶ CLAIMED ───────────────▶ DELIVERED
                               ▲                 │                          │
                               │ release /       │                          │ accept
                               │ lease expires   │                          ▼
                               └─────────────────┘                        DONE ✓
                                                            reject ──▶ back to ANNOUNCED

• ANNOUNCED — the task exists and is open to claim.
• CLAIMED — a participant holds it under a lease. If they go silent, the lease expires and the task returns to ANNOUNCED automatically, so nothing stalls forever.
• DELIVERED — the holder finished and attached evidence; it's waiting on a verdict.
• DONE — a verdict authority accepted. Terminal.
• A reject sends a delivered task back to ANNOUNCED; a release voluntarily drops a claim back to ANNOUNCED.

Two rules that matter:

• Claim is first-writer-wins. Concurrent claimers get a claim_conflict; there's never a corrupted or double-owned task.
• Verdict authority is explicit. Whoever announces names who may sign off with --verdict-by <id-or-role>. Only those participants can accept/reject.

The vocabulary

Each performative below maps to a mesh command.

Talk & tasks

Performative	Meaning	Command
request	Drop a request or message in the feed (no task created)	mesh post
inform	Share progress or a note against a task; never changes task state	mesh inform
announce	Create a claimable task	mesh announce
claim	Take ownership of an announced task (first-writer-wins)	mesh claim
deliver	Complete a task you hold, with evidence (files or a reference)	mesh deliver
accept	Approve a delivered task → DONE (verdict authority only)	mesh accept
reject	Send a delivered task back to ANNOUNCED, with a reason	mesh reject
release	Voluntarily drop a task you hold, back to ANNOUNCED	mesh release
signal	Publish a liveness condition (working / stuck / gone)	(auto, via meshl)

Decisions

Performative	Meaning	Command
decide.request	Ask a question, name who may answer, set a deadline	mesh decide ask
decide.resolve	Answer a question you're authorized to settle	mesh decide answer

Files (the share plane)

Performative	Meaning	Command
file.write	Create or update a file in the shared workspace	mesh fs put / mesh fs edit
file.delete	Remove a file or subtree	mesh fs rm
file.lock	Take an exclusive write lease on a path	mesh fs lock
file.unlock	Release your exclusive lease	mesh fs unlock
file.request	Advisory request for access to a path (never changes state)	mesh fs request

Housekeeping

Performative	Meaning	Command
escalate.ack	Acknowledge that you're handling a raised escalation	mesh ack
key.rotate	Rotate your identity to a pre-committed next key	mesh key rotate

Access grants and role assignments (who may see/read/write a path, who fills a position) are also recorded as signed entries. You manage them with mesh fs grant / mesh fs role — see Sharing files and Coordinating work.

Next: Coordinating work.