[rust-guard] Rust Guard: Downscope 5 `pub` functions in tools.rs to `pub(crate)`

[github-actions]

🦀 Rust Guard Improvement Report

Improvement 1: Downscope 5 pub functions in tools.rs to pub(crate)

Category: API Surface
File(s): guards/github-guard/rust-guard/src/tools.rs
Effort: Small (< 15 min)
Risk: Low

Problem

Five classification functions in tools.rs are declared pub, but they are only ever called from within the same crate (via tools:: in lib.rs). Because this is a WASM library (no public Rust API consumers), pub(crate) is the correct visibility.

Affected functions (lines 145–189):

tools.rs:145  pub fn is_write_operation(tool_name: &str) -> bool
tools.rs:152  pub fn is_read_write_operation(tool_name: &str) -> bool
tools.rs:157  pub fn is_merge_operation(tool_name: &str) -> bool
tools.rs:162  pub fn is_delete_operation(tool_name: &str) -> bool
tools.rs:189  pub fn is_blocked_tool(tool_name: &str) -> bool

All five are called only from lib.rs:

lib.rs:532  tools::is_write_operation(...)
lib.rs:535  tools::is_merge_operation(...)
lib.rs:536  tools::is_delete_operation(...)
lib.rs:545  tools::is_read_write_operation(...)
lib.rs:570  tools::is_blocked_tool(...)
lib.rs:1620 tools::is_blocked_tool(...) [test]

Note: is_lock_operation and is_unlock_operation were already correctly scoped as pub(crate). These five were missed in that pass.

Suggested Change

Change pub fn → pub(crate) fn for each of the five functions.

Before

// tools.rs:145
pub fn is_write_operation(tool_name: &str) -> bool { ... }
pub fn is_read_write_operation(tool_name: &str) -> bool { ... }
pub fn is_merge_operation(tool_name: &str) -> bool { ... }
pub fn is_delete_operation(tool_name: &str) -> bool { ... }
// tools.rs:189
pub fn is_blocked_tool(tool_name: &str) -> bool { ... }

After

pub(crate) fn is_write_operation(tool_name: &str) -> bool { ... }
pub(crate) fn is_read_write_operation(tool_name: &str) -> bool { ... }
pub(crate) fn is_merge_operation(tool_name: &str) -> bool { ... }
pub(crate) fn is_delete_operation(tool_name: &str) -> bool { ... }
pub(crate) fn is_blocked_tool(tool_name: &str) -> bool { ... }

Why This Matters

• Documents intent: these are internal dispatch helpers, not public API
• Consistent with is_lock_operation / is_unlock_operation which are already pub(crate)
• Allows rustc/clippy to flag accidental dead code without #[allow(dead_code)]

---

Improvement 2: Replace 3 raw "github" literals in lib.rs tests with scope_names::GITHUB

Category: Centralization
File(s): guards/github-guard/rust-guard/src/lib.rs
Effort: Small (< 15 min)
Risk: Low

Problem

Three test assertions pass the raw string "github" as a scope argument where the rest of the codebase consistently uses the scope_names::GITHUB constant:

lib.rs:1528  labels::writer_integrity("github", &ctx)
lib.rs:1562  labels::writer_integrity("github", &ctx)
lib.rs:1572  labels::writer_integrity("github", &ctx)

All other writer_integrity/reader_integrity calls in the same file and in tool_rules.rs use scope_names::GITHUB or scope_names::USER. These three are inconsistent outliers.

Before

// lib.rs:1528, 1562, 1572
labels::writer_integrity("github", &ctx),

After

labels::writer_integrity(scope_names::GITHUB, &ctx),

(Ensure scope_names is in scope — already available via the existing labels::constants import or a use labels::constants::scope_names; in the test module.)

Why This Matters

Consistency and refactor-safety. If scope_names::GITHUB ever changed value, these three hardcoded string tests would silently test the wrong scope. Using the constant ties expectations directly to the definition.

---

Codebase Health Summary

• Total Rust files: 10
• Total lines: ~12,249
• Areas analyzed: lib.rs, tools.rs, labels/helpers.rs, labels/tool_rules.rs, labels/response_paths.rs, labels/response_items.rs, labels/backend.rs, labels/constants.rs, labels/mod.rs
• Areas with no further improvements: labels/constants.rs (well-organized, fully covered)

---

Generated by Rust Guard Improver • Run: §29820027294

Warning

Firewall blocked 1 domain

The following domain was blocked by the firewall during workflow execution:

• awmgmcpg

To allow these domains, add them to the network.allowed list in your workflow frontmatter:

network:
  allowed:
    - defaults
    - "awmgmcpg"

See Network Configuration for more information.

Generated by Rust Guard Improver · 58.8 AIC · ⊞ 6.7K · ◷

• expires on Jul 28, 2026, 9:58 AM UTC

[github-actions]

🤖 This is an automated response from Repo Assist.

Both improvements here are clean and low-risk. PR #9778 already addresses them:

1. Downscoping — changes pub fn → pub(crate) fn for is_write_operation, is_read_write_operation, is_merge_operation, is_delete_operation, and is_blocked_tool, consistent with the already-scoped is_lock_operation / is_unlock_operation.
2. Constant consistency — replaces the three raw "github" string literals in the test assertions with scope_names::GITHUB.

Both changes are purely internal to the WASM library crate, so there are no downstream API impact concerns.

Warning

Firewall blocked 1 domain

The following domain was blocked by the firewall during workflow execution:

• awmgmcpg

To allow these domains, add them to the network.allowed list in your workflow frontmatter:

network:
  allowed:
    - defaults
    - "awmgmcpg"

See Network Configuration for more information.

Generated by Repo Assist · 145.1 AIC · ⊞ 11.1K · ◷
_{Comment /repo-assist to run again}

_{Add this agentic workflow to your repo}

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/repo-assist.md@851905c06e905bf362a9f6cc54f912e3df747d55