/ 
Developer-Dashboard-2.17
/ Developer::Dashboard::Collector

NAME

Developer::Dashboard::Collector - file-backed collector storage

SYNOPSIS

my $collector = Developer::Dashboard::Collector->new(paths => $paths);
$collector->write_job('sample', { name => 'sample', command => 'true' });

DESCRIPTION

This module owns the on-disk storage model for collector job definitions, status records, and latest outputs.

METHODS

new, collector_paths, write_job, read_job, write_result, write_status, read_status, read_output, inspect_collector, list_collectors

Construct and manage collector storage.

PURPOSE

This module is the file-backed persistence layer for collectors. It knows where each collector stores its job definition, stdout, stderr, combined output, last-run marker, and status JSON across the layered runtime roots, and it updates those files atomically.

WHY IT EXISTS

It exists because collectors are stateful background work. Their output and status files need one owner that handles layered lookup, atomic writes, and stable file layout instead of scattering those rules across the runner, prompt renderer, and inspection commands.

WHEN TO USE

Use this file when changing collector on-disk layout, status JSON fields, output artifact names, or the read/merge/write behavior for collector state.

HOW TO USE

Construct it with the active path registry, then use write_job, write_result, write_status, read_status, read_output, and list_collectors. Keep collector storage rules here and let the runner focus on process execution.

WHAT USES IT

It is used by Developer::Dashboard::CollectorRunner, by collector inspection/list commands, by prompt and status views that read collector state, and by collector persistence tests.

EXAMPLES

Example 1:

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

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

Example 2:

prove -lv t/02-indicator-collector.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.