OPER-163
OPER-KNUCK-RESCOPE-2: Bulk-repair routing metadata on 239 NEEDS_RESCOPE KNUCK-P tickets and re-run admission
Suggested
Justin Cooke
Body
## Context 239 KNUCK-P* tickets sit in NEEDS_RESCOPE without any admission-rejected footer. Inspection shows they have no quality-gate frontmatter (all have `size: null`, `band: null`, `module: null`) despite having clean bodies with Context, Acceptance Criteria, and Provenance sections. They were rescoped (or bounced by an earlier admission pass) not because of content problems, but because they're missing required routing metadata. This ticket instructs the dispatcher to bulk-repair all 239 tickets by inferring size/band/module from ticket content, then re-running admission. **Routing metadata to infer per ticket:** - `size`: from acceptance-criteria complexity (S | M | L | XL) — most KNUCK-P tickets are S (single-file changes) or M (one package touched) - `band`: from PHI/schema/RLS impact — most are `low` (docs, CI, monitoring); a handful touching RLS are `high` - `module`: from ticket title + acceptance-criteria file paths — infer nearest package under `packages/` or `apps/` - `phiInScope`: already correct (all false) - `hasMigration`: infer from acceptance criteria mentioning `packages/database/prisma/schema/*.prisma` or migration SQL **Ledger category:** `ASSURE-ADMISSION-REPAIR` **Depends on:** OPER-KNUCK-RESCOPE-1 (feature_id declaration must land first, else the 92 unknown_feature_id tickets stay rejected) **Blocked by:** none ## Goal Repair the routing metadata on 239 NEEDS_RESCOPE KNUCK-P tickets and re-run admission so they transition to PLANNING_VALIDATED and become dispatch-eligible. ## Acceptance Criteria - **Done when:** - A one-shot dispatcher job reads all KNUCK-P* tickets in NEEDS_RESCOPE - For each, infers `size`, `band`, `module`, `hasMigration` from body content using deterministic rules (documented in the job source) - PATCHes each ticket with the inferred fields - Triggers `admission.rerun` on each after the patch - Reports final count: how many transitioned to PLANNING_VALIDATED, how many stayed NEEDS_RESCOPE (with reason), how many bounced - **Self-test:** - Fixture: 5 sample KNUCK-P tickets are re-run through the inference pipeline; asserted output matches hand-labeled expected fields for each ## Constraints - PR size: M. This is a one-shot repair job plus its inference rules; not a permanent piece of infrastructure. - The inference job must be idempotent: running it twice must produce identical results. - Do NOT flip status directly. Use the admission-rerun path so quality gates continue to apply — if a ticket is genuinely unfit after metadata repair, it must still bounce. - If more than 20% of tickets fail to auto-classify (e.g. size can't be inferred), stop, surface the sample failures, and file a follow-up ticket for hand-triage rather than defaulting to S. ## Provenance Filed by user:justin as part of clearing the 331 KNUCK-P Knuckles Master Ordered Action Plan backlog. See KNUCK-P001 through KNUCK-P331 for the ticket cluster this unblocks. Paired with OPER-KNUCK-RESCOPE-1 which handles the 92 unknown_feature_id tickets. --- <!-- admission-rejected --> **Admission rejected (missing_feature_id):** ticket body is missing `feature_id: FEAT-...` frontmatter — declare which feature this ticket implements
Attachments
Loading attachments…
Comments
Loading comments…