view release on metacpan or  search on metacpan

DASHBOARD_IMPROVEMENT_PLAN.md  view on Meta::CPAN

Keep the public `dashboard` command thin. Do not replace the switchboard design. Instead, reduce repeated startup work, especially current-directory and project-root recomputation.

### Recommended Priority Order

1. Eliminate repeated `cwd()` calls from the startup and helper path.
2. Add request-local caching inside `PathRegistry` for cwd, project root, runtime layers, and derived roots.
3. Profile and optimize dotted skill dispatch, especially nested skill command routing.
4. Audit helper commands like `paths` for repeated calls into path-derivation methods that can be computed once.
5. Only after that, consider deeper module-load reduction in `bin/dashboard`.

## Solution Plan

### Phase 1: Remove High-Volume `cwd()` Cost

- Store a single cwd value per invocation and reuse it throughout the command lifetime.
- Teach `PathRegistry` to accept and actually use a precomputed cwd.
- Replace repeated internal `cwd()` lookups with the cached value wherever the command is operating in one fixed current directory.

### Phase 2: Add Request-Local `PathRegistry` Memoization

- Memoize:
  - current project root
  - runtime layers
  - runtime root
  - state root and derived roots
  - CLI root and similar derived directories
- Keep memoization strictly per-process and per-invocation so it does not create stale cross-command state.

### Phase 3: Reduce Repeated Helper-Side Computation

- For helper commands like `paths`, compute the path inventory once and reuse that data structure rather than calling multiple lazy getters that each recompute upstream state.
- Review `all_paths()` and related accessors for repeated tree walks and repeated state-root creation.

### Phase 4: Module Load Cleanup

- Move non-essential `use` statements behind `require` when the command path does not always need them.
- Keep the switchboard’s eager module set as small as possible.
- Preserve readability and safety; do not trade away clear error behavior for micro-optimizations.

### Phase 5: Dotted Skill Dispatch Optimization

- Profile the `ssh.list` and `sk.system-status.disk /` paths specifically.
- Measure where time goes inside:
  - skill name resolution
  - nested skill discovery
  - env-layer loading
  - command path selection
  - repeated cwd and project-root derivation
- Add request-local caching for nested skill lookup results where safe.
- Avoid recomputing the same nested skill chain multiple times during one invocation.

## Expected Outcome

The biggest likely gain is from removing repeated `/bin/pwd` subprocess calls. Since the trace showed 72 `pwd` executions for one `dashboard paths` command, reducing that to one or a small handful should materially reduce wall time. After that, reque...

The second biggest likely gain is from optimizing dotted skill dispatch. The measured gap between `dashboard ssh.list` and the direct skill CLI, and between `dashboard sk.system-status.disk /` and the direct nested skill CLI, is large enough that imp...

## Implementation Notes

- Any optimization work should preserve the DD-OOP-LAYERS behavior and lookup order.
- Do not hide errors or weaken explicit runtime checks.
- Re-profile after each phase instead of batching all changes blindly.

## Suggested Verification After Changes

1. Re-run timing probes for `dashboard version` and `dashboard paths`.
2. Re-run syscall trace and count `/bin/pwd` executions.
3. Verify helper behavior and path outputs remain identical.
4. Re-run the dispatch-shape benchmarks for:
   - `dashboard ps1`
   - `dashboard system-temp cpu`
   - `dashboard ssh.list`
   - `dashboard sk.system-status.disk /`
5. Run the relevant CLI, path, and skill-dispatch regression tests.

## Conclusion

The public `dashboard` command is not slow because the switchboard pattern is wrong. It is slow because repeated path discovery work, especially `cwd()` on this environment, is expensive and occurs many times per invocation. On top of that, dotted sk...