Repository navigation
[codex] Add tiny.place orchestration pairing flow - #4400
Conversation
…gents graph + tiny.place DMs Claude-Session: https://claude.ai/code/session_01Mt7hgcGPT6sLcEeN1a1Vju
…r stages The tiny.place relay refuses 1:1 DMs between non-contacts (403 not_a_contact), so session identities must pair with the owner agent before envelopes flow. Claude-Session: https://claude.ai/code/session_01Mt7hgcGPT6sLcEeN1a1Vju
…etup/pairing, no per-run flags Claude-Session: https://claude.ai/code/session_01Mt7hgcGPT6sLcEeN1a1Vju
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (4)
📝 WalkthroughWalkthroughThis PR adds TinyPlace orchestration pairing and contacts RPCs, a new Brain tab UI with client wiring and tests, locale translations, and architecture/planning docs for the broader subconscious orchestration system. ChangesTinyPlace orchestration feature
Architecture and orchestration planning docs
Estimated code review effort: 4 (Complex) | ~60 minutes Suggested labels: Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Comment |
coderabbitai
Bot
added
agent
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 2bedc567a6
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 6
🧹 Nitpick comments (2)
src/openhuman/tinyplace/manifest.rs (1)
65-82: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winDuplicate route-building helpers vs.
agent_orchestration/pairing.rs.
encode_path_segmentandcontact_pathhere are functionally identical to the private helpers of the same name insrc/openhuman/agent_orchestration/pairing.rs(see context snippet:pairing.rs:331-348). Two independent implementations of contact-route construction risk silently drifting (e.g. one gets updated with new percent-encoding rules or an extra suffix case and the other doesn't), which would desync the client route contract.Consider extracting a small shared helper (e.g. in a common
tinyplace/util module reachable by both domains) for percent-encoding and/contacts/...path construction.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/openhuman/tinyplace/manifest.rs` around lines 65 - 82, The contact route helpers are duplicated between this module and the pairing logic, so route construction can drift over time. Extract the shared percent-encoding and `/contacts/...` path builder used by encode_path_segment and contact_path into a common helper module that both manifest.rs and pairing.rs call, and update both call sites to use that single implementation.src/openhuman/agent_orchestration/pairing.rs (1)
77-110: 🚀 Performance & Scalability | 🔵 Trivial | ⚡ Quick winSequential HTTP calls in
list()can be parallelized.The three tiny.place fetches (
/contacts,/contacts/requests,/contacts/stats) are independent and currently run sequentially, adding up their latencies whenever the Brain tab loads pairing state.⚡ Run the three fetches concurrently
- let contacts: Value = client - .http() - .get_agent_auth::<Value>("/contacts", &[("limit".to_string(), "100".to_string())]) - .await - .map_err(map_err)?; - let requests: Value = client - .http() - .get_agent_auth::<Value>( - "/contacts/requests", - &[("limit".to_string(), "100".to_string())], - ) - .await - .map_err(map_err)?; - let stats: Value = client - .http() - .get_agent_auth::<Value>("/contacts/stats", &[]) - .await - .map_err(map_err)?; + let (contacts, requests, stats) = tokio::try_join!( + client + .http() + .get_agent_auth::<Value>("/contacts", &[("limit".to_string(), "100".to_string())]), + client.http().get_agent_auth::<Value>( + "/contacts/requests", + &[("limit".to_string(), "100".to_string())], + ), + client.http().get_agent_auth::<Value>("/contacts/stats", &[]), + ) + .map_err(map_err)?;🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/openhuman/agent_orchestration/pairing.rs` around lines 77 - 110, The three independent tiny.place requests in `list()` are still being awaited one after another, which makes `PairingSnapshot` loading slower than necessary. Refactor the fetches in `list` to run concurrently after `client` is acquired, using the same `client.http().get_agent_auth(...)` calls for `/contacts`, `/contacts/requests`, and `/contacts/stats`, and preserve the existing `map_err(map_err)` handling for each result before constructing `PairingSnapshot`.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@app/src/components/intelligence/TinyPlaceOrchestrationTab.tsx`:
- Around line 70-91: The current chat classification in chatKindForEnvelope is
using searchText to scan free-text fields like envelope.body and
envelope.contentHint, which can misclassify ordinary session messages. Update
chatKindForEnvelope to determine the ChatKind from the structural envelope.type
field only, and stop using keyword matching on message content; if searchText is
no longer needed elsewhere in TinyPlaceOrchestrationTab, remove or repurpose it
accordingly.
In `@docs/arch-subconscious.md`:
- Around line 307-309: The example in the workflow compilation snippet uses an
in-memory checkpointer, which does not match the intended durable crash-resume
flow. Update the snippet around workflow.compile and MemorySaver to use
SqlRunLedgerCheckpointer instead, or clearly label the example as
illustrative-only if it is meant to stay non-durable. Keep the guidance aligned
with the existing workflow.compile, compiled_autonomous_harness, and
checkpointer setup so readers see the correct persistence path.
In `@docs/plans/subconscious-orchestration/stage-04-frontend-agent.md`:
- Around line 34-40: The stage-4 topology uses inconsistent guard-node naming
between the deliverables list and the routing description, so make the name
consistent throughout this plan section. Update the graph topology text in the
stage-04 frontend agent document to use a single symbol name for the guard node,
matching the rest of the node list and the conditional-edge flow in
`orchestration/graph/mod.rs`.
In `@docs/plans/subconscious-orchestration/stage-05-reasoning-orchestrator.md`:
- Around line 35-39: The compress node budget in orchestration/graph/compress.rs
is not strictly ratio-compliant because the 200-token floor can exceed the
intended input_tokens / 20 target for short traces. Update the compress logic so
the minimum budget is only applied when the source trace is large enough, and
keep the enforced output budget tied to the 20:1 ratio while preserving the
retry-once-then-truncate flow and the append/persist behavior for
compressed_history.
In `@docs/plans/subconscious-orchestration/stage-06-subconscious-steering.md`:
- Around line 42-45: The “Subconscious chat surface” step currently mentions
optionally mirroring emitted directives as a self-DM over tiny.place, which
conflicts with the offline-only contract. Update the stage-06 guidance around
the Subconscious directive publication so it only describes publishing each
emitted directive as an OrchestrationMessage with chat_kind: Subconscious, and
remove any reference to self-DM mirroring or other external effects.
In `@src/openhuman/agent_orchestration/pairing.rs`:
- Around line 254-314: The pairing store update flow in persist_record,
remove_record, load_store, and save_store can race because each call does an
unprotected read-modify-write cycle on the same pairings.json. Add a
per-workspace synchronization guard (for example a shared tokio::sync::Mutex or
equivalent file lock) and acquire it in the entry points like link_session,
accept_request, decline_request, and block_request so only one store mutation
happens at a time. Also make save_store use a unique temp file per write or keep
it inside the same locked critical section to avoid collisions on the fixed
json.tmp path.
---
Nitpick comments:
In `@src/openhuman/agent_orchestration/pairing.rs`:
- Around line 77-110: The three independent tiny.place requests in `list()` are
still being awaited one after another, which makes `PairingSnapshot` loading
slower than necessary. Refactor the fetches in `list` to run concurrently after
`client` is acquired, using the same `client.http().get_agent_auth(...)` calls
for `/contacts`, `/contacts/requests`, and `/contacts/stats`, and preserve the
existing `map_err(map_err)` handling for each result before constructing
`PairingSnapshot`.
In `@src/openhuman/tinyplace/manifest.rs`:
- Around line 65-82: The contact route helpers are duplicated between this
module and the pairing logic, so route construction can drift over time. Extract
the shared percent-encoding and `/contacts/...` path builder used by
encode_path_segment and contact_path into a common helper module that both
manifest.rs and pairing.rs call, and update both call sites to use that single
implementation.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 099a9239-5c85-4d49-8bda-6b1091715aa0
📒 Files selected for processing (36)
app/src/components/intelligence/TinyPlaceOrchestrationTab.test.tsxapp/src/components/intelligence/TinyPlaceOrchestrationTab.tsxapp/src/lib/agentworld/invokeApiClient.tsapp/src/lib/i18n/ar.tsapp/src/lib/i18n/bn.tsapp/src/lib/i18n/de.tsapp/src/lib/i18n/en.tsapp/src/lib/i18n/es.tsapp/src/lib/i18n/fr.tsapp/src/lib/i18n/hi.tsapp/src/lib/i18n/id.tsapp/src/lib/i18n/it.tsapp/src/lib/i18n/ko.tsapp/src/lib/i18n/pl.tsapp/src/lib/i18n/pt.tsapp/src/lib/i18n/ru.tsapp/src/lib/i18n/zh-CN.tsapp/src/pages/Brain.tsxdocs/arch-subconscious.mddocs/plans/subconscious-orchestration/README.mddocs/plans/subconscious-orchestration/stage-01-tinyplace-session-bridge.mddocs/plans/subconscious-orchestration/stage-02-contact-pairing.mddocs/plans/subconscious-orchestration/stage-03-core-ingest.mddocs/plans/subconscious-orchestration/stage-04-frontend-agent.mddocs/plans/subconscious-orchestration/stage-05-reasoning-orchestrator.mddocs/plans/subconscious-orchestration/stage-06-subconscious-steering.mddocs/plans/subconscious-orchestration/stage-07-rpc-and-ui.mddocs/plans/subconscious-orchestration/stage-08-testing-observability.mdsrc/core/all.rssrc/core/event_bus/events.rssrc/openhuman/agent_orchestration/mod.rssrc/openhuman/agent_orchestration/pairing.rssrc/openhuman/agent_orchestration/pairing_schemas.rssrc/openhuman/tinyplace/manifest.rssrc/openhuman/tinyplace/mod.rssrc/openhuman/tinyplace/schemas.rs
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 353cf758bc
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
docs/arch-subconscious.md (1)
66-67: 🔒 Security & Privacy | 🟠 Major | 🏗️ Heavy liftKeep a trust boundary between channel input and steering prompts.
The spec currently lets the cumulative
world_state_diff—built from external channels—flow directly into the Reasoning LLM prompt. If that diff includes user-supplied text, this becomes a prompt-injection surface and can corrupt steering. Normalize/filter it first and keep raw channel content out of the steering payload.Also applies to: 93-94
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/arch-subconscious.md` around lines 66 - 67, The graph-state documentation for Channels and the Front-End Agent should be updated to preserve a trust boundary between external channel input and steering prompts. In the relevant prose around the Channels/Front-End Agent sections, clarify that raw channel content must be normalized or filtered before it is included in any Reasoning LLM steering payload, and that only sanitized state diffs should flow into the prompt. Reference the Channels and Front-End Agent concepts consistently so the boundary is explicit wherever the world_state_diff handoff is described.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Outside diff comments:
In `@docs/arch-subconscious.md`:
- Around line 66-67: The graph-state documentation for Channels and the
Front-End Agent should be updated to preserve a trust boundary between external
channel input and steering prompts. In the relevant prose around the
Channels/Front-End Agent sections, clarify that raw channel content must be
normalized or filtered before it is included in any Reasoning LLM steering
payload, and that only sanitized state diffs should flow into the prompt.
Reference the Channels and Front-End Agent concepts consistently so the boundary
is explicit wherever the world_state_diff handoff is described.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 4a7a1d75-26f8-448a-9792-15e0a4df6205
📒 Files selected for processing (9)
app/src/components/intelligence/TinyPlaceOrchestrationTab.test.tsxapp/src/components/intelligence/TinyPlaceOrchestrationTab.tsxdocs/arch-subconscious.mddocs/plans/subconscious-orchestration/stage-04-frontend-agent.mddocs/plans/subconscious-orchestration/stage-05-reasoning-orchestrator.mddocs/plans/subconscious-orchestration/stage-06-subconscious-steering.mdsrc/core/all.rssrc/core/all_tests.rssrc/openhuman/agent_orchestration/pairing.rs
✅ Files skipped from review due to trivial changes (2)
- docs/plans/subconscious-orchestration/stage-04-frontend-agent.md
- docs/plans/subconscious-orchestration/stage-05-reasoning-orchestrator.md
🚧 Files skipped from review as they are similar to previous changes (4)
- docs/plans/subconscious-orchestration/stage-06-subconscious-steering.md
- app/src/components/intelligence/TinyPlaceOrchestrationTab.test.tsx
- app/src/components/intelligence/TinyPlaceOrchestrationTab.tsx
- src/openhuman/agent_orchestration/pairing.rs
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 42d329ca66
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| return Array.from(byId.values()).map(chat => ({ | ||
| ...chat, | ||
| active: chat.pinned ? true : isActive(chat.lastTimestamp, chat.unread), | ||
| })); |
There was a problem hiding this comment.
At this return point, byId has only been populated from data.messages and data.inboxItems; data.pairing.records is never read. When a user pastes a fresh session identity, linkSession persists a pending/linked PairingRecord before any DM or inbox item exists, then load() refreshes but the Sessions list can still remain empty, so the user cannot see or revisit the pending link they just created until a message arrives. Please add pairing records as session rows, or otherwise surface them in this tab.
Useful? React with 👍 / 👎.
1 participant
Summary
tinyplacedomain so OpenHuman can request, accept, remove, block, list, and inspect contact edges through JSON-RPC.agent_orchestrationpairing policy and local pairing store for user-consented Codex/Claude session links.Problem
403 not_a_contact.Solution
openhuman.tinyplace_contacts_*.openhuman.orchestration_pairing_*controllers that persist local pairing intent, mirror live contact status, and require explicit link/accept/block actions.OrchestrationPairingChangedevents so downstream orchestration surfaces can react to pairing updates.Submission Checklist
## Related- no coverage matrix feature IDs identified.docs/RELEASE-MANUAL-SMOKE.md) - no release smoke checklist change identified.Closes #NNNin the## Relatedsection - no issue number provided.Impact
not_a_contact.Related
AI Authored PR Metadata (required for Codex/Linear PRs)
Linear Issue
Commit & Branch
plan/subconscious-orchestration42d329ca66a5ea9f2e799a43f4a6b1e2259e880bValidation Run
pnpm --filter openhuman-app format:check(via pre-push)pnpm typecheckpnpm debug unit src/components/intelligence/TinyPlaceOrchestrationTab.test.tsx;cargo test --manifest-path Cargo.toml agent_orchestration::pairing --lib;cargo test --manifest-path Cargo.toml tinyplace::manifest::tests::contacts --lib;cargo test --manifest-path Cargo.toml schema_for_rpc_method_finds_internal_orchestration_pairing_link_session --lib;cargo test --manifest-path Cargo.toml rpc_method_from_parts_does_not_expose_internal_orchestration_pairing --libcargo fmt --manifest-path ../Cargo.toml --all --checkandcargo check --manifest-path app/src-tauri/Cargo.tomlvia pre-push; focused Rust tests listed abovecargo fmt --manifest-path app/src-tauri/Cargo.toml --all --checkandcargo check --manifest-path app/src-tauri/Cargo.tomlvia pre-pushValidation Blocked
command:N/Aerror:N/Aimpact:N/ABehavior Changes
Parity Contract
Duplicate / Superseded PR Handling
senamakel:plan/subconscious-orchestration.Summary by CodeRabbit