166 Commits

Include renames

Author	SHA1	Message	Date
dtourolleandClaude Opus 5	d7aeafaf84	Move to wgpu 29, the version Slint can share a device with ... Groundwork for spike S1. Importing a texture into a Slint scene requires it to come from the *same* `wgpu::Device` Slint renders with, and Slint hands out a device of the version it was compiled against. Slint 1.17 offers `unstable-wgpu-28` and `unstable-wgpu-29` and nothing older, so wgpu 23 could never have met it: two semver-incompatible wgpu crates in one tree are two distinct types, and the device would not typecheck across the gap. The version is therefore not a free choice, and the manifest now says so — Slint and wgpu move together or not at all. The Slint requirement is also corrected from "1.9" to the 1.17 it has actually been resolving to. Nothing about the render path changes here. The readback bridge is still in place and still the display path, so this is verified by the tests that already existed rather than by anything new: 39 dr-gpu tests, which compare real pixels off a real device, and 888 across the workspace, all passing. Zero-copy lands separately and small. What the six releases cost, in full: - `ImageCopyTexture`/`ImageCopyBuffer`/`ImageDataLayout` became the `TexelCopy*` names (24). - `Instance::new` takes the descriptor by value, and `InstanceDescriptor` lost its `Default` — it carries a boxed display handle now, so a headless context says `new_without_display_handle` and means it. - `request_adapter` returns `Result` rather than `Option` (24). - `DeviceDescriptor` absorbed the API trace from `request_device`'s second argument and gained `experimental_features` (25). - `PipelineLayoutDescriptor` takes `Option<&BindGroupLayout>` per slot, and `push_constant_ranges` became `immediate_size`. - `Maintain` became `PollType`, and `poll` is fallible. Two of those are improvements worth having rather than churn. The error scope is a guard whose `pop` runs on drop, so an early return from the pipeline compiler no longer leaves a scope open on the device for whatever ran next to fall into. And a fallible `poll` reports a lost device (NFR-R7) at the point it happens, where before the map callback simply never arrived and the failure surfaced later as a readback that spun out its poll limit. Still to do for S1: dr-ui renders through `renderer-femtovg`, which is OpenGL. Texture import needs Slint itself rendering on wgpu. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-16 21:34:04 +02:00
dtourolleandClaude Opus 5	3b0950c39b	Regenerate the matrix that dr-thumbs moved out from under ... Commit 9a51cc8 edited core/dr-thumbs/src/lib.rs and pushed its TRACES tag from line 341 to 376 without rerunning the extractor, so the two rows that cite it — FR-CAT-15 and NFR-RES-4 — kept pointing at a line that is now something else. Nothing else in the report changed. The matrix records line numbers, so any edit above a tag dates it; the CI step exists precisely because that staleness is invisible in review. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-16 21:19:51 +02:00
dtourolleandClaude Opus 5	7c57f490fe	Declare a develop operation in YAML, and generate the rest ... An operation was, in the overwhelming majority of cases, four facts: what its parameters are, what uniforms they compute, what WGSL those uniforms drive, and where it sits in the chain. Written in Rust those four facts arrived wrapped in ninety lines of trait implementation — a match on parameter id to a struct field, another match back, an is_active comparing each field to its default, a Vec<Uniform> built by hand. All mechanical, and each one a place to make a silent mistake: a param() arm returning the wrong field reads perfectly and breaks the sidecar round-trip. So the four facts are the file now. core/dr-pipeline/ops/<id>.yaml is a node, build.rs compiles it into the same Operation impl as before, and the result lands in OUT_DIR — the same reasoning as style.yaml -> theme.slint, including why it does not land beside the sources it would look exactly like. Nothing downstream can tell a declared node from a hand-written one: same &'static OpDescriptor, same fused-shader composition, same sidecar. Nine nodes moved: exposure, white_balance, contrast, highlights_shadows, blacks_whites, brilliance, vibrance, saturation, and the shared WGSL helper registry. Their prose came with them, and so did their tests — set/expect/expect_active/expect_wgsl in the declaration compile to real #[test]s, so a node file carries its own proof rather than leaving it behind in a file that no longer exists. Two stayed in Rust and say so with `rust:`. The tone curve's neutral is a relationship between five interpolated points rather than a set of values; the colour mixer generates thirty-six faceted parameters from twelve computed hue bands. A schema stretched to cover either would be a worse language than Rust aimed at one caller. They still declare their position here, because the chain's *order* is the one thing a reader comes to this directory to learn, and an order written half in YAML and half in Rust would be worse than either alone. default_chain() is generated from it. Uniforms are derived by a small expression language — exp2(exposure), blacks / 100 * 0.02 — compiled to Rust rather than interpreted, so an unknown name or a wrong arity is a build error naming the file and the key and the arithmetic costs nothing at runtime. The build script refuses a duplicate order, a filename disagreeing with its id, a default outside its own range, a test value the graph would clamp before the node saw it, a helper that does not define the function it names, and a declared node colliding with a file in src/ops. Verified by adding a scratch node and removing it again: one file, no other edit, and it joined the chain at its declared order with its test running. 237 tests pass in dr-pipeline, clippy and fmt clean. .yaml joins the traceability tool's scanned suffixes, because a node's Rust now lives in OUT_DIR where a tag could never be linked from the report. Coverage 47.7% -> 48.3%. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-16 21:08:16 +02:00
dtourolleandClaude Opus 5	65e6a96a65	Say what the application is doing, in one bar and one list ... Every background job reported into a window property of its own — library-thumbs-done, library-pin-total, library-syncing — which only the grid ever read. A pin download that outlived the view it was started from drew nothing at all once the user opened an image, and there was no answer anywhere to "what is this busy with", because the answer was spread across eight properties nothing collected. They report to one register now (ui/dr-ui/src/activity.rs). It publishes an aggregate, which draws a three-pixel bar across the top of the shell in every view, and a row per job, which the settings page lists: scans, thumbnail batches, pin and open downloads, sidecar uploads, the sync and the trash. Failures stay on the list until they are cleared; routine successes do not, or a scroll would bury them. The handle removes a still-running job when it drops, so a worker that dies mid-transfer takes its row with it rather than leaving the bar sweeping for the rest of the session. Also carries in-flight work from a parallel session — the drawn icon set and the dr-pipeline ops split. dr-pipeline's build script does not compile at this commit; ui/dr-ui does, with clippy clean and its tests passing. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-16 18:32:09 +02:00
dtourolleandClaude Opus 5	67c0237ddd	Make one slider, and take the lids off the develop column ... Two complaints from a tablet, with one cause between them. **Some sliders dragged and others only answered a tap.** They were not the same control. `ParamSlider` read its geometry from a `ParamRow` for the generated panel and `PlainSlider` took plain numbers for the straighten angle, each with its own track, handle, hit area and gesture rules written out separately — and a comment arguing the duplication was safe, because "a slider that dragged differently depending on which panel it sat in would be a worse inconsistency than the duplication". That is exactly what happened. The touch arbitration fixed in the previous commit went into `ParamSlider` and `CurveEditor`; `PlainSlider` kept the old code, so two sliders in the same sidebar behaved differently and which one you got depended on where you were dragging. The duplication failed to survive its first change. There is now one `SliderTrack`, owning the track, the hit area, the claim test, the hover arbitration, click-to-jump and double-click reset. The two wrappers differ only in where their numbers and labels come from. **Nothing in the develop column collapses any more.** Every group was a `Section` with a disclosure triangle, including five operations that carry a single parameter — so the lid was most of the row, wrapping one slider whose own label repeated the heading word for word. A control behind a lid is one the user does not know the pipeline has. `GroupHeading` keeps what the section was actually for: the name, the dot that says something inside differs from its default, and the reset. The reset is now permanently visible rather than appearing on hover, because a hover-only control is one no finger can reach. IMAGE goes back to flat as well. The column as a whole still closes, from the status strip — which is the control that was wanted, at the level it makes sense at. This costs no vertical space: `Section` defaulted to expanded and nothing ever set it otherwise, so the panel was already unfolded and the lids were overhead with no saving behind them. Verified with cargo test -p dr-ui (192), clippy at -D warnings, and an arm64-v8a release build installed on a tablet. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-16 15:38:23 +02:00
dtourolleandClaude Opus 5	489465faf0	Show the photograph the way it was taken ... Nothing read EXIF orientation, so every frame from a body held sideways lay on its side — in the grid, in develop, and in the read-only preview. The tag is honoured as part of *reading the file*, at the same standing as a RAW's masked-photosite crop, never as an edit. It lives as a baseline on Framing rather than as a starting value for quarter_turns, which is what keeps four things true: a sideways file opens unmodified, reset returns it to upright rather than to the sensor's scan order, its sidecar stays empty, and the rotate button still moves the image 90° whatever the file underneath it says. Framing::effective composes the baseline with the user's own turns through the group law rather than by adding turns and OR-ing flags. The naive version gets one case wrong — an odd baseline turn plus a user mirror — and gets it wrong quietly, because the result is still a plausible orientation. The composition collapses to a single permutation, so obeying the tag costs nothing per pixel. dr_decode::orientation is a header-only IFD walk, separate from metadata() for the reason the entry points are separate at all: the grid asks once per cell and must not build a rawler decoder to get one tag. CR3 and RAF fall back to the full read, being neither TIFF nor JPEG. Written down as FR-DEV-3h. Known gap: thumbnails cached before this stay sideways. The store is keyed by file and size, and its shards sync — invalidating them would have every client re-download 25 MB a shard, which is not this commit's call to make. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-16 15:37:05 +02:00
dtourolleandClaude Opus 5	fe66eba87f	Write down the trash requirement the code already implements ... The traceability gate failed on an orphan tag: seventeen sites across dr-catalog, dr-sync, dr-thumbs and the UI claim FR-CAT-15, and requirements.md defines FR-CAT-1 through FR-CAT-14. Not a typo and not a renumbering — the trash was built, designed and documented in the modules that implement it, and the requirement itself was never written. An orphan is the gate working: a tag naming an undefined ID would otherwise count as covered, which is how a matrix comes to report coverage of things nobody specified. FR-CAT-15 now says what trash.rs does, in the terms the module already argues: a soft delete moves the file into `.darkroom-trash/` and the catalog records that it happened, because a flag alone would not survive invariant 5.2.4 — the catalog is rebuildable from sources, so a rescan would find every deleted file still in the library and re-index it. That is also why the scanner exclusion is part of the requirement rather than an implementation detail; the folder and the exclusion are one mechanism and neither works alone. Permanent delete removes the file before the row, a delete of something already gone counts as success, and the count and bytes are shown before emptying. docs/traceability.md is regenerated: 150 requirements, 71 covered, no orphans. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-16 14:48:31 +02:00
dtourolleandClaude Opus 5	94a2686dcb	Fit the interface to the system bars, the finger and the back key ... Four faults that only show on a device, and one that was hiding on the desktop too. The system bars. Target SDK 36 forces edge-to-edge, so the window spans the display and the develop status strip was drawn underneath the clock and the wifi icons. Slint already computes the inset from Android's OnApplyWindowInsetsListener and exposes it as Window.safe-area-insets; nothing read it. The four views now sit inside a shell placed within the safe area. Every inset is zero on the desktop, so that layout does not move. Sliders under a finger. A Flickable steals any gesture that drifts more than 8 logical pixels along its scrolling axis within half a second of the press, and it steals it by cancelling the child. ParamSlider's axis test correctly declined to claim vertical drags, but nothing told the Flickable to stand down once a drag was claimed — so an adjustment would start moving and then be taken away mid-motion. A mouse holds a horizontal line closely enough to stay under 8px; a finger does not, which is why these worked on the desktop and not on the tablet. The claim now sets `interactive: false` for the rest of the gesture. The tone curve had the same fault and worse: its points are dragged vertically, which is the Flickable's own axis, so every drag was stolen — on the desktop as well. The back gesture. Nothing handled it, so back closed the application from anywhere in it. Android delivers it as Key.Back to the focused item and bubbles it up the ancestors, which is the second reason the shell wraps the views rather than sitting beside them. The order is innermost first: settings, then crop, then zoom, then develop to the grid, then a collection scope. Answering false at the top of the stack leaves Android to close the activity, as it does for every other application there. Escape does the same on a keyboard. back_step is a pure function over a flat NavState so the ordering can be tested without a backend: which of two states is left first is the whole of the feature, and it is the part that is easy to get subtly wrong when spelled out in nested ifs over live properties. Develop's canvas now takes focus on show. Without it the arrow keys did nothing until the canvas was clicked, and Key.Back had no focus item to bubble from. Panels that close. The collections sidebar and the develop column are collapsible from the grid header and the status strip. The layout class now supplies only the default: a panel closed to see more of a photograph stays closed while the window keeps its shape, and the choice is dropped when the class changes, because rotating a tablet asks a different question from the one answered in landscape. IMAGE became a Section, being the only group in the column that could not be put away and the one whose content is read first and needed least. Pinch to zoom on the develop canvas, anchored on the midpoint between the fingers (FR-UI-4). The wheel is the desktop's answer and there is no wheel on a tablet. The develop status strip was 28px against the 44px headers on the library and settings pages either side of it — the one screen where a way out has to be found was the one drawn smallest. All three now agree. Verified with cargo test -p dr-ui (192 passing, 6 new), clippy at -D warnings, and an arm64-v8a release build packaged to an APK. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-16 11:59:31 +02:00
dtourolleandClaude Opus 5	fa12afed18	Keep originals on this device, by pin and by use ... Fills in `image_cache`, which the previous commit's "On this device" filter read but nothing wrote. Also carries in-flight work that shared these files: the Android TLS root store, the settings page, and a regenerated traceability report. # Two populations, deliberately separate An original is kept here for one of two reasons, and conflating them produces the exact failure the feature exists to prevent. **Pinned** originals were asked for. Pinning a collection before a trip is a promise, so pinned rows are never evicted and never counted against the budget — a cap that could silently delete a pinned trip would make pinning worthless, because it could not be relied on without checking. **Passively cached** originals are a side effect of working: develop already downloads the whole file, so keeping it costs no bandwidth and saves the entire transfer next time. This population is what the budget bounds, evicted least-recently-used, because it otherwise grows until a day of culling fills a disk. Sharing one budget would let a large pin starve the passive cache, or let browsing evict a pin. They are separate. # What was built `dr_catalog::cache` owns the bookkeeping — held tier, size, last use, pinned — and writes the bytes; deciding to download stays with the caller, which is what keeps a crate with no network out of the network's business. Files are written to a temporary and renamed, so a dropped connection cannot leave a truncated file recorded as a complete original. They are named by image id, not filename: `Photos/IMG_0001.CR2` and `Trips/IMG_0001.CR2` are different photographs, and a flat cache keyed on the name would serve one for the other. `spawn_full_fetch` became read-through. A hit is a disk read; a miss stores what it downloads and enforces the budget. A cache that cannot be opened is a miss, not a failure to open the photograph. Pinning writes intent — `tier_desired` — without downloading, so the button responds immediately, and `spawn_pin_fetch` fills it in sequentially afterwards. Sequential because these are tens of megabytes each: the lanes that make the thumbnail sweep fast buy little against one connection's bandwidth and cost a great deal of memory. A pin interrupted by a lost connection resumes from where it stopped. Schema v5 adds `pinned` and `path`. `pinned` is a column rather than something inferred from `pinned_by_rule`, which is ON DELETE SET NULL and so cannot answer for an image whose rule was deleted. A v4 catalog migrates in place; existing rows default to unpinned, the safe direction. The budget and "keep opened originals" come from the settings page rather than a constant, and are applied at startup rather than only on change — a cache capped at 2 GB last session would otherwise spend this one filling to the default. Turning off keeping leaves what is already cached readable: those bytes are paid for, and refusing them would re-download images sitting right there, including pinned ones. Also removes a doubled `#[test]` introduced in the previous commit. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-11 21:12:01 +02:00
dtourolleandClaude Opus 5	02b66ddfcf	Document trash, collections, thumbnails, and the UI direction ... Specs for the work that follows: soft delete via a MOVE that preserves the remote id, the collection tree and smart collections, the thumbnail store, and the derived-state folder. Adds two design documents. ui-refinement.md names the structural gaps between the v0.1 UI and something that feels like a photo editor. view-composition.md proposes a view controller for the display layer, against the 500-line run() that has become one by accretion. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-09 20:36:23 +02:00
dtourolle	09e3043f4c	Add secure credential storage, sessions, and a launch screen ... Login now persists properly rather than through the JSON file the test harness was using. dr-plat SecretStore trait plus a Secret Service backend. Verified against the live GNOME Keyring: store, retrieve, delete, confirm-gone all round-trip. Session/SessionStore splits credentials from settings — the app password goes to the keyring (FR-NC-2), while server, login, chosen root and format selection are ordinary config. A test asserts the credential never appears in the config file. LaunchModel the launch-screen state machine, testable without a display server: sign in, approve in browser, choose folder, tick formats, sign out. launch.slint the screen itself, in its own file. Absence of a secrets daemon is an explicit degraded mode, not a silent fallback to plaintext — the screen says sign-in will not persist rather than letting the user find out next launch. Android's Keystore backend fails loudly for the same reason: a no-op store would look like it worked and then lose the credential. Two bugs caught by tests rather than by running it: - fail() after busy() signed the user out, because busy() had already discarded the session. A failed *scan* would have logged you out. Busy now carries the session. - normalise_server upgrades http:// to https:// rather than accepting it. NFR-SEC-3 requires TLS, and silently sending a credential in the clear is not a decision to make on the user's behalf. launch.slint is not yet wired into app.slint. Calling slint_build::compile twice replaces the generated module rather than adding to it, which broke the other in-flight work on dr-ui; I reverted that immediately. Wiring it needs an import inside app.slint, which is that work's file to change. 419 tests passing across ten crates.	2026-08-09 15:20:39 +02:00
dtourolleandClaude Opus 5	78e3e6b846	Add the develop pipeline: demosaic and seven raw adjustments ... Decode through display, on the GPU: black/white normalisation, Bayer demosaic, camera colour transform, and the first seven adjustment operations — white balance, exposure, highlights/shadows, blacks/whites, brilliance, vibrance, saturation. Composable shaders. Each operation contributes a WGSL fragment rather than owning a pass, and dr-pipeline fuses the *active* ones into a single compute shader. One texture read and one write per frame regardless of how many adjustments are in play, while the operations stay independent in Rust — adding one is a new file, with no central shader to edit. An operation at neutral settings contributes no code, no uniform and no branch. Uniforms are prefixed per operation so two may both declare `amount`; helpers dedupe by name from a single source of truth. Pipelines cache on a structure hash covering the op-set and its order but not the values, so dragging a slider uploads uniforms and reuses the compiled pipeline. Measured on a 24 MP CR2: 0.60 ms re-render, one pipeline compiled across ten slider positions. The UI is generated, not written. EditGraph::capabilities() reports parameters with their kinds, ranges, defaults and current values; the panel builds one control per entry chosen by ParamKind. No file in ui/ names an operation, and dr-pipeline has no wgpu dependency, so codegen is testable without a device (ARCH §6.5a). Three defects found against real files, each silent: - rawler 0.7.2's `xyz_to_cam` is all zeros — deprecated and no longer populated. The live matrices are in `color_matrix`, keyed by illuminant. Reading the old field yields no colour transform at all. - `cam_to_xyz_normalized()` returns all NaN on any Bayer sensor: it divides each of four rows by its own sum, and the unused fourth (emerald) row sums to zero. Inverting the 3x3 ourselves avoids it. `wb_coeffs[3]` is NaN for the same reason and is normalised at decode. - As-shot white balance reached the uniform block but no shader read it, so the first render of a real CR2 came out violently green. Green photosites collect roughly twice the signal of red and blue. Now applied unconditionally before any operation, with tests on ordering. Demosaic is Malvar-He-Cutler rather than bilinear: gradient-corrected interpolation at one 5x5 neighbourhood per pixel, where bilinear leaves visible zippering on any high-contrast edge at 1:1. Two of the four packed CFA constants were wrong on the first attempt, so all four layouts are asserted to reconstruct the same colour. Crop origins at odd coordinates re-phase the pattern; without that, red and blue swap. X-Trans reports GpuError::UnsupportedCfa rather than approximating with the Bayer path, which would look like a corrupt file. 206 tests, including GPU tests proving every operation and the full seven-operation chain generate compilable WGSL. Known gaps: the display path still reads back to the CPU each frame, which ARCH §6.1 forbids and AC-8 asserts against — it is gated behind the `readback` feature and waits on spike S1 wiring Slint's texture import. Curve shapes are a first draft and want tuning against real photographs. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-09 11:37:58 +02:00
dtourolle	cc1c5c892d	Support requesting VFS hydration; fix Android TLS cross-compilation ... Correcting the previous commit: I claimed VFS placeholders could not be downloaded. That was wrong. The desktop client exposes a socket at $XDG_RUNTIME_DIR/Nextcloud/socket speaking newline-delimited COMMAND:argument, and MAKE_AVAILABLE_LOCALLY:<path> does fetch the file. Verified against client 4.0.7: a 1-byte stub became a real 2.8MB file in 2.8 seconds. Implemented as dr-sync-nextcloud::desktop_client, deliberately optional. Android has no desktop client, no XDG_RUNTIME_DIR socket and no placeholders, so detect() returns None there and callers fall back to the connector. It earns its place only because it is ~30 lines with no dependencies: where a library already lives in a VFS folder, asking the client to fetch beats downloading a second copy over WebDAV and leaving the client's placeholder state inconsistent. What this does not change: hydration is whole-file, so it suits the original tier and never browsing. Filling a grid this way downloads the entire library. Range extraction remains the only mechanism satisfying FR-NC-3, and ARCH §9.0 now says so precisely. Also fixes two real Android build failures found by cross-compiling: - reqwest's `rustls` feature defaults to aws-lc-rs, whose aws-lc-sys crate is C and fails under the NDK — exactly the pain D1 chose Rust to avoid. Switched to rustls-no-provider + ring, installing the provider in the constructor so no caller can build a client that panics on first use. - ring itself needs CC/AR per target; cargo-ndk sets only the linker. Added them to the container. 87 tests passing. dr-sync-nextcloud cross-compiles for aarch64-linux-android.	2026-08-09 10:10:29 +02:00
dtourolle	f8a718f42e	Add Nextcloud connector; reject VFS as a transfer mechanism ... Investigated using the Nextcloud desktop client's Virtual Files as a cache instead of talking to the server directly. Measured on this machine (client 4.0.7): the configured folder holds 121,785 placeholders against 10,267 materialised files, including 7,037 CR2 and 9,411 DNG. Three findings, each independently disqualifying: - Linux VFS is *suffix* mode. A dehydrated IMG.CR2 exists only as IMG.CR2.nextcloud holding one byte; the real name is absent. - Reading a placeholder does not hydrate it. dd of the first 256KB returned 1 byte, the stub was unchanged, and the real name never appeared. There is no FUSE layer — the stub is an inert marker. - Even with hydration the granularity is wrong: VFS has two states, 1 byte or all bytes, and the preview tier needs a ~256KB prefix of a 27MB file. That is ~100x what FR-NC-3 requires. Recorded as ARCH §9.0. Coexistence is still supported: dr-types now recognises *.nextcloud stubs, and the viewer lists them as "not downloaded" rather than as corrupt files or not at all. So the connector talks to the server directly, as D7 specified. Implemented: Login Flow v2, PROPFIND with oc:fileid and nc:has-preview, ETag pruning via a Depth:0 probe, range GET with local slicing when the server ignores the header, conditional PUT, and /core/preview with forceIcon=false. delta() returns Unsupported and says why. Chunked upload v2 is not implemented yet — put() rejects bodies over 5MB explicitly rather than silently truncating. Two bugs found by testing: my hand-computed epoch in a date test was a day out (the parser was right), and quick-xml reaches EOF on truncated input without erroring, so unbalanced elements needed an explicit check — a half-parsed multistatus must not look like an empty directory. 83 tests passing.	2026-08-09 09:09:27 +02:00
dtourolle	9717e59909	Add RAW decode and a working image viewer ... dr-decode exposes four entry points rather than one decode, because callers differ sharply in what they need (ARCH §3.2): culling wants a preview, the grid wants metadata, only develop and export touch sensor data. Fusing them forces a full decode where a header read suffices, which is why Lightroom stalls ~2s per image while culling. Smoke-tested against 1,852 real Canon CR2 files (EOS 6D, ~27MB each): metadata 0.2ms from a 256KB header read, no full decode preview ~250ms 5472x3648, downscaled to 2048 for display jpeg 3.0ms Two findings worth recording: rawler 0.7.2's CR2 decoder implements only full_image; thumbnail_image and preview_image are unimplemented trait defaults returning None. So every rung of the preview ladder resolves to a full-resolution decode at ~250ms — 5x over NFR-P13's 50ms budget. CR2 does carry smaller IFDs, so the fix is our own IFD walk or an upstream contribution. The ladder is written now so that fixing it is a decoder change, not a change to every caller. Recorded in milestone-v0.1 risks. Preview.downscale_to bounds memory: a 5472x3648 RGBA preview is 79.8MB, which exhausts a phone's budget after a handful of images. Box-filtered so downscaled thumbnails do not alias. Also fixed a RefCell double-borrow that panicked on first navigation — `*x.borrow_mut() = *x.borrow() + 1` holds both borrows at once. Verified with 10,000 programmatic navigations. 58 tests passing. Traceability 20.3% (29/143).	2026-08-09 08:28:26 +02:00
dtourolle	0f202fd3f9	Add requirements traceability gate and Gitea pipelines ... Ports JellyTau's traceability tooling to Rust, carrying across the bug it was repaired for. That gate divided a traced count by frozen literal denominators; the requirements file outgrew them and it reported 158% coverage, so it could never fail its own threshold. Two rules, both enforced by the extractor's own tests: - denominators parsed from docs/requirements.md at run time - coverage is |traced ∩ defined| / |defined|, never a raw traced count The gate additionally fails hard on a misconfigured run — zero requirements parsed or zero files scanned — rather than reporting a plausible 0%, and on any orphan tag naming a requirement that does not exist. Adapted for DarkRoom: IDs are FR-CAT-1 / NFR-P13 / FR-DEV-3a shapes rather than JellyTau's fixed three digits, and decisions (D), spikes (S), milestone items (M) and test ids remain taggable while being excluded from the denominator — counting them inflated it by 25. Also adds dr-sync: the RemoteBackend trait and capability model, so the Nextcloud connector is one implementation rather than the only shape the engine understands. No mature Nextcloud crate exists (reqwest_dav is too thin), so the connector will be hand-rolled over reqwest per D7. Gitea workflows follow the same style: containerised, commented with the reasoning, desktop and Android on every push, plus a CI check that no core/ crate depends on the UI toolkit (ARCH §6.5a). Coverage today: 13.3% (19/143). 50 tests passing.	2026-08-09 08:01:32 +02:00