Fork genesis: Python sovereignty backend grafted onto upstream TS codebase
jrklaus8 starts not by modifying willchen96/mike but by committing an entirely new Python tree alongside it. The result is a dual-stack repo where Canadian features live in a separate FastAPI service that shares a repo with the unmodified upstream Bun/Express backend.
The first commit (60a3c9c) drops a fresh Python backend/ tree: api/main.py (FastAPI 0.1.0), compliance/lso_audit.py, reasoning/prompts.py, retrieval/canlii_client.py, retrieval/citation_validator.py, a Dockerfile, docker-compose, and requirements.txt. None of this exists in upstream. The very next commit (d87b9848) merges the full willchen96 TypeScript codebase underneath it, resolving only a README conflict.
So the architecture from day one is two stacks in one repo. The Python side handles Canadian concerns: CanLII retrieval, LSO audit logging, McGill Guide citations. The TypeScript side is upstream, essentially untouched. They share no code and aren't wired together.
The lso_audit.py LSOAuditor class is illustrative of the approach: it scrubs SINs, emails, and phone numbers from text via regex before any LLM call, then writes a JSONL audit trail with a hashed lawyer_id, prompt/output lengths, and "verification_required": true. Lightweight, but shows real intent around confidentiality. The api/main.py query endpoint at this stage is a complete stub returning "R v Jordan, 2016 SCC 27" as a hardcoded citation with a 0.95 confidence score.
The key architectural fact: most "feature" commits in this fork land in the Python tree and are essentially standalone from the real app. They carry minimal upstream-merge risk but also minimal integration with upstream's actual chat, document, and auth flows.
Spotted something wrong? Or know the PR text has fresher detail than the writeup above?