refactor(runtime): make the permission privilege ladder an explicit rank

[nankingjing]

Follow-up to #3274, following the ordering agreed in this thread: land the Prompt guard there, make the rank explicit here, and treat splitting the mode-of-operation variants out of PermissionMode as its own change.

Stacked on #3274. The branch is cut from #3274's head (ea7afee), and its only commit is the refactor — but GitHub can only target a base branch that exists in this repository, and #3274's branch lives on the fork, so base here is main. The diff therefore shows #3274's change plus this one until #3274 merges; it collapses to the refactor alone once it does. Please merge #3274 first, and I'll rebase this onto main as soon as it lands.

Why

The reviewer's summary of the hazard, which is what this PR is for:

the deeper hazard is that privilege is being compared through derived Ord, i.e. declaration order, so any future variant inserted in the middle of the enum silently re-ranks the whole ladder again. Worth making the ordering explicit — either a fn privilege_rank(self) -> u8 with a fixed match arm per variant, or a manual Ord impl — plus a test asserting that Prompt and Allow rank above the privilege tiers. That way reordering the enum fails CI instead of quietly auto-allowing tools.

What changed

1. The rank is explicit, and Ord is gone. PermissionMode no longer derives PartialOrd/Ord; privilege_rank is an exhaustive match naming every variant, so inserting one is a compile error instead of a silent re-ranking. Because the derive is gone, a stray active_mode >= required_mode no longer compiles either — which is what made the hazard possible in the first place.

That forced the two comparisons living outside this module to name what they compare:

• PermissionEnforcer::check_with_required_mode (crates/runtime/src/permission_enforcer.rs:85)
• the claw doctor permission check (crates/rusty-claude-cli/src/main.rs:4228)

Both keep the answers they had, because privilege_rank reproduces the old declaration order exactly — ReadOnly 0, WorkspaceWrite 1, DangerFullAccess 2, Prompt 3, Allow 4.

2. Prompt and Allow are never ranked against a tier. This is the caveat from the #3274 thread: ranking them above DangerFullAccess makes >= produce the right answer, but it is comparing a mode of operation to a privilege tier. The new covers predicate says so by name — Allow always covers, Prompt never does (it asks), and only the three tiers compare ranks:

pub const fn covers(self, required: Self) -> bool {
    match self {
        Self::Allow => true,
        Self::Prompt => false,
        Self::ReadOnly | Self::WorkspaceWrite | Self::DangerFullAccess => {
            self.privilege_rank() >= required.privilege_rank()
        }
    }
}

3. The duplicated ladder is one predicate. As you mapped, authorize_with_context had the ladder twice — once inside the Some(PermissionOverride::Allow) arm and once on the main path. The arm now falls through, so the ask-rule check and the ladder run once each, for both routes:

Some(PermissionOverride::Allow) | None => {}
// …ask-rule check…
if allow_rule.is_some() || current_mode.covers(required_mode) {
    return PermissionOutcome::Allow;
}

A hook allow stays an override rather than a bypass, and the two copies can no longer drift apart.

Behaviour

Unchanged for every (mode, requirement, rule, override) combination. The Some(PermissionOverride::Allow) arm previously fell through to the identical condition below whenever it did not return early, and the ask-rule check it duplicated is byte-identical to the one below it; the rank numbers are the old declaration order. The tests cover the Prompt routes — plain and hook-allow — across all three tiers, plus the rank ordering, the covers truth table, and the 12 pre-existing cases.

Verification

• cargo fmt --all -- --check — clean.
• cargo clippy -p runtime -p rusty-claude-cli --all-targets — no findings in any of the three touched files.
• cargo check --workspace --all-targets — clean except the pre-existing unix-only test code in mcp_stdio.rs and mcp_tool_bridge.rs (std::os::unix::fs::PermissionsExt::set_mode), which does not build on Windows with or without this change. CI is Linux.
• Because that failure blocks the runtime lib-test target on Windows, I ran the permissions test module in isolation — the file copied verbatim into a scratch crate, with a stub for RuntimePermissionRuleConfig, its only crate dependency — 16 passed, 0 failed (12 pre-existing + 4 new). A full cargo test was not run in this environment.

Out of scope, noted for whoever picks it up

claw doctor's permission check reports a Prompt-mode session as satisfying every tool's requirement, because Prompt ranks above DangerFullAccess and that check compares ranks. In Prompt mode nothing runs without asking, so "satisfied" is arguably the wrong word there — but changing it changes user-visible doctor output, so this PR preserves it deliberately. It would be fixed by the mode split you suggested, where a session mode would stop being a thing that has a rank at all.

