Define the closed-loop GitHub issue and PR contract #456

Parent

#455

What to build

Define one repository-wide GitHub lifecycle contract and matching issue/PR templates. The contract makes GitHub authoritative, requires one category and one triage state, distinguishes tracking and runtime work, uses native parent and blocked-by relationships, and makes Refs, Closes, and manual runtime closure unambiguous.

Acceptance criteria

• Repository agent instructions and issue-tracker documentation define exactly one category, exactly one triage state, optional tracking/runtime qualifiers, native relationships, and one active owner.
• PRD/tracking, engineering-change, and runtime-rollout issue templates expose the required acceptance, dependency, controller, rollback, and evidence fields without duplicating a project-management database.
• The PR template requires exactly one issue relationship: Refs #N, Closes #N, or None.
• Partial work, non-default-base stacked PRs, tracking parents, and runtime contracts cannot claim closure; runtime closure requires immutable live evidence.
• Parent closeout is an explicit acceptance audit after the last direct child closes and is never automatic.
• Documentation links and template syntax validate, and git diff --check passes.

Blocked by

None - can start immediately.

Contract clarification

• Closing keywords in commit messages are governed by the same rule as PR bodies because GitHub can close an issue when that commit reaches the default branch. Partial, stacked, runtime, and tracking work must not use close, fix, or resolve keywords with an issue reference in either surface.