Files

tocmo0nlord 935394620b Rename module to activeblue_familylaw_v2 (coexist with legacy prod module)

Production already has a DIFFERENT, earlier module installed as `activeblue_familylaw`
(models fl.*, real data). Renamed this build's technical name to
`activeblue_familylaw_v2` so it installs ALONGSIDE the legacy app instead of replacing
it. Models (familylaw.*) and test tags (familylaw_step<N>) are unchanged — only the
module name and its group XML IDs change.

Changes:
- Folder activeblue_familylaw -> activeblue_familylaw_v2 (git mv)
- All 44 dotted refs activeblue_familylaw. -> activeblue_familylaw_v2.
  (security group XML IDs in views/python; test patch targets odoo.addons.*)
- Manifest display name -> "Active Blue Family Law v2"; root menu -> "Family Law (v2)"
- scripts/validate_module.py ROOT path; BUILD_STATUS.md run commands + coexistence
  note; START_HERE.md pointer

Verified in live Odoo 18:
- Fresh install + full suite: 200 tests, 0 failed, 0 errors.
- COEXISTENCE on a clone of prod db1: installing _v2 alongside the installed legacy
  activeblue_familylaw left the legacy untouched (still installed 18.0.1.0.0, fl.*
  models registered, fl_caselaw 25 rows intact) while adding the 30 familylaw.* models.
  Exit 0, no errors. Clone dropped; prod DBs untouched.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

2026-06-02 11:23:34 +00:00

4.6 KiB

Raw Blame History

Build Status — Active Blue Family Law (`activeblue_familylaw_v2`)

All 14 roadmap steps are implemented, validated, and committed. Module version 18.0.14.0.0. Built on Odoo 18 Community.

⚠️ Technical name is activeblue_familylaw_v2 (folder activeblue_familylaw_handoff/activeblue_familylaw_build/activeblue_familylaw_v2). It was renamed from activeblue_familylaw because production already has a different, earlier module installed under that name (models fl.*, real data) — see "Production coexistence" below. The _v2 module uses familylaw.* models and its own security groups, so it installs alongside the legacy app without collision. Models/tags are unchanged (familylaw.case, familylaw_step<N>).

✅ Tests run green in a live Odoo 18: 0 failed, 0 error(s) of 200 tests (installed clean into a throwaway DB on the local odoo:18.0 image against Postgres 16, then dropped — production DBs untouched). Also validated statically via scripts/validate_module.py (Python compile, XML well-formed, no Odoo-18 forbidden constructs, button→method mapping, manifest/ACL integrity, view-field resolution, duplicate-id + action-ref + load-order checks).

Reproduce: see "Run the tests" below.

Run the tests

# whole module (install + all tests)
odoo -d <db> -i activeblue_familylaw_v2 --test-enable --stop-after-init

# one step
odoo -d <db> -u activeblue_familylaw_v2 --test-enable --test-tags familylaw_step7 --stop-after-init

# all family-law tests
odoo -d <db> -u activeblue_familylaw_v2 --test-enable --test-tags familylaw --stop-after-init

Re-run static checks any time: python3 scripts/validate_module.py

Production coexistence

Prod db1 has a separate legacy activeblue_familylaw installed (different lineage: fl.* models incl. fl.caselaw, fl.statute, fl.support.schedule.entry, with real rows). This module is activeblue_familylaw_v2 with familylaw.* models and distinct group XML IDs, so it coexists — installing it will NOT touch or remove the legacy app or its data. Verified by cloning db1 and installing _v2 into the clone.

Steps

Step	Slice	Tag
1	Case spine + lifecycle + attorney gates	`familylaw_step1`
2	Parties/children/issues + proceeding + conflict screening + intake	`familylaw_step2`
3	Documents + review gate (Gate 1)	`familylaw_step3`
4	Deadline engine (per-proceeding, weekend roll, overdue cron, calendar mirror)	`familylaw_step4`
5	Mandatory disclosure (12.285) — checklist + financial affidavit	`familylaw_step5`
6	Claude client + `ai.task` ledger + drafting agent + citation ledger (Tier 3)	`familylaw_step6`
7	Citation gate (Gate 2) — fail-closed verify + filing block + research loop	`familylaw_step7`
8	Discovery + Rule 12.351 subpoena (objection window + routing)	`familylaw_step8`
9	Child-support modification (new proceeding, 15%/$50, 20-day, DOR, prior-judgment)	`familylaw_step9`
10	Emergency workflow (12.941) — fork + attachment block + fast-path	`familylaw_step10`
11	DocuSeal e-signature (approved-only, webhook)	`familylaw_step11`
12	File archive (SHA-256) + retention lifecycle + calendar layers	`familylaw_step12`
13	Miami-Dade auto-seed (AO 14-13) + course-before-judgment guard	`familylaw_step13`
14	Comms (never auto-send) + AI-assist billing flag + matter-scoped access	`familylaw_step14`

The two sacred gates (verify these first)

Gate 1 (review): AI/draft documents are born ai_draft; only an attorney can approve; nothing files/sends unapproved. familylaw.document._ensure_approved.
Gate 2 (citation): every citation is born unverified; verification is fail-closed (down/no-record → stays blocked); filing is blocked on any unverified cite. familylaw.document._ensure_citations_verified + familylaw.citation.verifier.

Tier 3 caveat (unchanged from design)

Steps 6/7/9 build the structure; the legal content they produce is born unapproved/unverified and is not authoritative until a licensed Florida attorney validates the legal logic and approves the output. All external APIs (Claude, CourtListener, DocuSeal) are mocked in tests and isolated behind single methods.

Volatile legal values to confirm before production (search `VERIFY`)

Deadline day-counts (20/45/30/10), disclosure income threshold ($50k → 12.902(b)/(c)), 15%/$50 support-modification presumption, Rule 12.410 subpoena amendment (eff. Oct 1 2025), AO 14-13 obligations, retention periods. None are baked in as permanent.

4.6 KiB Raw Blame History

Build Status — Active Blue Family Law (activeblue_familylaw_v2)