new file mode 100644
index 0000000..fad698d
@@ -0,0 +1,50 @@
+---
+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.
\ No newline at end of file