Keep implementation details out of tickets

[williamthorsen]

Problem

The ticket-authoring skills — design-and-plan, create-ticket, and align-ticket-with-implementation — can produce tickets that carry implementation mechanism (file paths, framework API and config names, step sequences, deletion lists) that belongs with the implementation, not in the ticket. This is a content-placement problem, distinct from verbosity: a perfectly concise ticket can still leak mechanism, so the concision guidance (#811, #920) does not address it.

The doctrine that should prevent it is localized to design-and-plan and miscalibrated there — it categorically bars "code, paths, syntax," which wrongly excludes the cases where existing code legitimately is the ticket's subject (bug and refactoring tickets) or a key pointer that saves the implementer derivation. Meanwhile the parallel ticket doctrines (concision, the acceptance-criteria scaffold) already live in shared _partials/ consumed by all three skills. Placement is the outlier that stayed local, so create-ticket and align-ticket-with-implementation are unguided — and align-ticket, whose job is aligning a ticket to an existing implementation, is the most exposed.

Proposed solution

Give the placement doctrine the shared home the concision and acceptance-criteria doctrines already have:

• Extract a new shared _partials/ placement doctrine, distinct from the concision partial, and include it in design-and-plan, create-ticket, and align-ticket-with-implementation.
• The doctrine discriminates by placement, in routing-agnostic wording: the ticket carries the change's subject (the defect, the current structure being changed, the target contract it exposes) and key non-obvious details that save the implementer derivation; implementation mechanism (internal wiring, files as a diff-list, step sequences, the internals of a consumed dependency) belongs with the implementation, not the ticket.
• Each consuming skill supplies its own routing target (design-and-plan → the plan artifact; align-ticket → the code; create-ticket → derived when the work is planned).
• Demonstrate the line with one worked bad→good example drawn from the modal failure — a feature ticket that imports a reference implementation's API surface — because agents imitate the nearest example.

This replaces design-and-plan's current localized categorical rule (correcting its bug/refactor blind spot); it does not layer a new prohibition. Keep it separate from the concision doctrine — placement governs the kind of content, not its volume. No compose-time enforcement gate now; revisit if leakage recurs.

Acceptance criteria

Must have

• A new shared _partials/ placement doctrine exists, separate from the concision partial, discriminating subject / target contract / key derivation-saving detail (→ ticket) from implementation mechanism (→ implementation) in routing-agnostic wording.
• It is included by design-and-plan, create-ticket, and align-ticket-with-implementation, each supplying its own routing target.
• Bug and refactoring tickets — where existing code is the subject — are explicitly accommodated; the prior categorical exclusion of code, paths, and syntax is corrected.
• The distinction is demonstrated by one worked bad→good example based on the modal failure (a feature ticket leaking a reference implementation's API or paths).