/ 
Developer-Dashboard-2.17
/ Developer::Dashboard::Doctor

NAME

Developer::Dashboard::Doctor - runtime permission doctor for Developer Dashboard

SYNOPSIS

my $doctor = Developer::Dashboard::Doctor->new(paths => $paths);
my $report = $doctor->run(fix => 1);

DESCRIPTION

This module audits the current home runtime and any older dashboard roots that still exist in the user's home directory, checking that directories are owner-only and that files are readable only by the owner unless they are meant to stay owner-executable.

METHODS

new, run

Construct the doctor service and audit the known dashboard roots.

PURPOSE

This module audits and optionally repairs runtime permissions. It checks the home runtime and older dashboard roots for owner-only directory and file modes, applies the expected 0700/0600 policy where needed, and returns a structured report that the CLI can print or act on.

WHY IT EXISTS

It exists because runtime security should be inspectable and fixable from inside the product instead of depending on a manual shell checklist. That gives users and tests one trusted place to check whether the dashboard runtime is private enough.

WHEN TO USE

Use this file when changing the runtime permission policy, the report format for dashboard doctor, or the set of files and directories that should be audited and repaired.

HOW TO USE

Construct it with the active path registry, call run(fix => 0) to audit or run(fix => 1) to repair, and let the CLI wrapper render the resulting report. Site-specific doctor hooks should remain in the command hook layer, not inside this module.

WHAT USES IT

It is used by the dashboard doctor helper, by security and integration tests, and by contributors verifying that init/update paths do not leave insecure runtime permissions behind.

EXAMPLES

Example 1:

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

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

Example 2:

prove -lv t/00-load.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.