/ 
Developer-Dashboard-2.17
/ Developer::Dashboard::InternalCLI

NAME

Developer::Dashboard::InternalCLI - private runtime helper executable management

SYNOPSIS

use Developer::Dashboard::InternalCLI;

my $paths = Developer::Dashboard::PathRegistry->new(home => $ENV{HOME});
Developer::Dashboard::InternalCLI::ensure_helpers(paths => $paths);

DESCRIPTION

This module manages the built-in private helper executables that Developer Dashboard stages under ~/.developer-dashboard/cli/dd/ instead of exposing as global system commands.

FUNCTIONS

helper_names, helper_aliases, canonical_helper_name, helper_content, helper_path, ensure_helpers

Build and seed the built-in private helper command files.

PURPOSE

This module owns the dashboard-managed private helper assets. It decides which built-in command names exist, stages the corresponding helper files under ~/.developer-dashboard/cli/dd/, and resolves the helper paths that the public dashboard entrypoint should exec into.

WHY IT EXISTS

It exists because built-in helper staging is a product contract of its own. The switchboard must know which helpers are dashboard-managed and how to refresh them without mixing that policy into every command or shell bootstrap path.

WHEN TO USE

Use this file when adding, renaming, or removing built-in helper commands, when changing the private helper namespace, or when fixing helper staging drift between shipped assets and the home runtime copy.

HOW TO USE

Call ensure_helpers with the active paths object to stage or refresh managed helpers, use canonical_helper_name to normalize helper aliases, and use helper_path when the switchboard needs the final staged executable path.

WHAT USES IT

It is used by bin/dashboard, by init/update flows that stage built-ins, by shell bootstrap generation, and by tests that verify helper extraction and private-helper packaging.

EXAMPLES

Example 1:

perl -Ilib -MDeveloper::Dashboard::InternalCLI -e 1

Do a direct compile-and-load check against the module from a source checkout.

Example 2:

prove -lv t/07-core-units.t t/21-refactor-coverage.t

Run the focused regression tests that most directly exercise this module's behavior.

Example 3:

HARNESS_PERL_SWITCHES=-MDevel::Cover prove -lr t

Recheck the module under the repository coverage gate rather than relying on a load-only probe.

Example 4:

prove -lr t

Put any module-level change back through the entire repository suite before release.