Work Orders

A Work Order is how Chiron turns intent into something an agent can execute. It carries the reasoning, the behavior, and the acceptance criteria — not a one-line ticket that leaves the real decision unmade.

The design stance is *intent first, execute second*. Work is derived from the Work Order, not the other way around. This is what lets an agent (or a person) pick up a task without a meeting first: the "why" travels with the "what."

Anatomy of a Work Order

{
  "title": "Rotate session tokens on privilege change",
  "problem": "A token stays valid after a role downgrade.",
  "intent": "Invalidate and reissue the session when a member's role changes.",
  "context": "Session validation lives in verifySupabaseJwt; roles in workspace_members.",
  "requirements": ["Reissue on role change", "Old token rejected within 60s"],
  "acceptance_criteria": ["A downgraded member is denied within one minute"],
  "target_repositories": ["auth-backend"],
  "blocked_by": [],
  "assigned_to": "agent_7fa2",
  "status": "ready"
}

A Work Order also carries a context package — the repositories, a conversation summary, relevant memory, and ontology refs retrieval attached to it. That package is why an assigned agent starts already knowing where the relevant code is.

It asks instead of guessing

When the brief is ambiguous, Chiron does not invent a decision. It proposes the answer it would pick, marks it a suggestion, and stops. A person decides, and every resolved question lands back in the Work Order as acceptance criteria — and then into the graph.

Lifecycle

ready  ->  in_development       (when "sent to execution")

A ready Work Order has been approved in Plan. Sending it to execution flips it to in_development and places it in the Backlog column of the board. From there it is picked up like any other work.

Next: Epics & tasks.