← back to index

What Changed Since Runtime Hardening, API Auth and Layered Skills Became Real

2026-06-04

The last Developer Dashboard update was about making the runtime feel sturdier in daily use: collectors got more honest, routing got wider, workspaces resumed with better state and skills stopped assuming one language.

This next round matters for a different reason.

Developer Dashboard is starting to behave like a real local platform that can be automated safely, layered deeply and trusted across less-friendly environments.

That is the stage where local tooling either gets promoted into daily infrastructure or gets exposed as something that only worked in the checkout that created it.

If you have not read the earlier posts yet, start here:

Developer Dashboard runtime hardening illustration showing route-scoped API auth layered skills and portable local runtime defenses — This update is about trust boundaries, deeper layering and the kind of runtime hardening that only matters once a tool is used on imperfect machines.

The Useful Summary

Five changes stand out most:

selected saved Ajax routes can now be exposed to machine callers through route-scoped API credentials
the new dashboard api command makes that model operable instead of hand-maintained
layered skills now carry more of the real runtime chain, especially for env loading, Docker roots and shared navigation
runtime behaviour got harder to break on machines with stale Perl libraries, stripped PATH values, shell startup noise or packaged-install drift
the public command path got leaner, while collector lifecycle behaviour became safer

This is less about one UI-visible feature and more about a maturity shift. More of the platform now behaves like something that expects contact with reality.

1. Saved Ajax Routes Can Be Automated Without Weakening Browser Auth

The biggest conceptual change is the new machine-auth path for selected saved Ajax routes.

Previously, saved /ajax/... routes worked well for the browser and for helper-backed local sessions, but there was no clean machine-to-machine model. That forced awkward workarounds if you wanted to expose one specific dashboard action to another tool.

The new model is intentionally narrow.

Machine-facing access is configured in:

config/api.json

Callers must present:

X-DD-API-Key
X-DD-API-Secret

Stored secrets are verified as digests instead of raw plain-text values and unregistered routes still go through the normal helper-auth flow.

That is the right security shape for a local platform. The system is not switching everything into a vague API mode. It is authorising exact saved routes for explicit machine callers.

2. `dashboard api` Turns The Auth Model Into Operations

A backend auth model only becomes useful once operators can inspect and change it without editing layered JSON by hand.

That is why dashboard api matters:

dashboard api list
dashboard api add --route /ajax/example --key build-bot
dashboard api remove --route /ajax/example --key build-bot

The command gives operators a practical surface to:

inspect the effective merged registry
add or remove exact route grants
hash raw secrets before they are written
write only to the deepest writable layer
hide inherited API groups in child layers without mutating the parent

That last behaviour fits the broader design of Developer Dashboard. A child project can tighten inherited machine access locally without having to rewrite shared home-level configuration.

3. Layered Skills Stopped Acting Flat

One of the more important architectural shifts is that installed skills now behave more honestly as layered runtime content instead of top-level conveniences with exceptions.

Installed nested skills now load env files from root to leaf and overridden values are preserved under cumulative aliases. That means a deep skill command can still see the path of overrides that produced the final environment instead of only the last value that won.

Installed nested skills also contribute more cleanly to runtime surfaces that used to be shallower than the command tree:

Docker compose resolution now understands installed skill roots more accurately
shared nav/*.tt fragments can follow the same layered model as the rest of the runtime
nested skill trees behave more like actual runtime modules and less like bolt-ons

This is the sort of work that does not look dramatic in a screenshot, but it removes structural dishonesty from the platform.

4. Runtime Hardening Finally Targets Messy Machines

Some of the highest-value work here is the least glamorous.

Developer Dashboard now does more defensive repair around environments that are technically valid but operationally hostile. That includes stale local Perl modules, partial PATH values, shell startup chatter and packaged helper scripts that remember the wrong source path.

Installed nested skills now load env files from root to leaf, but the runtime work goes further than layered env state alone.

Dashboard-managed child commands also keep both:

the current Perl interpreter directory
the active shell directory

at the front of PATH.

That reduces a whole class of "works only in the shell that built it" failures, especially when subprocesses eventually re-enter dashboard through a generic #!/usr/bin/env perl path.

Collector shell commands now run through a non-login shell, which is exactly the right fix when shell startup banners or session-restore chatter are corrupting JSON output that would otherwise parse cleanly.

Packaged helper bootstrap behaviour also got corrected so staged helpers re-enter the active public dashboard entrypoint instead of leaking old checkout paths into extracted installs.

5. The Public Command Path Feels Lighter

The runtime also got leaner in the places users pay for constantly:

prompt dispatch avoids more unnecessary helper and suggestion work
helper refresh can target one helper instead of restaging everything
path derivation and invocation context are reused more aggressively
prompt rendering skips tmux and collector work when the environment does not need it

That sounds small until you multiply it across a full day in the terminal.

Developer Dashboard is gradually moving from "clever command surface" toward "background layer that stays out of the way until needed".

That is the correct destination for a prompt-adjacent local runtime.

6. Collector Operations Got Safer Too

This update also tightened collector control in quieter but important ways.

Disabled collectors now behave like runtime truth, not UI decoration. When a collector is disabled, it is stopped, skipped and prevented from reappearing through stale indicators or accidental named starts.

Manual lifecycle actions also interfere less with the watchdog. Explicit stop and restart operations pause supervision long enough to avoid the classic race where the watchdog respawns a collector underneath the operator's own action.

Those changes are not flashy, but they matter for trust. Background process control has to feel deliberate if the rest of the runtime is going to be taken seriously.

Why This Update Matters

These changes look varied on the surface:

route-scoped API credentials
a usable API management command
deeper layered skill behaviour
defensive runtime path repair
lighter prompt dispatch
stricter collector lifecycle semantics

Underneath, they are all about the same thing: reducing hidden assumptions.

Developer Dashboard is becoming more explicit about who can call what, which layer owns a setting, which path is actually active and which process lifecycle belongs to the tool.

That is what maturity looks like in local infrastructure.

Closing

The newest work is not about making Developer Dashboard look bigger. It is about making it safer to automate, harder to confuse and more portable across the kinds of machines developers actually use.

That is a strong direction, because once a local platform can expose selected behaviour deliberately, keep layered context coherent and survive rough environments, it stops feeling like a pile of useful commands.

It starts feeling like infrastructure.