README: plainer wording
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
@@ -5,8 +5,7 @@ resource class, including the billing that tends to outlive it.
|
||||
|
||||
## What it does and why
|
||||
|
||||
Deleting is the easy half. The hard half is proving nothing remains, and the
|
||||
two failures that matter are both invisible to the delete path itself.
|
||||
Deleting is straightforward. Proving that nothing remains is harder, and the two failures that matter are both invisible to the delete path itself.
|
||||
|
||||
### Billing outliving compute
|
||||
|
||||
@@ -21,8 +20,7 @@ so KillSwitch reports it as a separate critical finding and prints it first.
|
||||
A `DELETE` that returns 200 means the API accepted the request. It does not
|
||||
mean the resource is gone. A teardown whose only evidence is its own success
|
||||
response has verified nothing, so an `absent` state backed only by
|
||||
`delete-response` is reported as not assessed. That is the difference
|
||||
between terminated and verifiably terminated.
|
||||
`delete-response` is reported as not assessed.
|
||||
|
||||
KillSwitch never deletes anything. It takes an inventory you enumerated and
|
||||
decides whether the removal can be evidenced. There is no network access and
|
||||
|
||||
Reference in New Issue
Block a user