Decisions Log¶

A chronological record of major decisions made across conversations.

2026-03-27¶

Context system: Local-first with Dreamhost backup¶

Context: Choosing where to store the persistent context system Decision: Local folder on Mac as source of truth, with nightly rsync backup to Dreamhost. Google Drive sync deferred to a later phase. Rationale: Local is fastest for Claude to read/write, works offline, and is the most reliable. Dreamhost backup provides disaster recovery without adding complexity.

Context system: Markdown over database¶

Context: Choosing the format for context storage Decision: Structured markdown files in an organized folder hierarchy rather than a database or vector store. Rationale: Human-readable, portable, requires zero infrastructure, and Claude works natively with markdown. Can be migrated anywhere if needs change.

Knowledge base: Static site on Dreamhost¶

Context: How to make the knowledge base browsable beyond raw files Decision: Generate a static website using MkDocs from the same markdown files, hosted at context.rootphi.net with password protection. Rationale: One source of truth (markdown), two views (files for Claude, website for Brian). Accessible from any device.

LLM Triangulator: Shared API key vault¶

Context: How to manage API keys across multiple skills Decision: Central api-keys.json file shared by all skills rather than per-skill key storage. Rationale: Avoids duplication, single place to update keys, consistent across the toolkit.

LLM Triangulator: 7-provider architecture¶

Context: Which LLM providers to support Decision: Anthropic, OpenAI, Google, xAI, DeepSeek, Mistral, Together AI Rationale: Broad coverage across different model families for genuine triangulation.

CreativeOS architecture: Postgres + Supabase + Next.js + Vercel + Cloudflare¶

Context: Choosing the tech stack for CreativeOS, Brian's personal creative infrastructure platform Decision: Postgres (via Supabase) + Next.js + Vercel + Cloudflare + tldraw + LangGraph + n8n. Modular monolith pattern. "First tenant" productization model (build for Brian first, multi-tenant later). Rationale: Decided via 7-provider LLM triangulation (32 API calls). PostgreSQL scored 7/7 consensus. Supabase provides auth, RLS, realtime, and edge functions in one platform. Modular monolith avoids premature microservice complexity while keeping boundaries clean for later extraction.

CreativeOS Phase 1: REST over tRPC¶

Context: Whether to use tRPC or plain REST for API routes in Phase 1 Decision: Start with Next.js Route Handlers (plain REST), revisit tRPC in Phase 2. Rationale: REST is universal — n8n, mobile apps, any client can call it. tRPC adds TypeScript type safety but only works with TS clients. For Phase 1 where the priority is getting the foundation working, REST is simpler and more flexible.

CreativeOS: Mono-repo structure¶

Context: Whether to use a mono-repo or multi-repo for CreativeOS Decision: Single creativeos repo, consistent with modular monolith philosophy. Rationale: One repo keeps deployment simple, avoids cross-repo dependency management, and matches the "start simple, extract later" approach.

CreativeOS: Supabase Auth for Phase 1¶

Context: Which auth provider to use Decision: Supabase Auth for Phase 1, with option to migrate to Clerk or Auth0 later. Rationale: Already using Supabase for database and RLS — using their auth keeps everything in one platform during the foundation phase.

2026-03-28¶

CreativeOS infrastructure: GitHub + Supabase provisioned¶

Context: Setting up the actual infrastructure for CreativeOS Decision: GitHub repo bwitlin/creativeos (private) + Supabase project "creativeos" under Rootphi org (Pro plan, Micro compute, West US Oregon). Rationale: Pro plan ($25/mo) provides the features needed (RLS, extensions, reasonable compute). Micro instance is right-sized for a single-user foundation phase. Oregon region for low-latency Vercel pairing.

Session hygiene belongs in context-manager, not a separate oversight skill¶

Context: A stale mkdocs.yml was left inside claude-context/ after the canonical config was moved to ~/Documents/claude-context-mkdocs.yml. It was documented as "superseded" but never cleaned up. A system oversight skill being built in another session flagged it and asked whether it should fix it or defer to this infrastructure session. The question arose: should file hygiene checks live in a separate "system oversight" skill or in the context-manager skill itself? Decision: Add a "Session Hygiene" step to the context-manager skill's session-end lifecycle — not a separate oversight skill. Rationale: The context manager already owns the filesystem, knows what files should exist and where, and runs at session start/end. A separate oversight skill would need to duplicate all that awareness. Hygiene checks are a natural extension of the context manager's existing responsibilities. The check should: scan for stale/superseded configs, verify snapshots match installed skill files, flag orphaned references, and check for action items completed but not updated everywhere. Fix obvious issues silently, surface ambiguous ones to Brian. Action required: Update the context-manager SKILL.md to include this as step 4 in the "Session End — Auto-Save" lifecycle, then repackage the skill.