implement-ticket

Implement Ticket

Implement one ticket and close it only after one fresh independent $verify-ticket-closure verdict certifies the exact candidate.

This SKILL.md is the single authoritative procedure for $implement-ticket.

The common ticket-closure hardening below supersedes only the older root-verification/self-certification concepts preserved later in this file. All other preserved implementation, branch, hierarchy, project-delivery, applicability, helper, verification, persistence, commit, tracker, frontier, and handoff mechanics remain normative.

Superseded Legacy Concepts

The following older concepts are replaced by the current rules in this section:

• Durable Root-Verification Checkpoint → Durable Ticket-Closure Checkpoint;
• remediation-only root-verification re-entry → common closure re-entry for every ticket;
• any statement allowing an ordinary ticket to self-certify semantic acceptance and proceed directly to persistence/closure;
• Spec Review Root Closure verifier handoff/dispatch/verdict mechanics → the common Independent Ticket Closure Gate below;
• direct $verify-root-closure certification → $verify-ticket-closure;
• ROOT CLOSURE: PASS|FAIL as the ticket semantic verdict → TICKET CLOSURE: PASS|FAIL.

The preserved remediation-specific root reasoning, invariant sweep, preservation, and protected-root requirements remain applicable inputs for remediation; they are now certified inside the same common verifier rather than by a separate algorithm.

Core Authority Invariant

The implementation actor may propose closure evidence, but it may not certify its own candidate.

For every ordinary Implementation Ticket and every Review Remediation Ticket:

implement
    ↓
local / delegated implementation verification
    ↓
Proposed Closure Evidence
    ↓
immutable candidate checkpoint
    ↓
automatic fresh non-mutating $verify-ticket-closure dispatch
    ↓
one TICKET CLOSURE: PASS | FAIL
    ↓
persist / commit / close only after PASS