Messages & the ACTIONS contract

The message log is the org’s append-only event source. Every cross-department action is a Message in ~/.restart-org/messages.jsonl.

Message shape

type Message = {
  id: string;                  // UUID
  ts: number;                  // ms epoch
  from: string;                // dept slug or 'user'
  to: string[];                // dept slug list (single, multi, or all-broadcast)
  kind: string;                // see [charter](/org/charter) for the 17 kinds
  subject: string;
  body: string;                // markdown
  refId?: string;              // points at another message id (response chain)
  projectId: string;           // required. Defaults to platform or org-ops if not set
  directiveId?: string;        // when work is tied to a directive
  status: 'pending' | 'acknowledged' | 'actioned' | 'archived';
  metadata?: Record<string, unknown>;
};

Status lifecycle

• pending — created, unseen
• acknowledged — director’s orchestrator has seen it
• actioned — director has emitted a response (or completed handling)
• archived — explicit admin or 30-day age sweep via POST /admin/archive-acknowledged

Workers in the autonomous loop transition status via the mark_message_status action op.

Materialized views

When a message is appended, the central messages.jsonl is rebuilt and per-department views are written:

• ~/org-{dept}/.harness/inbox-view.jsonl — messages where to includes the dept
• ~/org-{dept}/.harness/outbox-view.jsonl — messages where from is the dept

Department directors read these local files; they don’t query the central log directly. This makes director prompts cheap and self-contained.

The ACTIONS contract

Workers in autonomous loops don’t have network access — they emit a structured JSON block that the backend executes:

[
  {
    "op": "send_message",
    "from": "management",
    "to": ["technology"],
    "kind": "BuildRequest",
    "subject": "...",
    "body": "...",
    "projectId": "...",
    "directiveId": "..."
  },
  { "op": "mark_message_status", "messageId": "<inbox-msg>", "status": "actioned" }
]

Supported ops:

Op	Purpose
send_message	POST a new message (charter-validated; rejects illegal kinds)
mark_message_status	Transition status of an existing message
spinup_project	CEO mode only: create a project + auto-fire kickoff/priority/budget
add_directive_summary	Append a CEO or user summary to a directive

Workers learn this contract from prompts/department/worker.md. CEO mode workers learn the spinup-aware variant from prompts/department/departments/business/ceo.md.

Universal search

Every message is indexed by:

• GET /api/org/messages?q= — full-text on subject/body/kind/from/to within messages
• GET /api/org/search?q= — universal across messages, directives, projects

The /papercup/search?q=... page is deep-linkable.

Comments (separate from refId chains)

Messages support inline comments via ~/.restart-org/message-comments.jsonl. Comments are operator notes on a message, distinct from the response chain (which uses refId). Endpoints: GET/POST /api/org/messages/:id/comments. UI: bottom of /messages/:id.

API

GET   /api/org/messages?from=&to=&projectId=&kind=&status=&q=
POST  /api/org/messages                          # charter-validated send
GET   /api/org/messages/:id                      # with referenced + responses
PATCH /api/org/messages/:id/status
POST  /api/org/messages/bulk-status              # update many in one request
GET   /api/org/messages/:id/comments
POST  /api/org/messages/:id/comments

UI

• /papercup/timeline — chronological feed across all departments, kind-color-coded, filterable
• /messages/:id — dedicated detail with response/reference threading + comments section