@@ -1,23 +1,119 @@
 # Design notes
 
-## Per-rule enable/disable (not implemented)
-
-The manage feature set (Save, edit in place, move) deliberately leaves
-per-rule disable out. nftables has no disabled state: a rule either is in the
-ruleset or it is not, so "disable" means deleting the rule while remembering
-enough to put it back exactly where it was.
-
-Doing that honestly needs a second persistence format — call it v2 of the
-saved file — that stores the tool's own view of the ruleset rather than nft's
-listing: a list of rule *specs* (the same `RuleSpec` the add and edit forms
-produce), each with an enabled flag and its position. Disabling would then be
-"delete the rule, keep its spec"; enabling, "insert the spec at its recorded
-position"; and Save would write both the active ruleset (as the `.nft` file it
-writes today, still loadable by plain `nft -f` on boot) and the spec sidecar
-that carries the disabled entries.
-
-That sidecar is a real format with compatibility duties, and it only pays for
-itself once the tool also reconciles it against a ruleset that changed behind
-its back. Until that reconciliation exists, a fake disable would silently drop
-rules on the floor, so the feature waits for persistence v2 instead of
-shipping as a trap.
+## Per-rule enable/disable, and the saved-file format
+
+nftables has no disabled state. A rule is in the ruleset or it is not, so
+"disable" can only mean deleting the rule while remembering enough to put it
+back exactly where it was. That memory is a file format, and this is what it
+is.
+
+### The file is still one file, and still an nft script
+
+The Save action (`W`) writes `nft list table inet tui` — nft's own text, which
+is a valid nft script — to `/etc/omarchy/router/tui-firewall.nft` on an
+Omarchy router or `/etc/nftables.d/tui-firewall.nft` elsewhere. The router
+profile loads that file with `nft -f` on boot, and nothing about that may
+change: a machine that loses this tool still has to boot the rules it had.
+
+So the disabled rules ride in the same file, in comment lines. `nft -f`
+ignores a line starting with `#`; this tool parses those lines and nobody else
+has to know they exist.
+
+```
+# tui-firewall:spec v2
+table inet tui {
+	chain input {
+		type filter hook input priority 0; policy drop;
+		iifname "wan0" tcp dport 22 counter drop comment "no ssh from the wan"
+	}
+}
+# tui-firewall:disabled {"index":2,"expr":["iifname","\"wan0\"","udp","dport","53","counter","drop"],"family":"v4","rule":{…}}
+```
+
+- `# tui-firewall:spec v2` is the version marker, and it is written **only
+  when something is actually disabled**. A ruleset with nothing disabled
+  produces the byte-identical v1 file earlier versions wrote, so a user who
+  never presses `D` never sees the format change and never sees a diff for it.
+- `# tui-firewall:disabled <json>` is one disabled rule, one line.
+- A file with no marker is version 1 and loads as "nothing disabled". A marker
+  naming a version this build does not read is an error, not a guess, and the
+  save is refused while it stands: overwriting a file whose disabled rules
+  could not be read would delete them.
+
+A sidecar file was the other option and was rejected. Two files drift, the
+boot path would have to learn about the second one, and the operator who
+copies `tui-firewall.nft` to another machine would silently leave half the
+configuration behind.
+
+### What one disabled entry holds
+
+Two renderings of the same rule, for two different jobs:
+
+- `expr` — the nft statement, one argv word per element, captured from the
+  live match at the moment the rule was disabled. This is what the re-add
+  replays. It is a snapshot rather than something recomputed later, so a
+  ruleset that has been re-read in between cannot change what comes back.
+- `rule` — the modelled rule (`Match` and all), because a disabled rule still
+  has to be a row in the table and the kernel no longer holds it. Plus
+  `family`, which `Match` derives from the expressions it decoded rather than
+  from a field nft printed, so it does not survive a JSON round trip on its
+  own.
+- `index` — the 0-based position in its chain the rule goes back to.
+
+`counter` is dropped on the way in: a disabled rule is not counting anything,
+and a stale number is a number the row invites the reader to believe.
+
+### Disable and enable
+
+- **Disable** is `nft delete rule … handle H`, plus the entry recorded in the
+  spec once that command has actually run. The statement is rebuilt from the
+  rule's own modelled match by the same machinery a move uses
+  (`rebuildRuleExpr`), so a rule this package does not hold in full — an
+  unmodelled match, a NAT translation, a verdict other than accept/drop/reject,
+  a log statement carrying a level or an nflog group — is refused before
+  anything is deleted. That is the same refusal set `E` makes.
+- **Enable** replays `expr` with `nft insert rule … index N`, or `nft add rule`
+  when the chain has since become shorter than the recorded position. The rule
+  comes back with a fresh handle and a counter at zero, and the preview says
+  so.
+
+Both are previewed and confirmed like every other change, and both go through
+`internal/nftables` — the only place in this tool that starts a process.
+
+### Why disable does not join a staged batch
+
+Staging collects changes and applies them later as one `nft -f` transaction.
+The record of what is disabled is written the moment its command succeeds. If
+the ruleset change were staged and the record were not, the file would claim a
+rule is disabled while the kernel still enforces it — the exact lie the
+preview contract exists to prevent — and a batch cannot carry the record
+either, because the record is a file write and an `nft -f` transaction is not.
+
+So `D` applies on its own, as one nft command, and is refused while staging is
+collecting or while an applied batch is waiting to be kept. It then **offers
+the save**, once the reload has put the new list on screen, because until that
+save happens the disabled rule lives only in this process. The header says the
+same thing: `rules: 1 disabled, unsaved (W)`.
+
+### Reading a file this tool did not write
+
+Everything that comes off disk is guarded before it becomes an nft statement
+or a table cell. A statement word is either a bare operand from a fixed
+alphabet or one closed double-quoted string; a table, family or chain name is
+a short name with no nft syntax in it; every string the row draws goes through
+the same one-line pass nft's own output goes through. A line that does not
+parse is an error rather than a skip, because dropping the ones that did not
+parse would lose exactly the rules the file exists to preserve.
+
+`FuzzParseSpec` asserts those invariants on arbitrary input, and
+`FuzzSaveFileRoundTrip` asserts that anything this package writes, it reads
+back.
+
+### What is still open
+
+The spec is not reconciled against a ruleset that changed behind this tool's
+back. If something else adds rules to `inet tui` while a rule is disabled, the
+recorded position is a position in a chain that has moved; enabling then puts
+the rule back at that index, which may not be the neighbour it had. The
+position past the end of a shorter chain is handled (it appends); the rest is
+a reconciliation pass this tool does not do yet.
@@ -132,7 +132,7 @@ Upgrades then arrive with the rest of your system updates.
 ### Any distribution, static binary
 
 ```sh
-curl -fsSL https://github.com/tui-tools/tui-firewall/releases/download/v0.2.2/tui-firewall_0.2.2_linux_amd64.tar.gz | tar -xz tui-firewall
+curl -fsSL https://github.com/tui-tools/tui-firewall/releases/download/v0.3.0/tui-firewall_0.3.0_linux_amd64.tar.gz | tar -xz tui-firewall
 sudo install -m0755 tui-firewall /usr/local/bin/tui-firewall
 ```
 
