new file mode 100644
index 0000000..85549a8
@@ -0,0 +1,84 @@
+---
+visibility: public
+---
+
+# Relationship to noos
+
+## Short version
+
+**picortex is NOT a noos sub-project.** It's a separate codebase with its own auth path, SQLite, and deployment. But several noos facilities are useful and will be consumed — via the normal public API, not deep imports.
+
+## What noos offers that picortex wants
+
+| noos | picortex use | When |
+|---|---|---|
+| OAuth / SSO (`globalbr.ai/auth/authorize`) | Web UI login (non-iMessage path) | S7 |
+| User graph (contacts, follows) | Future cross-chat MCP (who am I allowed to message?) | Deferred (R6) |
+| Knowledge-graph node storage | Maybe — picortex message-log could double as graph nodes | v0.3+ |
+| `NOOS_BOT_API_KEY` pattern | picortex backend calling noos for identity checks | S7 |
+
+## What picortex keeps to itself
+
+- Canonical message log (SQLite)
+- Chat configuration (attention modes, discriminator prompts)
+- Workspace filesystem state
+- Tmux session state
+- Linq event dedup cache
+- Unix user provisioning
+
+These are **runtime** state, not **knowledge** state. noos is the knowledge system; picortex is a chat runtime. They meet at the identity boundary.
+
+## What noos already has in this space (2026-04-23)
+
+noos's existing Slack bot (`~/code/noos/src/slack/`) does some of what picortex does:
+
+- Captures messages, extracts hashtags, creates knowledge-graph nodes
+- @mentions spawn `claude --print --resume` on the server and stream tool-use back
+- Reaction handlers (stubbed)
+
+But:
+- It's Slack-only, not Linq.
+- It does not have per-chat Unix isolation.
+- It does not have a mobile-first UI attached.
+- It does not have a web terminal.
+- It's coupled to Neo4j / the noos API.
+
+If picortex ever needs Slack as a channel (probably v0.3), it could either:
+- (a) add a `SlackChannel` adapter and re-implement what noos's slack bot does, or
+- (b) have noos's Slack bot relay through picortex (noos handles Slack; picortex handles sessions).
+
+Leaning (b) long-term because it preserves separation of concerns.
+
+## Overlap with voice-assistant
+
+voice-assistant (`~/code/voice-assistant`) also has:
+- file system read/write tools
+- run_command
+- Claude Code / Codex spawning
+- Noos OAuth SSO
+- daily logs / system context / preferences
+
+voice-assistant is voice-first and its deployment is on jcortex (Hetzner). Text-first picortex is structurally different — message log, tmux, web terminal attach — but the tool surface overlaps. Possible futures:
+
+- picortex and voice-assistant co-deploy on jcortex and share the `chat-*` user space
+- voice-assistant becomes a *consumer* of picortex for text (i.e. when a voice conversation drops into text, picortex handles the session)
+- they stay separate
+
+**Decision for v0.1:** stay separate, don't worry about it. Revisit in D1.
+
+## Testing noos integration
+
+If/when picortex calls noos:
+- Use `NOOS_BOT_API_KEY` with `x-api-key` header
+- Target `https://globalbr.ai/api/*` (production) or the dev port in `~/code/noos/.env`
+- Never import from `noos/` at the module level — always HTTP.
+
+## Repo location note
+
+`~/code/noos` tracks `IdeaFlowCo/noos` (private), **not** `tmad4000/noos` (which does not exist). Verified 2026-04-23 via `git remote -v` in the local clone. If picortex ever opens a PR to noos, it's against the IdeaFlowCo org.
+
+## Related
+
+- `~/code/PROJECTS.md` — ecosystem diagram
+- [ADR-0001](../adrs/0001-standalone-project-not-noos-fork.md) — why standalone
+- [openchat-adapter.md](openchat-adapter.md) — a third touchpoint on shared infra
\ No newline at end of file