view release on metacpan or  search on metacpan

DASHBOARD_IMPROVEMENT_PLAN.md  view on Meta::CPAN

## 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`

doc/internal-operating-checklist.md  view on Meta::CPAN

## 14. Recurring Mistakes To Screen For

Before and after implementation, explicitly check for these repeat failure
patterns:

1. claiming success before the runtime is truly ready
2. reading only part of the instructions or only part of the relevant docs
3. flattening layered behavior into a simpler project-vs-home shortcut
4. allowing docs, POD, or release notes to drift from real behavior
5. relying on source-checkout paths that fail after tarball install
6. weakening auth or exposing browser/runtime data incorrectly
7. trusting test output without checking real browser or SSL/runtime behavior where required
8. under-testing Windows, blank-environment installs, or packaged-runtime paths
9. treating Scorecard, coverage, or packaging as optional cleanup instead of delivery gates
10. stopping at `I can do X next` when X is already the correct next action

## 15. Definition Of Done

A task is done only when:

1. the implementation is correct