# REPORT — controller v0.197.0: R-203, both halves (2026-08-04)

Deployed to demo-hp guest 9201. No hub change. Nothing deleted, wiped or moved; the R-201 drill was
not resumed.

## What shipped

**Part 1 — one resolver, five callers.** `appbackup.NamespaceRootFor` / `IsEnrolledDrive` are now the
single expression of the drive-kind rule; `backup.Manager.namespaceRoot` and `stacks.Manager.inGuest`
delegate (they were two copies that already differed over `filepath.Clean`). Routed through it:
`stacks/deploy.go` `withPathVars` (the live defect), `appexport/fabplan.go` + `export.go` via a new
`GetStackNamespaceRoot` provider method, `web/handlers.go`'s FileBrowser mounts (the fifth site, which
the spec did not name — latent today), and `stacks/delete.go`'s `ExportDataMounts` (its own commit).
`ComputeFabBuckets` now receives the namespace root, matching `ComputeCaptureSet`.

**Part 2 — the verdict.** `last_status` gains `incomplete`; the capture gaps are recorded structurally
so the verdict has something to act on; the operator hears it through the existing per-run digest.

## Proven live on demo-hp

```
bind before:  /mnt/sys_drive/userdata/media/books
bind after:   /mnt/sys_drive/felhom-data/userdata/media/books
capture log:  0 mandatory path(s)  ->  1 mandatory path(s)

$ restic ls -l latest --tag calibre-web
-rw-r--r--  1000  1000  181  2026-08-04 12:53:06  .../media/books/DRILL-SENTINEL.txt
```

The file, by name and size, inside the snapshot — not a green status.

## Tests

`go build && go vet && go test ./...` rc=0; `controller_gates.py --fast` OK. Table-driven over BOTH
drive kinds, because this defect survived by being invisible on the kind that already worked.

**One red-proof PASSED and the test was wrong, not the code:** the first Scenario-C test reached only
`offboxCaptureSet` while the mutation lives in `runOffboxInternal`. Replaced with a run-level test
driving `RunOffboxBackup`; it now fails under both an unreachable gap-recording and an unconditional
`ok`. Scenario D's proof also could not fail by construction (the tier filter already excludes
optional paths) — the two-part mutation that does is recorded.

## Corrections to the spec

- **Five call sites, not four.** The fifth is the FileBrowser mount builder.
- **`ExportDataMounts` is export-only despite living in `delete.go`.** Its only caller is the `.fab`
  adapter, and the delete path's own `ProtectedHDDPaths` guard is layout-agnostic by construction, so
  the destructive-path risk the spec flagged does not exist.

## Observations

`resolveAbs` resolves `RootHDD` and `RootUserdata` against one root — fine on enrolled drives, and now
consistent between export and backup, but whether `${HDD_PATH}` should mean the namespace root on the
system drive is a separate decision affecting every deployed app. The deploy API is
first-deployment-only (409 after), so an existing app picks up the corrected path via start/redeploy.
The CSRF form field is `_csrf`, not `csrf_token` — second session running that this cost time.