Tickets

The v1 workflow

A ticket is always in one of four statuses: backlog, selected_for_dev, in_progress, or done. You don't set the status directly; you use named transitions, so the history stays honest about how work actually moved.

$ flicker ticket select-for-dev 42
# backlog → selected_for_dev
$ flicker ticket start 42
# selected_for_dev → in_progress
$ flicker ticket complete 42
# in_progress → done

Versioned documents

Each ticket carries markdown documents, one per kind. The kinds are a fixed set Flicker defines — one for each stage of the workflow — so the reasoning and evidence live next to the work instead of in a lost thread:

• feature_brief — the problem, who it's for, non-goals, risks
• plan_consensus — the chosen approach and the alternatives rejected
• task_contract — the acceptance criteria: what "done" means for this ticket
• design — UI/product design, when there's a surface to design
• implementation_notes — what changed, commands run, the PR link
• review · regression · test_verdict — evidence from the test stage
• release — the release record

Writes are append-only with a current head per kind, so you always have the latest and the full history. A document can also carry structured fields — a test_verdict of pass or fail, who approved it — that the workflow reads to gate stage transitions (a ticket can't complete without a passing verdict).

$ flicker ticket document write 42 task_contract --body "$(cat plan.md)"
$ flicker ticket document read 42 task_contract --history

Local checkout for agents

Check a project's tickets out as local markdown files so an agent can read and edit them in the working tree, then push changes back. Pushes are guarded against conflicts, so two workers can't silently clobber each other.

$ flicker ticket checkout my-project --out .flicker/tickets
# writes .flicker/tickets/000042-implement-checkout.md
$ flicker ticket push .flicker/tickets/000042-implement-checkout.md

Searchable memory

Memory is a searchable record Flicker maintains for the whole project — a Postgres full-text index over your current tickets, their current documents, and the events that recorded how work moved. It's how a worker finds the current contract and the prior evidence for a task without hunting through history.

Every result is labeled with its source_class — a current ticket, a current document, or an event — so an answer is traceable to where it came from, not a guess. Current truth is a ticket's fields and its latest documents; older versions and events are history, evidence of how the work got here. Agents search the same store with /flicker-recall.

$ flicker memory search "checkout conflict" --json