AkurAI-Build

Latest change 30e6b8c347048d64c2c048dfd05a8ded219d37f6 - Host authenticated Git repositories over Smart HTTP with repo host/sync CLI by Ólafur Búi Ólafsson

# Definition of Workflow

## Work item

A work item is one Markdown card under `columns/` with JSON front matter and an
outcome-focused body. Types are feature, bug, security, performance, docs,
chore, or spike. Priority is P0 (critical), P1 (high), P2 (normal), or P3
(low). A card is the canonical local task artifact; external issues/PRs are
references, not replacements for required local handoff state.

## Start, finish, and SLE

- Commitment point: entry into `In Progress`.
- Finish point: entry into `Done`.
- Provisional SLE: 85% finish within 10 calendar days of commitment.
- Recalculate after 30 completed items from observed cycle-time data.

## Pull policy

Pull the highest-priority, oldest Ready task whose dependencies are Done. Do
not pull when the destination WIP limit is full. Prefer finishing, reviewing,
verifying, or unblocking current work over starting another item.

## Column policies

### Inbox

Entry: a concise title and type are enough. Work: capture source and basic
intent. Exit to Triage: demand is understandable enough to assess. No delivery
commitment exists.

### Triage

Entry: an intake item exists. Work: establish value, urgency, duplicate status,
security/operational impact, likely owner domain, and whether discovery is
needed. Exit to Discovery or Ready: route is explicit. Exit to Done: add
`resolution` evidence and set a non-delivery resolution such as `cancelled`,
`duplicate`, `not-planned`, `superseded`, or `verified-existing`. `delivered`
may enter Done only from Release Ready.

### Discovery

Entry: uncertainty blocks safe execution. Work: inspect code and callers,
resolve requirements, dependencies, constraints, risks, acceptance criteria,
test strategy, non-goals, and approvals. Spikes produce a decision/evidence,
not production code by default. Exit to Ready: another agent can execute the
card without guessing.

### Ready

Entry: completed Objective, Context, Acceptance criteria, Boundaries, and
Verification sections; dependencies are Done. The CLI enforces these fields and
rejects untouched template text. Work: order by priority then
age. Exit to In Progress only by `claim`, with one owner and available WIP.

### In Progress

Entry: owner assigned, unblocked, WIP available. Work: implement only the card's
scope, keep notes/evidence current, and avoid two writers in one worktree. Exit
to Review: requested outcomes are implemented and `implementation` evidence
exists. Return to Discovery when the specification is invalid,
not merely because implementation is hard.

### Review

Entry: implementation evidence exists. Work: independent review for correctness,
security, project rules, acceptance criteria, unnecessary complexity, tests,
and docs. Record `review` evidence. Exit to Verification when findings are
resolved or explicitly accepted. Return to In Progress for actionable fixes.

### Verification

Entry: review gate passed. Work: run deterministic tests/typechecks/builds,
integration or UI checks, and verify current artifacts against acceptance
criteria. Record `verification` evidence. Exit to Release Ready only with that
current stage evidence. Return to Review or
In Progress when evidence fails.

### Release Ready

Entry: accepted review and verification evidence, unblocked, release notes/docs
current, and any PR/branch reference recorded. Work: await explicit approval for
merge, deploy, publish, migration, or other external effects. Exit to Done after
approved delivery or explicit resolution; the CLI requires the owner to assert
`--approval HUMAN` for this transition. This is an auditable trust assertion,
not cryptographic identity verification. New code changes return to an earlier
state and require refreshed evidence.

### Done

Entry: resolution and matching stage evidence exist; `completedAt` is recorded.
Possible resolutions include `delivered`, `verified-existing`, `cancelled`,
`duplicate`, `not-planned`, and `superseded`. Reopen to Triage when new facts
invalidate the resolution, but only after every Ready-or-later dependent is
moved upstream or no longer depends on this task.

## Blocking policy

Blocked is not a column. Use:

```sh
node .kanban/bin/kanban.mjs block KB-ID --reason "specific external dependency"
node .kanban/bin/kanban.mjs unblock KB-ID
```

The owner must record the blocker, required external action, and next review
point in the card or handoff. Blocked work still consumes its current WIP slot.
Escalate ageing work; do not move it to hide the queue.

## Expedite and exceptions

P0 work may jump upstream queues only with `--force --reason`; it still obeys
active-state WIP and quality gates. Forced events are auditable. An exception is
not a permanent alternate workflow—review it in the retrospective.