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.2 KiB

Raw Blame History

START HERE — Claude Code kickoff

Note (current state): the module is fully built (Steps 1–14) and its technical name is now activeblue_familylaw_v2 (renamed from activeblue_familylaw to coexist with a different legacy module of that name already in production). The design docs below still say activeblue_familylaw — that's the historical narrative; the live module folder/name is activeblue_familylaw_v2. See BUILD_STATUS.md.

You are picking up an in-progress build. Read in this order, then start the task at the bottom. Do not re-derive the design — it exists; follow it.

Read order (do this first)

CLAUDE.md — the operational brief and single source of truth. Read it fully. Pay special attention to:
- §1 — the governing rule + the two gates + Claude's role as the quality-elevation layer.
- §2 — the 15 capabilities, grouped by RISK (what's safe now vs. attorney-gated).
- §4 — locked decisions (apply them; do not re-litigate).
- §5 — the verifiable-step method + the test harness rules.
- §8 — STEP 2, your immediate task.
- §10 — the audit fixes already applied (esp. fix 2, the familylaw.proceeding model).
- §11 — the non-code success gaps (context for why some steps are gated).
BUILD_PLAN.md — the step contract and the run/test commands.
The design docs 00–11 (in the separate design package) — why/detail behind each step. Read the relevant doc(s) before each step, not all at once. For Step 2: docs 02 (domain) and 03 (data model).

Current state

Step 1 is DONE and validated — activeblue_familylaw module: the familylaw.case spine, the lifecycle state machine, attorney-only gates, security groups, views, and 10 passing tests (tag familylaw_step1). Module layout is in CLAUDE.md §6.
The code is Odoo 18 (uses <list> not <tree>; direct attributes, no attrs/states).
Nothing else is built yet. Steps 2–14 are designed, not implemented.

Hard rules (from CLAUDE.md — do not violate)

One verifiable step at a time. Don't scaffold ahead. Each step = installable code
- a UI walkthrough + tagged unit tests + a done-when. Get green before advancing.
The two gates are sacred: no code path lets AI output be filed/sent/signed without attorney approval, or lets an unverified citation into a filing. If a request would breach this, flag it — don't build it.
Mock all external APIs in tests (Claude, DocuSeal, CourtListener). Never hit the network from a test. Test date math with fixed dates.
No outcome/success-percentage prediction. The decision graph compares strength of support, never a "% chance of winning" (CLAUDE.md §2 EXCLUDED).
Tier 3 (capabilities 8–9, Steps 6–7–9) is gated behind licensed-attorney validation of the legal logic. You may build the structure/scaffolding but flag that the legal content is unvalidated; do not present legal reasoning as authoritative.

Your first task: STEP 2

Build exactly what CLAUDE.md §8 specifies:

Models: familylaw.party, familylaw.child, familylaw.issue, familylaw.proceeding.
Add indexed, searchable case_number to familylaw.case; open an initial proceeding on case creation.
Automated conflict screening — a local DB search over familylaw.party across all cases that surfaces potential conflicts for the attorney to clear (never auto-clears, never auto-blocks; the Step 1 conflict_check_cleared attorney gate remains).
Extend case search to find by party name, child name, and case_number.
Intake questionnaire (native models; creates a draft case): triage-first with the urgency screen, conditional strictness (standard = strict; emergency = fast-path on minimum facts), branching into the child-support modification question set, runs conflict screening on completion. Captures facts only — never answers "do I have a good case?" (logs it as an attorney question).
Tests tagged familylaw_step2 covering everything in §8's test list.
Done-when: familylaw_step2 green + the four-part walkthrough in §8.

Work in the module, keep Step 1's tests green, and deliver Step 2 as one reviewable, tested slice. Then stop and report before starting Step 3.