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
|
## What it does and why
|
||||||
|
|
||||||
Deleting is the easy half. The hard half is proving nothing remains, and the
|
Deleting is straightforward. Proving that nothing remains is harder, and the two failures that matter are both invisible to the delete path itself.
|
||||||
two failures that matter are both invisible to the delete path itself.
|
|
||||||
|
|
||||||
### Billing outliving compute
|
### 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
|
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
|
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
|
response has verified nothing, so an `absent` state backed only by
|
||||||
`delete-response` is reported as not assessed. That is the difference
|
`delete-response` is reported as not assessed.
|
||||||
between terminated and verifiably terminated.
|
|
||||||
|
|
||||||
KillSwitch never deletes anything. It takes an inventory you enumerated and
|
KillSwitch never deletes anything. It takes an inventory you enumerated and
|
||||||
decides whether the removal can be evidenced. There is no network access and
|
decides whether the removal can be evidenced. There is no network access and
|
||||||
|
|||||||
Reference in New Issue
Block a user