Files
famlaw_v2/START_HERE.md
tocmo0nlord 0d53967422 Initial commit — Step 1 complete: case spine, lifecycle, attorney gates
Delivers the validated Step 1 slice of the Active Blue Family Law platform
(Odoo 18 Community module `activeblue_familylaw`):
- familylaw.case model: identity, team, representation flag, conflict_check_cleared gate
- Full lifecycle state machine (intake→engaged→disclosure→discovery→mediation→hearing→closed)
- Attorney-only guards enforced in Python + view groups=
- Security groups (Family Law/Staff, Family Law/Attorney), model access rules
- List, form, and search views (Odoo 18 <list> syntax; no attrs=/states=)
- Family Law app menu with Configuration placeholder
- 10 tagged unit tests (familylaw_step1): transitions, conflict gate, attorney-only, audit
- CLAUDE.md, BUILD_PLAN.md, START_HERE.md: full design brief and step contract

Step 2 (parties, children, issues, proceeding model, conflict screening,
intake questionnaire) is the next build target.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-06-02 03:14:33 +00:00

61 lines
3.8 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# START HERE — Claude Code kickoff
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 214 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 89, Steps 679) 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.