/ 
Developer-Dashboard-2.17
/ Developer::Dashboard::IndicatorStore

NAME

Developer::Dashboard::IndicatorStore - file-backed indicator state for Developer Dashboard

SYNOPSIS

my $store = Developer::Dashboard::IndicatorStore->new(paths => $paths);
$store->set_indicator('docker', status => 'ok');

DESCRIPTION

This module stores small status indicators that are consumed by prompt rendering and dashboard views. It also provides a small built-in refresh path for core generic indicators.

METHODS

new, set_indicator, get_indicator, list_indicators

Construct and manage the indicator store.

mark_stale, is_stale, refresh_core_indicators, page_header_items, page_header_payload

Handle stale state and refresh built-in generic indicators.

PURPOSE

This module persists prompt and browser status indicators. It stores indicator definitions and live status updates, merges collector-managed indicators with user-managed ones, and provides the ordered indicator data used by the prompt renderer and the browser status strip.

WHY IT EXISTS

It exists because indicators are shared state that multiple features read and write. Prompt rendering, collector status, and browser chrome all need one source of truth for icon, label, priority, prompt visibility, and current status.

WHEN TO USE

Use this file when changing indicator JSON layout, sorting rules, collector-managed indicator behavior, or the persistence semantics of prompt-visible versus hidden indicators.

HOW TO USE

Construct it with the active runtime paths, then call the store and list methods rather than editing indicator state files directly. Collector code should report into this store instead of inventing its own indicator persistence.

WHAT USES IT

It is used by the indicator command helper, by collector refresh paths, by the prompt renderer, by the browser status page, and by regression tests that verify indicator ownership and ordering.

EXAMPLES

Example 1:

perl -Ilib -MDeveloper::Dashboard::IndicatorStore -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.