mathiasandClaude Opus 5
097d8747c6
Adds the repos panel from #4's "Not yet shipped" list, following the shipped
issues slice (b2761a4) structurally rather than inventing a second approach:
- internal/atlas/repos.go — RepoNodes(), a pure parser over an already-decoded
/user/repos response. Archived repos are dropped: the atlas shows where work
happens, and an archived repo is by definition somewhere it does not.
- internal/gitea/client.go — MyRepos(), same PAT and same contract as MyIssues:
errors when GITEA_TOKEN is unset so the caller skips the overlay rather than
issuing an unauthenticated request. That unset path is the one running in
prod today (#4), so it is tested, not assumed.
- internal/web/handler.go — wired into liveOverlay().
Stage 05 is the right home — repos are what the execution stage acts on — but
#11 had just claimed its `generate` key for stuck-badges, and a stage could
only name one source. So `generate` now accepts either spelling:
"generate": "ci-jobs"
"generate": ["stuck-badges", "gitea-repos"]
The bare string stays valid and marshals back as a bare string, so no authored
stage is rewritten and the frontend contract is unchanged. Stages 04 and 08
already share stuck-badges between them; this is the same growth one level in.
The overlay merge also moves out of the handler into atlas.PrependGenerated,
which is unit-testable where the inline loop was not — it sat behind a network
call. It covers the issues path too, and fixes a latent aliasing bug there: the
old `append(liveNodes, authored...)` wrote into the live slice's backing array,
so two stages sharing a key would corrupt each other. That shape is no longer
hypothetical now that stuck-badges spans three stages.
Verified end-to-end both ways: without GITEA_TOKEN the atlas returns 200 with
stage 05's authored nodes intact; with a real token stage 05 serves both
overlays at once — stuck badges, then eight live repos, then the authored
nodes — and a repo with no language emits one tag rather than an empty pill.
task check green (golangci-lint 0 issues, vet, -race).
Closes #10.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
cad-atlas
A visual atlas of the Continuous Agentic Development (CAD) workflow — from a captured signal to a deployed k3s pod.
One screen, reel-style: Signals → TELOS → Strategic session → Spec/Oath → Human gate → agentsquad → CI → CD → pod, looping back to TELOS. It renders the CAD audit chain, which doubles as the regulated-industry audit artifact.
The CAD audit chain is the visualization data. Phase C renders it once and serves two masters: observability + compliance.
Phases
- A — static hero viz (current): self-contained
internal/web/static/cad-atlas.html, served at/. SVG spine, animated pulse, dashed feedback bus, replay/slow-mo. - B — generated-from-source: render from brain docs + workflows + infra manifests (no drift).
- C — live trace viewer: hydrate from the
assessor-loopledger +session_log+ Gitea run API + Flux events.
Quickstart
task check # lint + vet + test (CI gate)
task run # → http://localhost:8080
Context
Full project context, the 9-stage workflow, the three governance gates, the dogfooding model, and all brain deep-links + external references live in .context/PROJECT.md. Any clean agent session should read that first (brain_get <path> for the linked notes).
Governance (dogfooded)
This repo is built through the workflow it depicts: dispatch-allow-enabled, build increments governed by a var-go Oath in their spec issues. Bootstrapping honesty: the Oath is defined but cmd/vargo-gate is not yet wired into this repo's CI — advisory until it is. See PROJECT.md.