Repository navigation
Decide: whether Feint ever manages a resource whose loss would matter, or hands that to another project #196
Description
Everything --vm creates today is disposable by construction. feint clean
sweeps what carries the label, the conformance suites destroy what they made,
and docs/limits.md says a restart starts empty. The whole safety argument of
this project rests on that: it only ever touches what it created, and what it
created was made to be thrown away.
Materialising the cloud model on a real cluster (#195) makes that assumption a
question. A homelab has two kinds of resource in it, and they need two different
promises:
| lab | persistent | |
|---|---|---|
| lifetime | the test | months |
| storage | disposable | data somebody wants back |
| network | rebuilt freely | addresses other things point at |
a wrong feint clean |
costs a rerun | costs the weekend |
The question
Does Feint ever manage a resource whose loss would matter?
Answering no keeps the current safety argument intact and keeps the product
honest: a cloud lab, disposable by design, and anything durable belongs to a
tool that was built for it.
Answering yes means everything downstream changes — deletion needs
confirmation or ownership beyond a label, clean needs a blast radius, state
needs to survive the emulator rather than the session, and the audit posture
this repository has built around "we only touch what we made" needs rewriting
rather than extending.
This is filed as a decision rather than a feature because taking it implicitly,
by shipping a cluster runtime that happens to work on persistent storage, is how
a project acquires an obligation nobody agreed to.
What is already known and should weigh on it
- An audit already turned a crafted snapshot into
incus delete --forceon an
operator's own instance andnetwork delete incusbr0on the host's default
bridge. The guards exist now, and they exist because the failure was real.
Persistent resources raise the cost of the next one from a rerun to data. Resource.Runtimeis restored verbatim from a snapshot and is designed to
travel between instances, so "this name came from us" stops being true at the
first persistence boundary. That reasoning does not get safer with a cluster.- The user's own framing draws the line first: lab mode is fully within this
project's DNA, persistent mode is where it starts becoming an infrastructure
orchestrator.
What deciding looks like
A section in docs/limits.md that says which of the two Feint does, in the same
voice as the rest of that page — and if the answer is ever yes, an issue per
guard it requires, none of which should be discovered after the fact.
Activity
docs(roadmap): the runtime stops being one machine, and the question …
[-]Decide: whether a resource this emulator creates may ever be one somebody depends on[/-][+]Decide: whether Feint ever manages a resource whose loss would matter, or hands that to another project[/+]stephrobert commentedon Aug 15, 2026
Reframed by the direction in #197.
The original question stands, but the answer now has a third option that is better than either of the first two.
Rather than no (stay disposable, give up on real hardware) or yes (Feint grows the guards, the ownership model and the blast-radius rules that persistent resources demand), the split filed in #195 means: Feint stays disposable, and a separate control plane owns whatever is durable.
That is not a dodge. It moves the obligation to a project whose whole purpose is to carry it, and it keeps this repository's safety argument intact — that it only ever touches what it created, and what it created was made to be thrown away.
What still has to be decided here, and is what this issue now asks: is that the answer? Because if a cluster backend ships and somebody points it at persistent storage, the obligation arrives whether or not anybody wrote it down. An audit has already turned a crafted snapshot into
delete --forceon a host's default bridge; persistent resources raise the cost of the next one from a rerun to data.Deciding looks the same as before: a section in
docs/limits.mdthat says which of the two Feint does, in the same voice as the rest of that page.docs(roadmap): the runtime belongs to another project, and the coupli…
docs(roadmap): the environment becomes the thing that travels, after …
stephrobert commentedon Aug 27, 2026
Attaching this to
0.19.0 — The homelab is not disposable, because that milestone is the moment the question stops being answerable both ways: a volume that holds bytes someone wants back is a resource whose loss would matter.The roadmap now takes the decision this issue asked for — explicitly, which is what it demanded. The homelab ladder (0.17–0.20) answers yes, and answers it as a second personality (
feint controller start) rather than a change to the emulator, so the "no" answer this issue defends stays true forfeint serve: disposable by construction,cleansweeps the label, a restart starts empty.Per this issue's own terms, deciding looks like a section in
docs/limits.mdand an issue per guard, filed before the fact. The 0.19 milestone description makes that section a gate: the milestone does not open until the decision is written. #555 carries the storage work; the guard inventory (a blast radius forfeint cleanamong them) gets filed when the section is written, not discovered after.docs: the lab is disposable, and that is the boundary (#196, #733) (#879
stephrobert commentedon Nov 11, 2026
Reopened: the decision recorded in #879 was the wrong one, and the maintainer has reversed it.
#733 asked for the decision to be written, explicitly not for a particular outcome. What was written on 2026-11-11 answered "feint never manages a resource whose loss would matter" and refused this issue on that basis. The maintainer's answer is the other one: feint is to become the tool that builds a durable homelab — volumes holding real bytes, a reconciler, quotas.
So the roadmap sentence at
docs/roadmap.md:829is superseded in part rather than upheld, and the candidate wording #733 itself offered is the one that stands:Nothing about this issue's own content was wrong. What changed is the boundary it sits inside.
One consequence is named here rather than discovered later. The argument that makes feint safe to point at an operator's own station is "it only touches what it made, and what it made is disposable", and the second half is what makes a sweep affordable:
feint cleanremoves everything carrying the label, with no confirmation, no backup and no recovery path. Once feint holds a volume whose bytes somebody wants back, that sentence stops being true and every place invoking it has to be re-grounded. That work is now tracked, and it blocks nothing here — but it is the real cost of this direction, and it belongs in the open rather than in a commit message.stephrobert commentedon Nov 11, 2026
Reopened in error, and closed again. The decision stands as written in #879: the lab is disposable, and
docs/limits.mdcarries it.What happened is worth recording, because it is a measurement failure of my own and not a change of mind. The decision was taken cleanly, as a choice between three stated options, and the answer was "the lab stays disposable, and the record may persist". I then asked a follow-up in prose — "if you want feint to become the tool that builds a durable homelab, say so and I will do it" — which is a leading question with a yes-shaped answer, and I read the yes as a reversal of the decision rather than as a reply to a badly-posed question.
A decision taken against stated options was overturned by a sentence I wrote. That is the wrong direction for a change of this size, and the correction is to put it back rather than to leave the tracker reflecting it.
So: the boundary is a resource whose loss would matter, not persistence as such. #551 and #552 stay in scope — the emulator's own record may survive a restart, because it is explicitly rebuildable, never authoritative, and holds nobody's content. This issue is refused for the reason given in the closure above it, unchanged.