Sizing a Ticket

Judge ticket as written, not as hoped. Torn between rows → take heavier —
process depth, not admissibility.

Read first: gh issue view <N> --json title,body,comments --jq '.title, .body, (.comments[]|.author.login + ": " + .body)'. ## Agent Brief comment outranks body. Not --json body (body only, brief invisible) nor bare --comments (comments only, nothing at all when none, exit 0 — silent loss).

Fleet member on heavy: write the plan under your own scratch path, <scratch>/impl-<N>/, then carry it out inline, test first.
Heavy is never a reason to give up: a ready-for-agent ticket's ## Agent Brief
already settles the open design choices, so plan from it. Solo session has a user:
settle the open design choices with them before planning.

Bug reports, either row: reproduce with a failing test before fixing.

Report row, path, one-line why. Process depth only — no admissibility call
here, for anyone. Both rows workable, solo and in fleet; heavy means more process,
never blocked ticket.

Tie-break here: torn → take the heavier row. Right for process depth, opposite of
fleet's admissibility tie-break, where torn → surface to maintainer. Two
questions, two biases. Never carry this one across.

Red flags

• "Body is short, so it's simple" → short bodies hide most design ambiguity. Size by unknowns, not word count.
• "A plan is overkill here" → that thought is heavy row.
• "The Agent Brief is thorough, so it's light now" → brief quality never promotes
  a heavy row for process depth. Says nothing about admissibility — thorough
  brief is exactly what makes big ticket safe to run unattended.