MuseLegal/AI-Legal-Platform
Fork being rebuilt as a firm-branded client portal with role-based matter access
MuseLegal is repositioning the upstream legal-AI assistant as a productized law-firm portal. The recorded activity covers two architectural moves: an explicit authorization model for matter-scoped resources, and a public marketing landing page that splits the app into three distinct surfaces - public site, client portal, and attorney back office.
The access control work is the more substantial piece. A new matter_participants join table, Supabase RLS policies on six tables, and mirrored TypeScript helpers in access.ts together enforce role-based matter isolation at both the database and application tiers. The public landing page commit completes the structural framing by replacing the upstream root redirect with a firm-branded entry point that routes clients to /portal and attorneys to /assistant.
This fork is diverging from the upstream product identity. It presupposes a matters schema, a custom JWT role claim, and a client-portal data model that don't exist upstream.
What's in it
- Law firm storefront A public landing page positions the product as a law firm's website (Johnson Law) rather than as an AI tool. The AI lives behind the front door, not on it.
- Role-based access for clients, attorneys, and paralegals Each persona gets a distinct key to the building. What a client sees is not what a paralegal sees, and neither sees what an attorney sees.
- Matter-level visibility Access is scoped per matter via a participants model - you see the matters and documents you're explicitly attached to, and nothing else.
- Database-enforced permissions Who can see what is a hard rule at the data layer, not a frontend convention. The UI can't accidentally leak a matter to the wrong user.
Direction
personasmulti-tenantbranding
Activity
MuseLegal ↗ analysis ↗ GitHub Threads of work (detailed view)
MuseLegal puts a real law firm's face on the front door
The fork stops dumping every visitor straight into the AI assistant and builds a proper firm-branded entrance instead.
Root page replaced with a public law firm marketing site
MuseLegal's fork drops the `/assistant` redirect that was the upstream root and replaces it with a full marketing page for a fictional "Johnson Law" firm - separating the public entry point from two distinct authenticated routes: `/portal` for clients and `/assistant` for attorneys.
MuseLegal locks down who can see which matter
The fork adds real access control to a platform that previously had none enforced at the data layer.
Matter-participant access model replaces implicit ownership for portal resources
MuseLegal rewrites portal authorization around an explicit many-to-many `matter_participants` join, enforced at both the database (Supabase RLS) and application tiers. This is infrastructure groundwork for a client-portal product layer sitting on top of the upstream assistant.
MuseLegal locks every matter down to its assigned people
The fork bolts real per-matter access control onto a client portal that previously leaned on ownership and hidden buttons to keep people out.
Add matter_participants table and RLS policies for portal access control
MuseLegal replaces implicit matter ownership with an explicit participants model: a new join table, two SQL helper functions, and Supabase RLS policies covering six portal tables. TypeScript helpers in `access.ts` mirror the database check at the application tier.
Pull requests (detailed view)
✅ Merged (1)
MuseLegal · opened 3mo ago · merged 3mo ago by MuseLegal