Stuck-state view: render where runs actually die in the pipeline #11

New Issue

2026-08-28T10:39:29Z

mathias commented

2026-08-28 10:39:29 +00:00

Proposed 2026-08-28. Consumes mathias/cad#14 (the cad-stuck query surface).

Why this fits the atlas specifically

cad-atlas already renders the CAD pipeline signal → deployed pod, and its roadmap moves from the static hero visualisation toward a live trace viewer. A stuck-state overlay is that evolution with a concrete, immediately useful first payload.

The pipeline diagram currently shows the happy path. A day of real runs showed the interesting information is where things stop:

Stage	What died there, 2026-08-27/28
Trigger	armed but never fired (`brain-gardener#190`)
Claim	claimed, executor could not start — 4 issues, tracker read them as handled
Execute	turn ceiling ×3, context/payload 413 ×1, denial loop ×1
Verify	—
Deploy	—
Close	5 sitting done-with-green-CI, awaiting a human

Rendered on the pipeline, that is immediately legible in a way a table is not: two clusters, one at claim/execute and one at the very end, with nothing in the middle. The middle is the part everyone assumes is risky.

The finding worth designing around

The largest stuck category is not a failure. Five issues are complete, pushed, CI-green including E2E, and simply waiting for a human to close them. That is the model working as intended — the human gate is real — but on any dashboard it reads as a backlog.

So the view must distinguish blocked from awaiting-human, or it will misrepresent a functioning control as a bottleneck. Suggest separating them visually rather than by a status label nobody reads.

Suggested first cut

Existing pipeline diagram, with a count badge per stage from cad-stuck
Two visual classes: stuck (needs intervention) vs awaiting human (working as designed)
Each badge links to the underlying issues, so the atlas becomes an entry point rather than a poster
Read-only, no controls — consistent with cad-atlas being a viewer and with cad#14 being observation not control

Scope note

Deliberately smaller than the "live trace viewer over the assessor-loop ledger" already on the roadmap. This needs one query and a badge per stage, and it can ship before the ledger integration exists. If it proves the pipeline-overlay idea, the fuller trace viewer inherits a validated design; if nobody looks at it, that is cheap to learn.

Depends on

mathias/cad#14. No point rendering a query that does not exist yet.

Closed by the infra#419 archived-repo sweep, 2026-09-16.

mathias/cad-atlas is archived in Gitea: read-only, and its comments endpoint returns HTTP 423. This disposition is in the body because a comment is not possible here.

Superseded by mathias/cad#19, which carries this work in the repo that is still live.

If this work is still live, it belongs on the successor repo, not here — nothing in an archived repo can be worked, labelled or reopened usefully.

Proposed 2026-08-28. Consumes `mathias/cad#14` (the `cad-stuck` query surface). ## Why this fits the atlas specifically cad-atlas already renders the CAD pipeline signal → deployed pod, and its roadmap moves from the static hero visualisation toward a live trace viewer. **A stuck-state overlay is that evolution with a concrete, immediately useful first payload.** The pipeline diagram currently shows the happy path. A day of real runs showed the interesting information is *where things stop*: | Stage | What died there, 2026-08-27/28 | |---|---| | Trigger | armed but never fired (`brain-gardener#190`) | | Claim | claimed, executor could not start — 4 issues, tracker read them as handled | | Execute | turn ceiling ×3, context/payload 413 ×1, denial loop ×1 | | Verify | — | | Deploy | — | | **Close** | **5 sitting done-with-green-CI, awaiting a human** | Rendered on the pipeline, that is immediately legible in a way a table is not: two clusters, one at claim/execute and one at the very end, with nothing in the middle. The middle is the part everyone assumes is risky. ## The finding worth designing around **The largest stuck category is not a failure.** Five issues are complete, pushed, CI-green including E2E, and simply waiting for a human to close them. That is the model working as intended — the human gate is real — but on any dashboard it reads as a backlog. So the view must distinguish **blocked** from **awaiting-human**, or it will misrepresent a functioning control as a bottleneck. Suggest separating them visually rather than by a status label nobody reads. ## Suggested first cut - Existing pipeline diagram, with a count badge per stage from `cad-stuck` - Two visual classes: **stuck** (needs intervention) vs **awaiting human** (working as designed) - Each badge links to the underlying issues, so the atlas becomes an entry point rather than a poster - Read-only, no controls — consistent with cad-atlas being a viewer and with `cad#14` being observation not control ## Scope note Deliberately smaller than the "live trace viewer over the assessor-loop ledger" already on the roadmap. This needs one query and a badge per stage, and it can ship before the ledger integration exists. If it proves the pipeline-overlay idea, the fuller trace viewer inherits a validated design; if nobody looks at it, that is cheap to learn. ## Depends on `mathias/cad#14`. No point rendering a query that does not exist yet. ---  **Closed by the infra#419 archived-repo sweep, 2026-09-16.** `mathias/cad-atlas` is archived in Gitea: read-only, and its comments endpoint returns HTTP 423. This disposition is in the body because a comment is not possible here. Superseded by mathias/cad#19, which carries this work in the repo that is still live. If this work is still live, it belongs on the successor repo, not here — nothing in an archived repo can be worked, labelled or reopened usefully.

mathias added the risk/low size/s type/feat labels 2026-08-28 10:39:37 +00:00

mathias commented

2026-08-28 11:35:11 +00:00

