write-ticketlisted

# Write Ticket ## Process 1. Determine the ticket type: story, bug, task, or investigation 2. Read the matching example file and follow its panel structure and field rules exactly - don't reuse another type's structure 3. Apply the [shared principles](#shared-principles) below regardless of type 4. Before finishing, check the draft against the type's field rules and the shared principles, and adjust if it drifts ## Shared principles ### Outcome-focused, not implementation - Tickets are guidance and guardrails to achieve an outcome; planning docs handle implementation - Keep in tickets: the desired outcome (what success looks like), architectural decisions that constrain the approach, business rules and edge cases that define correctness, which components/entry points to touch, test scenarios expressed as outcomes - Remove from tickets: anything that is implementation detail and could reasonably change without changing the outcome - method/class internals, return types and parameter types, the exact algorithm or loop used, exact error message copy, CSS class names and other framework-specific code, anything that amounts to "here is exactly how to write this code, or where it goes/is called" - Boundary: needed to deliver the correct outcome, or a decision that's expensive to reverse later → ticket. Needed to write correct code but free to change without affecting the outcome → planning doc - Do not state standard framework/architecture practice - it is impli