08 — Next-batch plan + carry-forward

Carry-forward items

ID	Severity	Title	Why	Next pack
CF-1	HIGH	Wire real heartbeat caller for cut.* job_kinds	7 signal jobs sit queued with no claimant; §15.5 silent gap still not closed for the cut pipeline	IU_CUT_PIPELINE_HEARTBEAT_CALLER_WIRING (Option B: external operator wrapper, HC pattern per [[feedback-hc-executor-last-run-is-proven-heartbeat-pattern]])
CF-2	HIGH	Cleanup executor (15-day TTL)	cleanup_scheduled_at set by fn_cut_complete, but nothing transitions cleanup_scheduled → cleaned; staging rows accumulate indefinitely	IU_CUT_PIPELINE_CLEANUP_EXECUTOR — implement fn_cut_request_cleanup_apply() that calls existing fn_iu_op_cleanup_dry_run then transitions cut_request + deletes payload rows
CF-3	MED	Recovery path for cut_failed terminal	State machine has no exit from cut_failed; operator must surgically intervene	Add cut_failed → mark_verified transition (re-cut with patched manifest); or add cut_failed → cleaned (abandon)
CF-4	MED	DOT-driven KB→server copy helper	Step 0 of the runbook is still bespoke (lo_export block). Codify as fn_cut_zone_stage_from_kb(p_kb_path text, p_target_filename text)	IU_CUT_PIPELINE_KB_STAGER
CF-5	MED	Idempotent re-request	fn_cut_request_add doesn't dedup against existing in-flight requests for the same source_ref	Add UNIQUE INDEX on (source_ref, status) where status NOT IN ('completed','cleanup_scheduled','cleaned','cut_failed','mark_rejected')
CF-6	MED	Wire cut.complete job_kind to schedule cleanup	When queue.worker.enabled becomes true, the cleanup job should be picked up by a stale-tolerant executor	Bundled with CF-1+CF-2
CF-7	LOW	Điều 38 DRAFT IU lifecycle	8 IUs created with lifecycle_status='draft'. When Điều 38 is enacted (v3.0 → v3.1+ BAN HÀNH), these need supersede/retire per §B2.1 (Fix19)	Track in Điều 38 ban-hành plan; not blocking
CF-8	LOW	Birth gate L1 P-pub1/P-pub2 warnings	16 non-blocking warns during CUT; same as Phase 3 carry-forward	Same as Phase 3B carry-forward; not blocking
CF-9	LOW	Manifest digest reconciliation post piece-patch	The patched cut_manifest payload's pieces array no longer reconstructs the stored manifest_digest. G5/G6 still pass per Phase 3B feedback, but a "patched=true" marker in metadata would aid forensics	Add iu_staging_record.metadata.patched=true/false flag set by recovery helper

Open questions (route to Council / User)

1. Should fn_cut_request_add accept an explicit expected_pieces_count? Helps operator catch wildly off-spec mark proposals at REQUEST time rather than at MARK.

2. Where should DOT-driven cleanup execution actually run? Options: (A) external HC executor on a 24-hour tick + idempotent SQL; (B) make cut.cleanup a real job_kind once queue.worker.enabled=true; (C) PG trigger on cleanup_scheduled_at < now().

3. Should cut_request rows be retained after cleaned? Currently the audit trail persists; an explicit retention policy (e.g., 365 days per §11 of Điều 45 v1.0) would be cleaner.

4. Multi-source / multi-doc CUT request? Current design: one source_ref per cut_request. For composite IUs spanning multiple source documents, the contract would need a sibling cut_request_source table.

5. Approval signature integration with Điều 32 (PR/QUORUM)? mark_approval_doc_id is a free-text KB path. For high-stakes laws (e.g., constitution amendments) the approval should be linked to a dot_iu_command_run row or an Điều 32 quorum decision row.

Next pack candidate name

DIEU45_PHASE_4_CUT_PIPELINE_HEARTBEAT_CALLER_AND_CLEANUP_EXECUTOR_DRY_RUN_FIRST

Suggested structure (echoing Phase 3B pattern):

• Step A: dry-run author the heartbeat caller (HC-pattern, external operator ticks queue_heartbeat for cut_pipeline_executor)
• Step B: dry-run author the cleanup executor (PL/pgSQL function fn_cut_request_cleanup_apply that scans WHERE cleanup_scheduled_at < now() AND status='cleanup_scheduled', calls the cleanup helper, transitions to cleaned)
• Step C: live apply both; verify on the Điều 38 cut_request (will reach cleanup readiness on 2026-06-10)
• Step D: D30/D31 protection re-run

Rollback option for THIS mission (mig 052)

BEGIN;
DROP FUNCTION public.fn_cut_complete(uuid, text);
DROP FUNCTION public.fn_cut_verify_cut(uuid, text);
DROP FUNCTION public.fn_cut_apply(uuid, boolean, text);
DROP FUNCTION public.fn_cut_verify_mark(uuid, boolean, text, text, text);
DROP FUNCTION public.fn_cut_mark_staged_file(uuid, jsonb, text, text);
DROP FUNCTION public.fn_cut_copy_to_staging(uuid, text, text);
DROP FUNCTION public.fn_cut_request_add(text, text, text);
DROP FUNCTION public.fn_cut_request_signal(text, uuid, text, jsonb);
DROP FUNCTION public.fn_cut_request_transition(uuid, text, text, jsonb);
DROP VIEW public.v_cut_request_ready_to_verify_cut;
DROP VIEW public.v_cut_request_ready_to_cut;
DROP VIEW public.v_cut_request_ready_to_mark;
DROP VIEW public.v_cut_requests_by_status;
DROP TABLE public.cut_request_transition;
DROP TABLE public.cut_request CASCADE;
DELETE FROM dot_config WHERE key LIKE 'vocab.cut_request_status.%';
COMMIT;

Note: the 8 Điều 38 IUs created in information_unit would NOT be rolled back by this — they live independently. Separate cleanup if desired:

DELETE FROM information_unit WHERE canonical_address LIKE 'DIEU-38-v3.0%';

Cross-links

• [[project-dieu45-phase3b-queue-cutter-hardening-pass-2026-05-26]] — direct parent (queue cutter hardening)
• [[project-dieu45-phase3-mark-cut-queue-pilot-dieu37-write-channel-pass-2026-05-26]] — methodology grandparent (Điều 37 pilot)
• [[project-dieu45-phase2-heartbeat-activation-lease-governance-pass-2026-05-26]] — heartbeat substrate
• [[project-dieu45-phase1-minimal-job-substrate-live-apply-pass-2026-05-26]] — job queue substrate
• [[feedback-mcp-query-pg-is-context-pack-readonly-no-phase3-writes]] — channel doctrine
• [[feedback-mark-pieces-live-in-iu-staging-payload-cut-manifest-not-in-iu-staging-record-metadata]] — recovery via jsonb_set
• [[feedback-hc-executor-last-run-is-proven-heartbeat-pattern]] — CF-1 implementation pattern
• [[feedback-protect-legacy-silent-passive-heartbeat-from-false-heal]] — heartbeat caller hard-refusal pattern