v0.10.0: One Command to Rule Them All

If you use AI coding agents seriously, you have probably hit this wall: the agent is productive, but keeping it well-informed takes work. Does it know your .env schema? Does it know which ports your services claim? Is your CLAUDE.md still accurate after three sprints of refactoring? Are the docs you told it to trust still correct?

Each of those is a solved problem. WhenLabs ships tools for all of them. The friction was that each tool had its own config file, its own install step, and its own CLI surface. A six-tool toolkit was starting to feel like a six-tool burden.

v0.10.0 is the release that collapses that complexity.

What shipped in v0.10.0

1. when init — full project onboarding in one command

Before v0.10.0, onboarding a new project meant: create .env.schema, create .vow.json, create .stale.yml, register berth ports, run each tool to verify, fix whatever it found. Four to eight commands, in order, some depending on others.

when init does all of it in one shot:

$ when init

when  Project onboarding

  Project:  my-saas-app
  Stack:    Node.js + TypeScript + React
  Package:  npm (347 deps)

  Bootstrap
  + Created .env.schema
  + Created .vow.json  (opensource)
  + Created .stale.yml
  + Generated .whenlabs.yml

  Scan
  ✓ stale     No doc drift
  ! envalid   2 undocumented env vars
  ✓ berth     No port conflicts
  ✓ vow       All licenses permissive
  ✓ aware     Generated CLAUDE.md, .cursorrules

Run when install to connect MCP tools to your editor.

Bootstrap, parallel scan, auto-fix, unified config — all in one call. The command is idempotent: safe to re-run after adding new services or dependencies.

2. Auto-fix MCP tools — scan and fix in a single call

Every tool that can fix things now has an _auto_fix variant that combines the scan and the fix into one MCP call:

Before, an agent running these checks had to call stale_scan to find issues, inspect the output, then call stale_fix with the right arguments. Two round-trips, and the agent had to correctly parse and re-encode the scan results.

With stale_auto_fix, the agent makes one call. The tool handles the feedback loop internally and returns a summary of what it fixed. This also means the auto-fix tools work correctly even in autonomous or background contexts where there is no agent to interpret intermediate results.

3. Cross-tool intelligence

Tools now trigger suggestions for related tools when they detect relevant issues. These surface as Tip: lines in tool output.

For example: running aware_init generates new context files. Generating new files means existing stale-detection baselines may be wrong. So aware_init now emits:

Tip: New files generated — run stale_scan to update drift baselines.

Or: envalid_detect finds a REDIS_URL env var. That looks like a service URL, which means there is probably a port involved:

Tip: Service URL env vars detected — run berth_register to track ports.

The connections are not hardcoded rules. They are grounded in what each tool actually observes. The result is that running one tool surfaces work you would have otherwise missed.

4. Unified .whenlabs.yml config

Previously each tool read from its own config file: .stale.yml, .vow.json, .aware.json, etc. They still work. But v0.10.0 introduces .whenlabs.yml as a single source of truth for all six tools:

# .whenlabs.yml
stale:
  ignore: ["node_modules", "dist"]

envalid:
  schema: .env.schema
  envFiles: [".env", ".env.local"]

berth:
  ports:
    api: 3000
    worker: 3001

vow:
  policy: opensource

aware:
  targets: [claude, cursor]

Generate it from your existing configs with when config init. Validate with when config validate. All six tools read .whenlabs.yml first. Per-tool config files remain as overrides.

Getting started

Three lines:

npx @whenlabs/when install   # register MCP server, write CLAUDE.md
when init                    # onboard current project
when doctor                  # verify everything looks good

That is it. All six tools are available to your agent in every session.

What is next

The next release is focused on the velocity side of the toolkit: a web-based task timing dashboard, smarter velocity estimates that account for task type and file complexity, and export to standard time-tracking formats. If your team has multiple engineers using AI agents, velocity data across sessions becomes genuinely useful for planning — that is what we are building toward.

If you run into issues or have questions: github.com/WhenLabs-org/when