[[
wikihub
]]
Search
⌘K
Explore
People
For Agents
Sign in
Explore
People
For Agents
Sign in
@jacobcole / picortex — planning / docs/adrs/0001-standalone-project-not-noos-fork.md
Suggest edit
Cancel
Submit suggestion
Title
Name
Note
--- visibility: public --- # 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: 1. **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. 2. **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. 3. **Standalone project**, borrowing patterns but owning its own code. ## Decision **Standalone project**, hosted at `~/code/picortex/`. ## Consequences ### Positive - 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. ### Negative - 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. ### Mitigations - **Inherit-don't-re-derive rule**: see [`docs/wiki/cortex-inheritance.md`](../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`](../wiki/relationship-to-noos.md). ## Alternatives considered - **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.