Phase 2 Python backend: local JWT auth, multi-model council, redline parser, MCP stub
A single "Phase 2" commit fleshes out the Python backend with four new modules. The concepts are sound - local JWT auth, concurrent multi-model analysis, DOCX tracked-changes parsing. The implementations are mostly scaffolding and stubs.
4fecd8f adds api/auth.py (SovereigntyAuth), reasoning/council.py (MultiModelCouncil), retrieval/redline_parser.py, and retrieval/mcp_connector.py, all wired into api/main.py.
SovereigntyAuth uses python-jose + bcrypt for local JWT issuance, bypassing Supabase. The framing is "zero data leaves Canadian infrastructure." The problem: SECRET_KEY = "super-secret-local-sovereignty-key-change-in-prod" is hardcoded in the source file. That's a real security issue, not a placeholder oversight - the auth endpoint at /api/v1/auth/token calls SovereigntyAuth.create_access_token({"sub": "lawyer_demo"}) with no credential validation at all, returning a token for anyone who hits it.
MultiModelCouncil is pure simulation. Both procedural_analysis and substantive_analysis are asyncio.sleep(1) returning hardcoded dicts: ["Limitation period may be expired", "Form T2 required"] and "High likelihood of Vavilov judicial review standard applying". The interface sketch is reasonable for a council pattern, but there's no actual LLM routing.
redline_parser.py admits in its own comments that proper parsing "requires diving into the lxml elements." The actual implementation does a shallow '<w:ins' in run._r.xml string check. Better than nothing, but not the same as extracting structured <w:ins>/<w:del> data from the DOCX XML tree.
The MCP connector at this stage is also a stub, later evolved into the MikeOSS_MCP_Manager covered separately.
Spotted something wrong? Or know the PR text has fresher detail than the writeup above?