Estate planning: practice review, practice areas, and federal + New Jersey statutory research tools
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 backenddownloads, decodes (windows-1252), parses (~55k sections, 69 titles), batch-upserts intonjsa_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. Headingheaders,TITLE nnbanners). 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 diffand removed unrelated changes. - Updated docs / env examples if setup, config, or behavior changed.
- No secrets, API keys, real documents, or
.envfiles 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.