Say which requirements the code was already satisfying

Thirteen requirements were surveyed as built but untagged. Eight of them
were: R3, R6, FR-DEV-1, FR-UI-6, FR-NC-6d, NFR-OPS-3, NFR-PORT-2 and
NFR-SEC-3. Each was read against its full text in requirements.md and
against the code before the tag was added, because a tag that is wrong is
worse than an absent one — it turns a visible gap into an invisible one.

The five that were refused, and why, because the reasoning is the part
worth keeping:

R2 carries "(figure TBD)" in its own acceptance criterion and asks for a
stated prefetch margin and cache-hit rate; neither figure exists anywhere
in the tree and neither quantity is measured, while TD-2 and TD-3 both
describe the thumbnail path falling short of it.

R5 asks for three things and the code does one. The display pipeline does
run at viewport resolution, but "only visible tiles are computed" and
"panning recomputes only newly exposed tiles" need a tile scheduler that
does not exist — and frame_budget.rs currently argues for striking tiled
computation from the interactive path rather than building it.

FR-RAW-2 asks for a trait taking a SourceRef, so that a second decoder can
be added without changing callers. What exists is free functions over
&[u8]. That meets the requirement's stated *purpose* — the same decoder
serves a local file, a SAF document and a byte range, which is exactly why
it takes bytes — but there is no trait and no second implementation seam,
so the requirement should probably be amended rather than tagged.

NFR-ARCH-1 asks for named executors with stated thread counts.
architecture.md §7.1 states the table; nothing implements it. Workers are
twenty-odd ad-hoc std::thread::spawn sites, each building its own
one-worker tokio runtime, with no decode pool, no GPU-submit executor and
no I/O pool. The requirement's own text says R4 and NFR-P9 "assert an
outcome with no stated means", and that is still true.

NFR-SEC-4 is satisfied by absence — there is no telemetry — and absence
has no module to tag. A tag would point at nothing.

NFR-OPS-3 was the closest call of the eight taken. The store is single,
separate from the catalog, survives a catalog rebuild and does not sync
between devices; it has no version *field*, deliberately, and
settings.rs argues why and names the condition that would need one. The
substance is met and the reasoning is recorded where it belongs.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

core/dr-export/src/lib.rs

@@ -1,4 +1,4 @@
-//! TRACES: FR-EXP-1 | FR-EXP-2 | FR-EXP-3 | FR-EXP-4 | FR-EXP-6 | FR-EXP-9
+//! TRACES: FR-EXP-1 | FR-EXP-2 | FR-EXP-3 | FR-EXP-4 | FR-EXP-6 | FR-EXP-9 | R3
 //! Turning a rendered frame into a file's worth of bytes.
 //!
 //! # What this crate is, and is not

core/dr-gpu/src/lib.rs

@@ -1,3 +1,4 @@
+//! TRACES: NFR-PORT-2
 //! GPU device and compute for DarkRoom.
 //!
 //! In v0.1 this exists to prove one thing: a compute shader can write a

core/dr-pipeline/src/graph.rs

@@ -1,3 +1,4 @@
+//! TRACES: FR-DEV-1
 //! The edit graph — an ordered set of operations (ARCH §3.4).
 //!
 //! CPU-side state, deliberately. The GPU device can be lost and rebuilt at any

core/dr-pipeline/src/lib.rs

@@ -1,3 +1,4 @@
+//! TRACES: R3
 //! The develop pipeline — operations, descriptors, and shader composition.
 //!
 //! # What this crate is

core/dr-pipeline/src/sidecar.rs

@@ -1,3 +1,4 @@
+//! TRACES: FR-DEV-1
 //! Sidecar serialisation — the edit graph as durable, mergeable data.
 //!
 //! # Generic, for the same reason the UI is generic

core/dr-sync-folder/src/borrow.rs

@@ -1,4 +1,4 @@
-// TRACES: FR-NC-6c | FR-NC-6a
+// TRACES: FR-NC-6c | FR-NC-6a | FR-NC-6d
 //! Hydrating a file for as long as it is needed, and no longer.
 //!
 //! A pass over a library — thumbnails, face indexing — needs each photograph's

core/dr-sync-folder/src/lib.rs

@@ -1,4 +1,4 @@
-// TRACES: FR-NC-13 | FR-NC-12
+// TRACES: FR-NC-13 | FR-NC-12 | FR-NC-6d
 //! A library that is just a directory.
 //!
 //! The second [`RemoteBackend`], and the one that exists to prove the first

core/dr-sync-folder/src/vfs.rs

@@ -1,4 +1,4 @@
-// TRACES: FR-NC-6c
+// TRACES: FR-NC-6c | FR-NC-6d
 //! Virtual-filesystem conventions layered over a directory.
 //!
 //! A sync client in virtual-files mode leaves a *placeholder* where a file is

core/dr-sync-nextcloud/src/lib.rs

@@ -1,3 +1,4 @@
+//! TRACES: R6 | NFR-SEC-3
 //! Nextcloud connector.
 //!
 //! One of two [`RemoteBackend`] implementations, registered through

core/dr-sync-nextcloud/src/provider.rs

@@ -1,4 +1,4 @@
-// TRACES: FR-NC-12 | FR-NC-1
+// TRACES: FR-NC-12 | FR-NC-1 | NFR-SEC-3
 //! Registering Nextcloud as a storage backend.
 //!
 //! The account model this connector used to own now lives in

core/dr-types/src/settings.rs

@@ -1,4 +1,4 @@
-//! TRACES: FR-NC-6a | FR-EXP-1 | FR-EXP-2 | FR-EXP-3 | FR-EXP-6 | FR-PLAT-LIN-1
+//! TRACES: FR-NC-6a | FR-EXP-1 | FR-EXP-2 | FR-EXP-3 | FR-EXP-6 | FR-PLAT-LIN-1 | NFR-OPS-3
 //! Device preferences: how much disk to spend, and what an export defaults to.
 //!
 //! # Why these live beside the session and not in the catalog

ui/dr-ui/src/settings_store.rs

@@ -1,4 +1,4 @@
-//! TRACES: FR-PLAT-LIN-1 | FR-NC-6a | FR-EXP-5
+//! TRACES: FR-PLAT-LIN-1 | FR-NC-6a | FR-EXP-5 | NFR-OPS-3
 //! Reads and writes `settings.json` beside the session config.
 //!
 //! Deliberately a near-twin of [`SessionStore`](dr_sync_nextcloud::SessionStore)

ui/dr-ui/ui/widgets.slint

@@ -1,3 +1,4 @@
+// TRACES: FR-UI-6
 // Shared chrome primitives and the style layer.
 //
 // Before this file every button was a Rectangle + TouchArea written out where