@@ -309,6 +309,7 @@ firewall nor `sudo` is available, it says so and points at `--demo`.
 | `a` | Add a rule |
 | `E` | Edit the selected rule in place — same handle, same position (nftables) |
 | `K` / `J` | Move the selected rule up / down, as one atomic transaction (nftables) |
+| `D` | Disable or enable the selected rule, keeping its spec and its position (nftables) |
 | `d` | Delete the selected rule |
 | `e` | Enable or disable the firewall (ufw only) |
 | `r` | Reload the firewall |
@@ -467,7 +468,7 @@ is restored automatically when the timer expires, and you are back on the rulese
 that was working. It is the standard `iptables-apply` idea, done as one nft
 transaction.
 
-### Manage, not view: edit, move and save
+### Manage, not view: edit, move, disable and save
 
 The nftables backend does not stop at adding and deleting.
 
@@ -502,8 +503,36 @@ the usual include from `/etc/nftables.conf` (the dialog spells this out), and
 the running table: staged changes that were not applied yet are not in the
 file, and the dialog says so.
 
-Per-rule enable/disable is deliberately absent for now; `DESIGN.md` describes
-the persisted-spec format it is waiting for.
+**Disable.** Press `D` and the selected rule stops being enforced without
+being lost. nftables has no per-rule off switch — a rule is in the ruleset or
+it is not — so disabling is `nft delete rule … handle H` plus a record of the
+statement the rule was and the position it sat at. The rule stays in the table
+as a greyed-out row marked `disabled`, drawn from that record rather than from
+the kernel, and `D` again puts it back where it was with `nft insert rule …
+index N` (or appends it, if the chain has become shorter since). Only rules
+the tool holds in full can be disabled: the same refusals `E` makes, for the
+same reason.
+
+That record is written to the same file `W` saves, as comment lines `nft -f`
+ignores and this tool reads back:
+
+```
+# tui-firewall:spec v2
+table inet tui {
+	…
+}
+# tui-firewall:disabled {"index":2,"expr":["iifname","\"wan0\"","udp","dport","53","counter","drop"],…}
+```
+
+The live half of the file is still nft's own listing, byte for byte, so the
+boot path is exactly as it was — and a file written before this feature
+existed still loads, as a ruleset with nothing disabled. A ruleset with
+nothing disabled still *writes* that same v1 file, so nobody who does not use
+`D` sees the format at all. Disabling never joins a staged batch (the ruleset
+and the record have to change together), and it offers the save straight
+afterwards, because until it is saved the disabled rule lives only in the
+running process — which is what the `rules: 1 disabled, unsaved (W)` fact in
+the header is telling you. `DESIGN.md` has the format in full.
 
 ### Per-rule logging and the live log
 
