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.
Fleet Console
MODULE_015
TECHNICAL_OVERVIEW
Fleet Console is Diana's own operations layer for running a multi-agent content and coding fleet - the tool that replaced Notion as the system of record for four specific surfaces: the LinkedIn/Labs-articles/Instagram content pipeline, and coding-agent token usage tracking. It's deliberately local-first: no hosting, no auth, a single SQLite file on the owner's machine, because the tool has exactly one user and the operational cost of running infrastructure for that isn't worth paying.
The backend is TypeScript + Drizzle ORM over SQLite, with FTS5 for full-text search. The dashboard (src/dashboard/) is a Vite + React SPA, not a Next.js app - a dev-only Vite plugin (api-plugin.ts) exposes a small REST surface directly against the Node-side data layer, so there's no separate server process to run. The content model treats content_items as a shared spine across LinkedIn, Labs articles, and Labs experiments, with Instagram split into its own table and Labs-experiment-specific fields living in a one-to-one detail table - a schema shape chosen specifically to avoid nullable-column bloat as new platforms were added.
The migration off Notion ran as a parallel-run cutover: both systems stayed live and in sync until external callers were repointed to Fleet Console, at which point the Notion phases were retired outright rather than flag-gated off. The dashboard has grown well past its original "view and edit workflow state" scope - it now also hosts a live Fleet > Repos view (reading project-index.md and every project's inventory file directly, read-only, no caching) and a Fleet > Agents view (parsing the team's roster.yaml on every request), making it a general operational window into the fleet, not just a content-pipeline tool.
PROJECT_LEARNINGS_LOG
KEY_LEARNING_01
A sync job kept treating the frozen, post-cutover Notion Content Pipeline database as authoritative - running the regular sync with a live Notion API key present overwrote already-migrated content_items rows with stale data (two real rows regressed, caught and restored by hand the same session). The fix was deleting the phase outright rather than adding a flag to gate it, because a "temporarily disabled" flag on a data-corruption path is still a data-corruption path waiting for someone to forget it's there.
KEY_LEARNING_02
A SQLite table-recreate migration failed silently - no error message, just exit code 1 - against the live database once a recreated table had foreign-key children with actual rows in them. Two independent causes stacked: the migration runtime doesn't rewrite table-qualified CHECK-constraint references during the rename the way the app's own runtime does (so CI stayed green while the live run failed), and wrapping the migration in a transaction turned a PRAGMA foreign_keys=OFF into a no-op, so the drop hit live FK constraints. The working fix was replaying the migration statement-by-statement by hand against a backup first - a recovery procedure now documented for the next migration that touches a table with FK children.
KEY_LEARNING_03
A CSS scroll()-timeline animation silently stopped playing - twice, in two separate PRs, from two unrelated causes one DOM level apart (a min-height vs height mismatch on one ancestor; an overflow: hidden on another). In both cases an ancestor element accidentally became the resolved scroll-timeline source instead of the intended container, with no console error and no visual break - the animation just never ran. Nothing in automated testing catches "the element I expected to be a scroll timeline source isn't," which is why it took two separate incidents to name the actual failure class.