06 — Điều 39 rerun VERIFY_MARK result

Invocation (preview only — p_apply=false)

SELECT public.fn_iu_verify_mark(
  p_staging_record_id := '9fa4685e-d35a-45d4-aee7-aa2836785ca5'::uuid,
  p_apply := false,
  p_actor := 'dieu39_verify_mark_preview_v1'
);

Result

{
  "ok": true,
  "verdict": "approved",
  "axis_a_ok": true,
  "axis_b_ok": true,
  "axis_c_ok": true
}

axis	what it checks	outcome
Axis A	source_position dense from 1 (min=1, no holes)	PASS (1..16 dense)
Axis B	every piece has non-empty piece_role AND non-empty section_type	PASS
Axis C	every parent_local_id resolves to a sibling local_piece_id	PASS vacuously (all parents null)
(coverage)	coverage_proof.covered_bytes == manifest.source_bytes	PASS (23394 == 23394)
(digest)	manifest_digest ~ '^[0-9a-f]{32}$'	PASS (aded6af9…)

Demonstrated regressions of the original failure

1. No malformed array literal exception — verify returns structured JSON in both pass and rejected paths.
2. Axis A would now also surface non-integer source_position as a structured problem (instead of raising in the cast) — verified earlier in the run when the OLD manifest was previewed and produced:

   {"ok":false,"verdict":"rejected","problems":[  "Axis A: source_position missing or non-integer on at least one piece",  "Axis B: piece_role or section_type missing on at least one piece"],"axis_a_ok":false,"axis_b_ok":false,"axis_c_ok":true}
   

3. Axis B correctly identifies missing piece_role and section_type (the originally-failing condition for Điều 39).

State at exit

• cut_request.status = marked (NOT advanced to mark_verified — see 08-next-step-cut-approval.md).
• manifest_staging_record.lifecycle_status = pending_review (awaiting operator approval).
• cut_request.cut_run_id = NULL (no CUT was run — strict non-goal).
• ready_for_cut is implicitly true (all 3 axes pass), but a separate approval step is required before fn_cut_apply would accept the request.