Merge master into partial-preset-scope

# Conflicts:
#	docs/traceability.md
#	ui/dr-ui/ui/app.slint

docs/distribution.md

@@ -0,0 +1,251 @@
+# DarkRoom — Distribution
+
+**Satisfies:** NFR-COMPAT-2 (v1 channels) · FR-PLAT-LIN-3 (sandboxed distribution)
+**Companion to:** [requirements.md](requirements.md) §3.8, §4.8 · [storage.md](storage.md)
+
+NFR-COMPAT-2 asks for the v1 channels to be *stated*, and says why in its own
+second sentence: the channel decision and the storage design are coupled. A
+channel is not a build target. It is a set of constraints that reach back into
+the code — what the application is allowed to see, what it may ask for, and
+what it must be able to do without asking. This document records which channels
+v1 targets and what each one costs, and it is where to look before adding a
+permission to a package rather than after.
+
+---
+
+## 1. The channels
+
+| Platform | Channel | State | What it constrains |
+|---|---|---|---|
+| Linux | Arch source package — [`packaging/PKGBUILD`](../packaging/PKGBUILD) | Built, in tree | Nothing. Full filesystem access, system Vulkan, system secret daemon |
+| Linux | Flatpak — [`packaging/flatpak/`](../packaging/flatpak/) | Manifest in tree, **library selection does not work** (§4) | Portals only. No `--filesystem=`, no host mount table, no typed paths |
+| Linux | AppImage | v1 channel, **recipe not yet written** (§5) | Oldest supported glibc, and no sandbox at all |
+| Android | F-Droid | v1 channel, not yet submitted | GPLv3-clean build, reproducible, no proprietary blobs |
+| Android | Play Store | **Not v1** (§6) | Would make ARCH §6.9 binding as policy rather than as engineering |
+
+Three of these five exist as recipes and two do not. That is stated rather than
+smoothed over, because the value of writing the channels down is knowing which
+constraints are already being met and which are promises.
+
+### What every channel has to get right
+
+Independent of packaging format, and each of these has bitten a package
+somewhere:
+
+- **One identifier, four places.** `paris.tourolle.darkroom` is the AppStream
+  component id, the `.desktop` basename, the Flatpak application id, and the
+  string `dr_ui::run` sets as the Wayland `app_id` and X11 `WM_CLASS`. A rename
+  that misses one of them costs the icon in the shell or the association in the
+  software centre, and neither failure announces itself.
+- **The metainfo, not just the desktop entry.**
+  [`packaging/paris.tourolle.darkroom.metainfo.xml`](../packaging/paris.tourolle.darkroom.metainfo.xml)
+  is the single description of the application, installed by every channel that
+  has somewhere to put it. Its `metadata_license` is CC0-1.0 and its
+  `project_license` is GPL-3.0-or-later; those differ on purpose — see the
+  comment in the file.
+- **Vulkan is a requirement, not a preference.** The develop pipeline is
+  compute shaders through wgpu, and NFR-R8 — how far a CPU fallback goes — is
+  still open, so today there is nothing behind it. A package that installs onto
+  a machine with no working ICD produces an application that starts and cannot
+  develop.
+- **A Secret Service implementation, or an honest degraded mode.** FR-NC-2 is
+  explicit that the absence of a secrets daemon is a stated degraded mode and
+  never a silent fall back to plaintext. Packages express this as an optional
+  dependency (the PKGBUILD) or a talk hole (the Flatpak manifest), never as a
+  hard dependency — a headless or minimal-WM install is a supported way to run.
+- **The face models are Git LFS objects.** A checkout without `git lfs pull`
+  has ~130-byte pointers where 11 MB models should be. Both the PKGBUILD and
+  the Flatpak manifest check the file size and refuse, because the alternative
+  is a package whose face indexing fails inside the graph loader on a user's
+  machine rather than on the packager's.
+
+---
+
+## 2. Why Flatpak is the channel that matters most
+
+Not because it is expected to be the most used. Because it is the only one that
+tests anything.
+
+The Arch package and an AppImage both hand the application the same
+unrestricted process the developer runs it in, so neither can discover that a
+design assumed unrestricted access. Flatpak takes that assumption away, and
+FR-PLAT-LIN-3 exists to make the discovery happen deliberately rather than in a
+bug report. §4 is what it discovered.
+
+The same argument runs the other way on Android, where SAF has been the only
+option since before the first line was written (ARCH §6.9) and `SourceRef`
+exists because of it. Linux got the abstraction — `LocalStorage::grant` is the
+one place a `Path` enters — and never got the constraint that would have proved
+it worked.
+
+---
+
+## 3. What already works inside the sandbox, unchanged
+
+Worth listing, because it is the part FR-PLAT-LIN-1 quietly paid for in
+advance:
+
+- **XDG directories.** Flatpak redirects `XDG_CONFIG_HOME`, `XDG_DATA_HOME` and
+  `XDG_CACHE_HOME` into `~/.var/app/paris.tourolle.darkroom/`. Settings
+  (`settings_store.rs`), accounts (`dr_sync::account`), the catalog and the
+  thumbnail store all read those variables, so every one of them lands in the
+  application's own directory with no code change and no permission.
+- **The face models.** `system_face_models_dirs()` reads `$XDG_DATA_DIRS`
+  rather than hard-coding `/usr/share`, which is exactly why `/app/share`
+  inside a Flatpak is found by the same lookup that finds the Arch package's
+  copy.
+- **Opening a photograph from a file manager.** The `.desktop` entry declares
+  the RAW MIME types and `Exec=darkroom-desktop %F`; under Flatpak the file is
+  exported through the document portal and arrives in `argv` as a path under
+  `/run/user/$UID/doc/`, which is mounted in every sandbox. `main.rs` takes
+  paths from `argv` and `collect()` handles a file or a directory. This is
+  genuine portal-mediated access and it needs nothing new.
+- **The Nextcloud sign-in browser.** `open_in_browser` spawns `xdg-open`; the
+  freedesktop runtime's `xdg-open` forwards to the OpenURI portal, and portal
+  calls need no `--talk-name` because Flatpak always permits them. FR-NC-1's
+  "system browser, never an embedded webview" therefore holds inside the
+  sandbox for the same reason it holds outside it.
+- **Credentials.** The keyring crate speaks the Secret Service D-Bus interface,
+  reached through the session-bus proxy with one talk hole. The app password
+  stays visible to `secret-tool` and Seahorse, which is what keeps it
+  individually revocable by the user.
+
+---
+
+## 4. What does not work: choosing a library
+
+**FR-PLAT-LIN-3 is not satisfied today, and the manifest does not pretend
+otherwise.**
+
+A folder library is chosen by typing an absolute path. `dr-sync-folder`'s
+provider declares `SignIn::EndpointOnly` with the placeholder
+`/home/you/Pictures`, and `normalise_endpoint` expands `~`, requires the path
+to be absolute, and checks it with `std::fs`. Nothing in the tree calls the
+FileChooser portal — there is no `ashpd`, no `rfd`, and no toolkit file dialog
+anywhere in `ui/`, `platform/` or `core/`.
+
+Inside a sandbox with no `--filesystem=`, `$HOME` still resolves to the real
+home *path* but that directory holds only the application's own
+`.var/app/…` tree. So a typed `~/Pictures` fails the `exists()` check and the
+launch screen says `No folder at /home/you/Pictures.` — a truthful message
+about a situation the user cannot fix from inside the application.
+
+Import is blocked one step earlier. `dr_plat::volumes()` finds a camera card by
+reading `/proc/self/mountinfo` and the `removable` flag under `/sys`. A
+sandboxed process is in its own mount namespace, so the table it reads
+describes the sandbox; a card mounted at `/run/media/…` on the host is not in
+it. `volumes()` correctly returns an empty list, which the interface presents
+as "no card found" — right for the code, wrong for the user, who is looking at
+a card.
+
+### The permission that would hide this, and why it is not in the manifest
+
+`--filesystem=host` makes both work immediately and is the thing FR-PLAT-LIN-3
+names as the alternative to portals. Granting it would mean the sandboxed build
+never exercises the sandbox, which removes the entire reason for shipping one
+(§2). `--filesystem=xdg-pictures` is narrower and would be tempting, but it is
+still a static grant that lets a typed path resolve — it makes the same design
+work by not testing it, only in a smaller directory.
+
+So the manifest grants no filesystem access at all. The consequence is stated
+plainly: **a Flatpak built from this manifest can open photographs handed to it
+and cannot yet be pointed at a library.**
+
+### What closes it
+
+Two changes, in this order:
+
+1. **A portal file chooser behind a platform seam.** `ashpd`'s
+   `OpenFileRequest` with `directory(true)` returns a URI the document portal
+   has exported, which the sandbox can read and which stays valid across
+   restarts. It resolves to a real path under `/run/user/$UID/doc/`, so
+   `normalise_endpoint` accepts it as it stands — `canonicalize()` on a fuse
+   path returns the path itself. The seam matters more than the crate: this
+   belongs beside `LocalStorage::grant` in `dr-plat`, which is already the one
+   place a `Path` enters the application, and must not become a second way for
+   `ui/` to learn about paths.
+2. **Removable volumes through the same door.** There is no portal for "list
+   the mounted cards". The honest answer is that under a sandbox
+   `imports_supported()` should report the same `false` it reports on Android,
+   for the same reason it gives there — the operation cannot be performed
+   however hard the user tries — and the import flow should offer the folder
+   chooser instead of a volume list.
+
+**Done when:** a Flatpak built from
+[`packaging/flatpak/paris.tourolle.darkroom.yml`](../packaging/flatpak/paris.tourolle.darkroom.yml),
+with its `finish-args` unchanged and no `flatpak override` applied, can select a
+library root, scan it, and write a sidecar back into it.
+
+### Running a Flatpak build before then
+
+For testing the rest of the application inside the sandbox, grant the access
+per-installation rather than in the manifest, so the file that describes the
+application keeps telling the truth:
+
+```bash
+flatpak override --user --filesystem=~/Pictures paris.tourolle.darkroom
+```
+
+---
+
+## 5. AppImage
+
+A v1 channel, and the recipe is outstanding work rather than a decision to be
+made. What it will have to account for, none of which is a surprise:
+
+- **glibc.** An AppImage links against the oldest glibc it must run on, so it
+  is built in a container with an old base rather than on a rolling-release
+  developer machine. A release binary built on a current rolling-release host carries
+  `GLIBC_2.44` references and would run on almost nothing else.
+- **What to bundle and what not to.** The binary links fontconfig, freetype,
+  expat, libpng, zlib, brotli and bzip2 — bundle those. It does *not* link
+  Vulkan, libxkbcommon or either display-server library: wgpu `dlopen`s
+  `libvulkan.so.1`, and `x11rb` and `wayland-client` speak the wire protocols
+  in Rust. The Vulkan loader and the ICD must come from the host, and bundling
+  a loader is the classic way to break an AppImage on a driver it did not
+  expect.
+- **The models.** ~15 MB of ONNX weights inside the image, or a first-run
+  download. In-tree is consistent with how the Lensfun database ships and with
+  NFR-SEC-5's local-first posture; the licence question (D13) is the same one
+  it is everywhere else and is not made easier or harder by this channel.
+- **No sandbox.** An AppImage tests nothing about FR-PLAT-LIN-3. It is a
+  convenience channel for distributions the PKGBUILD does not serve, and should
+  never be the channel a portal problem is discovered on.
+
+---
+
+## 6. Android: F-Droid in v1, Play deferred
+
+NFR-COMPAT-2 says Play distribution is what makes ARCH §6.9's constraints
+binding, and that is worth reading precisely, because the constraint is already
+met and would be met whatever the channel.
+
+§6.9 is *verified*, not assumed: `MANAGE_EXTERNAL_STORAGE` is not grantable
+under Play policy, and `READ_MEDIA_IMAGES` would not help because proprietary
+RAW is not typed `image/*` by the platform scanner and does not appear in
+`MediaStore.Images`. SAF is the only route that works, so FR-PLAT-AND-1 asks
+for it unconditionally and `SourceRef` (ARCH §3.1) exists to make it possible.
+A sideloaded or F-Droid build *could* ask for broader permissions; it would
+gain nothing by doing so.
+
+So the coupling runs the opposite way from how it is usually described. Play is
+deferred for a reason that has nothing to do with storage: GPLv3 distribution
+through Play is generally workable but has not been confirmed for this project
+(ARCH §14), and F-Droid has no such question. Confirming it is a licence-reading
+exercise; nothing in the storage design waits on the answer.
+
+---
+
+## 7. Where the recipes live
+
+```
+packaging/
+  PKGBUILD                                  Arch source package
+  paris.tourolle.darkroom.desktop           the desktop entry, installed by every channel
+  paris.tourolle.darkroom.metainfo.xml      AppStream, installed by every channel
+  flatpak/
+    paris.tourolle.darkroom.yml             the manifest, and where the permissions are argued
+```
+
+`packaging/` also accumulates built `.pkg.tar.zst` artefacts from local
+`makepkg` runs. Those are not part of any channel and should not be committed.

