dtourolleandClaude Opus 5
1ad35e2b87
Judgements only ever travelled outward. A rating went to the catalog and to the photograph's sidecar, the sidecar reached the server, and there it stopped: the scan indexes files, `derived_sync` exchanges thumbnails, face shards and collections, `dr_catalog::merge` reconciles everything in a catalog except `versions.rating` and `versions.flag`, and the one sidecar reader that existed ran when a single photograph was opened in develop and handed its answer to the develop graph. `JobKind::ReadSidecar` was declared for exactly this when the job queue was written and was never enqueued or handled anywhere. The grid draws `versions.rating`. So a day of culling on the tablet could not reach the laptop by any path the application had, and the laptop's catalog says so plainly: 23,568 images, one of them judged. `pull_sidecars` closes it, off the back of work the scan already does. `dr_sync::scan` reports the `.drsc` files it meets in listings it was making anyway — no extra request, and a directory whose ETag is unchanged is still pruned before it is listed at all. A new `sidecars` table records the ETag of each one this device has taken in, so the fetch is one GET per sidecar that genuinely changed rather than one per photograph. A library nobody has edited costs nothing. The judgement is taken rather than maximised. The sidecar is the authoritative store and the fuse has already settled any contest between devices on `revision`, so lowering a rating from four to one on the tablet lowers it here — taking the larger would have refused every demotion the photographer ever made, which is most of what a second pass over a shoot is. A zero is the exception: it means *never judged*, not "judged zero", so a sidecar carrying none cannot erase a star this device holds. That is `merge_judgement`'s asymmetry and it carries the same known cost — clearing a rating does not propagate. A sidecar names a stem, so both halves of a RAW-and-JPEG pair are judged: they are one photograph (FR-CAT-11) sharing one document, and judging only one of them would leave the grid disagreeing with itself over which it drew. The `LIKE` that finds them is a filter, not the decision — `sidecar_path` is applied to every candidate, because a folder is entitled to contain a `%` and a rating landing on the wrong frame would be silent and permanent. Failing to read one is not a failure to scan: the ETag goes unrecorded, the ratings already here stay where they are, and the next scan tries again. The count is reported to the status line as well as the log, because a grid that silently gains three hundred stars is indistinguishable from one that has gone wrong — and because while this number was structurally zero there was nothing to tell the photographer their cull had not arrived. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
DarkRoom
A cross-platform, non-destructive RAW photo editor for Linux and Android.
Status: 0.9.0, and no longer a spike. A library opens, culls, develops and exports on both platforms, across eight tagged releases. What is not built is written down rather than merely absent — see docs/outstanding.md for the requirements that have no implementation and why, and docs/technical-debt.md for the compromises that were chosen.
Documentation
| Document | Contents |
|---|---|
| CONTRIBUTING.md | How to land a first change without reading the rest |
| requirements.md | What the software must do — 179 numbered requirements |
| architecture.md | How it is built — crates, GPU pipeline, data model, sync |
| technical-debt.md | Compromises taken deliberately, each with the condition that retires it |
| outstanding.md | What is not built, and whether that is a decision or a gap |
| code-health.md | What a contribution costs, per seam, measured |
| traceability.md | Generated: which requirement is claimed by which file |
| faces.md | Face detection and identity — the models, the licence problem, and what S14 measured |
Building
Desktop:
cargo run -p darkroom-desktop
Android (containerised toolchain, see docker/android):
./docker/android/build.sh cargo ndk -t arm64-v8a build --release
Git LFS is required for the model weights, and the toolchain pins itself. CONTRIBUTING.md has the details and the four commands CI will run against what you send.
Current state
Working. A catalog over a local folder, a Nextcloud account, or a folder a
sync client keeps in virtual-files mode — where a placeholder is treated as the
photograph rather than as a one-byte file. A virtualised library grid with a
capture-time timeline, ratings, labels, keywords, collections and a trash that
survives a crash mid-operation. Card ingest. Face detection and identity, with
the index syncing between devices. A develop pipeline of fifteen declared
operations fused into a single compute dispatch, plus the neighbourhood
operations that cannot be — clarity, texture, capture sharpening, noise
reduction, lens correction, spectral film simulation. Crop, straighten, spot
removal, gradient and subject-segmentation masks, named presets, and a
generated panel that no operation in ui/ is allowed to name. Export to JPEG,
PNG and 8- or 16-bit TIFF with resize and output sharpening.
The zero-copy display path works on desktop. The compute pass writes a texture that Slint composites directly, which is what ARCH §6.1 requires; the readback it forbids costs 96% of frame time at 4K, and
cargo run -p dr-gpu --example bench --features readback
still reproduces that measurement. The one exception is the Android develop view, which reads the frame back through the CPU because zero-copy there needs wgpu's Vulkan swapchain, and that tears a portrait window on a tablet whose panel is mounted landscape. It is debt, not a revision of the rule: the reasoning, the on-device measurements that forced it, and the three separate things any one of which would remove it are in technical-debt.md TD-1.
Not built. Plugins, compare and survey culling, focus peaking, burst grouping, AI denoise, tiled and progressive rendering, and most of the Android platform integration beyond running. The performance targets in §4.1 are unverified rather than unmet — the per-commit benchmark suite §8 requires does not exist, so nothing fails a build on a regression. docs/outstanding.md is the list, with the reasoning.
Licence
GPL-3.0-or-later.