CORE DIRECTORY // SYSTEM.USER.DIANA_ISMAIL

Labs by Diana — Experiments that ship.

Side projects that got out of hand. AI tools built for problems I kept tripping over — now live, now yours.

Full-StackActive

Cleanroom

MODULE_014

TECHNICAL_OVERVIEW

v1.4.0ActiveFull-Stack

Cleanroom exists for a specific moment: you have a document with sensitive content in it - client names, figures, internal codenames - and you want to paste a clean version into an LLM without doing the redaction by hand. The pipeline runs three independent detectors before showing anything to the user: regex for structured data (API keys, emails, IBANs, SSNs, addresses), a user-supplied protected-terms list, and a contextual pass from a local Ollama model (gemma4:12b-mlx) for the things regex can't catch - unannounced dates, financial figures, named individuals, medical information. Every finding defaults to hidden; there is no "keep all" shortcut, only "hide all in this category," and the user reviews each one explicitly.

The architecture is deliberately narrow: lib/parse/ normalises .docx/PDF/text into a canonical block array with block-local span offsets; lib/detect/ runs the three passes and merges them by priority; lib/rebuild/ takes the scrubbed block array and constructs a fresh, metadata-free docx.Document from scratch - export never copies into or mutates the uploaded file's container. There's no database, no auth, no persistence beyond the browser session; app/api/scan and app/api/export/docx are the only two API surfaces, and both are stateless.

The local-only guarantee is the product's actual value proposition, so it's enforced structurally rather than asserted in a README: tests/unit/security/network-guard.test.ts statically scans every production source file for network-call sites and fails the build if anything targets a non-localhost destination. Document content and findings text are never written to logs - only counts, categories, and error codes cross that boundary.

PROJECT_LEARNINGS_LOG

KEY_LEARNING_01

Every quote the local LLM returns as a "finding" is checked against the source chunk - if it doesn't exist verbatim in the original text, the finding is dropped rather than surfaced. This anti-hallucination gate exists because an LLM-generated span that sounds plausible but doesn't actually anchor to real text in the document is worse than a false negative: it would tell a user "this is safe" about content the tool never actually verified.

KEY_LEARNING_02

The "no network calls except localhost Ollama" claim is backed by a dedicated test (network-guard.test.ts) that statically scans every production source file for call sites, not a policy Diana just tries to remember to follow. A privacy tool's core promise turned out to need the same enforcement rigor as a security invariant - self-reported compliance wasn't good enough for the one claim the whole product rests on.

KEY_LEARNING_03

When the local Ollama instance is unreachable, the scan still completes with regex + protected-term findings and a visible partialScan: true banner - it never silently returns a partial result dressed up as a complete one. Treating "LLM unavailable" as a first-class UI state rather than an error path was the difference between a tool that degrades honestly and one that quietly under-detects without telling you.

Next.jsTypeScriptZodOllamaLocal LLMPrivacyDocument Processing

SYSTEM.INT // 2026 LABS_CORE v2.108.0

LATENCY: STATUS: NOMINAL