feat(about_app): add a runtime capability catalog for app discovery#267
Merged
graycyrus merged 2 commits intotinyhumansai:mainfrom Apr 2, 2026
Merged
feat(about_app): add a runtime capability catalog for app discovery#267graycyrus merged 2 commits intotinyhumansai:mainfrom
graycyrus merged 2 commits intotinyhumansai:mainfrom
Conversation
- Added a new module for the capability catalog, providing a single source of truth for user-facing features in the OpenHuman app. - Implemented functions for listing, looking up, and searching capabilities, enhancing user interaction with the app's features. - Created a structured schema for capabilities, including categories and statuses, to improve organization and accessibility. - Added comprehensive end-to-end tests to validate the functionality of the new capability catalog, ensuring robust performance and reliability. This update significantly enhances the app's ability to expose its features to users, improving overall usability and experience.
…oved instructions - Revised existing capability instructions for clarity and accuracy, enhancing user guidance on accessing features. - Introduced several new capabilities related to skills and authentication, including connections to Google, Notion, and Web3 wallets, expanding the app's functionality. - Added new settings management capabilities, allowing users to manage desktop services and clear app data, improving user control over the application. These updates significantly enhance the capability catalog, providing users with more options and clearer instructions for utilizing the app's features.
Contributor
📝 WalkthroughWalkthroughThis PR introduces a new Changes
Sequence Diagram(s)sequenceDiagram
participant Client as JSON-RPC Client
participant Server as RPC Server
participant Handler as Schema Handler
participant AboutApp as about_app Module
participant Catalog as Catalog
participant Validator as Validator
Client->>Server: POST list/lookup/search capability request
Server->>Handler: Route to about_app schema handler
Handler->>Handler: Deserialize parameters
Handler->>AboutApp: Call list_capabilities/lookup_capability/search_capabilities
AboutApp->>Catalog: Access catalog for filtered results
Catalog->>Validator: Trigger ensure_validated() (first call only)
Validator->>Validator: Validate capability IDs (uniqueness, non-empty)
Validator-->>Catalog: Return OnceLock guard
Catalog-->>AboutApp: Return filtered/searched capabilities
AboutApp-->>Handler: Return RpcOutcome with results
Handler->>Handler: Serialize to JSON
Handler-->>Server: Return JSON response
Server-->>Client: HTTP 200 with capability data
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related issues
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
🧹 Nitpick comments (3)
tests/json_rpc_e2e.rs (2)
1591-1594: Consider making the catalog size assertion more flexible.The assertion
capabilities.len() >= 40is tied to the current catalog size. If capabilities are removed or the catalog is reorganized, this test may fail unexpectedly. Consider either:
- Asserting a smaller minimum (e.g.,
>= 10) that represents a sanity check- Removing the size assertion entirely and relying on specific capability presence checks
💡 Suggested change
assert!( - capabilities.len() >= 40, + capabilities.len() >= 10, "expected large capability catalog, got: {list_result}" );🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@tests/json_rpc_e2e.rs` around lines 1591 - 1594, The fixed test should avoid a brittle hard minimum of 40 for capabilities; update the assertion around the `capabilities` length in this test (the assert! that currently uses `capabilities.len() >= 40` and references `list_result`) to either a smaller sanity threshold (e.g., `>= 10`) or remove the length assertion entirely and instead assert presence of specific expected capability entries from `capabilities` (use membership checks against known capability identifiers in the same test). Ensure you update the failure message to reference `list_result` or the specific missing capability for clearer diagnostics.
1578-1583: Optional: Extract sharedinner()helper.This helper pattern is duplicated across
billing_rpc_e2e,team_rpc_e2e, and nowabout_app_rpc_list_lookup_and_search. Consider extracting it to a shared test utility function to reduce duplication.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@tests/json_rpc_e2e.rs` around lines 1578 - 1583, The local helper function inner(outer: &Value) that returns outer.get("result").cloned().unwrap_or_else(|| outer.clone()) is duplicated across billing_rpc_e2e, team_rpc_e2e, and about_app_rpc_list_lookup_and_search; extract it to a shared test utility (e.g., tests::utils or a new tests/helpers module) as a named function like extract_result(outer: &Value) -> Value, update the three tests to import and call extract_result instead of defining inner, and run tests to ensure no name/import conflicts.src/openhuman/about_app/catalog.rs (1)
6-637: File exceeds recommended ~500 line limit but splitting may not be beneficial.At ~773 lines, this file exceeds the coding guideline of ≤500 lines per file. However, the bulk is the static
CAPABILITIESarray which is inherently verbose and benefits from being co-located with its query functions.Consider whether future growth warrants splitting (e.g., moving capabilities to a separate
capabilities_data.rs), but for now the cohesion benefit of keeping everything together outweighs the size concern.As per coding guidelines: "Prefer ≤ ~500 lines per source file; split modules when growing larger."
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/openhuman/about_app/catalog.rs` around lines 6 - 637, The file is oversized due to the large static CAPABILITIES array; extract CAPABILITIES into a new module (e.g., capabilities_data.rs) and expose it via pub (or pub(crate)) so catalog.rs can import it with mod/use; update catalog.rs to remove the inline CAPABILITIES constant and reference the moved CAPABILITIES symbol from the new module wherever it's used (ensure any functions that previously referenced CAPABILITIES still resolve, e.g., query functions in catalog.rs).
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@src/openhuman/about_app/catalog.rs`:
- Around line 6-637: The file is oversized due to the large static CAPABILITIES
array; extract CAPABILITIES into a new module (e.g., capabilities_data.rs) and
expose it via pub (or pub(crate)) so catalog.rs can import it with mod/use;
update catalog.rs to remove the inline CAPABILITIES constant and reference the
moved CAPABILITIES symbol from the new module wherever it's used (ensure any
functions that previously referenced CAPABILITIES still resolve, e.g., query
functions in catalog.rs).
In `@tests/json_rpc_e2e.rs`:
- Around line 1591-1594: The fixed test should avoid a brittle hard minimum of
40 for capabilities; update the assertion around the `capabilities` length in
this test (the assert! that currently uses `capabilities.len() >= 40` and
references `list_result`) to either a smaller sanity threshold (e.g., `>= 10`)
or remove the length assertion entirely and instead assert presence of specific
expected capability entries from `capabilities` (use membership checks against
known capability identifiers in the same test). Ensure you update the failure
message to reference `list_result` or the specific missing capability for
clearer diagnostics.
- Around line 1578-1583: The local helper function inner(outer: &Value) that
returns outer.get("result").cloned().unwrap_or_else(|| outer.clone()) is
duplicated across billing_rpc_e2e, team_rpc_e2e, and
about_app_rpc_list_lookup_and_search; extract it to a shared test utility (e.g.,
tests::utils or a new tests/helpers module) as a named function like
extract_result(outer: &Value) -> Value, update the three tests to import and
call extract_result instead of defining inner, and run tests to ensure no
name/import conflicts.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 71887676-77af-4c15-86aa-fc97f1798894
📒 Files selected for processing (8)
CLAUDE.mdsrc/core/all.rssrc/openhuman/about_app/catalog.rssrc/openhuman/about_app/mod.rssrc/openhuman/about_app/schemas.rssrc/openhuman/about_app/types.rssrc/openhuman/mod.rstests/json_rpc_e2e.rs
5 tasks
This was referenced Apr 13, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
src/openhuman/about_app/module as the machine-readable source of truth for user-facing capabilities in the desktop app.about_app.list,about_app.lookup, andabout_app.search, wired into the shared controller registry and JSON-RPC surface.about_appin sync.Problem
Solution
about_appdomain with typed capability models and a static catalog that can be queried programmatically.about_app.list,about_app.lookup, andabout_app.searchin the shared controller/schema registry so the same capability data is available over the existing JSON-RPC infrastructure.about_appas part of the feature design workflow so future user-visible changes update the catalog in the same work.Submission Checklist
app/) and/orcargo test(core) for logic you add or changeapp/test/e2e, mock backend,tests/json_rpc_e2e.rsas appropriate)//////!(Rust), JSDoc or brief file/module headers (TS) on public APIs and non-obvious modulesImpact
src/openhuman/about_app/to preserve catalog accuracy.Related
Summary by CodeRabbit
New Features
Documentation