@@ -583,10 +612,14 @@ are capped, so a firewall under a scan cannot grow it without bound.
 - Move a rule up and down with `K` and `J`, as one atomic `nft -f` transaction
   (a copy at the new position plus a delete of the old handle), staged into
   the batch when staging is on.
+- Disable a rule with `D` and enable it again with `D`: the rule leaves the
+  ruleset and stays on screen as a greyed-out row, rebuilt from the tool's own
+  persisted spec and put back at the position it had.
 - Save the tool's own table to disk with `W` — `nft list table inet tui`
   installed to `/etc/omarchy/router/tui-firewall.nft` on an Omarchy router,
   `/etc/nftables.d/tui-firewall.nft` elsewhere — with a unified diff against
-  the current file in the confirm dialog.
+  the current file in the confirm dialog. The disabled rules ride in the same
+  file as comments `nft -f` ignores, so it stays loadable on boot as it is.
 - Mark a rule to be logged with `l`: the rule is replaced in place, keeping its
   handle and position, with a stable `log prefix "tui:<chain> <verdict> "` the
   live view greps for. Toggle it off the same way.
@@ -612,8 +645,11 @@ are capped, so a firewall under a scan cannot grow it without bound.
 - **No nftables set-element editing**: a named set is created or used, and its
   members are added and removed one at a time from the actions menu, not
   edited in bulk.
-- **No per-rule enable/disable**: nftables has no disabled state, and faking
-  one honestly needs the persisted-spec format `DESIGN.md` describes.
+- **No per-rule enable/disable on ufw or firewalld**: it needs the tool's own
+  persisted spec, which only the nftables backend has. On nftables the spec is
+  not reconciled against a ruleset something else changed behind this tool's
+  back, so a rule enabled after another tool has reshuffled the chain lands at
+  the recorded index rather than beside the neighbour it had.
 - On ufw and firewalld, rules follow the backend's own order; the move keys
   are an nftables feature.
 
 
