Repository navigation
needs_hardware is deliberately not a safety gate; pin the decision - #103
Merged
Merged
Conversation
An audit of the manifest cost-flags after #46 confirmed destructive and requires_confirmation are enforced end to end: BaseToolWrapper.execute passes destructive to the scope gate, and plan_exec authorises both where the manifest and dispatch meet. needs_hardware is the one cost-flag still display-only, and that is by design, not the #90/#102 defect repeated. Unlike the other two it is a capability prerequisite, not an authorisation: the leaf fails on its own when the adapter or interface is absent, no generic check settles "hardware present" the way os.geteuid() settles root, and a planning-only manifest already errors above. Folding it into the gate would force an engagement onto every hardware chain for no safety gain. Record the decision where the question arises: a note in plan_exec next to the #46 enforcement, and test_needs_hardware_alone_does_not_gate alongside the tests that pin the other two flags. The test fails if someone adds needs_hardware to the gate condition, which is the reminder to read the note first. Bump 12.1.8 -> 12.1.9.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Context
Follow-up audit to #102 (which enforced
requires_root): checked the other manifest cost-flags for the same "declared but not enforced" class.Audit result
destructiveandrequires_confirmationare enforced end to end. Safety: implement tiered confirmation (requires_confirmation is unenforced) #46 made them binding inplan_execwhere the manifest meets dispatch, andBaseToolWrapper.executepassesdestructiveto the scope gate;test_manifest_declaration_binds.pyalready guards it. No defect.needs_hardwareis the one cost-flag still display-only, and that is by design — not the Planner slice 1: nmap per-invocation root requirement #90/requires_root was declared on four tools and enforced on none #102 defect repeated.Why needs_hardware stays informational
Unlike the two safety flags it is a capability prerequisite, not an authorisation:
os.geteuid()settles root.plan_exec.Change
Records the decision so it is not re-flagged as a bug or wrongly "fixed":
plan_execnext to the Safety: implement tiered confirmation (requires_confirmation is unenforced) #46 enforcement explaining the exclusion.test_needs_hardware_alone_does_not_gatealongside the tests that pin the other two flags. It fails if someone addsneeds_hardwareto the gate condition (verified: doing so raises "no active engagement").No behaviour change. Bump 12.1.8 -> 12.1.9.