#560 Treat tickets as requests; design as if from the beginning

[williamthorsen]

What

Agents working from tickets now treat them as requests rather than specifications and explicitly consider whether the proposed change is worth making at all. When proposing designs, agents target the shape the code would have had if the new behavior had been there from the start, treating workarounds, carve-outs, and bolt-ons as anti-patterns to avoid.

The new behavior applies wherever tickets are turned into designs: design-and-plan, assess-ticket, plan, and software-engineering all consume the updated guidance.

Why

Agents (and humans) tend to over-defer to ticket text — implementing proposed behavioral or API changes as written, even when the underlying problem is different, the scope is wrong, or the change isn't worth making at all. Once a change is accepted, the same deference shows up at the design stage: new behavior gets bolted onto existing structure as a workaround or special case rather than integrated as if it had always been there. The result is code that accumulates patches around its wrongness instead of evolving cleanly. The new guidance gives agents an explicit ownership posture and a generative design heuristic to push back on both failure modes.

Details

🎉 Features

• Adds an explicit ownership stance to ticket evaluation: a ticket is treated as a request whose proposed change must be evaluated, not an instruction to implement. Includes a new "Is the change worth making?" synthesis step that keeps the do-nothing option on the table.
• Adds a "Designing as if from the beginning" heuristic to the shared design-priorities rule, naming three anti-patterns it detects — workarounds, carve-outs, and bolt-ons — and acknowledging that reaching the target may require touching code outside the ticket's literal frame.

Closes #560

[github-actions]

Dependency audit

Production dependency audit passed.