@@ -8,6 +8,7 @@ import (
 
 	tea "github.com/charmbracelet/bubbletea"
 	"github.com/tui-tools/tui-firewall/internal/firewall"
+	"github.com/tui-tools/tui-firewall/internal/nftables"
 	"github.com/tui-tools/tui-firewall/internal/nftables/staging"
 	"github.com/tui-tools/tui-kit/compat"
 	"github.com/tui-tools/tui-kit/theme"
@@ -99,6 +100,17 @@ type app struct {
 	// the applied batch is on screen before its keep window begins.
 	keepTickPending bool
 
+	// pendingDisable is the toggle the change now at the confirm dialog
+	// applies, so a yes records it in the backend's spec. It is nil when the
+	// pending change is something else.
+	pendingDisable *nftables.Toggle
+	// pendingSave marks the change at the confirm dialog as the save, so a yes
+	// clears the "not written yet" state of the spec.
+	pendingSave bool
+	// saveOfferPending asks the next load to offer the save, so the disabled
+	// rule is on screen before the dialog that writes it to disk opens.
+	saveOfferPending bool
+
 	// editing marks the open rule form as an edit: submitting replaces
 	// editTarget in place rather than adding a rule.
 	editing    bool
@@ -230,6 +242,13 @@ func (a *app) Update(msg tea.Msg) (tea.Model, tea.Cmd) {
 		a.applyFilter()
 		// A batch that just applied starts its keep window now, with the applied
 		// ruleset already on screen, so the operator sees what they are keeping.
+		// A disable or enable that just applied offers the save that puts the
+		// tool's record of it on disk; until that happens the record lives only
+		// in this process.
+		if a.saveOfferPending {
+			a.saveOfferPending = false
+			return a, a.beginSave()
+		}
 		if a.keepTickPending && a.staging != nil {
 			a.keepTickPending = false
 			token := a.keepToken
@@ -243,7 +262,11 @@ func (a *app) Update(msg tea.Msg) (tea.Model, tea.Cmd) {
 	case ranMsg:
 		a.busy = false
 		wasApply := a.pendingApply
+		wasDisable := a.pendingDisable
+		wasSave := a.pendingSave
 		a.pendingApply = false
+		a.pendingDisable = nil
+		a.pendingSave = false
 		if msg.err != nil {
 			if wasApply {
 				// The batch was atomic: nft rejected it, so nothing changed and
@@ -265,6 +288,18 @@ func (a *app) Update(msg tea.Msg) (tea.Model, tea.Cmd) {
 		}
 		a.setStatusf(ui.StatusOK, "%s: %s", msg.change.Description, firstLine(summary))
 		a.loading = true
+		if wasSave {
+			if saver, ok := a.backend.(tableSaver); ok {
+				saver.SpecSaved()
+			}
+		}
+		if wasDisable != nil {
+			// The rule is out of the ruleset (or back in it): record that now,
+			// and offer the save once the reload has put the new list on
+			// screen, so the file being written is the state the user can see.
+			a.commitToggleDisabled(*wasDisable)
+			a.saveOfferPending = true
+		}
 		return a, a.load()
 
 	case keepExpiredMsg:
@@ -347,8 +382,10 @@ func (a *app) handleConfirm(msg tea.KeyMsg) (tea.Model, tea.Cmd) {
 	change, ok := a.confirm.Payload.(firewall.Change)
 	a.confirm = ui.Confirm{}
 	if !confirmed || !ok {
-		// A cancelled apply must not leave the next run looking like the batch.
+		// A cancelled change must not leave the next run looking like this one.
 		a.pendingApply = false
+		a.pendingDisable = nil
+		a.pendingSave = false
 		a.setStatus(ui.StatusInfo, "cancelled")
 		return a, nil
 	}
@@ -562,6 +599,8 @@ func (a *app) handleTableKey(msg tea.KeyMsg) (tea.Model, tea.Cmd) {
 		return a, a.load()
 	case "a":
 		return a, a.startAdd()
+	case "D":
+		return a, a.confirmToggleDisabled()
 	case "E":
 		return a, a.startEdit()
 	case "K":