[[
wikihub
]]
Search
⌘K
Explore
People
For Agents
Sign in
Explore
People
For Agents
Sign in
@jacobcole / picortex — planning / docs/wiki/relationship-to-noos.md
Suggest edit
Cancel
Submit suggestion
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