What Changed Since "Routing, Collectors and Workspaces"

2026-05-15

The last Developer Dashboard update was about broader platform dependability: cleaner installs, better progress reporting, safer runtime control and less fragile cross-platform setup.

This follow-up is narrower and more interesting.

It is not about making the system look bigger. It is about making the daily operating model harder to break.

For terminal-first developers, this work is about reducing the number of quiet failures and stale assumptions that show up once a local runtime is used all day.

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

• What Changed Since "Layers, Context, Skills, Pages and Runtime"
• How Developer Dashboard Layers Context, Skills, Pages and Runtime
• Introducing Developer Dashboard: A Terminal-First Workspace for Local Developer Operations

The recent work is less about adding another surface area and more about tightening the runtime loops that usually go wrong in long-lived local tooling.

The Useful Summary

Six changes matter most in practice:

• collector watchdogs now treat stalls as failures instead of only clean exits
• collector overlap is now an explicit policy instead of accidental behavior
• child-process cleanup got stricter, which matters on macOS and WSL
• route aliases can now cover /app, /ajax, /js, /css and /others
• resuming a workspace now rebuilds plain .env state from the directory chain instead of trusting the old tmux session blindly
• skills can now ship JavaScript and Python commands without changing the dispatch model

If the earlier update made Developer Dashboard feel broader, this one makes it feel more operational.

1. Collectors Are Now Managed Like Real Background Work

Collector reliability is one of those things users notice only after it fails.

The bad version of the experience is familiar:

• the collector is configured
• the prompt still implies everything is fine
• the process might even still exist
• the underlying state has quietly stopped updating

That is exactly the kind of failure mode local tooling should catch first.

The newer collector supervision work now restarts dead loops, treats live-but-stalled loops as unhealthy and records restart history and restart-window state before escalating to an attention-needed condition.

That is a much better contract. The runtime should not require the user to babysit ps output just to learn whether a background status loop is still doing useful work.

Overlap stopped being undefined behavior

Collector execution also got a cleaner policy model.

The safe default is still singleton, which suppresses a new run if the old one is still active.

There is now a deliberate multiple mode for collectors where skipping an interval is worse than overlap, with bounded concurrency instead of accidental pileups.

That changes overlap from "whatever happened under load" into part of the configuration model.

2. Process Cleanup Matters More Than It Looks

Another quiet improvement is child-process cleanup.

This is not glamorous work, but it is the kind of runtime bug that destroys trust slowly. A tool can look functional while it leaves zombie launcher processes behind.

The recent cleanup work tightened managed collector shutdown, detached helper behavior and web runtime cleanup paths so unreaped children are treated as a real regression instead of tolerated noise.

For a tool meant to sit on a machine all day, that is a meaningful quality threshold.

3. Routing Got Broader Without Getting Confusing

Developer Dashboard had already started moving toward a cleaner model for skill-local routes and saved surfaces. The new work makes that model easier to reason about.

Custom route aliases now live in config/routes.json and the structure is flatter: public paths map directly to the internal route they should resolve to.

That sounds minor, but route configuration should be readable the moment a user opens the file.

Alias coverage is now wide enough to be practical

The more important change is scope.

Route aliases can now cover /app, /ajax, /js, /css and /others.

That means cleaner URLs are no longer limited to one route family. Saved pages, handlers and static assets can sit behind the same alias model instead of relying on separate special cases.

Smart routing still wins first

The right routing rule here is simple:

1. try normal smart route resolution first
2. fall back to the configured alias
3. return 404 if neither path resolves

That preserves the layered routing model instead of turning aliases into a second competing dispatcher.

One practical result is that saved pages can now resolve cleanly behind runtime aliases as well, which is exactly the kind of small detail that makes a local dashboard feel natural instead of brittle.

4. Workspaces Replaced The Older Ticket Mental Model

The dashboard workspace flow is now the primary tmux-oriented session model, with the older ticket naming kept as a compatibility path.

That rename is more accurate. The feature is not really about tickets. It is about resuming project work with the right shell state and the right context.

Environment refresh now behaves the way people expect

The more important improvement is environment handling.

When a workspace is created or resumed, Developer Dashboard now rebuilds environment state from the directory chain:

• highest ancestor .env first
• parent .env files next
• current directory .env last

Removed keys also get unset during refresh, so a resumed session does not keep carrying dead state forward.

That is exactly the difference between "tmux remembered something" and "the workspace was resumed correctly".

5. Skills Now Speak Node And Python Natively

This is the most visible extension in the update.

Skill commands can now be written in JavaScript through node and Python through python, alongside the existing Perl, Go, Java and shell-backed command model.

That matters because skills are supposed to be reusable local capability bundles, not language-gated demos. A team that already has small Node or Python helpers should be able to drop them into the same command and hook flow without rewriting them first.

The important design choice is that this does not introduce a separate "Node mode" or "Python mode". It extends one dispatch model across more runtimes.

6. Dependency Handling Finally Matches The New Command Surface

Supporting new command runtimes without their package manifests would have been incomplete.

That gap is now closed.

Skills can now carry package.json and requirements.txt alongside the existing dependency surfaces, with the install flow handling them in a predictable order.

That makes the skill system more credible as a packaging surface instead of only a dispatch surface.

Why This Update Matters

This work is not flashy, but it is the kind of work that decides whether a local developer platform survives daily use:

• does it notice when its own background loops are unhealthy
• does it avoid leaking process junk
• does routing stay coherent as more surfaces get exposed
• does tmux resume the actual workspace state
• can teams reuse the language runtimes they already use

That is the difference between an interesting framework and an operating surface people keep around.