amal66 is rebuilding Mike around a shared workspace

This is not a new legal-AI feature, but it makes a heavily modified fork more practical to evolve.

infrastructureworkflow

amal66 has reorganised the product so its web experience, API, and shared building blocks live in a single coordinated workspace. The move touches much of the project, including deployment and developer setup, but keeps the underlying product largely intact.

The payoff is structural: work that affects more than one part of Mike can be managed together rather than maintained across disconnected areas. It is the sort of change users will not see directly, but which can make future additions, fixes, and integrations less brittle.

Teams assessing Mike as a foundation for a sustained legal product should care, because this fork is investing in maintainability before piling on more features.

So what For legal-tech teams planning to adapt Mike over time, amal66's restructuring signals a fork being prepared for longer-term product work.

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 amal66/mike, oldest first. Source extracted verbatim from the harvested git log.

SHA	Subject	Author	Date
`62f73a51`	chore(chapter-01): organize the repo into readable workspaces	Amal	2026-05-24	↗ GitHub
commit body Chapter: 01 - Repository shape. Plain-English map: Move the project from flat `backend/` and `frontend/` folders into a workspace layout: `apps/api`, `apps/web`, and shared `packages/*`. This makes the codebase easier to walk because each folder has a clear job. Why it matters: A contributor should not need private context to know where the API, web app, shared types, client package, or SDK live. The repo structure should teach the project before anyone opens a README. Principle: Make the project legible before making it bigger. Monorepos work best when each workspace owns one understandable responsibility. Precedent borrowed: The fork report showed active forks splitting concerns, adding SDK surfaces, and creating deployment-specific structure. This commit turns that pressure into a stable workspace map. Upstream base: willchen96/mike@d39f580. Original local commit: b587d63.
`be60ae90`	chore(chapter-08): give the API workspace its own project config	Amal	2026-05-24	↗ GitHub
commit body Chapter: 08 - Workspace independence. Plain-English map: Add the API package metadata, TypeScript config, and Vitest config needed for `apps/api` to build, run, and test as a clear workspace. Why it matters: After the monorepo move, each workspace needs its own local controls. A new contributor should be able to enter `apps/api` and understand its commands. Principle: Every package should be independently understandable even inside a monorepo. Precedent borrowed: Monorepo conventions used by larger TypeScript open-source projects and by forks that split Mike into clearer package boundaries. Upstream base: willchen96/mike@d39f580. Original local commit: 377d685.
`eea82f6a`	chore(chapter-09): move API source into the workspace path	Amal	2026-05-24	↗ GitHub
commit body Chapter: 09 - Physical source move. Plain-English map: Move the API implementation files from the old backend location into `apps/api` so the directory structure and package boundaries match. Why it matters: The repo should not say one thing in package metadata and another thing in its file layout. Matching structure reduces mental bookkeeping for readers. Principle: Make ownership visible in the filesystem. Precedent borrowed: The same workspace and modularization pattern introduced in Chapter 01. Upstream base: willchen96/mike@d39f580. Original local commit: d1ec379.

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-1998.md from inside the repo you want the changes in.

⬇ Download capture-thread-1998.md