Looks that work well: a failed picture is retried, a sleeping app says so, a card says why it has no picture, and the thumbs are the ones the owner would choose #1150

From the owner, on pinning cs-engine to the top of the home: "the image is missing, I see a question mark. This should work well and be good screenshots; it really improves the look and feel."

The picture existed on disk the whole time; an edge gate from the 5th refused it (removed tonight). But the hunt turned up three things in the look sweep itself:

• [ ] A picture that failed at a head is never retried (looks/service.ts: "a picture that failed at this head is not retaken"). Under load — a check and two agent runs beside it — the browser's 20 s pass fails and the card stays empty until the next deploy. Retry with doubling waits, up to a day, and retake when the machine is quiet.
• [ ] A production that is not serving (cs answered 404) is still pictured through the grant door; the proxy bounces the browser to the forge's own https door, which the pod resolves to an internal certificate, and the log says ERR_CERT_AUTHORITY_INVALID. Say "not serving" and skip; and point the browser at the forge's listener for every hop, never at a public name the pod resolves differently.
• [ ] A card with no picture never shows a question mark. It shows the one-line reason the forge has ("taking a picture", "not serving", "failed under load; retrying at 20:40", "pictures are the writers' on this private app") or, when there is nothing to say, the app's name set well on a calm ground.
• [ ] The pictures are the ones the owner would choose: a thumb at the card's real size (2x for phones), the first paint waited for (a game draws after load; the picture must not be a blank canvas), and the sweep retakes a thumb older than a week on a running production.
• [ ] Tests: a failed look is retried on schedule; a non-serving app is skipped with its reason; the card renders the reason; a thumb is retaken when stale.

Files I expect: src/looks/service.ts, src/looks/capture.ts, src/web/studio/home.ts (the app card), src/web/pages/looks.ts.

Seen on the cs-engine card after the gate came down: the thumb is Chrome's "Your connection is not private" for git.open-platform.sh (NET::ERR_CERT_AUTHORITY_INVALID). The thumb is taken as nobody; on 2026-10-06 cs-engine was private, so nobody got the sign-in door, the forge sent the browser to its origin's sign-in at git.open-platform.sh, and inside the pod that name resolves to the cluster's own Forgejo behind the platform CA, which Chromium does not trust (Bun does, through NODE_EXTRA_CA_CERTS). The owner's desktop and phone pictures from the same night show the real page. The app went public since, and the picture was never retaken because its head never moved.

Two more lines for this issue, then:

• [ ] A capture that ends on a browser error page or a sign-in page is a failed capture, not a picture: check the final URL and the document title (Privacy error, the forge's own sign-in) before keeping the file; record the reason.
• [ ] When an app's access changes, every picture of it is retaken: a thumb taken as nobody of a private app is a sign-in page, and a public app made private must not keep a stranger's view of its inside.
• [ ] The browser in the pod is never sent to a public name the pod resolves differently from the world: every hop of a look stays on the forge's own listener through the host-resolver rule, or the capture refuses with "left the forge".

Parked by the crew: the check failed ("the look > a failed picture is retried on a doubling schedule, a thumb a week old is retaken, a failed retake keeps the picture, and an app that is not serving is skipped with its reason (#1150)") and the decider saw no point in another try (pull #1359 closed). Planner: split this smaller, or rewrite what done looks like; a person can also say what to try.

Parked by the crew: the check stayed red through 2 automatic tries (pull #1449 closed).

Parked twice since a person last spoke here, so it is the planner's now. Every reason:

1. the check failed ("the look > a failed picture is retried on a doubling schedule, a thumb a week old is retaken, a failed retake keeps the picture, and an app that is not serving is skipped with its reason (#1150)") and the decider saw no point in another try (pull #1359 closed)
2. the check stayed red through 2 automatic tries (pull #1449 closed)

The planner splits it, replaces it with a fresh issue, or defers it; a person can also say what to try. Nothing starts here until then, and the board lists it.

Deferred behind the Later gate (#595): look retries wait while the owner's top is /flow and Boards. The second try went red on its own looks test, so it should come back as two pieces: the retry schedule first, then the sleeping-app reason.