51 Commits

Include renames

Author	SHA1	Message	Date
dtourolleandClaude Opus 5	8b07a90e71	Regenerate the traceability matrix the clippy pass moved ... `traceability-check` fails on master: the committed matrix does not match what the generator produces, so the gate that exists to keep the two in step is the thing reporting they are not. Nothing was traced or untraced. Coverage is 51.4% (91/177) before and after, the same 604 tags against the same 177 requirements; every one of the 32 changed rows is a line number that moved when the clippy warnings were cleared -- `adjust.rs:2150` is now 2164, 632 is 651, 751 is 770. The matrix links to lines, so touching a file above a tag rewrites its row without changing what it says. Regenerated with `cargo run -p traceability -- report`, which is what the failing step tells you to run. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-25 23:21:13 +02:00
dtourolle	6925aa2a86	Merge master into film-simulation ... Master gained the library's index paging while this branch was building the film simulation, and the two met in library_ui.rs. Only the generated traceability matrix conflicted; it is regenerated here rather than hand-resolved, which is what it is for.	2026-08-25 20:34:28 +02:00
dtourolleandClaude Opus 5	6d18517d28	Ship every stock that exists, black and white included ... Three profiles was what the first cut needed to prove the model. This is the rest of the open data: 23 camera stocks and 9 papers, which is all of spektrafilm. Black and white was the gap, and it turned out not to be a gap in the data -- it was a gap in where I looked. Upstream's `main` has 28 colour profiles and nothing monochrome; `dev` has three more, and they are Tri-X, Double-X and the 2302 print film they go onto. So the answer to "do we have B&W" was yes all along, and it needed the dev branch rather than a fortnight digitising Ilford's datasheet graphs by eye. Those three are pinned to `dev` per stock; the colour stocks stay on the released branch. A monochrome profile is single-channel -- one emulsion, not three -- and spreading that one layer across all three is exact rather than an approximation: three layers with identical sensitivity and identical curves respond identically, which is what one layer does. The dye is the trap. The renderer *sums* the three layers' contributions, so replicating it unchanged renders every frame three times too dense -- neutrally, and therefore plausibly. A third each reconstructs the single emulsion, and two tests hold both halves: that the densities stay equal, and that they sum to one emulsion and not three. Double-X and 2302 ship five curves apiece, measured at five development times -- 4 to 12 minutes for Double-X. That is push and pull processing as measured data. The standard 6.5 minutes is what ships; the rest is in the upstream file waiting for a control to ask for it. Two stocks are `support: film` and are nevertheless what a negative is printed *onto*: the cine projection films 2383 and 2393, which the Vision3 stocks print to. Filtering the picker on support alone offered a projection stock as something to load in a camera, so it filters on stage, with a test saying so. The picker had to change shape twice over. Chips were right for three stocks and off the edge of a 280px column at twenty-four, and the column that replaced them was a thousand pixels standing between the photographer and every slider below. It is a disclosure now: one row carrying the answer, opened to change it, closed again on choosing. That is the opposite of the argument this panel used to take the lids off its sliders, and deliberately so -- an instrument you compare wants to be visible, and a list you consult once wants to be out of the way. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-25 20:30:11 +02:00
dtourolleandClaude Opus 5	3330f350a4	Move the timeline marker from the window the grid already read ... The last of the per-scroll queries, and the strangest of them: this one got slower the further down the library you had scrolled. The marker has to follow every scroll event or it advances in jerks while the photographs beside it move smoothly — that part is right and stays. What was wrong is that each event asked the catalog `LIMIT 1 OFFSET n`, and that is not a seek: SQLite reaches row `n` by producing and discarding the `n` rows before it. 0.02 ms near the top of the library, 0.7 ms at twenty thousand, per row crossed, on the thread drawing the frame. A flick therefore got choppier the longer it went on. The window the grid has already read holds the answer, and since the loaded window now covers the whole view, the row is nearly always in it. So this is a vector index at the position the ordinal has in the window, and the query survives only as the fallback for a row outside it — briefly, after a scrub or a keyboard jump, before the load lands. The fallback is also the less correct of the two, which is worth recording rather than quietly keeping: it counts in a dated-only ordering while the argument is a grid row, so the two disagree wherever undated frames sit in between. It is kept because a marker about to be corrected is not worth a second index, and because being wrong there is what it always did. The window path has no such disagreement — it reads the very cell the row belongs to. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-25 20:01:51 +02:00
dtourolleandClaude Opus 5	0f231afe85	Stop re-answering questions about the library every time the window moves ... The timeline's bars, the filter chips' counts, the "on this device" count and whether the scoped collection is pinned all describe the *library*. None of them can change because the view scrolled. `load_window` recomputed all four every time the window moved, which is several times per screenful. Together that is a `MIN`/`MAX`, a `GROUP BY`, two counts, and under a collection three more queries — about 8 ms of SQLite on the thread that is trying to draw the frame, for four answers that were already on screen and already right. They are now keyed on what they actually depend on: the scope, the filter, whether this is the trash, and the total. The total earns its place as the change detector as much as for the scrollbar — a scan landing, a delete or a restore all move it, and it was already read on every load. What a total cannot see is a rating edited under an unchanged count. That is covered, and deliberately not by widening the key: `apply_judgement` already refreshes the chips itself, because it has to report what actually landed rather than what was asked for. Same for the axis — a zoom, a pan, a scrub and dates arriving from the thumbnail worker each call `refresh_timeline` directly. Skipping the recompute here cannot leave anything stale on screen. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-25 20:01:39 +02:00
dtourolleandClaude Opus 5	6d6ef8d34b	Page the grid along an index instead of sorting the library each time ... Scrolling jittered, and this was the largest single reason. Every window the grid loads is `ORDER BY ... LIMIT n OFFSET k`, and neither half of that was being answered the cheap way. **The sort.** `GRID_ORDER` leads with `captured_at IS NULL`, so undated frames fall to the end. No ordinary index answers that — the leading term is an expression, not a column — so SQLite sorted the whole library into a temp b-tree on every window read, then threw away the first `k` rows of it. Schema V7 indexes the expression exactly as the query writes it, partial on the same `shadowed_by IS NULL AND trashed_at IS NULL` the grid filters by, so the read becomes a walk along the index. **The join.** `LEFT JOIN remote` was paged *after* it was joined, so reading 280 cells at offset 20,000 first seeked into `remote` for all 24,000 rows and then discarded 23,720 of them. The file ids are now fetched for the 280 rows that survived — the shape the badge and rating reads already use, one query for the window rather than one per cell. Measured together on 24,000 images at offset 20,000: **15.2 ms → 0.36 ms**, inside a scroll handler that has 16.7 ms to draw a frame. The test asserts on the query plan rather than on a duration, because there is no other symptom. A `GRID_ORDER` edited out of step with the index, or a column added back that drags `remote` in again, both still return exactly the right cells — just after sorting the library — and the jitter would come back with nothing to point at. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-25 20:01:04 +02:00
dtourolleandClaude Opus 5	baa8957e80	Let a photographer choose the film, and remember which one ... The stock model rendered correctly and nothing could ask for it. This is the picker, and the sidecar key that makes the choice outlive the session. How the choice persists was the open question, and the answer was already written down twice in sidecar.rs: `rating` is a top-level key "because a rating is not an edit", and `masks` are one "because a layer is not a scalar". A stock is that kind of thing -- a choice of material, not a number a slider moves -- so it is a top-level key too. It stores the **id**, not an index. Stocks are files that users add, so an index would mean installing a profile silently changed which film every existing photograph had been developed on. A name this build has no profile for still round-trips untouched, because the alternative is that syncing to an older phone quietly un-develops the picture. Only the names travel. Turning one back into tables needs the profile database, which dr-pipeline deliberately does not link, so `Version::apply` clears the film and the session re-bakes -- after the parameters, because the bake reads the film's own exposure sliders and the print balance is solved against them. That is also why moving those sliders rebuilds the lookup where no other control in the panel does: an enlarger's filtration depends on how the negative was exposed. The panel keeps its rule. It still names no operation and still generates every control from a declared parameter kind; the stock gets a bespoke control beside those, exactly as the mask stack does, and for the same reason. The film's exposure and print exposure arrive as ordinary generated sliders. Two defaults worth stating. Picking a colour negative prints it, because an unprinted one is an orange strip and offering that as the first thing somebody sees after choosing Portra reads as a bug rather than as a choice -- the toggle is there for anyone who wants the scan. And a paste carries no film: a preset is a parameter map, and a stock is not a parameter, so pasting one would paste a choice the clipboard never took. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-25 19:57:41 +02:00
dtourolleandClaude Opus 5	4a2fcb6d22	Render a film stock on the GPU, and let it take over the rendering ... The stock model landed in dr-film with no way to see it. This is the pipeline node, the two texture bindings it reads, and the end-to-end test that proves the shader agrees with the model. The design point is that a film simulation is not an adjustment. Every other node changes a picture; this one makes it. A stock's characteristic curve does the camera profile's base curve's job -- from measurements rather than from a curve somebody drew -- so running both renders the scene twice: the camera's rendering, and then a film's rendering of that. It looks like neither, and it reads as a colour-management bug with no colour-management bug to find. So `Operation::renders` is new. A node declaring it takes camera RGB and hands back linear sRGB, and the composer emits neither the base curve nor the conversion out of camera space. Both halves move together, and the composer keeps them as one string precisely so that getting half of it right is impossible. The tables are not parameters, for the reason vignetting's coefficients are not: they are measurements. dr-pipeline declares the layout as a plain struct and keeps its no-dependency property; the two crates share no types on purpose. `EditGraph::set_film_tables` offers them to every node rather than to the one that wants them, because knowing which concrete type is which is what the graph is organised not to know. Bindings 4 and 5 follow the masks precedent: declared unconditionally so one bind group layout serves every generated shader, bound to 1x1 placeholders when no stock is loaded. Both are interpolated by hand with textureLoad -- this pipeline binds no sampler, and adding one for two lookups would cost a binding in every shader. Uploads are keyed on content so an unchanged stock does not push half a megabyte across the bus per frame. The end-to-end test earned its place immediately: it found the density lookup being filled z-fastest while a 3D texture upload wants x-fastest, so the red and blue axes were transposed. Green matched exactly, which is what that bug looks like -- a plausible photograph of the wrong colour, and one that every unit test on either side of the seam passes. dr-film now pins the layout in a test that needs no device, and states it where the field is declared. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-25 15:12:56 +02:00
dtourolleandClaude Opus 5	b6a95e1965	Simulate a film stock from its measurements, not from someone's grade ... FR-DEV-3f asks for look emulation and proposes HaldCLUT import to inherit the free film-simulation ecosystem. This takes the other road for the stocks where the measurements exist: run the physics. A stock here is its manufacturer's own datasheet -- spectral sensitivity, characteristic curves, dye densities. Light exposes three emulsion layers, the layers develop to densities, the densities are dyes that absorb, and what is left is what reaches the eye. A colour negative comes out orange and upside down because that is what a colour negative is; it becomes a photograph when a paper profile prints it, with the enlarger's filtration solved rather than dialled. What that buys over a LUT is that the parameters stay physical. Opening up a stop moves the picture along the film's real characteristic curve, shoulder and all, instead of scaling a number baked at one exposure. The data cost runs the other way too: a stock is 17 kB of published measurements where one HaldCLUT is 800 kB of one person's grade. It looks like it needs a spectral integration per pixel. It does not, and that is the whole design: - Exposure is a 3x3 matrix. The reconstructed scene spectrum is linear in the sRGB triple, so the integral collapses into nine numbers, exactly -- no approximation. - The characteristic curve is three 1D functions, sampled exactly. - Everything after that -- dye absorption, the print through the negative, the paper, the viewing illuminant, the adaptation -- takes exactly three numbers in, so it bakes into one 32^3 lookup. Per pixel: a matrix multiply, three curve taps, one fetch. Splitting the curve out of the 3D lookup rather than baking one LUT over exposure is measured, not assumed: the curve carries the sharp shape and the dye mixing is smooth, so folding them together would need three times the resolution for the same error. At 32^3 the worst error is 0.003 in linear sRGB, under one 8-bit code value, and a test says so. No wgpu dependency, deliberately, and the same isolation argument dr-lens makes: the model is plain f32 with a documented layout, so every property worth asserting is asserted on the CPU. Binding it to a texture is dr-gpu's job and is not done here yet. The expected values in tests/ came from a Python prototype running against a different colour-science stack. Agreement to three decimals is evidence about the model rather than about one implementation of it -- a transposed matrix or a mispasted observer row would pass every unit test and fail that one. Profiles are converted from spektrafilm by Andrea Volpato, CC BY-SA 4.0. The converter is in the tree and runnable, so what was changed from upstream is auditable rather than taken on trust; profiles/CHANGELOG.txt records it, including the one deliberate deviation -- Mallett & Yuksel's 1 kB basis instead of Hanatos's 4 MB table, which costs accuracy at the gamut edge and saves four megabytes. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-25 14:44:54 +02:00
dtourolleandClaude Opus 5	7c8e433911	Load the window around the whole view, not around its first cell ... The bottom row of the grid was often blank, at a scroll position the user could sit at indefinitely. Two numbers decided when the loaded window follows the view, they lived in different languages, and they disagreed. The grid loaded three screenfuls and Rust held the window still until the first visible cell was three quarters of the way through them. Three quarters of three screenfuls is 2.25, and the view itself is one screenful tall — so the bottom of the screen had already travelled a quarter of a screenful past the last loaded cell before anything moved. Those rows are not in the model, so nothing is drawn for them. The same margin was wrong upward, and exactly so. The window is placed a quarter of itself behind the view, and the margin then declared the view too close to the top at precisely that distance: every single row scrolled upward re-read the catalog, rebuilt all 360 cells and re-queried their badges and ratings, and so did the row after it. So the grid now reports what it shows — a screenful, counting the row the scroll position has cut in half, which `visible-rows` alone undercounts and which is exactly the row reported missing — and Rust owns the rest: four screenfuls loaded, placed a quarter back, and moved once the view comes within half a screenful of an edge of them. One decision in one place, and the test now walks the view the length of the library and asserts the window covers it at every step. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-24 19:48:58 +02:00
dtourolleandClaude Opus 5	33847a0bbc	Open one GPU device for the tests, and stop the checkout dying over LFS ... Two CI failures, unrelated except that both were mine. **The test binary faulted under parallel threads.** Every GPU test opened its own `GpuContext`, and `cargo test` runs on as many threads as there are cores — so a full run asked the driver to bring up a dozen Vulkan devices at once and died with SIGSEGV. Serially it passed, which made it look like flakiness rather than a fault in the harness. One device now, behind a `OnceLock`: a `GpuContext` is an `Arc<Device>` and an `Arc<Queue>`, so sharing it is a refcount, and the losers of the race block until the winner is done. 416 tests now pass in parallel, in half the time twenty-six devices took. **`lfs: true` on the checkout made the checkout fail.** The intent was right — the model is in LFS, a plain checkout writes a 133-byte pointer, and the build script panics on it — but on this server `git lfs fetch` is rejected at `/info/lfs/objects/<oid>` with a client error: the credential `actions/checkout` installs for git is not one the LFS endpoint accepts. So a fetch problem presented as a checkout problem and took the whole job with it. The object is on the server; a clean clone over SSH with `git lfs install --local` pulls all 11 MB of it. It is now its own step with an explicit token, and `continue-on-error` so a credential problem cannot masquerade as a broken checkout — if it fails, the build still runs and fails with the build script's own message, which names the real problem. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-24 19:36:34 +02:00
dtourolleandClaude Opus 5	6b5ffc6a93	Anchor the delete on what the view was showing, not on the window's start ... The grid still jumped. Anchoring on `offset` was wrong for a reason this file already states, a few hundred lines away: "the first *visible* ordinal, not the window's start: the loaded window deliberately begins a quarter of a screen above the view, so its first cell is one the user cannot see." Two things made `offset` the wrong number. It is a screen-quarter above what is being looked at, and by the point this runs it has already been re-clamped against the new, smaller total — so seeking to it moved the view somewhere the photographer had not been. A smaller jump than the original, and the same fault. `resume_at` is what the grid last reported as its first visible image, which is the photograph the person is actually looking at. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-23 19:38:27 +02:00
dtourolleandClaude Opus 5	cd64166b15	Keep the view on the photographs after some of them are deleted ... Deleting made the grid go blank and jump somewhere arbitrary. Two causes, both of them the viewport being left behind by everything else that moved. The Flickable is sized to the *whole* library so its scrollbar is a real address into twenty thousand images. Delete some and that content gets shorter, which leaves a view near the end scrolled past what now exists — cells sitting above a viewport looking at empty space. Slint does not pull a Flickable back on its own. (The clamp for that went in with the previous commit.) The jump is the other half. Cells are drawn at their absolute place in the library, `(i + offset) / columns`, and a delete re-clamps `offset` downward so the loaded window still fills. Nothing touches `viewport-y`, so the same scroll position now addresses different photographs and the grid appears to leap somewhere unrelated. `restore_position` re-anchors on the ordinal the view was showing, clamped into what is left. Not on the deleted image's own position, which no longer exists, and not on the top of the library, which would throw the scroll position away on every delete — after removing one frame from a wall of twenty thousand, the one you want next is the one that just moved into its place. Only on a shrink, and the shrink is detected by reading `library-total` before overwriting it. Re-anchoring on every load would fight a scrub, which sets exactly this property to go where the user asked. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-23 19:03:15 +02:00
dtourolleandClaude Opus 5	fa4ad6e2d6	Drag the date range on the axis it is chosen from ... The range could be turned on with a finger and not aimed with one. Its two ends were typed as `YYYY-MM-DD` into 108px fields behind a soft keyboard, to name days already drawn on the axis a thumb away; and the chip that seeds them takes its span from the timeline's zoom and pan, which are a wheel and a middle button. A touch screen has neither, so on Android the filter was a switch with no aim. The band is now on the timeline. Two ends with grips, dragged along the bars, released to filter — the histogram was already how a period is found, and this makes it how a period is stated. Both ends snap to whole days, which is what the typed fields mean, what `show_range` reads back out, and a floor under a range dragged shut. The fields stay for what dragging cannot do: name an exact day, and say in words what the range is. For that to work the axis had to stop following the range. Redrawn to the band, it moved the ground under the very handles doing the narrowing, and there was nothing outside the range left to widen back into. While there: a fixed number of equal bins instead of calendar buckets. Between one calendar unit and the next the bar count is free to wander by a factor of twelve, so zooming in halved it two steps out of three — the same picture drawn wider until it jumped back to fine. Equal bins also include the empty ones, so a bar's position on the track and the date under it are finally the same quantity; before, a library with gaps drew a February six months wide and the marker, the band and a click all pointed somewhere else. The count is a setting, 32 or 64, because the right answer is a question about the screen. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-23 18:42:42 +02:00
dtourolleandClaude Opus 5	b0b6dd559a	Show what is selected, and let a collection be made of it ... Three things a selection needed and did not have. **Seeing it.** The count existed — "12 selected" — in the header row, which scrolls sideways. On a tablet it sat past the right-hand edge along with every button beside it, so a selection was something you could make and then not see. A selection you cannot see is one you act on by accident. **Putting it down.** The only way to clear one was "Done", which also leaves select mode — so after filing forty photographs the next forty began by re-entering a mode the user had not meant to leave. Clearing is now its own action and keeps the mode. **Filing it somewhere new.** Making a collection of a selection took four steps: create one, find it in the tree, select the photographs again because creating it changed the scope, then add them. It is one press, which is how a selection is usually meant — it is gathered *because* it is going somewhere. The new collection is created at the top level rather than inside the current scope, unlike the tree's "+". A selection can be gathered from anywhere, including across collections, so filing it under whichever one happens to be open would put it somewhere its contents did not come from. It opens straight into its name field, for the reason `collection_new` already does: the placeholder name is nobody's choice, and making the user find the rename afterwards is asking them to finish a job we started. All of it on its own strip beside the date range's, appearing only while there is a selection — the third control this session that was invisible for being put in a row that scrolls. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-23 17:57:35 +02:00
dtourolleandClaude Opus 5	f9c7aba8b6	Regenerate the traceability matrix ... Six commits added nineteen TRACES tags between them and none regenerated the matrix, so the gate failed on every one of them — including the commit the release tag points at. The gate is doing its job: a matrix that disagrees with the tree is worse than none, because it is read as current. Coverage is unchanged at 50.3%; what moved is where each requirement is tagged, which is the half of the file that is actually consulted. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-23 15:00:45 +02:00
dtourolleandClaude Opus 5	b7bd2356be	Regenerate the traceability matrix ... The gate regenerates it and fails if the result differs from what is committed, which is what it is for: a matrix that disagrees with the tree is worse than none, because it is read as current. Stale since the detail stage landed — 160 files and 436 tags then against 180 and 521 now. Coverage 49.1% to 50.3%, and no orphan tags. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-23 10:26:59 +02:00
dtourolleandClaude Opus 5	d04087af83	Import into the library, which is on the server ... There was a local destination, defaulting to ~/Pictures, and an "upload" switch that could be turned off. That was wrong twice over. DarkRoom's library *is* a folder on a Nextcloud server (FR-NC-6) — there is no local library — so a user-chosen local destination built a second pile of photographs that no view in the application ever lists, and made "where did my import go" a question with two answers. An import now has exactly one destination and the page asks nothing about it. With no account there is nowhere to go at all, so Import is refused rather than quietly filling a folder. What lands on the device is a staging copy in a directory the app owns, the same shape `export` uses for its outbox and for the reason its module docs give: staging first is the only path, not a fallback for being offline. The bytes have to reach disk before the network — streaming a card straight to the server would let a move-import erase a card against an in-flight upload, and would make importing impossible with no connection (FR-NC-10). A staged file is removed once the server confirms it; one that is not confirmed stays queued, and the next import drains it. And the rule that was stated but never enforced: `retirable` was reported and `dr_ingest::retire` was never called by anything, so a move-import silently behaved as a copy. The card is now emptied by the worker, of exactly those photographs the *server* has confirmed — not those merely written here, because the staging copy is removed moments later and anything unconfirmed would then exist nowhere at all. FR-NC-7b said "copied locally first ... then queued for upload", which is a staging area; it has been rewritten to say so in terms that do not also permit what was built. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-22 21:09:26 +02:00
dtourolle	56dd3187f1	Merge integration into wip/ingest ... Second pass, against the detail-stage and thumbnail work that has landed since the first. Resolved and verified here rather than in the shared merge worktree, so what goes back is a fast-forward. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> # Conflicts: # docs/traceability.md	2026-08-22 19:44:42 +02:00
dtourolle	42f1f55fd3	Regenerate the traceability matrix ... The detail stage and its four kernels, the camera profiles, per-channel tone curves, keywords and export metadata all landed since the last regeneration.	2026-08-22 19:37:56 +02:00
dtourolle	5d15b753f7	Regenerate the traceability matrix ... Five branches merged since the last regeneration. Generated file, so the only correct version is the one produced once, here, from the merged source.	2026-08-22 19:31:22 +02:00
dtourolleandClaude Opus 5	28325af448	Make the thumbnails while the originals are still in hand ... An import read every byte of every original, uploaded them, and then left the grid to fetch a preview range back out of each one over the network — for files that had been on this machine minutes earlier. The pixels are now made from the bytes already in memory, on the fast path FR-CAT-3 names: locate the camera's own embedded JPEG, decode a few hundred KB, downscale, orient. Never a demosaic. A file with no usable preview yields none, which is not an error and simply leaves the grid to fetch one later. The filing waits for the upload, and only the filing. The shard store is keyed by `oc:fileid` (FR-NC-5) and that does not exist until the server has the file — so the thumbnail is made from the local copy and held until an id can be attached to it. One listing per folder supplies every id at once, rather than a PROPFIND per photograph over a link that may be mobile data. Best-effort throughout: a thumbnail that cannot be filed costs the grid one preview fetch later, and failing an import over it would be the wrong trade. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-22 19:20:13 +02:00
dtourolle	45214d3ca8	Regenerate the traceability matrix ... Four branches merged, each of which had regenerated this file against its own tree. Those versions all disagreed and none was right for the union, which is why the merges took whichever side was to hand and deferred to this: the matrix is generated, so the only correct version is the one produced once, here, from the merged source.	2026-08-22 19:01:39 +02:00
dtourolleandClaude Opus 5	f4c21c4e2c	Regenerate the traceability matrix after the merge ... Both sides added tags. 49.7%. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-22 15:53:25 +02:00
dtourolleandClaude Opus 5	939f33a3a3	Say on the import page where the photographs end up ... Three lint findings and the gap the third one was pointing at. `Context::library_label` was dead: the page named the folder on this machine and said nothing at all about the server, which is half of what the Import button commits to and the half that takes minutes rather than seconds. It now names both, and states the order — copied and verified here first, then uploaded (FR-NC-7b) — beside the destinations rather than beside the button, because someone watching a slow upload needs to already know the photographs are safe on disk. The label is cached when the page opens rather than read in `render`: reaching it goes through the context closure to the account, and `render` runs on every keystroke. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-22 15:49:02 +02:00
dtourolleandClaude Opus 5	98e0ad0537	Regenerate the traceability matrix ... FR-CAT-10, FR-NC-7a and FR-NC-7b gained implementations; the two new requirements also raise the denominator. 46.9% to 48.6%. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-22 14:01:01 +02:00
dtourolle	610f679881	Reconcile the three branches ... Two faults textual merge could not see. Both agents added a `mod tests` to masks_ui.rs — the module boundary was an artefact of them being written apart, and the tests do not overlap, so they fold into one. And `segment` lost its context argument when the work moved to a worker, which a test written on another branch still passed.	2026-08-22 13:33:55 +02:00
dtourolle	12d320cf33	Record what the spec got wrong about the model that exists ... docs/segmentation.md §4 priced arm B as costing a C dependency under the NDK and treated that as most of the difference between the arms. It is not a cost that has to be paid: `ort`'s `alternative-backend` disables its linking entirely and `ort-tract` supplies the API from tract, which is pure Rust. D13's "largest exception the policy would tolerate" turns out not to be needed, and the answer generalises to the face pipeline — so D13's runtime half is now answered and only its licensing half is open. Three findings contradict §4 outright and are recorded as F4-F6 rather than quietly designed around. There is no ADE20K-trained YOLO, so the shipped vocabulary selects subjects and not stuff — "select the sky" comes from the watershed or from nowhere. It is instance segmentation, so it partitions nothing and two people come back as two instances. And tract cannot parse a dynamic-shape export, which fixes the input at 640 square and makes tiling the only route to more semantic resolution. Arm C ships, but §8's criteria are not what decided it, and saying so matters more than claiming the process worked. §8 asked for a two- interaction margin over arm A on a traced corpus. That comparison was never run: F4 and F5 changed what the arms are, and a model that recognises subjects but has no word for sky cannot be a selection tool alone, while a watershed cannot tell a person from the wall behind them. They stopped being candidates and became complements. What is *not* done is written down as plainly: the 24-image corpus is untraced, so M1-M4 have no numbers and "this feels right" has not become one. M5 is answered on one device only, and region ids now reach the sidecar — so a cross-vendor divergence would mean a mask written on the desktop meaning something else on Android. F3 stands.	2026-08-22 08:39:17 +02:00
dtourolleandClaude Opus 5	02ae92ba0d	Tidy what the seven-branch merge left behind ... Three lints, all from merged work rather than from any one branch: `terrace` and `disc` were steps on the way to the ramp the plateau test now uses, and the reasoning that discarded them lives in docs/segmentation.md §12 rather than needing the code; two mechanical clippy suggestions in segment and cache. 1176 tests pass, clippy and fmt clean, traceability regenerated. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-17 12:36:15 +02:00
dtourolleandClaude Opus 5	a8b28136a6	Merge the batch export, and settle the seven-branch merge ... Resolves the last of the parallel work. Two conflicts worth recording, because both were semantic rather than textual: `render_for_export` gained a colour space on master while the batch branch was rewriting the single-image export path around it. Kept both: the batch request supersedes the synchronous path, and the space still has to be chosen at render time because the conversion happens in the shader before the clip to 0..1. `render_open_frame` takes it as an argument rather than reaching for a controller it does not hold. The map-wait moved into `readback::await_mapping` on one branch while another was editing the constant it used, so `READBACK_POLL_LIMIT` survived the merge with no callers. Removed rather than left for clippy to find later. 1164 tests pass, clippy clean, fmt clean. Traceability 53.0% -> 54.3%. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-17 10:11:44 +02:00
dtourolleandClaude Opus 5	4b36ca66aa	Render an export into the colour space its file will claim ... The colour-managed export branch left one call site deliberately unfixed, and this is it. `render_for_export` composed with the default sRGB shader, so a Display P3 export failed with an accurate error rather than producing a mislabelled file — the right way to leave a half-finished path, and no way to leave it. The space is chosen at render time because that is the only time it can be: the conversion happens in the shader, before the clip to 0..1, so by the time pixels reach an encoder they are in exactly one space and the only honest thing left is to label them. `Frame::in_space` carries which, and a mismatch between what was rendered and what was asked for stays a typed error. Also regenerates the traceability matrix over the four merged branches. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-17 09:34:57 +02:00
dtourolleandClaude Opus 5	40d4e439a9	Drop the parameter the offline sidecar writer never used ... `write_one_sidecar` took an `Option<&NextcloudBackend>` it ignored. It was a leftover from the shape the write path had before online and offline separated into two functions: the offline one records to the cache and queues, and has no server to talk to by definition. A parameter that is always `None` and always unused says the opposite — that there is a case where it is `Some` — and the next reader has to check. The closure it was threaded through is renamed to say what it does rather than how it is called. `run(None)` needed the reader to know what `None` meant; `queue_all()` is the sentence. Also regenerates the traceability matrix, which now records FR-CAT-9's queue. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-17 07:17:31 +02:00
dtourolleandClaude Opus 5	cb1d2be240	Choose the export folder by walking the server, not by typing it ... The destination for a Nextcloud export was a text field. Nobody recalls the exact spelling of a path three levels down, and getting it wrong does not fail — `create_dir` makes whatever was typed, so a misremembered folder becomes a new one at the root and the exports are somewhere nobody looks. So it is picked the way the library root is picked, using the same `FolderBrowser` model the launch screen drives: up, into, and "use this folder", confirming the folder currently *shown* rather than one selected in the list. Same rule in both places, so the phrase means one thing. The model is shared; the worker is not. `settings_ui::spawn_folder_list` is a near-twin of the launch screen's, because that one reaches into the `LaunchController` for its session and reports onto the launch screen's error line, while this one is handed credentials and writes to the settings page. Factoring them together needs a function taking both controllers or a trait implemented twice to abstract two call sites — more machinery than the twenty lines it saves. What matters is shared already: navigation behaves identically because both drive the same model. The callbacks are wired in `lib.rs` rather than in `settings_ui::wire`, because listing a remote folder needs credentials and the settings page holds no session on purpose — it is reachable before a library is opened and must not depend on one existing. With no account the picker says to sign in first, rather than showing an empty list that reads as a server with no folders. Details that are decisions rather than accidents: the picker opens at the library root rather than at whatever half-typed path is in the field, which would list nothing and look broken. The listing area is a fixed 180px, since a folder with sixty children would otherwise push the rest of the settings page off the bottom. "Up" is disabled at the root rather than hidden, so the row does not jump as the user navigates. A failed listing leaves the picker open on the folder it was showing — where the user had got to is not something to discard over a dropped request. And the chosen folder saves immediately like every other setting on a page that has no Save button. The poll timer lives on the controller for the reason `LaunchController` keeps its own there: a `slint::Timer` stops when dropped, so one local to the function that starts it would be collected before the listing arrived. Carries in-flight work from a parallel session — a segmentation pass in dr-gpu, a sidecar cache, and the develop panel's continuing changes. 1020 tests pass, fmt clean. One clippy warning remains and is not mine: `sidecar_cache::dir` is unused while that work is in progress. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-17 07:12:01 +02:00
dtourolleandClaude Opus 5	e00c99b864	Let a photograph leave: an export button, and a cache to leave from ... dr-export could turn a frame into bytes and nothing could ask it to. This is the button, and the place the bytes go. **Everything is staged first.** An export bound for the server is written to a local outbox and uploaded afterwards; offline is not a special case, it is the same path with a drain that finds the server absent. Doing it the other way — upload directly, stage only on failure — makes the failure path the one that is rarely exercised and always broken, and a network drop mid-batch leaves some exports existing and some not with nothing recording which. Staged first, an export is finished the moment it is written and the upload is a promise kept later. The outbox sits beside the catalog rather than under the cache. dr_catalog's cache already draws that line: passive entries are a convenience and go under LRU, pinned ones are a promise and never do. An export awaiting upload is a promise — the user was told it succeeded — and sweeping it for disk would destroy the only copy. Bytes are written before the destination record, so a kill between the two leaves an orphan the drain ignores rather than a record pointing at nothing. The status line says "Queued for Exports/2026", never "Exported to Nextcloud", until it has actually landed. There is a test asserting that wording, because the tempting shorter sentence is a claim the app cannot keep. The drain runs on the sync pass, before the shards: a thumbnail shard can be rebuilt from the originals and the catalog is an index, but a queued export exists nowhere else. `DevelopSession::render_for_export` renders the framed size rather than reusing the frame on screen, which is deliberately viewport-sized (FR-DSP-1) — encoding that would hand the user a soft, screen-sized file with nothing to say anything had been lost (FR-EXP-9). One compromise, recorded rather than hidden: the export runs synchronously on the UI thread, so the window is unresponsive for the few hundred milliseconds a full-resolution render and encode takes. Moving a DevelopSession and its GPU pass to a worker is a larger change than one button earns, and it is batch export that makes the wait intolerable rather than merely noticeable. Still missing: the Nextcloud folder *picker*. The destination is typed into Settings for now. `FolderBrowser` in launch.rs is already the reusable model for it — it browses a remote tree and nothing about it is specific to choosing a library root — but wiring it into the settings page needs a listing worker and browser UI there, which is its own piece of work. Carries in-flight work from a parallel session — presets, the develop copy and paste, and the node schema's `presentation` and `enum` support. One misplaced callback in settings_ui.rs is moved from `render` to `wire`: registered in `render` it borrowed a `&SettingsController` into a 'static closure and would not compile, and that file's own docs say render pushes properties while wire connects callbacks. 992 tests pass, clippy and fmt clean. Traceability 48.3% -> 51.0%. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-16 23:58:17 +02:00
dtourolleandClaude Opus 5	151dcc3c02	Make a file out of a photograph ... Export existed as a settings page and nothing else: format, quality, colour space, five sizing modes, a filename template and a metadata switch, all configurable in detail, and no way to produce a single file. dr-export is the other half. **It returns bytes and a name, and writes nothing.** An export has three destinations with nothing in common — a path on Linux, a SAF document on Android where there is no path at all (ARCH §6.9), and a PUT to a Nextcloud folder — so a crate that opened the file itself would serve one of them and be rewritten for the other two. The caller places the bytes. Resize, then sharpen, then encode, in that order and for a reason: output sharpening compensates for the softening the resample introduced, so its strength scales with how much scaling actually happened, and sharpening before shrinking would throw the result away. Lanczos-3, separable, with weights computed once per output row — FR-EXP-4 asks for Lanczos or better because a box filter turns a distant fence into moiré. Collision handling takes the "is this name taken" test as a closure rather than looking at a directory, because there is no directory it could look at that works everywhere. That shape is not politeness toward Linux: Android's createDocument renames on collision by itself and cannot overwrite at all, so all three CollisionPolicy settings need the answer *before* anything is created. Overwrite, Skip and Increment are each tested, and Increment gives up after ten thousand rather than spinning against a destination that reports everything as taken. Three things are honest rather than done: - **Colour space.** sRGB only. The shader encodes and clips to sRGB before this crate sees a pixel, so tagging a file Display P3 would claim a gamut it does not contain. Refused with a typed error instead of mislabelled; honouring it is a pipeline change (FR-EXP-2). - **AVIF and JPEG XL.** No encoder. libaom and libjxl are C, ravif is slow enough to change what a batch feels like, and the settings page offers both because FR-EXP-1 lists them — so asking for one says so rather than writing a JPEG under a .avif name. - **16-bit TIFF** is a real 16-bit file carrying eight bits of information, because AdjustPass renders to Rgba8Unorm. Widened by *257, not <<8, so white lands on 65535 rather than a quarter-percent grey. Making it mean what it says needs the composer told what format to write. Metadata is not written at all, which satisfies the half of FR-EXP-8 that matters most: strip_location defaults to on, and a file with no EXIF block has no GPS tag. Retaining camera and copyright when asked is not implemented and cannot be faked by omission. Also here: - `AdjustPass::export_pixels`, ungated where `read_output` is behind a feature. The two are the same transfer and opposites in intent: reading pixels back to *display* them is what ARCH §6.1 forbids and AC-8 asserts against, while reading them back to encode a JPEG is the only way a file has ever been made. Separate methods so the instrumentation can count one without counting the other. - `ExportTarget`, so a destination can be a folder on the server. On Android that is the only destination needing no platform work whatsoever — a PUT against create_dir, already on the RemoteBackend trait, behaving identically on both platforms. Switching target clears the destination, since a path is not a remote folder and carrying one across would offer to create a folder called `home` at the library root. Verified end to end rather than by unit test alone: `cargo run -p dr-export --example export` decodes a frame, runs the develop chain on the GPU at full resolution, reads it back, and writes all five formats — 27 ms for a full-size JPEG, 165 ms with a Lanczos reduction to 1200px. ImageMagick agrees the 16-bit TIFF is 16-bit. dr-export cross-compiles clean for aarch64-linux-android; all three encoders are pure Rust, which is why they were chosen. 944 tests pass, clippy and fmt clean. Not yet wired to a button. The develop view has no export action, so nothing in the running app can reach any of this yet. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-16 22:26:37 +02:00
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