Suggest edit — 0001-standalone-project-not-noos-fork

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.