#227 tests: RoleBoundaryRule's multi-path worst-wins loop has no dedicated test

[Anonymous]

Originally created by: fu351

The gap

RoleBoundaryRule handles actions that touch several paths at once (a glob, a batch edit) via action.metadata["raw_paths"]:

• src/doberman/engine/rules/role_boundary.py:77-83 — _candidate_paths() collects them
• src/doberman/engine/rules/role_boundary.py:105-119 — a worst-wins loop keeps the most severe boundary result, with an early break once a blocked path is found

Nothing tests that loop. raw_paths appears in the test suite only for ProtectedPathRule (tests/unit/test_path_confinement_raw.py, tests/unit/test_rule_paths.py); none of test_role_escalation.py, test_role_elevation_satisfies.py or test_role_matcher.py passes more than one path to the role-boundary rule.

grep -rl raw_paths tests/

Why it matters

Worst-wins is the whole point of multi-path handling: an action touching ten allowed files and one blocked file must be judged on the blocked one. A bug in the severity comparison, or an early break that exits before reaching a later blocked path, would silently downgrade that action — and no test would notice.

This is a raise-only invariant, the same family as [#188]: combining results may tighten a verdict, never loosen it.

What to do

Add a test that builds a SecurityObject with metadata={"raw_paths": [...]} mixing an allowed path with a blocked or out-of-scope one, and assert the rule reports the worst boundary. Cover ordering both ways — blocked path first, and blocked path last — since the early break makes order the interesting variable.

tests/unit/test_role_escalation.py is a reasonable home, or a new tests/unit/test_role_boundary_batch.py.

Done when

The test passes against current code, and fails if the worst-wins comparison is inverted or the loop is made to return on its first result.

The bar

Please verify by mutation, not by a green run: break the comparison deliberately, confirm your test goes red, then revert. Say so in the PR — a test around a security invariant that can't fail is worse than no test, because it reads as coverage. [#221] is a good model for the style.

Why this is level-4, not a good first issue

It's test-only and safe to attempt, but it needs the worst-wins invariant understood before the test means anything. Please don't change role_boundary.py itself — if the test reveals a real bug in the rule, report it in the PR and we'll scope the fix separately.

Comment here to claim it.

🤖 Generated with Claude Code

[Anonymous]

Originally posted by: jasperdingg

I'd love to give this a try, will open PR soon

[Anonymous]

Ticket changed by: fu351

• status: open --> closed