Suggest edit — relationship-to-noos

Title

Name

Note

---
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