ADR-0001: Standalone project, not a noos or Cortex fork

Status: Accepted Date: 2026-04-23 Deciders: Jacob

Context

Three plausible homes for this work existed:

Fork Cortex (IdeaFlowCo/cortex). Cortex already implemented 90% of what picortex needs (per-chat workspaces, attention gating, scoped tokens, sharing bridge, linq-sim, HMAC webhook ingestion). This past week Cortex shipped the J1-J11 texting-bot + groups plan.
Fork the noos Slack bot (~/code/noos/src/slack/). noos already has a working Slack bot that spawns Claude Code via claude --print --resume and streams tool-use progress back. It has reaction handlers (stubbed), per-workspace config, and a Noos OAuth backbone.
Standalone project, borrowing patterns but owning its own code.

Standalone project, hosted at ~/code/picortex/.

Jacob can experiment with a substantially different isolation model (Linux users vs Docker containers) without destabilizing Cortex's production deployment.
No entanglement with Cortex's enterprise design pressures (multi-tenant, billing, workspace dashboard, Slack plugin, Linq channel plugin framework).
picortex can target iMessage-first and mobile-first without Cortex's Slack/Web dual-surface constraint.
Clear IP boundary — picortex is Jacob's personal stack; Cortex is IdeaFlowCo's product. No attribution confusion.
Noos stays focused on being the knowledge-graph + SSO identity layer; picortex doesn't drag noos's release cadence around.

Duplicates initial backend scaffolding (Fastify, auth, logger, SQLite migrations) that Cortex already has.
Risk of divergent attention-gating implementations that drift from Cortex's prompt library over time.
No shared velocity — a fix Cortex makes doesn't automatically reach picortex.

Inherit-don't-re-derive rule: see docs/wiki/cortex-inheritance.md. When picortex implements a subsystem Cortex already has, the PR must link to the Cortex file it drew from and note divergences.
Quarterly diff review: every 3 months, skim Cortex commits since last review and port anything relevant.
linq-sim is shared (lives in ~/code/cortex/cloudcli/dev-tools/linq-sim). picortex's linq-sim changes (S2 thread support) go upstream as PRs to Cortex.
noos integration deferred but kept on the table. See docs/wiki/relationship-to-noos.md.

Fork Cortex into a private tmad4000 repo and strip. Rejected — too entangled with enterprise concerns; strip would take ~1 week and the remainder would still carry Cortex's Docker-per-workspace assumption.
Extend noos-slackbot to iMessage. Rejected — noos's Slack bot is a worker inside a Noos-centric knowledge graph, not a standalone chat agent. Bolting Linq support onto it would muddle noos's identity.
Build it inside voice-assistant. Tempting (voice-assistant already has file system, run_command, Claude spawning, Noos OAuth) but voice-assistant is voice-first and its deployment is on Hetzner jcortex alongside a conversational ElevenLabs pipeline. Text-first chat logic would be a shoehorn. Revisit in D1 if Hetzner ends up the deployment target.