---
{
  "n": 52,
  "title": "Kanban and agentic organization proposal",
  "abstract": "The functional proposal from Transportklok: kanbans and tickets, one orchestrator per ticket, domains and roles with contracts, a worktree per item",
  "refs": [
    "doc:51",
    "doc:37",
    "doc:40"
  ],
  "seen": [
    "agent",
    "system",
    "user"
  ],
  "data": {
    "environment": "main",
    "revisions": 1,
    "open_until": 1790170040.470573,
    "draft_of": "",
    "files": {
      "Revisievoorstel Journal Kanban en Agentic Organization (1).md": "The original proposal, in Dutch"
    },
    "kept": false
  },
  "created": 1790168205.157471,
  "updated": 1790179044.277917,
  "deleted": 0.0,
  "completed": 0.0,
  "outcome": "",
  "type": "doc"
}
---
Revision proposal dropped in dump 21, written in Dutch after the call in doc 51. Summarised here in English; the original is attached. It is functional only: names, YAML fields and folder layouts in it are proposals, not settled implementation.

## Summary
Work starts on a kanban. Each ticket gets a main agent, a root orchestrator and a worktree of its own, plus an optional hosted copy of the app. The root orchestrator turns the ticket into a plan and hands tasks to domain leads (engineering, marketing and so on). Each domain lead splits the work over the roles under it. Roles, leads and the orchestrator talk only through declared routes and input and output contracts. The user keeps the live chat, comments and steering they have today. The latest section of the proposal (v3) overrides earlier text where they differ.

## Core pieces
- Kanbans: several boards, each with its own name, subject, visibility and freely chosen stages. Automation acts on a stage only once that stage is mapped.
- Tickets: title, wanted result, context, source, priority, relations, history. A ticket is the anchor for its plan and outcome, and can come from the UI, an agent or a connector.
- Intake chat on the board: agent and user shape a ticket together, spot dependencies, and the user confirms before the ticket is created.
- Per-item runtime: ticket, main agent, root orchestrator, worktree and source commit, plan, hosting status and URL, leases and locks, and start, last activity and stop reason.
- Hosted app per item: started from the worktree through the project's Make Workspace tooling behind an adapter (start, check, open, stop, restart). It publishes a URL and stops after a period without activity.
- Browser and debugger capability, given to specific roles only.
- Two planes: the journal holds runtime coordination (status, dependencies, queues, events, comments). The worktree holds proposed repository changes, including rules, facts, docs, tools and agent configuration, until review.
- Agent organization: a folder in the project with domains/<domain>/domain.yaml and roles/<role>/role.yaml plus skills and tools. The MVP has domains and roles only.
- Contracts: every role and every coordination layer has an input and an output contract. Mismatches, rejected handovers and missing fields are recorded, so a later evaluation can propose contract changes. Those changes go through review, never live.

## Cardinality
- Global singular: at most one active instance across all items, with one shared queue. Example: a deploy agent.
- Worktree singular: at most one per ticket worktree, with more work queued. Every domain lead is worktree singular in the MVP.
- Plural: parallel instances, each reporting to the same domain lead.
- The root orchestrator is always singular per ticket. Wider resource locks, such as production, are declared explicitly and never inferred.

## Decided
- Kanban stages are fully free per board, with explicit mappings for automation.
- Plan approval is decided per ticket by the organization orchestrator and shown to the user.
- Orchestration is scoped per ticket: one root orchestrator per ticket, and at most one lead per group within a ticket.
- The root orchestrator talks to domain leads, not to specialists. Roles reach other domains only through their own lead.
- Dependencies between tickets are proposed in chat and become active only when the user confirms. Dependencies inside one ticket's plan are the orchestrator's to set.
- Lasting knowledge made during an item stays in its worktree until its pull request is accepted. Runtime events, proposals and comments may be shared before that.

## Still open
- Final names and YAML form of the three cardinalities, and whether global singular spans the installation or one project.
- Queue priority, fairness and cancellation.
- Which cross-domain routes leads may use directly.
- Who starts contract evaluations and who approves their proposals.
- Default MCP capabilities per agent type.
- Completion and auto-merge conditions for code items.
- Host timeout, keep-alive and restart defaults, and the minimal Make Workspace adapter.
- Whether a singular role's queue is shown and can be reordered in the UI.
- Which events wake a dependent ticket by themselves, and which need a person first.

## Where it meets the journal
The journal already has most of the parts: a kanban of to-dos (the Board page), plans with phases, environments and worktrees per session, sequences, checks, and plugins that hear the bus. The proposal's MVP is nine items (proposal section Actuele MVP-grens). It would add typed tickets on several boards, a runtime per item, domain and role definitions with contracts, and queues with leases. Doc 37 and doc 40 hold the earlier orchestrator and kanban thinking.