Closing out — built, shipped, and live.

What shipped

internal/atlas/stuck.go — ApplyStuckOverlay, fixture-tested, consumes mathias/cad#14's
cad-stuck query directly (imports git.d-ma.be/mathias/cad's app/domain packages —
they're public Go modules, so this reuses the exact tested classification logic instead of
duplicating the taxonomy across two repos).

Stage mapping

Per the table in this issue's own body, adapted to the pipeline's real 9 stages (there's no
literal Claim or Close stage, so they collapse):

cad-stuck category	Pipeline stage
`armed_never_fired`	STAGE 04 · Human dispatch gate
`claimed_never_ran`, `ceiling_hit`, `refire_loop`, `near_attempt_cap`	STAGE 05 · Execute
`done_not_closed`	STAGE 08 · Loop back

Two visual classes, as asked

A coral "N stuck" badge (needs intervention) vs a green "N awaiting" badge (a
functioning control waiting on a human) — done_not_closed can never render as a bottleneck,
each finding links out to the underlying issue/comment, read-only throughout.

Verified live, not just in fixtures

Ran the real server against real Gitea data — JSON matched cad#14's own proven output
exactly. Then screenshotted it (koala k3s Playwright job, not just curl'd the JSON):

STAGE 05: coral "2 stuck" badge, #30 ceiling_hit + #10 near_attempt_cap cards
STAGE 08: green "5 awaiting" badge, all 5 done_not_closed cards including the
reconciliation-fixed ones (#3/#7/#12, citing the specific Actions run that concluded
success after dispatch's own comment went stale)

A real CI break, found and fixed before closing

go mod download failed authenticating to mathias/cad — it's a private repo (unlike
mcp-chassis, the only other internal module any cad-* Dockerfile had fetched, which is
public). Fixed with a BuildKit secret + GIT_ASKPASS (mirrors this repo's own existing pattern
for its private swedsl dependency) — token never lands in a persisted image layer. Verified
the fix locally against the real koala buildkitd before repushing, not by guessing and
re-running CI blind.

Final state: mathias/cad-atlas@62955c9, tagged v0.7.0, CI green end-to-end including
Deploy via GitOps — kubectl rollout status confirmed the live rollout, not assumed from a
green checkmark alone.

Depends-on chain, closed in order

cad#14 (proven against live estate) → skills#31 (built on the proven query) → this issue
(consumes the same proven query). All three now shipped and live.

Closing out — built, shipped, and live. ## What shipped `internal/atlas/stuck.go` — `ApplyStuckOverlay`, fixture-tested, consumes `mathias/cad#14`'s `cad-stuck` query **directly** (imports `git.d-ma.be/mathias/cad`'s `app`/`domain` packages — they're public Go modules, so this reuses the exact tested classification logic instead of duplicating the taxonomy across two repos). ## Stage mapping Per the table in this issue's own body, adapted to the pipeline's real 9 stages (there's no literal Claim or Close stage, so they collapse): | cad-stuck category | Pipeline stage | |---|---| | `armed_never_fired` | STAGE 04 · Human dispatch gate | | `claimed_never_ran`, `ceiling_hit`, `refire_loop`, `near_attempt_cap` | STAGE 05 · Execute | | `done_not_closed` | STAGE 08 · Loop back | ## Two visual classes, as asked A coral **"N stuck"** badge (needs intervention) vs a green **"N awaiting"** badge (a functioning control waiting on a human) — `done_not_closed` can never render as a bottleneck, each finding links out to the underlying issue/comment, read-only throughout. ## Verified live, not just in fixtures Ran the real server against real Gitea data — JSON matched `cad#14`'s own proven output exactly. Then **screenshotted it** (koala k3s Playwright job, not just curl'd the JSON): - STAGE 05: coral "2 stuck" badge, `#30 ceiling_hit` + `#10 near_attempt_cap` cards - STAGE 08: green "5 awaiting" badge, all 5 `done_not_closed` cards including the reconciliation-fixed ones (`#3`/`#7`/`#12`, citing the specific Actions run that concluded success after dispatch's own comment went stale) ## A real CI break, found and fixed before closing `go mod download` failed authenticating to `mathias/cad` — it's a **private** repo (unlike `mcp-chassis`, the only other internal module any cad-* Dockerfile had fetched, which is public). Fixed with a BuildKit secret + `GIT_ASKPASS` (mirrors this repo's own existing pattern for its private `swedsl` dependency) — token never lands in a persisted image layer. Verified the fix **locally against the real koala buildkitd** before repushing, not by guessing and re-running CI blind. Final state: `mathias/cad-atlas@62955c9`, tagged **v0.7.0**, CI green end-to-end including `Deploy via GitOps` — `kubectl rollout status` confirmed the live rollout, not assumed from a green checkmark alone. ## Depends-on chain, closed in order `cad#14` (proven against live estate) → `skills#31` (built on the proven query) → this issue (consumes the same proven query). All three now shipped and live.

mathias referenced this issue from a commit

2026-08-28 20:01:55 +00:00

feat(atlas): surface the user's own Gitea repos on stage 05 (#10)

mathias referenced this issue

2026-08-28 20:02:54 +00:00

atlas: repos panel — surface the user's own Gitea repos, mirroring the shipped issues slice #10

mathias closed this issue

2026-09-16 20:23:26 +00:00

This repo is archived. You cannot comment on issues.