Opus Verification — Pack 1 Phase 2 DDL PASS

Date: 2026-05-11 Author: Opus 4.7 (verifier)

Verdict: PASS

Check	Result
Columns added	10/10 (3 IU + 7 UV) ✅
All nullable, no default	10/10 confirmed ✅
No FK/index/trigger	0 added ✅
IU rows unchanged	12 = 12 ✅
UV rows unchanged	19 = 19 ✅
Gateway enforced	✅
Triggers enabled	2/2 gateway ✅
fn_iu_create_plan reachable	plan_ok ✅
No TAC modification	✅
No Qdrant mutation	✅
No Directus mutation	✅
DDL in single transaction with lock/statement timeout	✅ (agent added safety)

Hash Investigation — Critical Finding

Source	Algorithm	Match?
IU native unit_version	sha256(body::bytea)	✅ MATCH
TAC tac_unit_version	???	❌ Neither md5(body) nor sha256(body::bytea)

TAC hash is 64 chars (like sha256) but doesn't match sha256(body::bytea). Possible: sha256 over normalized/trimmed body, or sha256 over body+title+description+profile (per P5 design §5.2 "content_hash bao gồm body + title + description + content_profile").

This MUST be resolved before Phase 3 data migration. Investigation: check if TAC hash = sha256(body || title || description || content_profile::text).

Planner Quirk — unit_kind Resolution

fn_iu_create_plan('...', 'law_unit', ...) returned resolved_unit_kind=design_doc_section. This means the planner has a vocab/policy that remaps 'law_unit'. Need to investigate before using fn_iu_create for TAC→IU migration.

Recommendation

1. GPT confirm Phase 2 PASS
2. Phase 3 scope: hash algorithm investigation + vocab reconciliation design + compatibility view design. Still design/read-only, no data migration yet.
3. Two blockers for Phase 4 (data migration):
   • Hash algorithm must be identified and reconciled
   • unit_kind 'law_unit' must resolve correctly in planner

Status

phase2_ddl=PASS
columns_added=10
hash_blocker=TAC_HASH_ALGORITHM_UNKNOWN
planner_blocker=UNIT_KIND_RESOLUTION_QUIRK
next_phase=PHASE_3_HASH_INVESTIGATION_AND_COMPATIBILITY

---

Opus Verification | Phase 2 DDL PASS | 2026-05-11