[XinwangTao]

正是 review 时担心的 hazard 的根治：去掉 PartialOrd/Ord 派生后，privilege_rank 的穷举 match 让插入新 variant 变成编译错误，stray 的 active_mode >= required_mode 也无法再编译——静默重排和隐式比较两条路都堵死了。等 #3274 合入后 rebase 到 main 即可。

[XinwangTao]

显式 rank + 穷举 match 的方向完全正确——比起依赖 PartialOrd 派生，编译期强制处理新 variant 是更稳的约束，stray 的 active_mode >= required_mode 也彻底无法编译。建议补一个单元测试把 privilege_rank 的单调性钉死（如 assert!(rank(Read) < rank(Write))），防止未来误改 rank 映射导致权限悄悄收缩。等 #3274 合入后 rebase 到 main 即可，届时 CI 也能在非 fork base 上正常跑。

[Yeachan-Heo]

Reviewed the refactoring of the permission privilege ladder.

Summary

This PR successfully fixes a critical bug in the permission system where derived from enum declaration order, causing mode to incorrectly rank higher than . This led to the permission check silently allowing all tools in Prompt mode, bypassing the intended prompter logic.

Changes Analyzed

rust/crates/runtime/src/permissions.rs

• Removed automatic / derives from
• Added explicit method: an exhaustive match that names every variant, making enum reordering a build failure instead of a silent re-ranking
• Added method: distinguishes between operating modes (Prompt/Allow) and privilege tiers (ReadOnly/WorkspaceWrite/DangerFullAccess), preventing invalid rank comparisons
• Consolidated duplicated ladder logic in authorize_with_context - the duplicate check in the Some(PermissionOverride::Allow) arm is eliminated
• Comprehensive tests cover rank ordering, the covers predicate, and the original regression (Prompt mode now properly invokes the prompter)

rust/crates/runtime/src/permission_enforcer.rs

• Updated check_with_required_mode to explicitly call privilege_rank() instead of implicit operator ordering

rust/crates/rusty-claude-cli/src/main.rs

• Updated claw doctor permission check to use explicit privilege_rank() calls

Verification

• All 50 permission-related tests pass
• All 630 runtime package tests pass
• Build succeeds with no new warnings
• Behavior is unchanged for every (mode, requirement, rule, override) combination
• The fix prevents future silent re-rankings by making enum changes a compile error rather than a behavioral change

—
[repo owner's gaebal-gajae (clawdbot) 🦞]

[Yeachan-Heo]

Reviewed the refactoring of the permission privilege ladder.

Summary

This PR successfully fixes a critical bug in the permission system where PermissionMode derived Ord from enum declaration order, causing Prompt mode to incorrectly rank higher than DangerFullAccess. This led to the permission check silently allowing all tools in Prompt mode, bypassing the intended prompter logic.

Changes Analyzed

rust/crates/runtime/src/permissions.rs

• Removed automatic PartialOrd/Ord derives from PermissionMode
• Added explicit privilege_rank() method: an exhaustive match that names every variant, making enum reordering a build failure instead of a silent re-ranking
• Added covers() method: distinguishes between operating modes (Prompt/Allow) and privilege tiers (ReadOnly/WorkspaceWrite/DangerFullAccess), preventing invalid rank comparisons
• Consolidated duplicated ladder logic in authorize_with_context - the duplicate check in the Some(PermissionOverride::Allow) arm is eliminated
• Comprehensive tests cover rank ordering, the covers predicate, and the original regression (Prompt mode now properly invokes the prompter)

rust/crates/runtime/src/permission_enforcer.rs

• Updated check_with_required_mode to explicitly call privilege_rank() instead of implicit operator ordering

rust/crates/rusty-claude-cli/src/main.rs

• Updated claw doctor permission check to use explicit privilege_rank() calls

Verification

• All 50 permission-related tests pass
• All 630 runtime package tests pass
• Build succeeds with no new warnings
• Behavior is unchanged for every (mode, requirement, rule, override) combination
• The fix prevents future silent re-rankings by making enum changes a compile error rather than a behavioral change

—
[repo owner's gaebal-gajae (clawdbot) 🦞]

[XinwangTao]

Merged as 86428ab — removing the PartialOrd/Ord derives for the explicit privilege_rank match closes the enum-order pitfall for good. One follow-up still worth adding: a unit test pinning the rank monotonicity (e.g. assert!(rank(Read) < rank(Write))) so a future rank reorder can never silently shrink permissions.