Repository navigation
docs: adds documentation for IronHub - #6965
Conversation
|
Caution The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased. |
github-actions
Bot
added
scope: docs
📝 WalkthroughSummary by CodeRabbit
WalkthroughChangesIronHub documentation and CLI
Repository ignore documentation
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 4✅ Passed checks (4 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
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 @.gitignore:
- Around line 113-114: Update the .gitignore rule for the local TypeScript app
from app/ to /app/ so it only ignores the app directory at the repository root
and does not exclude nested paths such as docs/app/.
🪄 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: 497b8d7a-d33c-47ed-a86d-b812c58a148a
⛔ Files ignored due to path filters (2)
docs/zh/capabilities/skills.mdxis excluded by!docs/zh/**docs/zh/index.mdxis excluded by!docs/zh/**
📒 Files selected for processing (6)
.gitignoredocs/capabilities/skills.mdxdocs/docs.jsondocs/hub/contributing.mdxdocs/hub/installing.mdxdocs/hub/overview.mdx
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 `@docs/extensions/building-a-tool.md`:
- Line 708: Run the required documentation validation command, cd docs && mint
broken-links, before merging this change and resolve any broken-link failures it
reports.
🪄 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: 65e4079d-b801-43ac-837f-b4b3c65cebc4
📒 Files selected for processing (1)
docs/extensions/building-a-tool.md
elliotBraem
changed the title
thisisjoshford
left a comment
thisisjoshford
left a comment
There was a problem hiding this comment.
Overlaps #6970 — decide the order before merging either
These two PRs share commits ab3fe80c5 and 6fbdd78a4, and both add docs/hub/{overview,installing,contributing}.mdx, the same docs.json nav group, and the same ClawHub→IronHub renames. They will conflict. Worth deciding whether this one lands first and #6970 rebases onto it, or this gets folded in and closed.
That ordering matters for a specific reason: #6970 already contains fixes for two defects that are still live here — the .gitignore anchor (below) and the manifest-format wording. If this merges first, make sure those survive the rebase rather than getting reverted.
Blocking
1. .gitignore app/ silently ignores new WebUI frontend files
app/ is unanchored, so it matches a directory named app at any depth — including crates/ironclaw_webui/frontend/src/app/, which has 7 tracked files today and is actively developed.
Demonstrated rather than assumed — appending each form to .gitignore and asking git directly:
# with `app/` (this PR)
$ git check-ignore -v crates/ironclaw_webui/frontend/src/app/new-route.tsx
.gitignore:114:app/ crates/ironclaw_webui/frontend/src/app/new-route.tsx -> IGNORED
# with `/app/` (#6970's version)
$ git check-ignore -v crates/ironclaw_webui/frontend/src/app/new-route.tsx
-> not ignored
Existing tracked files are unaffected (gitignore only governs untracked paths), so this fails silently: the next person who adds a route or component under frontend/src/app/ won't see it in git status and will push a broken build. #6970 already carries the anchored /app/ fix.
Separately — the comment says "for a local typescript app, but don't want to push with main repo." A personal working directory belongs in .git/info/exclude, not in a .gitignore every contributor inherits.
2. The trust/tool-access claim is not true on main
installing.mdx introduces:
Packages installed from IronHub are attenuated — they have reduced tool access
| IronHub install | Installed | Read-only — no shell, no file write, no HTTP |
and the PR propagates the same claim through the renames in skills.mdx ("Installed skills (from IronHub) lose access to dangerous tools", the Trust Levels table, and the installed_skills/ note) and zh/capabilities/skills.mdx.
No such mechanism exists. I checked what skill trust actually governs — every non-test consumer of SkillTrust/SkillTrustLevel, not a grep for "attenuation." The contract is stated at crates/ironclaw_loop_contracts/src/skill_context.rs:112-119: Installed = description only, no prompt content; Trusted = description plus prompt body once loaded. The second lever is activation eligibility — builtin.skill_activate → skill_activation_capability.rs:81 → activate_skills_for_run → select_named_skill_activations → .filter(|c| c.loaded.trust == SkillTrust::Trusted) (activation.rs:1394).
So Installed skills are limited in how much of their content reaches the model and whether the model can self-activate them — not in which tools they may call. The old tool-ceiling wording predates this PR (it's inherited from the ClawHub text), but this PR restates it in a new page and carries it into three more places, so it's worth correcting here rather than propagating.
Should fix
overview.mdx says tools are "WASM binary + capability manifest (JSON)". Extension manifests are TOML — 19 manifest.toml files in the tree. The only two manifest.json files are skills/portfolio/widget/manifest.json (a skill widget, not an extension) and an LLM-trace test fixture; the legacy capabilities.json format is at zero occurrences on main. #6970 already corrects this to "TOML, manifest.toml".
Provenance table is missing Private. IronHubProvenance (crates/ironclaw_extension_manager/src/ironhub/model.rs:41-50) has five variants: Official, Trusted, Verified, Private, New. The table lists four. Private and its --private-manifest-url-file flag arrived with the org-scoped manifest work (#6780).
--acknowledge-unverified is never named. installing.mdx describes the gate but not the flag that satisfies it. The gate is catalog.rs:121 — if provenance.is_community_unverified() && !options.acknowledge_unverified — and the flag is declared at ironhub.rs:75. As written, a reader who follows the install examples onto a New entry hits the error with no documented way through.
Verified correct — no change needed
Checked against code rather than waved through:
- "The agent cannot install them autonomously" is accurate, and it's the security-relevant claim on the page, so worth stating that it holds: the agent-facing capability path hardcodes
acknowledge_unverified: false(ironhub/capabilities.rs:200), and the gate above rejects community-unverified installs without it. Only the operator's CLI flag can set it. - CLI surface —
search/list/info/install,--kind tool|skill,--force,--expected-version,--expected-artifact-digestall match the clap definitions incrates/ironclaw_reborn_cli/src/commands/ironhub.rs. skill_installis still a real model-callable tool on main (builtin.skill_install,first_party_tools/skill_management.rs:30), so the Trust Levels reference to it is accurate.- Install destination —
~/.ironclaw/installed_skills/<name>/matchescrates/ironclaw_skills/src/types.rs:69.
One release-timing note
ironhub appears in 0 *.rs/*.toml files at the ironclaw-v1.0.0 tag and 51 on main. Everything documented here ships after 1.0.0, so a reader who installs the current release and runs ironclaw ironhub search github gets an unknown-subcommand error. Not a blocker for merging to main — but docs.ironclaw.com publishes from the default branch, so it's worth a deliberate call on whether the site tracks the released binary or main. Same question I raised on #6970; it only needs answering once.
Claims verified against main at f3cf3f21c: gitignore behavior via git check-ignore with each pattern applied; version counts via git grep against ironclaw-v1.0.0 restricted to *.rs/*.toml; the rest by reading the cited definitions.
- Anchor .gitignore app/ to /app/ so it doesn't silently ignore nested frontend app directories - Fix manifest format: JSON -> TOML in overview.mdx - Add missing Private provenance tier to provenance table - Replace false 'reduced tool access' claims with accurate content visibility + self-activation gating in installing.mdx and skills.mdx - Document --acknowledge-unverified flag for community entries - Add hub as visible_alias for the ironhub CLI subcommand
|
Resolved above comments |
|
Also resolves #6983 |
thisisjoshford
left a comment
thisisjoshford
left a comment
There was a problem hiding this comment.
Re-reviewed at 706f685 against fe20911. Five of my six content points are fixed, and fixed correctly — I re-checked each against code rather than reading the diff:
/app/is anchored, and the new comment points personal working directories at.git/info/exclude. Confirmed withgit check-ignore -v crates/ironclaw_webui/frontend/src/app/new-route.tsx→ not ignored.- Manifest format is TOML in
overview.mdx. Privateis in the provenance table, and the description is right:catalog.rs:98-105assigns it only when the install came from a private manifest source, and rejects a public entry that claims it.--acknowledge-unverifiedis named where the gate is described.- The trust rewrite in
installing.mdxandskills.mdxmatches the contract —skill_context.rs:106-119(Installed = description only; Trusted = description plus prompt body once loaded) and the.filter(|c| c.loaded.trust == SkillTrust::Trusted)activation gate.
I also ran the check CodeRabbit asked for, on this branch head:
$ cd docs && mint broken-links
success no broken links found
That one can be resolved.
Still blocking
The corrected claim survives in docs/zh/capabilities/skills.mdx
The rewrite landed only in the English page. The Chinese page still carries the mechanism that doesn't exist, in two places:
43: 按信任级别施加工具上限：安装技能默认降级为只读工具；受信任技能保留完整能力。
54:| Installed | 通过 `skill_install` 从 IronHub 安装 | 只读工具（无 shell、无文件写入、无 HTTP） |
This isn't the deferred-translation bucket — the PR edits line 54 itself for the ClawHub→IronHub rename, so the false claim is being carried forward by this diff. The net effect right now is that docs.ironclaw.com asserts a security property in Chinese that main doesn't implement, and asserts the opposite in English. The two pages should agree, and the zh column header (工具权限) needs the same content-visibility / self-activation split the English table got.
The hub alias needs to arrive with the rest of its change
fe20911 also adds visible_alias = "hub" to commands/mod.rs:40. Scoped fine — #6983 asks for exactly this — but four things travel with it:
No Rust CI ran on this PR. Checks are classify, scope, and CodeRabbit; the cargo lanes are path-filtered out by the docs-only diff, so nothing compiled it. I checked locally — cargo check -p ironclaw passes; clap derive chains the repeated attribute into .visible_alias("iron-hub").visible_alias("hub"). It works. Style nit: visible_aliases = ["iron-hub", "hub"] is the single-attribute form.
No test pins it. rg iron-hub across crates/ and tests/ returns only the declaration itself — the existing iron-hub alias isn't covered either. Since the whole point of #6983 is not breaking dashboard callers of ironclaw hub ..., an uncovered alias is one careless edit away from silently regressing the thing the issue exists to protect.
docs/reborn-binary.md:335 wasn't updated — it still reads "The command alias iron-hub is also accepted," and none of the new hub pages use the short form. The alias ships undocumented.
The PR description is now inaccurate. Security Impact says "None — docs-only change, no code or configuration behavior modified," and every Test Strategy row says "Not applicable: docs-only change." There's a CLI surface change in the diff.
Either fold the alias in properly — test, reborn-binary.md, updated PR body — or split it into its own PR against #6983 so it gets a Rust CI run. The second is cleaner and keeps this one genuinely docs-only.
One question from the last round, still open
#6970 ordering. Still open (docs/v1, last touched Aug 3) and still carrying the same docs/hub/* pages and nav group. Whichever lands second eats the conflict — worth saying now which one that is.
(Dropping my earlier docs-site-versioning question: this ships with the upcoming release, so the documented ironhub commands will exist for anyone reading the site.)
Follow-up, not this PR
The claim being corrected here still lives in three unedited places: .claude/rules/skills.md:69, CLAUDE.md:234-235 ("attenuation (trust-based tool ceiling)"), and architecture-video/src/scenes/SkillsPipelineScene.tsx:39. Once the public docs are right, the agent guidance disagrees with them — worth a small sweep so the next contributor doesn't reintroduce the wording from the rules file.
Verified at 706f685 (merge base main): gitignore via git check-ignore; alias compile via cargo check -p ironclaw with the branch's mod.rs; link check via mint broken-links in a clean worktree of the branch; the rest by reading the cited definitions.
Replace false tool-access attenuation claims with accurate content-visibility and self-activation gating — matching the English skills.mdx fix.
…tignore` Two latent CI bugs, one per lane, that #6965 is the first PR to trip. `Check production-target lints` runs `cargo clippy -p <changed package> --lib --bins`. `--lib` is a hard error on a bin-only package, so the first PR whose only changed package is `ironclaw` (crates/ironclaw_reborn_cli) dies on `no library targets found in package `ironclaw`` — exit 101, before a single lint runs. `--bins` alone is the quieter half of the same bug: on a lib-only package cargo warns `target filter `bins` specified, but no targets matched; this is a no-op` and the lane reports green having linted nothing. Cargo's default target set is already lib + bins, with tests, examples, and benches excluded, so the production-target lane needs no filter at all. `reborn_pr_test_plan.py` had no rule for root `.gitignore`, so its fail-closed arm raised `unclassified pull-request path: .gitignore` and failed the whole `Tests (Reborn)` roll-up on any PR that adds an ignore rule. It joins the decided-paths set rather than the repo-root prose set, because something does read it: Code Style filters on it for `has_code` and runs `Reject tracked files that match .gitignore`. That is the shape already recorded there for `scripts/no_panics_reborn_baseline.txt` — owned by a static check, read by no Reborn lane — and it leaves the decision in the plan's `reasons`. `validate_production_lint_targets` keeps the lane filter-free. It rejects every explicit target selector, not just the two that caused the outage: `--bin` pins a multi-bin package to one target, and `--test`/`--example`/ `--bench` and their plurals pull in what the lane exists to exclude. Flags are matched on word boundaries so `--bins` is not also reported as `--bin`, and `clippy_matrix` is checked too, since `${{ matrix.flags }}` expands into the same command. The check reads the step body rather than locating the command and parsing its arguments: a matcher is a thing to fool, and scanning has no match position to displace and no command formatting to get wrong. The trade — a command deliberately written to look inert would pass — is recorded beside the constant, along with the zero-target-package gap that is unreachable today. Verified red before the fix, green after: reverting the workflow to `--lib --bins` fails the contract; removing the `.gitignore` classification reproduces `ValueError: unclassified pull-request path: .gitignore`; unhooking the validator from `validate_workflow_texts` fails the top-level test. Suites: 30 workflow contracts, 44 planner, 6 shards. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
thisisjoshford
left a comment
thisisjoshford
left a comment
There was a problem hiding this comment.
Should be ready to merge when #7167 lands (resolving our CI bug issue)
…tignore` (nearai#7167) * fix(ci): unbreak per-package clippy on bin-only crates; classify `.gitignore` Two latent CI bugs, one per lane, that nearai#6965 is the first PR to trip. `Check production-target lints` runs `cargo clippy -p <changed package> --lib --bins`. `--lib` is a hard error on a bin-only package, so the first PR whose only changed package is `ironclaw` (crates/ironclaw_reborn_cli) dies on `no library targets found in package `ironclaw`` — exit 101, before a single lint runs. `--bins` alone is the quieter half of the same bug: on a lib-only package cargo warns `target filter `bins` specified, but no targets matched; this is a no-op` and the lane reports green having linted nothing. Cargo's default target set is already lib + bins, with tests, examples, and benches excluded, so the production-target lane needs no filter at all. `reborn_pr_test_plan.py` had no rule for root `.gitignore`, so its fail-closed arm raised `unclassified pull-request path: .gitignore` and failed the whole `Tests (Reborn)` roll-up on any PR that adds an ignore rule. It joins the decided-paths set rather than the repo-root prose set, because something does read it: Code Style filters on it for `has_code` and runs `Reject tracked files that match .gitignore`. That is the shape already recorded there for `scripts/no_panics_reborn_baseline.txt` — owned by a static check, read by no Reborn lane — and it leaves the decision in the plan's `reasons`. `validate_production_lint_targets` keeps the lane filter-free. It rejects every explicit target selector, not just the two that caused the outage: `--bin` pins a multi-bin package to one target, and `--test`/`--example`/ `--bench` and their plurals pull in what the lane exists to exclude. Flags are matched on word boundaries so `--bins` is not also reported as `--bin`, and `clippy_matrix` is checked too, since `${{ matrix.flags }}` expands into the same command. The check reads the step body rather than locating the command and parsing its arguments: a matcher is a thing to fool, and scanning has no match position to displace and no command formatting to get wrong. The trade — a command deliberately written to look inert would pass — is recorded beside the constant, along with the zero-target-package gap that is unreachable today. Verified red before the fix, green after: reverting the workflow to `--lib --bins` fails the contract; removing the `.gitignore` classification reproduces `ValueError: unclassified pull-request path: .gitignore`; unhooking the validator from `validate_workflow_texts` fails the top-level test. Suites: 30 workflow contracts, 44 planner, 6 shards. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(ci): reject edits that run the production lint and discard its verdict From review: the contract checked which flags the lint passes but not whether anyone reads its exit status. `|| true`, `|| :`, `set +e`, and a step-level `continue-on-error: true` all leave the lane running clippy and ignoring the result — the silent-green failure the whole contract exists to prevent. These are worth catching where a disguised command is not. Each is a plausible edit made on purpose and for a stated reason — unblock the queue, quiet a flaky lane — rather than an attempt to fool a validator, and the check is a substring scan over the same step body, so it adds no matcher to bypass. The `echo cargo clippy` case raised alongside it stays out of scope for the reason recorded beside the constant: it requires deliberate disguise in a file that only changes through reviewed PRs, and chasing it is what grew the previous parser through three bypasses. Verified: removing the check fails all four sabotage cases. --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
Note GitHub couldn't provide a complete incremental comparison for this pull request, so CodeRabbit is performing a full review instead. This review may take a little longer. |
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 `@docs/hub/installing.mdx`:
- Line 6: Update the installation guidance in the package overview and
chat-install sections to limit agent-assisted installs to provenance tiers
eligible for chat approval. Explicitly direct New packages to the CLI path using
the documented --acknowledge-unverified option, and ensure the CLI-only
limitation is consistent across all referenced sections.
🪄 Autofix
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: eeee344c-579e-4e83-97c5-a2fb11befbf6
⛔ Files ignored due to path filters (5)
docs/zh/capabilities/skills.mdxis excluded by!docs/zh/**docs/zh/hub/contributing.mdxis excluded by!docs/zh/**docs/zh/hub/installing.mdxis excluded by!docs/zh/**docs/zh/hub/overview.mdxis excluded by!docs/zh/**docs/zh/index.mdxis excluded by!docs/zh/**
📒 Files selected for processing (10)
.gitignorecrates/ironclaw_reborn_cli/src/commands/mod.rscrates/ironclaw_reborn_cli/tests/smoke.rsdocs/capabilities/skills.mdxdocs/docs.jsondocs/extensions/building-a-tool.mddocs/hub/contributing.mdxdocs/hub/installing.mdxdocs/hub/overview.mdxdocs/reborn-binary.md
Co-authored-by: Josh Ford <thisisjoshford@gmail.com>
Head branch was pushed to by a user without write access
0a5551c
Co-authored-by: Josh Ford <thisisjoshford@gmail.com>
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/hub/installing.mdx (1)
84-88: 🗄️ Data Integrity & Integration | 🟡 Minor | ⚡ Quick winUpdate the Reborn install destination documentation.
installed_skillsdoes not match the Reborn install/discovery path; Reborn uses the WebUI Extensions flow and discovers packages under/system/extensions/<extension-id>/manifest.toml. State the legacy-versus-Reborn scope or replace line 86 with the documented Reborn destination.🤖 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/hub/installing.mdx` around lines 84 - 88, Update the installation destination table in the relevant documentation to reflect Reborn’s WebUI Extensions flow: replace the Skills destination with /system/extensions/<extension-id>/manifest.toml, or explicitly label the existing ~/.ironclaw/installed_skills/<name>/ path as legacy and scope it accordingly.Source: Learnings
🤖 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/hub/installing.mdx`:
- Around line 84-88: Update the installation destination table in the relevant
documentation to reflect Reborn’s WebUI Extensions flow: replace the Skills
destination with /system/extensions/<extension-id>/manifest.toml, or explicitly
label the existing ~/.ironclaw/installed_skills/<name>/ path as legacy and scope
it accordingly.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 452c96f0-aad3-4694-a082-1a10b54d9c28
⛔ Files ignored due to path filters (1)
docs/zh/hub/installing.mdxis excluded by!docs/zh/**
📒 Files selected for processing (1)
docs/hub/installing.mdx
|
Note GitHub couldn't provide a complete incremental comparison for this pull request, so CodeRabbit is performing a full review instead. This review may take a little longer. |
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 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_cli/tests/smoke.rs`:
- Around line 1066-1083: Extend the ironhub_hub_alias_resolves test to invoke
the root command with --help and assert that its stdout contains the hub token.
Keep the existing hub --help verb assertions unchanged, so the test covers both
alias resolution and root-help visibility.
In `@docs/hub/installing.mdx`:
- Around line 93-98: Update the trust explanation and comparison table in the
installation documentation to explicitly scope these statements to skills
installed from IronHub, replacing the broader “Packages” and “IronHub install”
wording. Keep tool trust and activation semantics separate from the skill
prompt-visibility and self-activation behavior described here.
🪄 Autofix
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: 8803cf07-74fe-46fc-99d8-4bb9b6727f4d
⛔ Files ignored due to path filters (4)
docs/zh/capabilities/skills.mdxis excluded by!docs/zh/**docs/zh/hub/contributing.mdxis excluded by!docs/zh/**docs/zh/hub/installing.mdxis excluded by!docs/zh/**docs/zh/hub/overview.mdxis excluded by!docs/zh/**
📒 Files selected for processing (8)
.gitignorecrates/ironclaw_cli/src/commands/mod.rscrates/ironclaw_cli/tests/smoke.rsdocs/docs.jsondocs/extensions/building-a-tool.mddocs/hub/installing.mdxdocs/hub/overview.mdxdocs/reborn-binary.md
| #[test] | ||
| fn ironhub_hub_alias_resolves() { | ||
| let output = Command::new(reborn_bin()) | ||
| .arg("hub") | ||
| .arg("--help") | ||
| .output() | ||
| .expect("ironclaw hub --help should run"); | ||
|
|
||
| assert!( | ||
| output.status.success(), | ||
| "stderr: {}", | ||
| String::from_utf8_lossy(&output.stderr) | ||
| ); | ||
| let stdout = String::from_utf8_lossy(&output.stdout); | ||
| for verb in ["search", "list", "info", "install"] { | ||
| assert!(stdout.contains(verb), "missing `{verb}` verb: {stdout}"); | ||
| } | ||
| } |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win
Cover the visibility contract.
This test proves that hub resolves and exposes the IronHub verbs. It does not prove that hub remains listed in the root --help output. Changing visible_alias to a hidden alias would still pass. Add a root-help assertion for the hub token.
Proposed test extension
fn ironhub_hub_alias_resolves() {
+ let root_help = Command::new(reborn_bin())
+ .arg("--help")
+ .output()
+ .expect("ironclaw --help should run");
+ assert!(root_help.status.success());
+ let root_stdout = String::from_utf8_lossy(&root_help.stdout);
+ assert!(
+ root_stdout
+ .split(|character: char| !character.is_ascii_alphanumeric() && character != '-')
+ .any(|token| token == "hub"),
+ "missing visible `hub` alias: {root_stdout}"
+ );
+
let output = Command::new(reborn_bin())📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| #[test] | |
| fn ironhub_hub_alias_resolves() { | |
| let output = Command::new(reborn_bin()) | |
| .arg("hub") | |
| .arg("--help") | |
| .output() | |
| .expect("ironclaw hub --help should run"); | |
| assert!( | |
| output.status.success(), | |
| "stderr: {}", | |
| String::from_utf8_lossy(&output.stderr) | |
| ); | |
| let stdout = String::from_utf8_lossy(&output.stdout); | |
| for verb in ["search", "list", "info", "install"] { | |
| assert!(stdout.contains(verb), "missing `{verb}` verb: {stdout}"); | |
| } | |
| } | |
| #[test] | |
| fn ironhub_hub_alias_resolves() { | |
| let root_help = Command::new(reborn_bin()) | |
| .arg("--help") | |
| .output() | |
| .expect("ironclaw --help should run"); | |
| assert!(root_help.status.success()); | |
| let root_stdout = String::from_utf8_lossy(&root_help.stdout); | |
| assert!( | |
| root_stdout | |
| .split(|character: char| !character.is_ascii_alphanumeric() && character != '-') | |
| .any(|token| token == "hub"), | |
| "missing visible `hub` alias: {root_stdout}" | |
| ); | |
| let output = Command::new(reborn_bin()) | |
| .arg("hub") | |
| .arg("--help") | |
| .output() | |
| .expect("ironclaw hub --help should run"); | |
| assert!( | |
| output.status.success(), | |
| "stderr: {}", | |
| String::from_utf8_lossy(&output.stderr) | |
| ); | |
| let stdout = String::from_utf8_lossy(&output.stdout); | |
| for verb in ["search", "list", "info", "install"] { | |
| assert!(stdout.contains(verb), "missing `{verb}` verb: {stdout}"); | |
| } | |
| } |
🤖 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 `@crates/ironclaw_cli/tests/smoke.rs` around lines 1066 - 1083, Extend the
ironhub_hub_alias_resolves test to invoke the root command with --help and
assert that its stdout contains the hub token. Keep the existing hub --help verb
assertions unchanged, so the test covers both alias resolution and root-help
visibility.
| Packages installed from IronHub have **Installed** trust — the model sees the skill description but not its full prompt body, and the agent cannot self-activate them. Skills you place directly in your skills directory have **Trusted** trust — the full prompt body is loaded and the agent can activate them autonomously. | ||
|
|
||
| | Source | Trust | Tool access | | ||
| |-----------------------------------------------|-----------|---------------------------------------------------| | ||
| | `~/.ironclaw/skills/` or workspace `skills/` | Trusted | Full — same access as the agent | | ||
| | IronHub install | Installed | Read-only — no shell, no file write, no HTTP | | ||
| | Source | Trust | Content visibility | Model self-activation | | ||
| |-----------------------------------------------|-----------|---------------------------------------------|-----------------------| | ||
| | `~/.ironclaw/skills/` or workspace `skills/` | Trusted | Full prompt body available to the model | Yes | | ||
| | IronHub install | Installed | Description only — full body not injected | No | |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Separate skill and tool trust semantics.
Lines 82-87 state that IronHub tools become active immediately after installation. Lines 93-98 use Packages and IronHub install while describing skill prompt visibility and skill self-activation. This conflates tools with skills. Scope the paragraph and row to IronHub-installed skills, or add a separate tool row with its actual trust and invocation behavior.
Minimal wording fix
-Packages installed from IronHub have **Installed** trust — the model sees the skill description but not its full prompt body, and the agent cannot self-activate them.
+Skills installed from IronHub have **Installed** trust — the model sees the skill description but not its full prompt body, and the agent cannot self-activate them.
...
-| IronHub install | Installed | Description only — full body not injected | No |
+| IronHub skill install | Installed | Description only — full body not injected | No |📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| Packages installed from IronHub have **Installed** trust — the model sees the skill description but not its full prompt body, and the agent cannot self-activate them. Skills you place directly in your skills directory have **Trusted** trust — the full prompt body is loaded and the agent can activate them autonomously. | |
| | Source | Trust | Tool access | | |
| |-----------------------------------------------|-----------|---------------------------------------------------| | |
| | `~/.ironclaw/skills/` or workspace `skills/` | Trusted | Full — same access as the agent | | |
| | IronHub install | Installed | Read-only — no shell, no file write, no HTTP | | |
| | Source | Trust | Content visibility | Model self-activation | | |
| |-----------------------------------------------|-----------|---------------------------------------------|-----------------------| | |
| | `~/.ironclaw/skills/` or workspace `skills/` | Trusted | Full prompt body available to the model | Yes | | |
| | IronHub install | Installed | Description only — full body not injected | No | | |
| Skills installed from IronHub have **Installed** trust — the model sees the skill description but not its full prompt body, and the agent cannot self-activate them. Skills you place directly in your skills directory have **Trusted** trust — the full prompt body is loaded and the agent can activate them autonomously. | |
| | Source | Trust | Content visibility | Model self-activation | | |
| |-----------------------------------------------|-----------|---------------------------------------------|-----------------------| | |
| | `~/.ironclaw/skills/` or workspace `skills/` | Trusted | Full prompt body available to the model | Yes | | |
| | IronHub skill install | Installed | Description only — full body not injected | No | |
🤖 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/hub/installing.mdx` around lines 93 - 98, Update the trust explanation
and comparison table in the installation documentation to explicitly scope these
statements to skills installed from IronHub, replacing the broader “Packages”
and “IronHub install” wording. Keep tool trust and activation semantics separate
from the skill prompt-visibility and self-activation behavior described here.
…tignore` (nearai#7167) * fix(ci): unbreak per-package clippy on bin-only crates; classify `.gitignore` Two latent CI bugs, one per lane, that nearai#6965 is the first PR to trip. `Check production-target lints` runs `cargo clippy -p <changed package> --lib --bins`. `--lib` is a hard error on a bin-only package, so the first PR whose only changed package is `ironclaw` (crates/ironclaw_reborn_cli) dies on `no library targets found in package `ironclaw`` — exit 101, before a single lint runs. `--bins` alone is the quieter half of the same bug: on a lib-only package cargo warns `target filter `bins` specified, but no targets matched; this is a no-op` and the lane reports green having linted nothing. Cargo's default target set is already lib + bins, with tests, examples, and benches excluded, so the production-target lane needs no filter at all. `reborn_pr_test_plan.py` had no rule for root `.gitignore`, so its fail-closed arm raised `unclassified pull-request path: .gitignore` and failed the whole `Tests (Reborn)` roll-up on any PR that adds an ignore rule. It joins the decided-paths set rather than the repo-root prose set, because something does read it: Code Style filters on it for `has_code` and runs `Reject tracked files that match .gitignore`. That is the shape already recorded there for `scripts/no_panics_reborn_baseline.txt` — owned by a static check, read by no Reborn lane — and it leaves the decision in the plan's `reasons`. `validate_production_lint_targets` keeps the lane filter-free. It rejects every explicit target selector, not just the two that caused the outage: `--bin` pins a multi-bin package to one target, and `--test`/`--example`/ `--bench` and their plurals pull in what the lane exists to exclude. Flags are matched on word boundaries so `--bins` is not also reported as `--bin`, and `clippy_matrix` is checked too, since `${{ matrix.flags }}` expands into the same command. The check reads the step body rather than locating the command and parsing its arguments: a matcher is a thing to fool, and scanning has no match position to displace and no command formatting to get wrong. The trade — a command deliberately written to look inert would pass — is recorded beside the constant, along with the zero-target-package gap that is unreachable today. Verified red before the fix, green after: reverting the workflow to `--lib --bins` fails the contract; removing the `.gitignore` classification reproduces `ValueError: unclassified pull-request path: .gitignore`; unhooking the validator from `validate_workflow_texts` fails the top-level test. Suites: 30 workflow contracts, 44 planner, 6 shards. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(ci): reject edits that run the production lint and discard its verdict From review: the contract checked which flags the lint passes but not whether anyone reads its exit status. `|| true`, `|| :`, `set +e`, and a step-level `continue-on-error: true` all leave the lane running clippy and ignoring the result — the silent-green failure the whole contract exists to prevent. These are worth catching where a disguised command is not. Each is a plausible edit made on purpose and for a stated reason — unblock the queue, quiet a flaky lane — rather than an attempt to fool a validator, and the check is a substring scan over the same step body, so it adds no matcher to bypass. The `echo cargo clippy` case raised alongside it stays out of scope for the reason recorded beside the constant: it requires deliberate disguise in a file that only changes through reviewed PRs, and chasing it is what grew the previous parser through three bypasses. Verified: removing the check fails all four sabotage cases. --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
* init gitignore * ironhub docs * add to building a tool * fix: address PR review feedback for IronHub docs - Anchor .gitignore app/ to /app/ so it doesn't silently ignore nested frontend app directories - Fix manifest format: JSON -> TOML in overview.mdx - Add missing Private provenance tier to provenance table - Replace false 'reduced tool access' claims with accurate content visibility + self-activation gating in installing.mdx and skills.mdx - Document --acknowledge-unverified flag for community entries - Add hub as visible_alias for the ironhub CLI subcommand * fix: correct trust claims in Chinese skills docs to match English Replace false tool-access attenuation claims with accurate content-visibility and self-activation gating — matching the English skills.mdx fix. * docs: add Chinese translations for IronHub hub pages Translate overview.mdx, installing.mdx, and contributing.mdx to Simplified Chinese. Content reflects the corrected trust claims (content-visibility and self-activation gating), TOML manifest format, Private provenance tier, and --acknowledge-unverified flag. * fix: add hub alias test, zh IronHub nav, and alias docs - Add ironhub_hub_alias_resolves smoke test verifying the 'hub' alias routes to the ironhub subcommand - Add IronHub nav group to the Chinese docs.json sidebar - Drop dead #provenance-tiers anchor on the zh contributing page - Document 'hub' as an accepted alias in reborn-binary.md * Update docs/zh/hub/installing.mdx Co-authored-by: Josh Ford <thisisjoshford@gmail.com> * Update docs/hub/installing.mdx Co-authored-by: Josh Ford <thisisjoshford@gmail.com> --------- Co-authored-by: Josh Ford <thisisjoshford@gmail.com>
3 participants
Summary
docs/hub/docs/docs.jsonsidebar, between Channels and APIdocs/capabilities/skills.mdx,docs/zh/capabilities/skills.mdx, anddocs/zh/index.mdxPrivateprovenance tier to provenance table--acknowledge-unverifiedflag for community installshubas a visible alias for theironhubCLI subcommand.gitignoreapp/to/app/to avoid silently ignoring nested frontend app directoriesdocs/zh/capabilities/skills.mdxto match the English correctionszh/) translations for all three hub pages (overview, installing, contributing)Change Type
Linked Issue
None
Validation
cargo fmt --all -- --checkcargo clippy -p ironclaw --all-targets -- -D warningscargo buildcargo test --features integrationif database-backed or integration behavior changedmint dev, validated navigation and all hub pages render correctlymint broken-links— no broken links foundTest Strategy
User behavior:
Risk areas:
Tests added or updated:
What the tests prove:
cargo clippy -p ironclawpasses clean;mint broken-linksconfirms zero broken links.Commands run:
mint validate,mint dev,mint broken-links,cargo clippy -p ironclaw --all-targets -- -D warningsSecurity Impact
None — documentation fix and one-line clap alias addition. No trust-bearing types, secrets, or runtime behavior modified.
Reborn Trust-Boundary Checklist
N/A — documentation + clap alias change. No trust-bearing types, prompts, hashes, serialization, queues, errors, or sandbox boundaries modified.
serde(default)fields fail closed or have migration tests.Transient,Permanent,Misconfigured,PolicyDeniedor equivalent).Database Impact
None
Blast Radius
Docs site (
docs.ironclaw.com) plus one new CLI alias. If navigation or content breaks, only the IronHub sidebar group and its three pages are affected. Thehubalias is additive — existingironhubandiron-hubsubcommands are unaffected. No production code, runtime, or backend behavior changed.Rollback Plan
Revert the commit. No migration or state rollback needed.
Review Follow-Through
zh/) hub page translations included in this PRReview track: A