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.

~/code/PROJECTS.md — ecosystem diagram
ADR-0001 — why standalone
openchat-adapter.md — a third touchpoint on shared infra