09 — job:cut Registration Candidate Prep (Workstream H)

job:cut is the only verified_candidate and must not be ignored.

Live evidence

• v_process_discovery_verified_candidates_v3: PROC-CAND:job:cut, kind=job, 8 members, verified_candidate, birth_gate = VERIFIED_PENDING_OWNER, event_missing=true, owner_missing=true.
• v5: verified_candidate preserved (untouched by this macro).
• Runner: external_queue_runner (job_queue + run_id correlation); true Mode.DRYRUN runner proven (iu-cutter-v0.6, 366/366).

Registration-readiness packet (DRAFT — no birth, no canon, no approval)

1. Process definition candidate — job:cut, 8 correlated members; runtime verified via job_queue.run_id correlation (real run rows, not backfill).
2. Birth readiness — gate = VERIFIED_PENDING_OWNER. The only blocker is owner assignment (Điều 37 ownership). Birth = 10-law-definition split applies to dot:kg, not job:cut; job:cut is a single job process.
3. Owner gap — gov_object_ownership has no row; owner_missing=true. Needs an owner-of-record before birth admission.
4. Governance handoff — owner ratifies → birth admission → optional process.* activation. Do not auto-approve (the apr auto-approve trigger fires on action='add'; any approval_requests row must use action='review').
5. RP pivot status — surfaced as verified in v3/v4/v5; UI badge already correct.
6. Rollback caveat — none needed; this macro made no change to job:cut.

Why no approval row was inserted

Inserting an approval_requests row risks the trg_apr_auto_approve auto-approving action='add', and each insert is an unretirable birth. Per safety, this packet stays a KB artifact; an owner/operator files the review-action request. No fake approval.

Next

JOB_CUT_PROCESS_REGISTRATION_CANDIDATE_PREP → owner assignment → birth admission. No engineering blocker remains for job:cut.