docs(rustdoc): quiet warning links

[Audacity88]

Summary

• Base branch: master
• What changed and why:
  • Treat the generated [channels] config section mention as code so rustdoc does not resolve it as an intra-doc link.
  • Treat private helper/type names as code spans instead of intra-doc links.
  • Keep full mdBook/localization warning cleanup out of this branch because this PR fixes only the rustdoc warning subset.
• Scope boundary: Rustdoc warning cleanup only. This PR does not claim full mdBook/localization cleanup.
• Blast radius: Documentation comments only. No runtime behavior, config parsing, CLI behavior, or generated docs pipeline behavior changes.
• Linked issue(s): Related bug(docs): clean up docs build warning noise #7269. This fixes only the rustdoc warning subset; generated CLI placeholder warnings remain separate follow-up work.
• Labels: bug, size: XS, risk: low, channel, config, runtime, skills

Validation Evidence (required)

• Commands run and tail output:

git diff --check
<no output; exit 0>

RUSTDOCFLAGS=-Dwarnings cargo doc --no-deps -p zeroclaw-config -p zeroclaw-runtime -p zeroclaw-channels
Documenting zeroclaw-runtime v0.8.1
Documenting zeroclaw-channels v0.8.1
Finished `dev` profile [unoptimized + debuginfo] target(s) in 5m 42s
Generated <target>/doc/zeroclaw_channels/index.html and 2 other files

• Beyond CI — what did you manually verify? The focused rustdoc run exercises the three touched doc surfaces: the generated config section help text, the runtime skills cache module docs, and the Discord slash-command spec docs.
• If any command was intentionally skipped, why: Full fmt, clippy, and test batteries were skipped because this PR only changes documentation comments. Full mdBook/localization validation was skipped because that warning cleanup is intentionally out of scope for this PR.

Security & Privacy Impact (required)

• New permissions, capabilities, or file system access scope? No
• New external network calls? No
• Secrets / tokens / credentials handling changed? No
• PII, real identities, or personal data in diff, tests, fixtures, or docs? No
• If any Yes, describe the risk and mitigation: None.

Compatibility (required)

• Backward compatible? Yes
• Config / env / CLI surface changed? No
• If No or Yes to either: No upgrade steps required.

Rollback (required for risk: medium and risk: high)

Low-risk PR. Roll back with git revert cf0fb0e9194ec6de72c80af8b5f69979bb845868 if needed.

[singlerider]

I checked each converted link against item visibility and the failing check.

🟢 What looks good: only the unresolvable links were downgraded

load_skills_from_directory is pub, so its intra-doc link resolves and you correctly left it as a link. load_open_skills_from_directory is a private fn, so an intra-doc link to it warns under rustdoc; converting it to a plain code span is the right fix. Same for OptionSpec (private at that doc site) and [channels], which is a config section name and never a Rust item, so the bracket link was bogus from the start. The discrimination here is exactly correct: keep the one link that resolves, downgrade the three that cannot.

🟢 What looks good: the only red check is a stale title lint, not the code

The failing main job is the PR-title Conventional Commits check, and it ran against the old title docs: quiet rustdoc warning links with no scope. The title now reads docs(rustdoc): quiet warning links, which satisfies the type(scope): description rule, so a re-run clears it. The diff itself is docs-only and sound.

Approving on the corrected title; a CI re-run will turn the title check green.

[WareWolf-MoonWall]

Reviewed head cf0fb0e. I checked the three changed doc sites against local source, confirmed item visibility for each modified link, and verified the CI check suite.

🟢 What looks good — discrimination between resolvable and private items is exact

The diff changes exactly three intra-doc links and leaves one alone. Cross-checking against local source confirms the discrimination is correct:

• load_open_skills_from_directory — confirmed fn (no pub) in crates/zeroclaw-runtime/src/skills/mod.rs. An intra-doc link to a private item at that doc site warns under RUSTDOCFLAGS=-Dwarnings; converting to a plain code span is the right call.
• OptionSpec — private at the zeroclaw-channels discord types doc site; converting to a code span is correct.
• [channels] — a TOML section name, not a Rust item. A bracket-link to it was always a false intra-doc reference; converting to a backtick inline is the right fix.
• load_skills_from_directory — confirmed pub fn in the same module. The intra-doc link resolves; leaving it as a link is correct and is what the diff does.

Three items fixed, one left as a live link: the discrimination is exact.

🟢 What looks good — scope is strictly docs-only

The diff is +3 -3 across cache.rs, sections.rs, and discord/types.rs. No runtime behaviour, config parsing, CLI surface, or generated-docs pipeline logic is touched. The blast radius is zero outside the rustdoc output.

🟢 What looks good — CI is clean

All 18 CI jobs pass on this commit. The PR view briefly showed one failing check (the PR-title Conventional Commits job from the old title docs: quiet rustdoc warning links); the title has since been corrected to docs(rustdoc): quiet warning links, and the main job now shows pass. The diff itself has been clean throughout.

🟢 What looks good — validation evidence is proportionate

The author ran RUSTDOCFLAGS=-Dwarnings cargo doc --no-deps -p zeroclaw-config -p zeroclaw-runtime -p zeroclaw-channels and confirmed zero warnings on the three touched doc surfaces. That is the right targeted command for a docs-only fix. Skipping the full format/clippy/test battery for a doc-comment-only patch is explicitly justified by the PR template guidance and is appropriate here.