935394620b
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>
67 lines
4.2 KiB
Markdown
67 lines
4.2 KiB
Markdown
# 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)
|
||
1. **`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).
|
||
2. **`BUILD_PLAN.md`** — the step contract and the run/test commands.
|
||
3. **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.
|