Sloth-ninja gives JessicaOSS a clean bridge to Clio matters

The fork can now link a workspace to a Clio matter without turning its own database into a second practice-management system.

integrationworkflow

Sloth-ninja has completed the database groundwork for workspace-to-matter linking. JessicaOSS stores just the matter identifier and number, then relies on live reads from Clio, the legal practice-management platform, when it needs current matter details.

That is a restrained integration choice: fewer duplicated records to drift out of date, while still giving a workspace a durable connection to the matter it supports. The link is one-to-one, and it is removed automatically when the related project is purged, supporting cleaner deletion governance.

The team also checked the change against a fresh database, including access controls, duplicate prevention and deletion behaviour. It is designed to remain harmless until the migration is applied in production.

So what Legal teams using Clio should care because this creates a controlled foundation for connecting AI workspaces to active matter records.

View this fork on GitHub →

Spotted something wrong? Or know the PR text has fresher detail than the writeup above?

Commits in this thread

3 commits from Sloth-ninja/JessicaOSS, oldest first. Source extracted verbatim from the harvested git log.

SHA	Subject	Author	Date
`39e629f2`	feat(migration): add matter_workspace_links (Practice Management Task 1)	sloth-ninja	2026-08-12	↗ GitHub
commit body Creates the one stored Clio artefact for Practice Management: the id/number pair anchoring a JessicaOS workspace (a projects row) to a live Clio matter. Everything else stays a live Clio read; no matter data is persisted. project_id's on delete cascade is load-bearing for the WS8 deletion-governance purge path. Mirrored in schema.sql alongside the user_clio_connections precedent, RLS enabled, revoked from anon/authenticated. Includes the owner's own allowlist entry for 20260807_01_matter_workspace_links.sql in .claude/hooks/authorized-migrations.json (committing the owner's edit, not authoring it, per CLAUDE.md hard rule 1). The merged train's seam (lib/clio/mattersSurface.ts, userDataCleanup.ts, userDataExport.ts) already tolerates this table's absence, so this is additive-only: zero behaviour change until this migration is actually run in production. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
`c53b333a`	docs: commit the Practice Management plan doc	sloth-ninja	2026-08-12	↗ GitHub
commit body docs/superpowers/plans/2026-08-07-practice-management.md was sitting untracked in the owner's checkout, tracking Task 1 (this migration) of the Practice Management train. Committed as-is. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
`489da5e8`	docs: BUILD_LOG entry for the matter_workspace_links migration	sloth-ninja	2026-08-12	↗ GitHub
commit body Records Practice Management Task 1: scope, the load-bearing cascade FK decision, RLS/revoke posture, and the four re-run test suites' pass counts proving the pre-migration degrade direction still holds. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Capture this thread into my fork

Download a single Markdown prompt that tells Claude how to port every commit above into your working tree — adapting paths and structure to match your repo. Run it via claude -p < capture-thread-1025.md from inside the repo you want the changes in.

⬇ Download capture-thread-1025.md