view release on metacpan or  search on metacpan

README.md  view on Meta::CPAN

```

Collector indicators follow the collector exit code automatically: `0` stores
an `ok` indicator state and any non-zero exit code stores `error`.
When `indicator.name` is omitted, the collector name is reused automatically.
When `indicator.label` is omitted, it defaults to that same name.
Configured collector indicators are now seeded immediately, so prompt and page
status strips show them before the first collector run. Before a collector has
produced real output it appears as missing. Prompt output renders an explicit
status glyph in front of the collector icon, so successful checks show `✅🔑`
style fragments and failing or not-yet-run checks show `🚨🔑` style fragments.
Under `DD-OOP-LAYERS`, a deeper child layer no longer pins an inherited
collector indicator at that default `missing` placeholder just because the
child runtime has its own `.developer-dashboard/` folder. If the child layer
does not override that collector config and only has the placeholder state,
dashboard now falls back to the nearest inherited real collector state such
as a parent-layer `ok` result instead of turning the same indicator red.
The top-right browser status strip now uses that same configured icon instead
of falling back to the collector name, and stale managed indicators are
removed automatically if the collector config is renamed. The browser chrome
now uses an emoji-capable font stack there as well, so UTF-8 icons such as
`🐳` and `💰` remain visible instead of collapsing into fallback boxes.
For TT-backed collector icons, a collector such as `./foobar` can print
`{"a":123}` on `stdout`; the runner decodes that JSON into Perl data and
renders `[% a %]` into the live icon `123`. Later config-sync passes keep the
configured `icon_template` metadata and the already-rendered live `icon`, so
commands such as `dashboard indicator list` and `dashboard ps1` do not revert
the persisted icon back to raw `[% ... %]` text between runs.
The blank-environment integration flow also keeps a regression for mixed
collector health isolation: one intentionally broken Perl collector must stay
red without stopping a second healthy collector from staying green in
`dashboard indicator list`, `dashboard ps1`, and `/system/status`.

### Docker Compose

Inspect the resolved compose stack without running Docker:

```bash
dashboard docker compose --dry-run config
```

Include addons or modes:

```bash
dashboard docker compose --addon mailhog --mode dev up -d
dashboard docker compose config green
dashboard docker compose config
dashboard docker list
dashboard docker list --disabled
dashboard docker list --enabled
dashboard docker disable green
dashboard docker enable green
```

The resolver also supports old-style isolated service folders without adding entries to dashboard JSON config. If `./.developer-dashboard/docker/green/compose.yml` exists in the current project it wins; otherwise the resolver falls back to `~/.develo...
To toggle that marker without creating or deleting the file manually, use `dashboard docker disable <service>` or `dashboard docker enable <service>`. The toggle writes to the deepest runtime docker root, so a child project layer can locally disable ...
To inspect the effective marker state without walking the folders manually, use `dashboard docker list`. Add `--disabled` to show only disabled services or `--enabled` to show only enabled services.

During compose execution the dashboard exports `DDDC` as the effective config-root docker directory for the current runtime, so compose YAML can keep using `${DDDC}` paths inside the YAML itself.
Wrapper flags such as `--service`, `--addon`, `--mode`, `--project`, and `--dry-run` are consumed first, and all remaining docker compose flags such as `-d` and `--build` pass straight through to the real `docker compose` command.
Without `--dry-run`, the dashboard hands off with `exec`, so you see the normal streaming output from `docker compose` itself instead of a dashboard JSON wrapper.

### Prompt Integration

Render prompt text directly:

```bash
dashboard ps1 --jobs 2
```

`dashboard ps1` now follows the original `~/bin/ps1` shape more closely: a
`(YYYY-MM-DD HH:MM:SS)` timestamp prefix, dashboard status and ticket info, a
bracketed working directory, an optional jobs suffix, and a trailing
`🌿branch` marker when git metadata is available. If the ticket workflow
seeded `TICKET_REF` into the current tmux session, `dashboard ps1` also reads
it from tmux when the shell environment does not already export it.

The path helpers also treat path identity canonically where the filesystem can
surface aliases. On macOS, `dashboard path project-root`, `cdr`, and
`which_dir` may report the same temp tree through `/private/var/...` even
when the shell entered it through `/var/...`, and the test/install contract
now treats those as the same real path instead of failing on a raw-string
mismatch.

Generate shell bootstrap:

```bash
dashboard shell bash
dashboard shell zsh
dashboard shell sh
dashboard shell ps
```

The generated shell helper keeps the same bookmark-aware `cdr`, `dd_cdr`, `d2`, and
`which_dir` functions across all supported shells. `cdr` first tries a saved
alias, then falls back to an AND-matched directory search beneath the alias
root or the current directory depending on whether that first argument was a
known alias. One match changes directory, multiple matches print the list, and
`which_dir` prints the same selected target or match list without changing
directory. The shell-smoke regression coverage also compares those printed
paths by canonical identity, so macOS `/var/...` and `/private/var/...`
aliases do not fail equivalent `pwd` / `which_dir` checks. Bash still uses `\j` for job counts, zsh refreshes `PS1` through a
`precmd` hook with `${#jobstates}`, POSIX `sh` falls back to a prompt command
that does not depend on bash-only prompt escapes, and PowerShell installs a
`prompt` function instead of using the POSIX `PS1` variable.

`d2` is the short shell shortcut for `dashboard`, so after loading the
bootstrap you can run `d2 version`, `d2 doctor`, or `d2 docker compose ps`
without typing the full command name each time.

The same generated bootstrap also wires live tab completion for `dashboard`
and `d2`. Bash registers `_dashboard_complete`, zsh registers
`_dashboard_complete_zsh`, and PowerShell registers `Register-ArgumentCompleter`
for both command names. Completion candidates come from the live runtime
instead of a hardcoded shell list, so built-in commands, layered custom CLI
commands, and installed dotted skill commands all show up in suggestions.
For bash, the generated helper captures completion payloads first instead of
relying on process substitution, which keeps completion responsive on macOS
and inside packaged install-test shells.
The generated bootstrap also wires `cdr`, `dd_cdr`, and `which_dir`
completion. The first argument suggests saved aliases plus matching directory