Oliver Zehentleitner

Thanks for the hint :)

Now with dashboard 0.6.14 it can! See the "cited by" filter in the graph. Turn off friends to see it in this setup: https://keepthewhy.com/dashboard/live/#graph

Should be fixed with PR #585 and #586, released in dashboard 0.6.8. In the status bar at the bottom of the dashboard (https://keepthewhy.com/dashboard/live/) it says something like "10 states · 628.3 KB" - click on that. That's the "State Monitor": it lists every state the page loaded, and from now on also every one that failed, with the reason (e.g. "network error or blocked by CORS") and the address. A failed repository is also named in the globe's legend.

Good catch, and it's half covered. Not silent: since a recent release a repository that fails to load in a globe or registry wave is listed in the legend as "not loaded", with the reason on hover, and the rest of the wave loads. But the reason can't tell CORS from "host down" - browsers deliberately report both as the same network error to the page, so all you get today is "Failed to fetch", and the docs don't say the export host has to send Access-Control-Allow-Origin. Fair point that this is exactly what nobody notices until they hit it. I'll make the message name CORS as the likely cause, document the header for the common hosts, and have the registry check warn when an export is served without it - that one can see the headers, the browser can't.

Thanks - that was exactly the reasoning: an edge in the graph means someone wrote it down, nothing else. On the reverse direction: right now only by loading. The registry index is just the list (where each export lives, versions, size), not who cites whom. The globe can load everything listed in one wave, and from then on the graph shows citations both ways - so with the registry you do see who references you, but you pay for loading them, and that won't scale forever. Since the registry build already reads every export, it could write a small reverse index on the side, so a dashboard sees who cites it without loading them all. Not there yet, but it's one possible way if more projects get listed.

Yes, that's the experiment :) Maybe it turns out to be a fit for small and mid-sized teams only, but I'm curious how far it goes too.

A global graph with registered repositories ^^: https://keepthewhy.com/dashboard/live/#globe

Yes, and this is exactly where I think the agent itself has to remain the brain. Keep the Why does not try to infer semantic staleness on its own. A code diff is not enough for that anyway. A decision can survive a complete rewrite, while a tiny configuration change can invalidate it. KTW gives the agent lifecycle signals instead: Revisit when, evidence, verification, needs-review, supersession, and the surrounding rationale. When the agent works on the project again, it has to reason over those signals and the current codebase. If something no longer fits, it can flag the entry, revise it, or supersede it. The graph helps with visibility. If one rationale entry becomes questionable, it can show the later entries linked to it and where they live. But it does not claim that they are automatically invalid. I think that separation is important: Keep the Why stores and connects the reasoning. The agent interprets it.

Thanks! I'm working my way outwards from the core functions :)

That's a good third layer: working memory inside the current session. Keep the Why deliberately wouldn't pin the original prompt verbatim - that would turn project memory into a session log. But if part of the request becomes durable project intent, a constraint, or a decision, that distilled part should survive in context/. If compaction loses the current task goal before that point, I'd treat that as a session/runtime problem rather than project memory. The live graph is a good illustration of what happens after something crosses that durability threshold: it becomes connected repository knowledge rather than another isolated session note. https://keepthewhy.com/dashboard/live/#graph Grunz's example is a really good illustration of the boundary.