49 lines
2.6 KiB
Markdown
49 lines
2.6 KiB
Markdown
---
|
|
unconditional: true
|
|
# Deliberately always-loading. This rule exists because TWO sessions made the same destructive
|
|
# mistake on a live box, the second one WITH a prompt line telling it not to. A path-scoped rule
|
|
# would load when you edit the handler; the mistake is made when you probe it, from anywhere.
|
|
---
|
|
|
|
# Live probes — what a probe may touch on a real box
|
|
|
|
> One rule, earned twice in two days by two different sessions, both of which had a prompt line
|
|
> telling them not to. A prompt is read once; a rule file is loaded every session, which is the whole
|
|
> reason this file exists.
|
|
|
|
## Never send a deploy request for an app that is not installed — not even expecting a refusal
|
|
|
|
**`POST /api/stacks/<name>/deploy` ACCEPTS FIRST AND VALIDATES LATER.** It answers `202 Telepítés
|
|
elindítva` and runs the validation inside a goroutine, so a probe that expects a refusal gets a 202 —
|
|
and if the app happens to need no required field, it is now installed on the box.
|
|
|
|
- 2026-09-17: a session probing the required-field refusal picked an app that needed no field. It
|
|
installed. Recorded in `STATUS.md`.
|
|
- 2026-09-18: a session that had read that record, and had a prompt line forbidding it, did the same
|
|
thing with `vaultwarden`. Recorded in
|
|
`documentation/audits/i18n-slice2-2026-09-18/B/live/README.md`.
|
|
|
|
The lesson that sticks is narrower than "pick a different app": **the deploy endpoint cannot be used
|
|
to probe a refusal at all.**
|
|
|
|
**Instead, use a request that is refused BEFORE anything is created:**
|
|
|
|
| you want to see | use |
|
|
|---|---|
|
|
| a deploy-path refusal | an app that is ALREADY installed → `409 already deployed` |
|
|
| a not-found path | a name that exists nowhere → `404` |
|
|
| a validator's sentence | `POST /sharing/shares` with a bad name, `POST /api/disks/assign` with a bad mount point — both refuse before they write |
|
|
| a protected-resource refusal | `POST /api/stacks/felhom-controller/remove` → `403` |
|
|
|
|
## If a probe does create something, remove it through the product
|
|
|
|
Not by hand, and not by `docker rm`: stop it, then `POST /api/stacks/<name>/remove` with
|
|
`remove_hdd_data` and `remove_backups`, and then **verify** — no container, no `/opt/docker/stacks/<name>/app.yaml` (the folder itself stays — it holds the catalog's template files; path corrected 2026-10-24),
|
|
no volume. Say in the report that it happened. A tidy-up nobody is told about is how the next session
|
|
learns nothing.
|
|
|
|
## The general shape
|
|
|
|
**Before sending anything to a live box, ask which side of the write the refusal happens on.** A
|
|
refusal that comes after the write is not a refusal you can probe — it is a change you are making.
|