feat(infra): shared deps + helpers for VC capability domains#4142
feat(infra): shared deps + helpers for VC capability domains#4142Sathvik-1007 wants to merge 1 commit into
Conversation
- Cargo.toml: sqlparser, whatlang, nnnoiseless, strsim, lettre async - util.rs: uuid_v4(), now_epoch() shared helpers - about_app: UserContent privacy variant, 6 capability catalog entries - docs: capability plan + full API reference
📝 WalkthroughWalkthroughUpdates capability metadata and documentation for the Boost VC modules, adds a privacy classification and utility helpers, and adjusts dependency settings for SQL parsing, language detection, noise reduction, string similarity, and TLS mail transport. ChangesBoost VC capability foundation
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Suggested labels
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 9
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
src/openhuman/about_app/catalog_data.rs (1)
224-224: 🎯 Functional Correctness | 🟠 Major | ⚡ Quick winRestore the unrelated capability entries or remove them in their own PR.
This foundation PR is scoped to shared VC primitives, but it also drops
conversation.plan_review,intelligence.long_term_goals, andconversation.thread_goalfrom the catalog. In the supplied context there’s no matching product deprecation/removal, so the catalog will start under-reporting still-existing features.Also applies to: 363-363
🤖 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/about_app/catalog_data.rs` at line 224, The catalog in catalog_data.rs is unintentionally missing unrelated capability entries, so restore the dropped Capability items for conversation.plan_review, intelligence.long_term_goals, and conversation.thread_goal in the shared catalog data (or remove them in a separate PR if they are truly being deprecated). Update the Capability list in the catalog generation code so the existing product features remain represented and no supported capability is under-reported.
🧹 Nitpick comments (1)
src/openhuman/util.rs (1)
652-669: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winMove these helpers out of
util.rs.
src/openhuman/util.rsis now ~669 lines, and this adds more shared functionality to the root catch-all module instead of a dedicated submodule. Please relocate these helpers and re-export them if needed. Based on learnings from coding guidelines:Rust modules must be ≤ ~500 lines in sizeandNew Rust functionality must be in a dedicated subdirectory.🤖 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/util.rs` around lines 652 - 669, The shared helpers in util.rs should be moved out of the root catch-all module into a dedicated submodule to keep the module under the size guideline. Relocate uuid_v4 and now_epoch into an appropriate new module under src/openhuman/, then re-export them if existing callers rely on util::access; update any module declarations or pub use statements so voice_assistant, live_captions, and other users continue to compile without changing behavior.Source: Coding guidelines
🤖 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 `@docs/boost-vc-capability-plan.md`:
- Around line 72-73: The module list currently uses engine.rs for business
logic, which conflicts with the canonical src/openhuman/<domain>/ shape. Update
the referenced module name in the plan to ops.rs instead, and adjust the
surrounding description so the listed responsibilities align with the canonical
ops.rs role alongside rpc.rs.
- Line 12: The capability name in this plan is inconsistent with the catalog
entry: update the section header and every reference to use the canonical
“Guided Flows” name for the guided_flows capability. Locate the affected text in
the capability plan doc around the “Guided Recommendations” section and rename
it consistently throughout the related references so it matches the catalog
source.
In `@docs/VC_CAPABILITIES.md`:
- Around line 292-300: The Testing section currently presents unit and E2E
coverage as already existing, but this change does not add any test files;
update the text in VC_CAPABILITIES.md to describe these as planned or expected
tests for the full stack rather than current facts. Adjust the phrasing around
the “245+ unit tests across all modules” claim and the `cargo test --test
json_rpc_e2e` reference so they read as future/target coverage, not implemented
test evidence.
- Around line 286-287: The docs text in the capability section should not cite
unverifiable line numbers for a file that is not part of this PR. Update the
sentence referencing src/core/all.rs to remove the specific “lines 252–265”
detail and, if needed, replace it with a general reference to the controller
registry or module registration path. Also make sure the wording stays in the
correct tense and reflects the current state of the codebase.
- Around line 284-291: The Integration section in VC_CAPABILITIES.md uses
present tense for module registration and RPC availability, which conflicts with
the current PR state. Update the wording in the Integration section to future
tense or explicitly label it as the intended target state, and keep the
references to all 6 modules, src/core/all.rs, and the
openhuman.<namespace>_<function> RPC naming convention consistent with that
clarification.
- Around line 376-381: The “Security Hardening Applied” section overstates
implementation that is not present in this PR. Update the wording in
VC_CAPABILITIES.md to frame the items as planned or targeted security measures
for upcoming implementation PRs, not as already applied changes. Keep the same
bullets but change the tense/claiming language to reflect intended work, and
make sure references like sql_gen.rs, voice profile persistence, brain turn
locks, and RPC endpoint validation are clearly described as future
implementation areas rather than completed features.
In `@src/openhuman/about_app/catalog_data.rs`:
- Around line 1514-1522: The `operator_inbox.triage` privacy metadata is missing
the mailbox provider in `CapabilityPrivacy.destinations`, so the disclosed data
flow is incomplete. Update the `operator_inbox` capability entry in
`catalog_data.rs` so its `privacy` block includes the configured mail
server/provider alongside the existing backend and TinyHumans Neocortex
destinations. Keep the change localized to the `CapabilityPrivacy` construction
for this capability and ensure the `destinations` list reflects all places
message content may flow.
- Around line 1452-1538: These new Capability entries are advertising RPC
surfaces that are not actually implemented yet, so keep them from appearing as
usable until the corresponding openhuman.* methods exist. In catalog_data.rs,
update the added capability records (such as voice_assistant.session,
guided_flows.recommendation, live_captions.transcript, voice_actions.intent,
operator_inbox.triage, and chat_with_data.query) so they are not presented as
available RPC-backed features unless the matching module/controller
registrations are present. Prefer gating them behind the real implementation or
downgrading/removing the concrete how_to RPC references until the underlying
RPCs are wired up.
In `@src/openhuman/about_app/types.rs`:
- Around line 159-160: The new UserContent bucket needs to be applied
consistently across the existing user-authored outbound content entries, not
just added in the enum. Update the classification/mapping logic around
about_app::types::ContentCategory so that conversation.send_text,
conversation.send_voice, and voice.ptt are migrated from Derived to UserContent,
keeping equivalent text/audio user inputs on the same privacy surface as
UserContent.
---
Outside diff comments:
In `@src/openhuman/about_app/catalog_data.rs`:
- Line 224: The catalog in catalog_data.rs is unintentionally missing unrelated
capability entries, so restore the dropped Capability items for
conversation.plan_review, intelligence.long_term_goals, and
conversation.thread_goal in the shared catalog data (or remove them in a
separate PR if they are truly being deprecated). Update the Capability list in
the catalog generation code so the existing product features remain represented
and no supported capability is under-reported.
---
Nitpick comments:
In `@src/openhuman/util.rs`:
- Around line 652-669: The shared helpers in util.rs should be moved out of the
root catch-all module into a dedicated submodule to keep the module under the
size guideline. Relocate uuid_v4 and now_epoch into an appropriate new module
under src/openhuman/, then re-export them if existing callers rely on
util::access; update any module declarations or pub use statements so
voice_assistant, live_captions, and other users continue to compile without
changing behavior.
🪄 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: ef44d49f-b0d4-4588-bf7d-2b7031c989e8
📒 Files selected for processing (6)
Cargo.tomldocs/VC_CAPABILITIES.mddocs/boost-vc-capability-plan.mdsrc/openhuman/about_app/catalog_data.rssrc/openhuman/about_app/types.rssrc/openhuman/util.rs
| | Voice Actions | Alexa Skills, Siri Shortcuts | Utterance → controller-backed action routing | | ||
| | Operator Inbox | Front, Superhuman | Triage, draft replies, follow-up scheduling | | ||
| | Chat-with-Data | Julius AI, ChatGPT Code Interpreter | NL queries over local/connected datasets | | ||
| | Guided Recommendations | Typeform, Intercom Product Tours | Quiz-style intake flows with branching logic | |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
Align capability name with catalog: "Guided Flows", not "Guided Recommendations".
The catalog entry uses ID guided_flows with the display name "Guided Flows". Using "Guided Recommendations" in this plan doc creates an inconsistency with the canonical catalog source and risks confusing implementers. Update the section header and all references to match the catalog name.
Also applies to: 49-54
🤖 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/boost-vc-capability-plan.md` at line 12, The capability name in this
plan is inconsistent with the catalog entry: update the section header and every
reference to use the canonical “Guided Flows” name for the guided_flows
capability. Locate the affected text in the capability plan doc around the
“Guided Recommendations” section and rename it consistently throughout the
related references so it matches the catalog source.
| - `engine.rs` — business logic + state machine | ||
| - `rpc.rs` — JSON-RPC handlers |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
Use ops.rs per canonical module shape, not engine.rs.
The canonical Rust module shape for src/openhuman/<domain>/ specifies ops.rs for business logic. Listing engine.rs here contradicts that guideline and will lead to inconsistent module naming when the plan is implemented. Replace engine.rs with ops.rs and update the description to align with the canonical shape.
🤖 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/boost-vc-capability-plan.md` around lines 72 - 73, The module list
currently uses engine.rs for business logic, which conflicts with the canonical
src/openhuman/<domain>/ shape. Update the referenced module name in the plan to
ops.rs instead, and adjust the surrounding description so the listed
responsibilities align with the canonical ops.rs role alongside rpc.rs.
Source: Coding guidelines
| ## Integration | ||
|
|
||
| All 6 modules are registered in `src/core/all.rs` (lines 252–265) and are | ||
| callable over the standard JSON-RPC surface at `http://127.0.0.1:<port>/rpc` | ||
| with bearer auth. | ||
|
|
||
| RPC method naming convention: `openhuman.<namespace>_<function>` | ||
|
|
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Correct the tense or add a forward-looking note.
The Integration section states that all 6 modules "are registered" and "are callable" in present tense, but the PR objectives explicitly note that "there are no module declarations or controller registrations in this PR." This creates a factual inconsistency that could mislead readers about current implementation status.
Either rephrase to future tense ("will be registered") or add a clear note that this describes the target state, not the current implementation.
🤖 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/VC_CAPABILITIES.md` around lines 284 - 291, The Integration section in
VC_CAPABILITIES.md uses present tense for module registration and RPC
availability, which conflicts with the current PR state. Update the wording in
the Integration section to future tense or explicitly label it as the intended
target state, and keep the references to all 6 modules, src/core/all.rs, and the
openhuman.<namespace>_<function> RPC naming convention consistent with that
clarification.
| All 6 modules are registered in `src/core/all.rs` (lines 252–265) and are | ||
| callable over the standard JSON-RPC surface at `http://127.0.0.1:<port>/rpc` |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Remove or qualify the specific line number reference.
The claim "registered in src/core/all.rs (lines 252–265)" provides precise line numbers for a file that does not exist in this PR. This specificity is unverifiable and likely incorrect or copied from a different context. Remove the line numbers or replace with a general reference to the controller registry.
This compounds the issue flagged above about present-tense registration claims.
🤖 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/VC_CAPABILITIES.md` around lines 286 - 287, The docs text in the
capability section should not cite unverifiable line numbers for a file that is
not part of this PR. Update the sentence referencing src/core/all.rs to remove
the specific “lines 252–265” detail and, if needed, replace it with a general
reference to the controller registry or module registration path. Also make sure
the wording stays in the correct tense and reflects the current state of the
codebase.
| ## Testing | ||
|
|
||
| 245+ unit tests across all modules. Each module has: | ||
| - Schema registration tests (handlers match schemas, correct namespace) | ||
| - Engine logic tests (happy path + error cases) | ||
| - Type serialization round-trip tests | ||
|
|
||
| E2E: `cargo test --test json_rpc_e2e` | ||
|
|
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Rephrase test claims as planned rather than existing.
The Testing section asserts "245+ unit tests across all modules" and a specific E2E test command as present fact, but this PR contains no test files. This misrepresents the current state and could mislead readers about testability.
Rephrase to indicate these are planned/expected tests for the full stack, not currently implemented.
🤖 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/VC_CAPABILITIES.md` around lines 292 - 300, The Testing section
currently presents unit and E2E coverage as already existing, but this change
does not add any test files; update the text in VC_CAPABILITIES.md to describe
these as planned or expected tests for the full stack rather than current facts.
Adjust the phrasing around the “245+ unit tests across all modules” claim and
the `cargo test --test json_rpc_e2e` reference so they read as future/target
coverage, not implemented test evidence.
| ### Security Hardening Applied | ||
|
|
||
| - SQL identifiers double-quoted in all `sql_gen.rs` paths (prevents injection) | ||
| - Atomic file writes for voice profiles (write-to-tmp + rename) | ||
| - Per-session processing locks prevent concurrent brain turns | ||
| - Input validation on all RPC endpoints (required field checks) |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Rephrase security hardening claims as planned/targeted, not applied.
The "Security Hardening Applied" section uses present tense for implementation details in files that do not exist in this PR (sql_gen.rs, voice profile persistence, brain turn locks, RPC endpoint validation). This misrepresents the current state since this PR contains only documentation and shared primitives.
Rephrase to indicate these are the intended security measures for the implementation PRs, not currently applied hardening.
🤖 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/VC_CAPABILITIES.md` around lines 376 - 381, The “Security Hardening
Applied” section overstates implementation that is not present in this PR.
Update the wording in VC_CAPABILITIES.md to frame the items as planned or
targeted security measures for upcoming implementation PRs, not as already
applied changes. Keep the same bullets but change the tense/claiming language to
reflect intended work, and make sure references like sql_gen.rs, voice profile
persistence, brain turn locks, and RPC endpoint validation are clearly described
as future implementation areas rather than completed features.
| // ── Boost VC capability foundations ───────────────────────────────────── | ||
| Capability { | ||
| id: "voice_assistant.session", | ||
| name: "Voice Assistant Sessions", | ||
| domain: "voice_assistant", | ||
| category: CapabilityCategory::Automation, | ||
| description: "Core/RPC voice session foundation with open STT/TTS adapters, transcript \ | ||
| handoff, and session status controls.", | ||
| how_to: "Start a voice session via RPC: openhuman.voice_assistant_start_session.", | ||
| status: CapabilityStatus::Beta, | ||
| privacy: Some(CapabilityPrivacy { | ||
| leaves_device: true, | ||
| data_kind: PrivacyDataKind::UserContent, | ||
| destinations: &["OpenHuman backend", "TinyHumans Neocortex"], | ||
| }), | ||
| }, | ||
| Capability { | ||
| id: "guided_flows.recommendation", | ||
| name: "Guided Recommendation Flows", | ||
| domain: "guided_flows", | ||
| category: CapabilityCategory::Automation, | ||
| description: "Core/RPC quiz and recommendation flow engine with structured answers, \ | ||
| reusable flow definitions, and recommendation output.", | ||
| how_to: "Start a flow via RPC: openhuman.guided_flows_start_flow with flow_id.", | ||
| status: CapabilityStatus::Beta, | ||
| privacy: None, | ||
| }, | ||
| Capability { | ||
| id: "live_captions.transcript", | ||
| name: "Live Caption Transcripts", | ||
| domain: "live_captions", | ||
| category: CapabilityCategory::Automation, | ||
| description: "Core/RPC transcript pipeline for caption segments, saved transcripts, \ | ||
| summaries, and meeting-note handoff.", | ||
| how_to: "Start via RPC: openhuman.live_captions_start_transcript with source.", | ||
| status: CapabilityStatus::Beta, | ||
| privacy: Some(CapabilityPrivacy { | ||
| leaves_device: true, | ||
| data_kind: PrivacyDataKind::UserContent, | ||
| destinations: &["OpenHuman backend", "TinyHumans Neocortex"], | ||
| }), | ||
| }, | ||
| Capability { | ||
| id: "voice_actions.intent", | ||
| name: "Voice Action Recognition", | ||
| domain: "voice_actions", | ||
| category: CapabilityCategory::Automation, | ||
| description: "Core/RPC voice-command recognizer that maps utterances to controller-backed \ | ||
| or skill-backed actions with visible status metadata for app callers.", | ||
| how_to: "Recognize via RPC: openhuman.voice_actions_recognize with utterance.", | ||
| status: CapabilityStatus::Beta, | ||
| privacy: Some(CapabilityPrivacy { | ||
| leaves_device: true, | ||
| data_kind: PrivacyDataKind::UserContent, | ||
| destinations: &["OpenHuman backend", "TinyHumans Neocortex"], | ||
| }), | ||
| }, | ||
| Capability { | ||
| id: "operator_inbox.triage", | ||
| name: "Operator Inbox Triage", | ||
| domain: "operator_inbox", | ||
| category: CapabilityCategory::Automation, | ||
| description: "Core/RPC operator inbox foundation with IMAP fetching, SMTP reply sending, \ | ||
| message triage, contextual draft replies, and follow-up scheduling.", | ||
| how_to: "Triage via RPC: openhuman.operator_inbox_triage_message with sender/subject/body; fetch via openhuman.operator_inbox_fetch_inbox.", | ||
| status: CapabilityStatus::Beta, | ||
| privacy: Some(CapabilityPrivacy { | ||
| leaves_device: true, | ||
| data_kind: PrivacyDataKind::UserContent, | ||
| destinations: &["OpenHuman backend", "TinyHumans Neocortex"], | ||
| }), | ||
| }, | ||
| Capability { | ||
| id: "chat_with_data.query", | ||
| name: "Chat-with-Data Analytics", | ||
| domain: "chat_with_data", | ||
| category: CapabilityCategory::Automation, | ||
| description: "Core/RPC natural-language analytics over registered datasets with \ | ||
| SQL validation, anomaly detection, trend analysis, and summaries.", | ||
| how_to: "Query via RPC: openhuman.chat_with_data_query with dataset_id and question.", | ||
| status: CapabilityStatus::Beta, | ||
| privacy: Some(CapabilityPrivacy { | ||
| leaves_device: true, | ||
| data_kind: PrivacyDataKind::UserContent, | ||
| destinations: &["OpenHuman backend", "TinyHumans Neocortex"], | ||
| }), | ||
| }, |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
Don’t mark these RPC capabilities as usable before the RPCs exist.
The new entries are Beta and their how_to text points users at concrete openhuman.* RPC methods, but the PR notes for this stack explicitly say there are no module declarations or controller registrations here yet. That makes the catalog advertise callable surfaces that this PR does not actually provide.
🤖 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/about_app/catalog_data.rs` around lines 1452 - 1538, These new
Capability entries are advertising RPC surfaces that are not actually
implemented yet, so keep them from appearing as usable until the corresponding
openhuman.* methods exist. In catalog_data.rs, update the added capability
records (such as voice_assistant.session, guided_flows.recommendation,
live_captions.transcript, voice_actions.intent, operator_inbox.triage, and
chat_with_data.query) so they are not presented as available RPC-backed features
unless the matching module/controller registrations are present. Prefer gating
them behind the real implementation or downgrading/removing the concrete how_to
RPC references until the underlying RPCs are wired up.
| description: "Core/RPC operator inbox foundation with IMAP fetching, SMTP reply sending, \ | ||
| message triage, contextual draft replies, and follow-up scheduling.", | ||
| how_to: "Triage via RPC: openhuman.operator_inbox_triage_message with sender/subject/body; fetch via openhuman.operator_inbox_fetch_inbox.", | ||
| status: CapabilityStatus::Beta, | ||
| privacy: Some(CapabilityPrivacy { | ||
| leaves_device: true, | ||
| data_kind: PrivacyDataKind::UserContent, | ||
| destinations: &["OpenHuman backend", "TinyHumans Neocortex"], | ||
| }), |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
Include the mailbox provider in operator_inbox.triage privacy metadata.
This description covers IMAP fetch plus SMTP reply sending, but the disclosure only lists the LLM/backend path. That under-reports where message content can flow; the configured mail server/provider needs to appear in destinations as well.
🤖 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/about_app/catalog_data.rs` around lines 1514 - 1522, The
`operator_inbox.triage` privacy metadata is missing the mailbox provider in
`CapabilityPrivacy.destinations`, so the disclosed data flow is incomplete.
Update the `operator_inbox` capability entry in `catalog_data.rs` so its
`privacy` block includes the configured mail server/provider alongside the
existing backend and TinyHumans Neocortex destinations. Keep the change
localized to the `CapabilityPrivacy` construction for this capability and ensure
the `destinations` list reflects all places message content may flow.
| /// User-generated content (audio, text, queries) sent to cloud LLM for inference. | ||
| UserContent, |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
Backfill UserContent on the existing text/audio capabilities.
Adding this bucket here without migrating the already-shipped conversation.send_text, conversation.send_voice, and voice.ptt entries leaves the same outbound user-authored content split across Derived and UserContent. That will make the privacy surface inconsistent for equivalent data flows.
🤖 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/about_app/types.rs` around lines 159 - 160, The new UserContent
bucket needs to be applied consistently across the existing user-authored
outbound content entries, not just added in the enum. Update the
classification/mapping logic around about_app::types::ContentCategory so that
conversation.send_text, conversation.send_voice, and voice.ptt are migrated from
Derived to UserContent, keeping equivalent text/audio user inputs on the same
privacy surface as UserContent.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 0fb703082b
ℹ️ 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".
| category: CapabilityCategory::Automation, | ||
| description: "Core/RPC voice session foundation with open STT/TTS adapters, transcript \ | ||
| handoff, and session status controls.", | ||
| how_to: "Start a voice session via RPC: openhuman.voice_assistant_start_session.", |
There was a problem hiding this comment.
Register VC RPCs before advertising them
This and the following five Boost VC entries are added as Beta capabilities with how_to strings for openhuman.voice_assistant_start_session, openhuman.guided_flows_start_flow, etc., but I checked src/core/all.rs's controller registry and a repo-wide rg; none of these namespaces/controllers exist outside the docs/catalog. Any about_app/search/privacy consumer will show usable RPC-backed features that currently return unknown-method errors, so keep them docs-only/ComingSoon or land the controllers before cataloging them.
Useful? React with 👍 / 👎.
| /// Non-sensitive metadata (capability ids, feature flags, settings shape). | ||
| Metadata, | ||
| /// User-generated content (audio, text, queries) sent to cloud LLM for inference. | ||
| UserContent, |
There was a problem hiding this comment.
Add UI handling for user_content privacy
This new variant serializes as user_content, and the added catalog entries immediately emit it. The frontend client still defines PrivacyDataKind as only raw | derived | credentials | diagnostics | metadata, and PrivacyPanel has no label or badge mapping fallback for the new value, so Settings → Privacy renders these rows with an empty, unstyled data-kind badge. Please update the TS union, translations, and badge mapping when adding this wire value.
Useful? React with 👍 / 👎.
| # version pin and the import isn't an unstable transitive surface. | ||
| aho-corasick = "1.1" | ||
| walkdir = "2" | ||
| sqlparser = "0.62" |
There was a problem hiding this comment.
Commit the lockfile updates for new Rust deps
Adding new direct dependencies here requires the tracked root Cargo.lock to move with the manifest; the current lock entry for openhuman still lacks sqlparser, whatlang, and nnnoiseless (only strsim was already present). Any locked/reproducible build of the root crate will reject the manifest as stale, so either remove these unused deps or include the regenerated lockfile.
Useful? React with 👍 / 👎.
|
Closing — these need to be restacked properly with CI passing. Will resubmit once #4142 (shared wiring) lands and each domain PR compiles cleanly against it. |
Shared foundation for the 6 VC capability domain PRs (split from #2261).
Changes
sqlparser 0.62,whatlang 0.18,nnnoiseless 0.5,strsim 0.11, lettretokio1-rustls-tlsfeatureuuid_v4(),now_epoch()— used by all 6 domainsUserContentprivacy variant for audio/text/query dataContext
PR #2261 is being split per maintainer request. This is PR 1/7 — the shared wiring that all domain PRs will build on. Each subsequent PR adds one self-contained domain module + its
pub moddeclaration + controller registration.Validation
cargo fmt --checkpassesSummary by CodeRabbit
New Features
Documentation
Bug Fixes