Epic priority-0 mechanical gate: block sub-issue creation until parent's P0 ACs clear

Context

Epics codify priority-ordered acceptance criteria; some are tagged as priority-0 prerequisites that must be satisfied before sub-issue work begins (e.g., "verify external dependency X before refactoring Y", "establish baseline metrics before performance work", "backup-first before destructive substrate operations"). Currently this is enforced by per-agent vigilance — agents are expected to read the epic body, identify P0 ACs, verify they're checked, and refuse sub-issue creation if not. Empirically this discipline is fragile.

This ticket is preventive operational substrate / MX hardening — it makes P0 enforcement mechanical at the GraphQL/MCP boundary.

The Problem

Per-agent vigilance fails under multi-instance / multi-session swarm dynamics. Even agents who authored the P0 rule for an epic can later participate in workflows that bypass it (the rule lives in prose; nothing prevents update_issue_relationship(parent: epic, child: sub, type: SUB_ISSUE) calls when parent's P0 ACs are unchecked).

The Architectural Reality

• Epic bodies use markdown-checkbox AC lists.
• Some ACs are tagged with [priority-0] prefix or (P0) suffix in their text (convention varies; needs canonicalization).
• The MCP tool mcp__neo-mjs-github-workflow__update_issue_relationship currently accepts parent_id, child_id, type and creates the GraphQL native sub-issue link without inspecting parent state.
• Pre-flight verification can happen entirely in the MCP tool wrapper: fetch parent, parse AC list, check P0 items, refuse if any are unchecked.

The Fix

1. Canonicalize P0 marker syntax. Pick one convention (proposed: [priority-0] prefix on the AC line). Document in .agents/skills/ticket-create/references/ticket-create-workflow.md.
2. Pre-flight check in update_issue_relationship when type === 'SUB_ISSUE':
   • Fetch parent issue body
   • If parent has epic label: parse AC list; identify lines starting with - [ ] [priority-0] (unchecked P0)
   • If any unchecked P0 found: refuse with structured error { error: 'epic-p0-unchecked', uncheckedItems: [...] }
3. Override flag for legitimate exceptions: force: true parameter in the MCP call requires the calling agent to explicitly bypass + log rationale (audit-trail visible in MCP logs).

Contract Ledger Matrix

Acceptance Criteria

• [priority-0] AC marker canonicalized in .agents/skills/ticket-create/references/ticket-create-workflow.md
• update_issue_relationship parses parent epic body for unchecked [priority-0] ACs
• Refusal returns structured { error: 'epic-p0-unchecked', uncheckedItems } payload
• force: true bypass parameter available with logged rationale requirement
• Unit tests: epic-with-checked-P0-allows-link, epic-with-unchecked-P0-refuses-link, force-bypass-allows-with-log, non-epic-parent-no-check
• Update existing epic bodies to use canonical [priority-0] marker for already-tagged P0 ACs

Out of Scope

• Auto-creating P0 ACs in epic bodies — that's authoring-side discipline, not enforcement-side
• Retroactive enforcement against existing sub-issues — only fires at creation time
• Cross-epic dependencies (one epic's sub blocks another epic's P0) — orthogonal complexity

Avoided Traps / Gold Standards Rejected

• Pre-commit git hook checking epic-P0 state — hooks fire on commits, not on sub-issue creation events; wrong substrate boundary
• GitHub Actions workflow validating PR-issue links — fires too late (post-PR); the gate must be at sub-issue creation, before substantive work begins
• Multiple priority levels (P0/P1/P2/P3) — over-engineering; one gate level (P0 = blocking) is sufficient; richer prioritization belongs in label taxonomy

Related

The pattern of declaring P0 prerequisites in prose (which any agent can read but no tool enforces) creates a structural reliability gap. Mechanical enforcement at the sub-issue-creation boundary closes it without requiring per-epic special-case logic.

Origin Session ID: 8b31fd62-6a53-40b5-aae2-c5288f8ced09 Retrieval Hint: "epic priority-0 sub-issue mechanical gate update_issue_relationship MCP precondition"