# Part 2.1 — was the scratch resolver missed, or excluded on purpose?

**ANSWER: neither label fits exactly. It was consciously OUT OF SCOPE for R-356, and it was never
ruled out on the state-only grounds. The rule in §6.3 already covers it. → BRANCH (a).**

## The evidence, in the order it settles the question

### 1. R-356 itself says the scratch resolver was left alone — and says why

From R-356's own commit (`08eb1a6`, 2026-08-22), in its test file, twice:

> *"the prepared scratch **still resolves** to the registered storage path (`offboxRestoreScratchDir`
> step 2), so the srcs the fixture laid down are still where the code looks for them; **only the
> DESTINATION moves**, which is precisely what this change is about."*

> *"The scratch was laid out against the drive namespace, which is where `offboxRestoreScratchDir`
> **still resolves** (the drive stays a registered storage path). Only the DESTINATION moves."*

R-356 was about **where restored data LANDS**. It changed `PlaceOffsiteRestore` and
`ReconstituteFromOffsite`. It did not consider the scratch resolver a subject — and it assumed, in
every fixture, that **step 2 succeeds because a registered storage path exists**.

**`demo-felhom` is the case R-356 never had: zero registered storage paths.**

### 2. The one comment about a `systemDataPath` fallback was about a DIFFERENT function, and R-356 OVERRULED it

R-356's diff **deleted** this line from `PlaceOffsiteRestore`:

> *"NOT AppNamespaceRoot — its systemDataPath fallback would merge **userdata** onto the SSD system
> namespace."*

That concern was about placing the customer's **bulk userdata** on the SSD, and R-356 decided against
it deliberately. It was never a statement about a **scratch**.

### 3. The scratch resolver's own comment forbids a different path

> *"NEVER `cfg.Paths.DataDir` (the rootfs — the F-A1 filler)."*

`cfg.Paths.DataDir` is the controller's data dir on the **rootfs**. `cfg.Paths.SystemDataPath`
(`/mnt/sys_drive`) is a different filesystem. **The documented exclusion is the rootfs, not the system
data path.**

### 4. And the decisive one: a driveless app's unit ALREADY lives there, permanently, by design

`07-backup-architecture.md` §7, **[FACT]**:

> *"`GetAppDrivePath` returns the app's `HDD_PATH` if it has one and **`systemDataPath` otherwise** —
> what `appbackup/paths.go:26-27` calls the SSD-only system-data fallback. Nothing deletes a unit
> after it is copied onward … so for every app without a data drive, `mp1` holds the kept copy
> indefinitely."*

and:

> *"the same-device placement is **intended, not a defect**."*

**So a unit-only scratch on the system data path is at most a second copy of a unit that already sits
there permanently and by design.** Nothing anywhere states a restore scratch must not land there.

## Therefore

**Branch (a)** — apply the rule that already exists, **scoped by what is being restored**, which is
the distinction the register row did not carry and §2.2's state-only concern genuinely requires:

| restore | scratch fallback | why |
|---|---|---|
| **unit-only** (the nightly proof, and the customer's default) | **may fall back to the system data path** | the unit already lives there permanently (§7); the scratch is bounded by the unit's own size |
| **full** (bulk userdata) | **keeps today's behaviour and refuses** | this is the case the deleted `PlaceOffsiteRestore` comment worried about, and the SSD is a state-only tier |

**One resolver answering two questions is the R-356 defect itself.** Splitting it by restore scope is
the same separation R-356 made between *"installed?"* and *"where?"*.

§6.3's *"one expression"* sentence gains a **fourth** consumer and becomes true.