ticket-analysis

Use when starting work on a ticket, before any implementation, or when unsure whether a ticket is ready to implement at all. Turns the business request into an architectural one: a table with a row per acceptance criterion carrying the owning context and layer, the principle that governs it, the guide implementation must load, and the files — then a walk of the compliance checklist listing what the change puts at risk, so a deviation is decided and recorded here rather than discovered mid-diff. Takes the analysis document as its argument and revises it in place run after run, amending rows and striking answered questions rather than regenerating an essay. Reads the ticket against the architecture rather than against the existing code, runs a read-only exploratory round, then reports the four gate conditions with their evidence and leaves the decision to proceed to the person — recording anything they proceed without as an accepted risk. Refuses to start if the standards are not readable in the session.