amal66 stops its legal logs from remembering who touched what

A cleanup pass pulls user and document identifiers out of this fork's logs and treats activity records as sensitive data, not debugging exhaust.

complianceinfrastructure

amal66 went through the fork's logging end to end and stripped out the lines that quietly recorded which user opened which document. The team frames it as data-minimization in the GDPR sense: if a log doesn't need to know who did what, it shouldn't keep that record sitting around to be subpoenaed, breached, or audited later.

The same pass also tidied how the fork writes logs in the first place, tagging each request so a single user's actions can be traced as one trail when something goes wrong. That's the unglamorous plumbing a hosted legal service needs before it can credibly tell clients their document activity isn't leaking into operational logs.

So what Anyone weighing whether a Mike-based product is safe to run for real clients should care: this is the privacy hygiene that separates a demo from something a firm can actually deploy.

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
`bfc55399`	feat(chapter-05): add structured logs with request IDs	Amal	2026-05-24	↗ GitHub
commit body Chapter: 05 - Observability. Plain-English map: Add Pino JSON logging and attach a request ID to each request so related log lines can be traced together in production. Why it matters: Plain text logs are hard to search once many users are active. Structured logs let operators answer practical questions like "what happened during this one failed upload?" Principle: Production logs should be queryable, consistent, and tied to request context. Precedent borrowed: Upstream PR #156 and common production logging practice in hosted services. Upstream base: willchen96/mike@d39f580. Original local commit: 6f59af5.
`91f95485`	fix(chapter-06): remove console logs and avoid PII in logs	Amal	2026-05-24	↗ GitHub
commit body Chapter: 06 - Privacy-aware logging. Plain-English map: Replace ad hoc console logging with structured logger calls and remove log lines that exposed user/document activity identifiers. Why it matters: Legal-document activity is sensitive. Logs often flow to third-party systems, so they should contain only what is useful for debugging and operations. Principle: Minimize sensitive data. Treat logs as production data, not scratch paper. Precedent borrowed: Upstream PR #80 and GDPR-style data-minimization practice. Upstream base: willchen96/mike@d39f580. Original local commit: 9398be6.
`ca69fd8c`	refactor(chapter-26): bring chat tools into structured logging	Amal	2026-05-24	↗ GitHub
commit body Chapter: 26 - Sensitive-path observability. Plain-English map: Replace remaining console logging in `chatTools.ts` with the same structured Pino logger used elsewhere. Why it matters: `chatTools.ts` assembles prompts and handles model tool calls. It should have the same traceability and privacy discipline as the rest of the API. Principle: Observability conventions should be consistent, especially in sensitive code. Precedent borrowed: Upstream PR #156 and the structured logging baseline from Chapter 05. Upstream base: willchen96/mike@d39f580. Original local commit: 921ef5b.

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

⬇ Download capture-thread-586.md