From 059f9631180742ed1f65d19b4ff4ef561db967e3 Mon Sep 17 00:00:00 2001 From: Vuong Hoang Date: Wed, 19 Aug 2026 01:40:52 -0700 Subject: [PATCH] docs(waterland-studio): note why an adopted job shows as failed waterland-dev confirmed the mechanism: adoption marks a job failed on a sidecar saying running/queued, or on a directory with no plate.png. The pre-header-fix renders died 1.7s in with a source and no plate, so they land in the second branch. Recorded so nobody investigates adopted history as a live fault. --- stacks/waterland-studio/README.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/stacks/waterland-studio/README.md b/stacks/waterland-studio/README.md index 2b9bfac..03a79ad 100644 --- a/stacks/waterland-studio/README.md +++ b/stacks/waterland-studio/README.md @@ -161,3 +161,10 @@ Verified here after the update: `/api/jobs` went **1 → 16** against 16 directories on disk, with nothing reclaimed — correct, since 16 is under `RETAIN=40`; adoption only made them visible. The bound now holds across restarts, so no hand-pruning is needed. + +**Don't chase the one `failed` job in that list.** Adoption marks a job +`failed` on exactly two conditions: a sidecar saying `running`/`queued`, or a +directory with no `plate.png`. The renders that died 1.7 s in on the missing +CUDA headers (before that fix) wrote a source and never a plate, so they land +in the second branch. It is adopted history being labelled honestly, not a +current fault.