Conversation
🔎 IronLoop Review StatusHead: Current reviewers:
Reviewer summaries
Recent activity
Available commands
Run metadataAdmission: webhook accepted the request and IronLoop persisted reviewer state before this projection. |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (6)
📝 WalkthroughSummary by CodeRabbit
WalkthroughAdds capability-surface vocabulary and projection plumbing across host APIs, manifest aggregation, product-adapter projection, tests, and contract documentation. ChangesCapability surface projection
Estimated code review effort: 3 (Moderate) | ~25 minutes Sequence Diagram(s)sequenceDiagram
participant ExtensionManifest
participant HostApiContract
participant ProductAdapterContract
participant ManifestSurfaceAggregator
ExtensionManifest->>HostApiContract: project host-api section
HostApiContract->>ProductAdapterContract: parse and classify section
ProductAdapterContract-->>ExtensionManifest: return Channel surface for external_channel
ExtensionManifest->>ManifestSurfaceAggregator: combine tool, host-api, and auth surfaces
ManifestSurfaceAggregator-->>ExtensionManifest: return ordered capability surfaces
Possibly related PRs
🚥 Pre-merge checks | ✅ 3 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (3 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 |
|
Warning Gemini encountered an error creating the review. You can try again by commenting |
There was a problem hiding this comment.
✅ IronLoop Review: reviewer
Review at a glance
| Verdict | Blocking | Notes | Inline | Head |
|---|---|---|---|---|
| ✅ Approved | 0 | 0 | 0 | 014e49adaa27 |
Head: 014e49adaa2705a08eaaf21240b1b9954bbd36f4
Next: No reviewer action needed.
Run details
Status: Current
Needs human: no
Needs validation: no
Summary
No concrete blocking issues found in the reviewed merge diff. The change adds capability-surface vocabulary, manifest projection, product-adapter channel projection, and focused contract coverage.
Findings
None.
Developer follow-up
After fixing this feedback:
- Push the fix to this PR branch.
- Re-run this reviewer with
@ironloopai review --agent reviewerif you only changed this reviewer's findings. - Re-run all reviewers with
@ironloopai reviewwhen the fix may affect multiple areas. - Use
@ironloopai statusto check queued/running/completed/stale/stalled state while reviewers run.
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 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 `@crates/ironclaw_extensions/tests/manifest_v2_contract.rs`:
- Around line 1624-1727: Add a retired-only auth projection regression test
because the manifest contract suite currently covers OAuth/manual-token auth
surfaces but not provider references that resolve only to
RuntimeCredentialAccountSetup::Retired. In
crates/ironclaw_extensions/tests/manifest_v2_contract.rs, add a test alongside
tool_only_manifest_projects_one_tool_surface_per_capability_and_nothing_else and
product_auth_credentials_project_one_auth_surface_per_provider_with_unioned_scopes
that builds a manifest with a provider setup resolving to Retired, then assert
capability_surfaces() returns exactly one CapabilitySurfaceDeclV2::Auth with the
expected provider and setup = Retired.
🪄 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: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: c8218b14-a74e-4902-b309-3b8f8ef3c985
📒 Files selected for processing (10)
crates/ironclaw_extensions/src/host_api/capability_provider.rscrates/ironclaw_extensions/src/lib.rscrates/ironclaw_extensions/src/v2.rscrates/ironclaw_extensions/tests/manifest_v2_contract.rscrates/ironclaw_host_api/src/lib.rscrates/ironclaw_host_api/src/surface.rscrates/ironclaw_product_adapter_registry/CLAUDE.mdcrates/ironclaw_product_adapter_registry/src/lib.rscrates/ironclaw_product_adapter_registry/tests/manifest_ingestion.rsdocs/reborn/contracts/extensions.md
Coverage ratchetReborn integration-tier coverageLine coverage (Reborn crates): 85.39% — 297181 / 348046 lines Per-crate breakdown (63 crates, lowest-covered first)
This table itself is informational and never gates the PR on its own — not the percentage, not the per-crate holes, not the 0-coverage callout. A separate coverage ratchet (dry-run until enforce=true; see tests/integration/coverage-floor.toml) can fail the build on specific configured floors. Exemptions (3 entry/entries excluded from the accounting above)
|
|
🚅 Deployed to the ironclaw-pr-5833 environment in ironclaw-ci-preview
|
014e49a to
b081db0
Compare
Introduce CapabilitySurfaceKind (tool/channel/auth + reserved trigger/file) in ironclaw_host_api and derive an order-stable capability-surface projection on ExtensionManifestV2: one tool surface per capability declaration, contract-projected section surfaces (ironclaw.product_adapter/v1 external_channel sections project the channel surface; host-native web/cli/synchronous_api sections project none), and one auth surface per distinct product-auth provider with OAuth scopes unioned. Host API contracts projecting tool/auth section surfaces fail closed - those kinds have dedicated declaration paths. The extension is the top-level product object; surfaces answer "which faces of this extension can be enabled?" without a separate channel registry and without runtime kind leaking into product taxonomy (NEA-25, stack PR 1 of unified extension surfaces). Contract: docs/reborn/contracts/extensions.md "Capability surfaces" names the pinned tests (manifest_v2_contract.rs surface block; manifest_ingestion.rs projection through the real adapter contract). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
60e98ab to
0fda67b
Compare
…#5850) Atomic roll-up of the 8-PR NEA-25 taxonomy stack onto current main. Extension is the only installable product object; tool/channel/auth are derived capability surfaces; runtime kind controls loading only; manifest projection (v2, host_api contracts) is the sole surface-discovery source of truth. The connectable-channels rail and the parallel `kind` taxonomy are removed and pinned by a zero-legacy gate. slack_bot and slack_personal are retired into one `slack` extension with bounded forward migrations. Extensions wire carries runtime + surfaces, not a conflated kind. Supersedes #5833, #5839, #5842, #5845, #5847, #5848, #5849, #5850. Conflicts with main since the train forked were reconciled preserving main's newer behavior (#5851 unified slack cleanup, #6054 get_conversation_info DM resolution, #5499 extension import, #6057 TS source conventions). provider_identity domain duplication removed; the residual is a legitimate up-layer port adapter. See the PR description for the per-PR crosswalk, resolutions, placement audit, and verification. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Summary
Stack PR 1/7 for NEA-25 (unified extension surfaces — the top-level product object is always an extension; a channel is one capability surface an extension declares, not a sibling product type).
CapabilitySurfaceKind(tool/channel/auth+ reservedtrigger/file) toironclaw_host_api— shared vocabulary besideRuntimeKind. Placement note:product_workflowdepends onhost_apibut not onironclaw_extensions, so the vocabulary lives in host_api to keep the facade layer off substrate types.ExtensionManifestV2::capability_surfaces()projection:toolsurface per capability declaration (top-level orcapability_providerprojected);HostApiManifestProjection::surfaces, origin-stamped with the owning host-API id + section path — the realironclaw.product_adapter/v1contract projectschannelforexternal_channelsections; host-nativeweb/cli/synchronous_apisections project none;authsurface per distinct product-auth provider (OAuth scopes unioned sorted-dedup; OAuth masks weaker manual-token setups; retired-only providers surface as retired rather than being dropped).tool/authsection surfaces is rejected — those kinds have dedicated declaration paths.RuntimeKindstays internal: runtime never decides surface taxonomy.docs/reborn/contracts/extensions.mdnew "Capability surfaces" section names the pinned tests (house pattern).No product behavior change: existing manifests parse unchanged; surfaces are derived read-model vocabulary consumed by the next PRs in the stack (surface discovery replaces the connectable-channels rail; Slack unifies to one
slackextension).Testing
cargo test -p ironclaw_host_api— wire-shape pin for the new enumcargo test -p ironclaw_extensions --test manifest_v2_contract— 52 pass, incl. new: tool-only projection; per-provider auth surface with unioned scopes; gmail/google-drive-shaped manifests sharing providergooglewith provider id ≠ extension id; tool+channel manifest via the real capability-provider contract + a channel-projecting contract; fail-closed tool/auth section-surface rejectioncargo test -p ironclaw_product_adapter_registry— incl. new caller-level tests throughparse_product_adapter_manifest_recordwith the real contract:external_channelsection → channel surface with origin;websection → nonecargo test -p ironclaw_architecture— boundary tests passcargo clippyon the three touched crates — clean;cargo check -p ironclaw_host_runtime -p ironclaw_reborn_composition -p ironclaw_reborn_migration --all-features— clean--features integration(no DB-shaped change; substrate parser/vocabulary only — integration harness has no seam observing a pure manifest projection)🤖 Generated with Claude Code