docs/outstanding.md

@@ -0,0 +1,358 @@
+# DarkRoom — Outstanding work
+
+**Status:** Living document · first written 2026-08-29
+**Companion to:** [requirements.md §7](requirements.md), [technical-debt.md](technical-debt.md),
+[traceability.md](traceability.md)
+
+What is specified and not built, and for each cluster whether that is a decision, a dependency, or a
+gap nobody has looked at.
+
+This document exists because [traceability.md](traceability.md) cannot tell those apart. It reports
+one number — the share of requirements carrying a `TRACES` tag — and a missing tag means either
+"nobody has built this" or "somebody built it and did not say so". Both read the same way in the
+summary table, which makes that figure pessimistic *and* uninformative at once: it understates what
+works while hiding which of the remainder matters. Eight requirements gained a tag on this branch
+because the code already satisfied them and nobody had said so. Everything below is the other kind.
+
+It is also not a plan. [requirements.md §7](requirements.md) records what was deferred deliberately
+and needs no argument; this records what is still nominally in scope, so that the distance between
+the register and the binary is visible rather than something a reader has to reconstruct from a
+percentage. Where the honest answer is "this requirement should be amended rather than met", it says
+so — an unbuilt requirement that nobody intends to build is worse than a deferred one, because it
+keeps costing attention.
+
+**Four of these are being built right now**, in parallel worktrees, and are marked **⟳ in
+progress** where they appear: focus peaking (part of FR-CULL-3), burst grouping (FR-CULL-5),
+Flatpak packaging (FR-PLAT-LIN-3), and Android platform integration (FR-PLAT-AND-2/4/5/6). Strike
+those lines as they land rather than rewriting around them.
+
+---
+
+## 1. Plugins — 21 requirements, and a contradiction to resolve before any of them
+
+**Untagged:** FR-PLG-1, -1a, -2a, -2b, -2c, -3, -3a, -4, -4a, -5, -5a, -5b, -5c, -6, -6a, -7, -8,
+-9, -10, -11, -12.
+
+No plugin host exists. No crate loads anything at runtime: there is no manifest reader, no WASM or
+Lua engine, no registry, no signature check, no install path, no capability grant, no per-plugin
+failure ledger. `declared/mod.rs` says as much in its own documentation — the operation format is
+"not a plugin directory read at startup".
+
+**Two of §3.10's requirements are met, and they are the interesting two.** FR-PLG-2 and FR-PLG-2d —
+the declarative node format — are built and tagged: `core/dr-pipeline/ops/*.yaml` compiled by
+`build.rs`, with the restricted expression grammar in `declared/expr.rs` and a parity test asserting
+a declared operation and a hand-written one produce identical output.
+[code-health.md §3](code-health.md) calls it "a working plugin system that happens to resolve at
+build time", and that is exactly right. What is missing is not the format; it is everything that
+would let somebody who is not in this repository use it.
+
+**The contradiction.** [requirements.md §7](requirements.md) lists `| Plugin API | — |` among the
+things deferred for v1 — a bare row, where most deferrals carry a justifying note. §3.10 then spends
+roughly 280 lines and 23 requirement IDs specifying that same Plugin API in detail. Both statements
+are in the register of record, and the traceability denominator counts the second one: 21 IDs, 12%
+of all 179 defined requirements, worth about twelve points of coverage on their own — and nearly a
+third of everything the matrix reports as uncovered. A reader looking at the coverage figure has no
+way to know that, or that the subsystem behind it is one the same document says is not in this
+version.
+
+**And D16 is open.** [Decision D16](requirements.md) — plugin licensing — records that GPLv3
+answers the derivative-work question differently for each of §3.10's three plugin forms, and that
+this "must be answered *before* an ecosystem exists, not after", because a term introduced later
+cannot be applied to plugins already written. D16 explicitly does not block FR-PLG-2; it blocks
+publishing a third-party format as stable.
+
+**What would resolve this:** an edit to `requirements.md`, not code. Either §7 drops the row, or
+§3.10 is marked deferred with the two built requirements carved out. Until one of those happens the
+coverage figure is measuring a decision that has already been taken, and taking it again every time
+somebody reads the matrix.
+
+---
+
+## 2. Culling — the stated differentiator, half built
+
+[D11](requirements.md) names culling "the core differentiator". FR-CULL-1, -2, -4 and -8 through -12
+are built. Four are not.
+
+**FR-CULL-3 — Raw-truth overlays. All three bullets, unbuilt.** Focus peaking does not exist
+anywhere; the string appears zero times in the tree.
+
+The other two are easy to mistake for present, and are not. A histogram and clipping indicators do
+exist — `dr-gpu/src/histogram.rs`, `ui/dr-ui/src/histogram.rs`, the panel in `histogram.slint` —
+but they are tagged FR-DSP-7 and they answer the opposite question. They read `AdjustPass`'s 8-bit
+output and count clipping as `r == 255`, which is to say they describe **the frame the display is
+about to show**, after the whole develop chain has run. FR-CULL-3 asks for the histogram of the
+*sensor data*, on the explicit grounds that a rendered image "systematically lies about what is
+recoverable in the raw". A readout that measures the render cannot answer that however it is
+presented, so this is not a matter of moving an existing widget into the culling view.
+
+The requirement exists because a culling decision made against a rendered preview is a decision made
+against the wrong image, and the whole of it is still to build. **⟳ in progress** (focus peaking).
+
+**FR-CULL-5 — Burst and near-duplicate grouping.** Absent. Worth knowing before it is built:
+`core/dr-face/src/calibrate.rs` already *assumes* it exists — "since FR-CULL-5 already groups
+bursts, positives are bootstrapped from bursts" — and in fact bootstraps from confirmed labels
+instead. That comment is a forward reference to this requirement and will need correcting either
+way. `core/dr-catalog/src/dedup.rs` is not this: it is re-import detection under FR-CAT-11, matching
+a file against one already catalogued, not two photographs against each other. **⟳ in progress**.
+
+**FR-CULL-6 — Compare and survey.** Absent. No side-by-side view, no synchronised zoom or pan.
+This is the one of the four with no adjacent machinery at all, and it is also the one that most
+directly distinguishes culling from browsing.
+
+**FR-CULL-7 — Culling on tablet.** Absent, and blocked by the three above rather than independent
+of them: there is no separate tablet culling surface to build until there is something to put on it.
+
+---
+
+## 3. FR-DEV-3g — AI denoise
+
+Promoted into v1 by [D11](requirements.md), and named there as the precondition for deferring AI
+masking — the argument being that one learned stage earns the runtime that a second could then
+reuse. Only classical noise reduction exists: `ops/noise_reduction.rs`, a bilateral filter in two
+arrangements, exact for luminance and separable for chroma. It is good, and it is not this.
+
+`models/` holds two face models and nothing else; `core/dr-segment/models/` holds a YOLO
+segmentation model for subject masks. There is no denoise model, no learned demosaic, and no
+inference path that is not face or segmentation.
+
+The obstacle is not the pipeline. It is that [D13](requirements.md) — model licensing — is still
+open for the models that already ship, and adding a third learned stage adds a third licence to
+answer for. Building the runtime before that is settled means owning the same problem in one more
+place.
+
+---
+
+## 4. The render path — FR-DSP-2, FR-DSP-4, NFR-RES-2
+
+**FR-DSP-2 — Tiled computation. Unbuilt, and under challenge.** [architecture.md §6.2](architecture.md)
+calls for tiling "from day one" on the grounds that retrofitting it is a rewrite. It was not built,
+and the evidence has since moved. `core/dr-gpu/tests/frame_budget.rs` carries the argument in its
+own header: one fused dispatch over a viewport-sized target is comfortably inside the frame budget,
+and "if that stops being true, the recommendation to strike tiled computation from the interactive
+path stops being supported, and this test is what says so."
+[technical-debt.md TD-4](technical-debt.md) reaches the same place from the other direction — a
+tiled convolution at clarity's radius reads nearly twice the taps that an untiled one does, so the
+stage that looks most like it wants a tile cache is the stage that would be hurt most by one.
+
+What exists is the declaration and not the mechanism: `DetailPass::radius` is documented as the halo
+a tile would have to be grown by, with a test that pins it, and there is no scheduler to read it.
+That is deliberate plumbing, not an oversight.
+
+**So the open question here is not "when is tiling built" but "is FR-DSP-2 still a requirement".**
+Two measurements say it costs more than it saves on the interactive path. Neither says anything
+about the export path or about a device under memory pressure, which is where the case for it
+actually lives — and that is spike S6, which has not run.
+
+**FR-DSP-4 — Progressive refinement.** Unbuilt. FR-DSP-1's proxy rendering and TD-4's
+quarter-resolution base are adjacent and are not it: both are fixed choices about what resolution to
+compute at, where FR-DSP-4 asks for a first frame that is deliberately cheap and a second that
+replaces it. Nothing tracks a "this frame is provisional" state.
+
+**NFR-RES-2 — Images larger than GPU memory.** No answer, and §4.3 knows it: the requirement text
+itself asks the reader to "decide explicitly" how ARCH §6.4 and NFR-RES-2 are reconciled. There is
+no headroom budget, no allocation-failure fallback, and no spill. Spike S6 — a tiled pipeline on a
+mid-range Android device with an image larger than available GPU memory — is the one that would
+settle both this and FR-DSP-2, and there is no evidence it has run.
+
+---
+
+## 5. Android beyond running, and Flatpak
+
+The Android app is not a stub — it builds an APK, runs the whole application, unpacks bundled face
+models, and has been measured on a tablet ([faces.md §12.1](faces.md),
+[technical-debt.md TD-1](technical-debt.md)). What is missing is the platform contract around it.
+
+**FR-PLAT-AND-1 is tagged and should not be relied on.** The requirement demands that library access
+be obtained *exclusively* through the Storage Access Framework. There is no SAF code: no
+`ACTION_OPEN_DOCUMENT_TREE`, no `takePersistableUriPermission`, no `DocumentsContract`. The two tags
+rest on a `SourceRef::Document` variant that nothing constructs and a volumes helper, which is the
+"plumbing a future feature would use" case [CONTRIBUTING.md](../CONTRIBUTING.md) and
+[code-health.md CH-4](code-health.md) both warn about. Android reaches a library through a Nextcloud
+account or a folder, over paths, like the desktop.
+
+That has a consequence for the rest of the cluster: **FR-PLAT-AND-2** — detecting the loss of a
+granted tree permission and marking images offline rather than deleting rows — cannot be built until
+there is a permission to lose. It is listed here as unbuilt, but it is blocked, not skipped.
+
+**FR-PLAT-AND-4** (managed background execution, foreground service for exports, stated Doze
+behaviour): the manifest declares one activity, no service, and neither `FOREGROUND_SERVICE` nor
+`POST_NOTIFICATIONS`. **FR-PLAT-AND-5** (`onTrimMemory` with a stated eviction order): no callback
+is registered, though the eviction order it is supposed to drive is specified in FR-NC-6's text.
+**FR-PLAT-AND-6** (view and share intents, `FileProvider`): the only intent filter is
+`MAIN`/`LAUNCHER`. **⟳ in progress** for this group.
+
+**FR-PLAT-LIN-3 — Flatpak.** `packaging/` holds an Arch `PKGBUILD` and a `.desktop` entry. There is
+no Flatpak manifest, nothing goes through a portal, and `platform/dr-plat/src/secrets.rs` talks to
+the Secret Service directly rather than through the portal the requirement names. **⟳ in progress**.
+
+**NFR-COMPAT-2 — distribution channels.** Unstated, and this is the requirement that makes the
+others binding: §4.8 observes that the decision to publish on Play is what turns SAF from a
+preference into a constraint. Spike S11, the Play permissions dry-run that would settle it, has not
+run. Related, NFR-COMPAT-1's baseline is real but scattered — API 28/36 live in the Android
+Dockerfile and are checked in CI against the built ELF, which is good — while the items the
+requirement singles out are missing: whether `shaderFloat16` and 16-bit storage are required (the
+one it flags as jeopardising R1), minimum RAM, minimum desktop Mesa, and a named reference device
+from a second GPU vendor.
+
+**NFR-OPS-2 and NFR-OPS-4.** Crash reporting is a `log::error!` panic hook on Android and nothing at
+all on desktop: no local crash record, no backtrace capture, no upload path and therefore no opt-in
+gate to guard it. Update and first run are undefined; the concrete reason NFR-OPS-4 gives — that D2
+pins rawler at a non-SemVer alpha whose camera-support fixes users will need — is unaddressed, and
+there is no update mechanism of any kind.
+
+---
+
+## 6. Accessibility and internationalisation — the hard half is done and the easy half is not
+
+**NFR-A11Y-1 — Localisation.** `@tr(` appears **zero** times across 14,482 lines of Slint. That
+number overstates the problem, because the part that is genuinely architectural was got right:
+`LocalizedKey` keeps display strings out of `core/` entirely, every operation publishes a key rather
+than a label, and `labels::resolve` is the single point where a key becomes text. What that single
+point does, however, is a hardcoded English `match` in Rust source — so changing a translation
+requires a recompile, which is the one thing the requirement explicitly forbids. There is no message
+catalogue in any format, no locale-resolution rule, and no decision recorded about RTL.
+
+The work left is therefore smaller than it looks and entirely mechanical: a catalogue format, a load
+path behind `resolve`, and `@tr(` around the Slint literals. The design it needs already exists.
+
+**NFR-A11Y-2 — Accessibility.** `accessible-*` appears five times in the whole interface, all five
+on one control — the parameter slider in `adjust.slint` — and nothing is set from the Rust side at
+all. Everything else in eighteen Slint files is unnamed to AT-SPI and TalkBack. The requirement's own
+caveat, that Slint's Android accessibility needs verifying, is spike S13, which has not run.
+
+**NFR-A11Y-3 — Colour-independent status.** No compliance work found. This is cheap to satisfy while
+a control is being written and expensive to retrofit across forty of them, which is an argument for
+doing it as part of the NFR-A11Y-2 pass rather than after it.
+
+---
+
+## 7. Catalog and sync
+
+**FR-CAT-14 — Migration import.** Reading ratings, labels, keywords and collections out of a
+Lightroom `.lrcat` or a darktable `library.db`. Unbuilt. The destination is not: keywords,
+collections, ratings and the cross-device merge rules are all built and tested, and
+`keywords.rs` already anticipates the arrival ("an import from Lightroom can bring in…"). What is
+missing is only the two source adapters — which is a comparatively contained piece of work for a
+requirement that decides whether somebody can try this software on a library they already have.
+
+**FR-NC-11 — Initial catalog build.** Using WebDAV `SEARCH` (RFC 5323) against `/remote.php/dav/`,
+filtered by mimetype and paginated, in preference to walking folders with PROPFIND. Unbuilt: no
+`SEARCH` request is issued anywhere. The PROPFIND walk this exists to replace is fully built and
+well optimised — ETag pruning under FR-NC-4 turns an unchanged 50k library into one request — so the
+gap is narrower than it reads. It is the *first* build against a large remote library that pays, and
+that is the moment a new user meets.
+
+**FR-CAT-13 — XMP interoperability, tagged and not met.** Read and write standard XMP sidecars. The
+single tag sits on `keywords.rs`, which stores keywords; no XMP is parsed or written anywhere in the
+tree, and `dr-export`'s metadata module says so about its own half ("neither is read by `dr-decode`
+today"). Listed here rather than silently, because a tag makes a gap invisible and this one is
+load-bearing for interoperating with the editors FR-CAT-14 imports from.
+
+---
+
+## 8. The performance targets are unverified, not unmet
+
+Eleven of the fifteen §4.1 targets carry no tag: NFR-P2, -P3, -P4, -P6, -P7, -P8, -P10, -P11, -P12,
+-P14, -P15. That is the uninteresting part of this section.
+
+The interesting part is that §8 and §4.1 both require the same thing, in the same words, and it does
+not exist: an automated benchmark suite against a synthetic 50k catalog, run per commit, where **"a
+regression beyond a stated tolerance is a build failure, not a notification."** There is no
+`benches/` directory in the workspace, no criterion dependency, and no synthetic catalog. The three
+CI workflows run `cargo fmt --check`, clippy, `cargo test --workspace`, a release build, an Android
+cross-build and a layering check. None of them measures anything, so there is no baseline to
+regress against and no tolerance to exceed.
+
+What does exist is narrower and genuinely good: `dr-gpu/examples/frame_budget` is a real instrument,
+its results are committed in [frame-budget.md](frame-budget.md) with the machine and profile named,
+and TD-4's before-and-after was measured with it. But it is run by hand — frame-budget.md's own
+instruction is "rerun and diff this file" — and the guard version that does live in CI skips itself
+where there is no GPU adapter, which the workflow notes is the normal case on a runner, while
+asserting its CPU half only when `debug_assertions` is off, which a dev-profile `cargo test` is not.
+In CI it therefore asserts approximately nothing.
+
+**The claim to take from this is precise.** Nothing here says the performance targets are missed.
+Several are plausibly met. It says that if one were broken tomorrow, nobody would find out — which
+is the failure mode §8 was written to prevent, and the reason it belongs in this document rather
+than in a backlog.
+
+---
+
+## 9. Two core requirements that cannot be closed as written
+
+**R1 — Cross-platform output within a bounded tolerance.** §2 states that the threshold "must be
+fixed before spike S9", because S9 both validates R1 and calibrates what tolerance is achievable.
+The threshold was never fixed and S9 has not run, so R1 currently has no acceptance criterion at
+all — there is nothing a test could assert.
+
+Worse, the matrix reports R1 as *covered*. Both of its tags are string literals inside the
+traceability tool's own unit tests (`tools/traceability/src/lib.rs`), which the tool scans along with
+everything else, because a fixture demonstrating tag extraction is indistinguishable from a tag.
+NFR-OPS-1 is covered the same way, from a tag on `compute_coverage` — and no rotating, size-capped
+on-disk log exists; logging goes to stderr and logcat. These are two of the cases
+[CONTRIBUTING.md](../CONTRIBUTING.md) already warns about, now named.
+
+**R2 — Efficient display of huge RAW libraries.** Its acceptance criterion contains "*(figure
+TBD)*" — the scroll velocity below which no cell may render as a placeholder — and asks for a stated
+prefetch margin and cache-hit rate. No figure is stated anywhere in the tree, neither quantity is
+measured, and [TD-2](technical-debt.md) and [TD-3](technical-debt.md) both describe the thumbnail
+path falling short of it in ways that were measured. R2 was deliberately left untagged on this branch
+for that reason: the machinery is substantial and the criterion is unmet and partly undefined.
+
+Both belong with §8 above. A requirement whose threshold was never chosen and a target nothing
+measures fail in the same way — not by being wrong, but by being unfalsifiable.
+
+---
+
+## 10. Spikes
+
+§9 defines fourteen validation spikes and says of three of them: "S1, S2 and S10 are the three that
+can invalidate the architecture."
+
+Only **S1** (Slint + wgpu zero-copy on Linux) and **S14** (the face pipeline on a real library) have
+recorded results. S14's are the best evidence of any spike — a dedicated document, a measured pass
+over an 18,143-face library, a named device and a reproducible command — though D13's licensing half
+remains open.
+
+**S6, S9, S10, S11 and S13 show no evidence of having run at all.** Each is referenced only from the
+requirement text that asks for it:
+
+| Spike | Would settle | Blocked on |
+|---|---|---|
+| S6 | FR-DSP-2, NFR-RES-2 — tiling and images larger than GPU memory | Nothing; needs a device and a large image |
+| S9 | R1's tolerance threshold, and therefore R1 | Nothing; the threshold is defined *by* running it |
+| S10 | Whether SAF at 10k files meets NFR-P1/P3 | §5 — there is no SAF code to measure |
+| S11 | NFR-COMPAT-2, and whether Play makes SAF binding | Nothing |
+| S13 | NFR-A11Y-2 on Android | §6 — there is almost nothing to test with |
+
+S2, S3, S4, S5, S7, S8 and S12 are also unrun, several with acknowledgements in the code that say
+so (`dr-sync/src/upload.rs` on S8, `dr-sync-nextcloud/src/lib.rs` on S3). S2 is one of the three
+architecture-invalidating spikes and needs Adreno and Mali hardware, which the manifest notes no
+emulator represents.
+
+The pattern is worth stating rather than leaving to be inferred: the spikes that ran are the ones
+whose subject was being built anyway. The ones that did not are the ones that would have said
+whether something *should* be built — which is the opposite of the order §9 asks for.
+
+---
+
+## 11. D12, which governs all of the above
+
+[Decision D12 — scope versus pace](requirements.md) is still **OPEN**, and says:
+
+> The calibration selected an ambitious feature set — full tablet editing, full ingest, culling as a
+> differentiator, complete GPU masking, AI denoise, Fuji-first colour, deep sync, sidecar durability
+> — against a stated pace of evenings and weekends, indefinitely.
+>
+> **Those are not compatible as stated.**
+
+Sections 1 through 10 are what that incompatibility looks like eleven versions later, and they land
+almost exactly where D12 predicted: tablet editing carries SAF at unproven scale, background
+execution limits and two GPU vendors to validate (§5), and every one of those is unbuilt or unrun.
+The parts that *were* built — the develop pipeline, sync, faces, the catalog — are the parts that
+did not need a decision first.
+
+D12 is not resolved by choosing to work faster. It is resolved by moving requirements across the
+line into §7, which costs nothing but the admission, and which this document is intended to make
+easy: every cluster above is a candidate, and each says what it would take to build and what it
+would cost to drop. Resolving D12 sets D3 and [architecture.md §10](architecture.md)'s Phase 2.

