Estate planning: practice review, practice areas, and federal + New Jersey statutory research tools

🟢 open · #1 · adameliaslaw/mike ← adameliaslaw/mike · opened 20d ago by adameliaslaw · self · +2,299-6 across 19 files · ↗ on GitHub

From the PR description

Summary

Estate planning enablement in three layers: a codebase review (docs/estate-planning.md), private-client practice areas, and statutory research tools covering both federal law (US Code + eCFR, keyless) and the New Jersey Statutes (N.J.S.A.) via the Legislature's official bulk publication imported into Supabase.

Why / Motivation

Mike's legal research covered case law only. Estate planning is statute-first - and for a New Jersey practice that means N.J.S.A. Title 3B (wills, probate, intestacy, elective share, and the NJ UTC in 3B:31), Title 46 (property/POA), and Title 54 (transfer inheritance tax), alongside the IRC and Treasury Regulations. Without retrieval, the assistant answers all of this from model memory.

Changes

Review document (docs/estate-planning.md) - capability inventory with file references, workflow recommendations, remaining build list.

Practice areas - Estate Planning, Probate & Estate Administration, Elder Law added to the picker.

Federal statutory research (keyless, works on every deployment):

  • uscode_read_section - current US Code text from the OLRC (uscode.house.gov prelim edition, deterministic granule URLs, 302 → not-found).
  • ecfr_search_regulations / ecfr_read_section - CFR search and section text through the public eCFR API, covering the Treasury Regulations.

New Jersey statutory research (backend/src/lib/njStatutes.ts):

  • The NJ Legislature has no per-section API (the live browser is a legacy Folio NXT server), but it publishes the complete statutes as an official plain-text bulk file refreshed every weekday (pub.njleg.gov/statutes/STATUTES-TEXT.zip). This uses the codebase's existing CourtListener bulk-data pattern: import into Supabase, query from tools.
  • npm run import:njsa --prefix backend downloads, decodes (windows-1252), parses (~55k sections, 69 titles), batch-upserts into njsa_sections, prunes stale rows, and records currency metadata (updated through P.L.2025, c.346). It aborts without writing if the parse looks wrong.
  • njsa_search_statutes - Postgres full-text search (generated tsvector + GIN index) with optional title filter; njsa_read_section - exact lookup with citation normalization ("N.J.S.A. 3B:3-2." → 3B:3-2). Every result carries the source currency line. If the import hasn't been run, the tools return an instructive message instead of silence or hallucination.
  • Migration 20260726_01_njsa_sections.sql + schema.sql: tables with RLS and anon/authenticated grant revocation matching existing backend-owned tables.

Prompting - statutory quotes must come from retrieved text; inflation-adjusted federal figures are flagged as living in annual revenue procedures; for states other than NJ the assistant must say it cannot retrieve that state's text rather than recite from memory.

Frontend - event types, activity labels ("Searching NJ statutes..."), SSE handling, and tool-activity rendering for all five research events.

Tradeoffs & risks

  • NJSA data is imported, not live. The source refreshes every weekday; the import is one command and safe to re-run (upsert + stale-row pruning). Currency metadata is surfaced in every tool result so staleness is visible, not silent. A scheduled re-import is a natural follow-up.
  • Parser depends on the bulk file's layout (unindented 3B:3-2. Heading headers, TITLE nn banners). It was validated against the full live file - 55,452 sections parsed, only 8 empty-text rows (repealed placeholders) - and the import script refuses to write if the format shifts (< 10k sections parsed).
  • OLRC parsing is comment-marker-based; a marker change degrades to a clean error, never wrong text.
  • Other states remain uncovered; the system prompt makes the assistant say so. Additional states can be added per user as MCP connectors.
  • No new API keys anywhere. NJSA import requires only the Supabase credentials the backend already has.

How verified

npm run build --prefix backend    # clean
npm test --prefix backend         # 20 files, 289 tests passed (statutes + njStatutes suites added)
npx tsc --noEmit (frontend)       # clean
npm run lint --prefix frontend    # 0 errors, 40 pre-existing warnings
npm test --prefix frontend        # 7 files, 38 tests passed

Live verification against real sources:

  • eCFR: search located the portability regs (§§ 20.2010-2/-3, 25.2505-2); full current text of 26 CFR 20.2010-2 retrieved (current as of 2026-07-23).
  • OLRC: 26 U.S.C. § 2518 retrieved with heading and source credit; missing-section path (§ 99999) errors correctly.
  • NJSA: downloaded the actual 41 MB bulk zip, ran the real unzip → windows-1252 decode → parse pipeline: 55,452 sections across 69 titles in 1.25 s, current through P.L.2025, c.346. Spot-checked 3B:3-2 (will execution), 3B:8-1 (elective share), 3B:31-19 (UTC trust creation), 3B:5-4 (intestate shares), 46:2B-8.1 (Revised Durable POA Act), 54:34-1 (transfers taxable) - all returned clean, correctly headed text. Curly-quote decoding confirmed.

Not verified live: the Supabase write path (no live database in this environment); it uses the same supabase-js patterns as the rest of the backend and is covered by the import script's batch/abort logic.

Checklist

  • Ran the relevant build/test command for the area changed.
  • Reviewed git diff and removed unrelated changes.
  • Updated docs / env examples if setup, config, or behavior changed.
  • No secrets, API keys, real documents, or .env files committed.

Our analysis

Add statute-first estate planning research — read the full analysis →

Think the analysis missed something the PR description covers?

Capture this PR into my fork

Download a Markdown prompt that tells Claude how to port every commit in this PR into your working tree. Run it via claude -p < capture-pull-1.md from inside the repo you want the changes in.

⬇ Download capture-pull-1.md