view release on metacpan or  search on metacpan

doc/problem-report.md  view on Meta::CPAN

record and made Docker appear first in the prompt.

Reproduction: run `d2 ps1` in a shell without tmux indicator suppression, or
unset `TMUX`, `WORKSPACE_REF`, `TICKET_REF`, and
`DEVELOPER_DASHBOARD_TMUX_STATUS` for the command. Before the change, core
refresh probes for Docker and creates a whale status even with no configured
Docker collector. The focused Docker test reproduced the old behavior by
replacing the executable probe with a fatal test stub; the first red run exited
early at that probe. A second fixture seeds the exact old core record and
checks that core refresh removes it while preserving a collector-managed
`docker` record.

Implementation removes the executable probe and built-in status write. Core
refresh recognizes and removes only the former exact built-in record signature;
customized and collector-managed Docker indicators remain intact. The focused
Docker regressions pass after the change.

Safety regression: three red assertions exposed missing writer-lock protection
and invisible lock failures in cleanup. Cleanup now acquires the same lock as
status writers before reading ownership. Rerunning both focused test files in
Docker passed 1,042 assertions, including layered/custom collector preservation
and visible filesystem failures.

Container setup correction: the first full run hit Git's dubious-ownership
guard for the bind-mounted `/work` checkout, failing four tracked-document
assertions. A disposable Compose test definition adds `/work` to Git's
safe-directory list inside the test container only. The affected integration
asset tests and indicator tests then passed 491 assertions; the full gate was
restarted with that same isolated setup. Host Git settings were not changed.
The release-metadata gate then caught a stale main-POD version and a disallowed
word in the new testing guidance. Both were corrected; README was regenerated
from POD. Release metadata, integration assets, and indicator regressions passed
5,913 assertions before the next full run.

Security applicability review (ASVS V1–V14): V1/V11 preserve the opt-in
indicator contract; V5 uses a fixed name and presentation signature, not
user-supplied command or path text; V7 reports lock/open/remove errors;
V8/V12 preserve configured records and serialize filesystem cleanup; V14
removes an unwanted default without changing configuration. V2/V3/V4,
V6/V9/V10/V13 introduce no authentication, session, authorization,
cryptography, communication, executable-code, or API changes. Top 10 review:
A04/A05/A08/A09 apply to safe defaults, data ownership, concurrent writes,
and visible failures; A01/A02/A03/A06/A07/A10 have no new access-control,
crypto, injection, dependency, authentication, or outbound-request surface.
Required source searches found only existing audit expressions, documentation,
and synthetic test fixtures for prohibited/sensitive patterns; no new raw SQL,
shell execution, dependency, or credential data was added.

Verification: the complete Docker suite passed 258 files / 22,645 tests and
the library report reached 100.0% statement, branch, condition, and subroutine
coverage (45,841 detail rows, no stale uncoverable annotations). Devel::Cover
also printed missing-digest diagnostics for temporary test-generated helpers
that had already been removed; the canonical gate exited 0 and confirmed the
complete library metrics. The focused security/web trio passed 459 assertions;
the release kwalitee, source POD, and release-metadata gates passed 5,783
assertions, including 100% kwalitee. The final 5.67 archive contains no
`cover_db`. The blank Docker environment installed the same 5.67 release code
with `cpanm` and its normal test execution (no `--notest`); the complete
installed-runtime integration runner reported success. The installed Perl
`perlsec` documentation was reviewed after the gate. No new command execution,
dependency, SQL, endpoint, credential, or authentication surface was
introduced.

### Problem 42: Let skill environment values override home defaults (done in 5.68)

Expected: when a skill command runs, matching values from that skill's `.env`
or `.env.pl` override home runtime values from `~/.d2` or
`~/.developer-dashboard`. A deeper project runtime layer continues to override
both. Non-skill commands keep their current runtime-layer behavior.

Root cause: `SkillDispatcher` loaded skill and skill-CLI files, then called
`load_runtime_layers()` over the entire chain. That reapplied home `.env` files
after the skill and replaced the skill's value. The capture's exact outcome
was `(FOO) ...=HOME` and `(BAR) ...=HOME`, despite each skill having its own
different value; without the home file, both skills printed their own value.

Reproduction: in an isolated Docker dev container, create `foo/.env` with
`SKILL_WILL_OVERWRITE_THIS=I am foo`, `bar/.env` with
`SKILL_WILL_OVERWRITE_THIS=I am bar`, and
`~/.developer-dashboard/.env` with
`SKILL_WILL_OVERWRITE_THIS=HOME`. Run `d2 foo.bash -c` with a command that
prints `$SKILL_WILL_OVERWRITE_THIS`, then repeat for `bar.bash`. Before the
fix both print `HOME`; after the fix they print `I am foo` and `I am bar`.
Remove the home `.env` and rerun to verify the skill-specific values remain.
Also seed the same key in a deeper project runtime `.env` and verify that
project value remains the final override.

Red/green evidence: a regression was added to `t/19-skill-system.t` before
implementation. In Docker, it failed with actual `home-runtime` versus
expected `skill`. After the change, the focused skill and EnvLoader tests pass,
including both home runtime directory names, the skill override, and deeper
project precedence.

Verification: the complete Docker suite passed 258 files / 22,656 tests. The
coverage gate passed at 100.0% statement, branch, condition, and subroutine
coverage (45,874 detail rows; no stale uncoverable annotations). The required
web/security trio passed 459 tests. The gate emitted Devel::Cover missing-
digest diagnostics for temporary fixture helpers removed by their tests; some
existing negative-fixture tests also print expected shell/archive diagnostics.
These are visible and are not described as a warning-free run. `dzil build`
produced the sole archive `Developer-Dashboard-5.68.tar.gz`, with no `cover_db`
entry. CPANTS kwalitee passed 7/7 checks at 100%; POD syntax passed 348 source
files / 355 assertions. The blank Perl 5.44 container installed the archive via
`cpanm` without `--notest`, ran the distribution test suite, and completed its
installed-runtime integration script successfully. `d2 docker.images.build`
completed, and an isolated run of the built `d2` image reported version 5.68.

### Problem 43: Keep Docker Compose skill env scoped to the selected service (done in 5.71)

Expected: when two installed skills each contribute a Docker Compose service
and define the same variable in their skill `.env`, `d2 docker compose up
<service>` interpolates using that service's own skill value. Running `foo`
must not cause a later `bar` command to inherit `foo`'s value. An operation
without a selected service continues to use the environment from all effective
base services. Caller-exported values remain higher priority under Problem 44.

Reproduction from `/tmp/capture-1476.txt`: create `foo/.env` with
`SKILL_WILL_OVERWRITE_THIS=I am foo` and `bar/.env` with
`SKILL_WILL_OVERWRITE_THIS=I am bar`; add matching `config/docker/foo/compose.yml`
and `config/docker/bar/compose.yml` services whose `message` uses
`${SKILL_WILL_OVERWRITE_THIS:-UNDEFINED}`. Run `d2 docker compose up foo`,