A card is a branch with a living session — not a commit

One card = one deliverable. Commits are what the card produces along the way (many per card).

1 · What one card IS — four things bound together

Fix login redirect loop
fix/login-bug · 7 turns · needs_you
"Found it — Safari drops the session cookie on 302. Patched, added a test. Ship it?"
=
git branch
fix/login-bug
the deliverable — where commits accumulate
claude session
session_id: 9823bb6b…
the conversation — resumes, never rebuilt
worktree
swarmdeck-worktrees/fix-login-bug/
its own folder — parallel cards can't collide
flight recording
actions.jsonl + video
every steer & reply — the receipts

Select the card anywhere (desktop, phone, glasses) → you continue session 9823bb6b on fix/login-bug exactly where it left off. 1 card : 1 branch : 1 session : 1 recording : many commits.

2 · What a lane move DOES — the drag is the verb

▶

Backlog

request filed
  • a JSON row, nothing more
  • no branch yet
  • no session yet
  • no worktree yet
  • free to queue ideas
drag → Working = dispatch
▶

Working

dispatched
  • branch + worktree created
  • session opens with the task
  • steers --resume the session
  • agent edits, runs, commits
  • all of it recorded
drag → Review = submit
▶

Review

submitted
  • diffstat snapshotted
  • you read timeline first
  • video / diff as evidence
  • steer more if not right
      (back to Working)
drag → Done = accept

Done

accepted
  • deliverable taken
  • branch ready to merge / PR
  • session kept — reopen
      any time, context intact
  • recording archived
= client structure: filed → dispatched → submitted → accepted

3 · Inside one card's life — session vs commits

card dispatched
steer 1 "fix the redirect loop"   → agent works → commit a1f "repro test"
steer 2 "also cover Safari 16"    → same session resumes (remembers everything) → commit b7e "cookie fix" → commit c92 "edge case"
steer 3 "clean up + changelog"    → resumes again → commit d10 "polish"
drag → Review  (diff of a1f..d10 + the full recording = the submission)
drag → Done    branch fix/login-bug: 4 commits, ready to merge
■ steer (you)■ session turn (agent)■ commit (git)■ deliverable
So, not this: a card per commit (too fine — you'd drown), or a card per repo (too coarse — one conversation about everything). A card is the unit you'd naturally review and accept: one branch-sized piece of work with its own memory.

4 · Where HARNESS and LOOP fit

HARNESS — belongs to the REPO

the standing environment every card inherits through its worktree
repo/
├ CLAUDE.md / AGENTS.md   the rules & runbook
├ tools/                  check · evaluate · deploy…
├ hooks + permissions     what's allowed, what's enforced
└ MCP / data context      backends, secrets, memory

every card on this repo gets ALL of it for free
(the session runs inside the worktree = inside the harness)
+

LOOP — belongs to the CARD

two nested state machines, one per card
outer loop = the lanes  (who has the ball)
backlog → working → review → done
            you ⇄ agent         you

inner loop = quality states  (inside Working)
define → build → verify → commit
         agent self-advances; gates block

rule: a card may only move → Review
when its inner loop is green  (gates passed)

So your instinct is right, with one refinement each: the harness is not per-branch — it's the repo's toolbox, rules and data context, and every branch inherits it by running inside a worktree of that repo. The loop is per-card, and it's two loops nested: the lanes are the outer workflow (ownership handoffs between you and the agent), while the harness's own quality loop (define → build → verify → commit) runs inside the Working lane — and the submit-to-Review move is the gate where the inner loop must be green.