docs/technical-debt.md

@@ -55,6 +55,27 @@ readback is at viewport resolution, not sensor resolution. The 7.43 ms at 4K in
 not the bill. **It has not been measured on the device**, which is the first thing to do if the
 develop view feels heavy on the tablet; do not assume this is the cause without a number.
 
+### And a second transfer, while focus peaking is on
+
+Added 2026-08-29 with FR-CULL-3. The focus-peaking overlay is a compute pass writing its own
+`Rgba8Unorm` texture, which on desktop reaches the compositor with no copy — but on Android there is
+no more a path for *that* texture than for the frame it belongs to, and an overlay that stayed on
+the device while the picture underneath it did not would simply never be seen. So
+`FocusPeakPass::read_overlay` follows the frame back through memory, and the Android frame path
+carries **two** full-resolution `copy_texture_to_buffer` transfers instead of one.
+
+This is recorded under TD-1 rather than as its own entry because it is not an independent choice.
+It exists only because TD-1 exists, it is bounded by the same thing — `render` fits the pass to the
+canvas, so both transfers are at viewport resolution — and TD-1's "Done when" already covers it:
+whichever of the three fixes above lands removes the readback for the frame and the overlay
+together, because both are the same missing capability.
+
+Two things worth saying plainly. The doubling is **reasoned, not measured on the device** — the same
+gap TD-1 admits about its own cost, and the reason neither number should be quoted as a measurement.
+And it is paid only while the photographer has the overlay switched on: `DevelopSession::focus_overlay`
+returns on its first line when peaking is off, so with it off there is no dispatch and no transfer,
+and the Android frame path is exactly what it was before this feature existed.
+
 ### Paying it off
 
 Any one of these removes it: