Understand the first scan

Project creation starts a group of independent repository checks. Treat the first scan as the beginning of a maintained health baseline, not as a single operation that either makes the whole project green or fails as one unit.

What Guard starts

For every selected repository, Guard loads the current published audit catalog and attempts each published audit that has an executable runbook. The batch can include base diagnostics and several score-bearing audits.

Each repository and audit becomes its own task. One task may finish while another remains queued or fails. When the setup contains several tasks, Guard groups their notification bookkeeping so it can send one completion email for the batch rather than one message for every check.

The dashboard remains the source of truth. An email confirms completion; it does not replace the report, checked revision, or visible error state.

Base diagnostics orients later work

Base diagnostics runs the recon workflow. It identifies the repository target, current commit, stack, important structure, documentation and test baseline, automation signals, and representative risks. It produces a compact summary and a readable report that later work can use as context.

Recon is not a score-bearing health area. A successful recon does not mean the repository is healthy, and a high audit score should not be inferred from a clean-looking structure map. Its job is to establish what the repository is and where deeper audits should look.

Read Base diagnostics and recon for its exact boundary.

Read run states

Initial checks move through explicit states:

• Starting or queued — Guard accepted the request but work has not produced current evidence.
• Running or fetching — the task is active or Guard is retrieving its result.
• Done — the run completed and may provide a summary, report, or both.
• Error — the task stopped before it could prepare a valid current result.

Do not interpret a loading skeleton, an old snapshot, or a missing report as a successful current scan. Open the relevant card or activity entry to see whether the displayed result belongs to the task that just ran.

When results are ready

A useful completed result identifies the repository and audited revision, then explains evidence, findings, and limitations. Recon must inspect the exact repository before it publishes its summary. If repository context is missing or access fails, the workflow records a diagnostic and fails instead of unlocking deeper work with invented context.

Score-bearing audits may finish without the same evidence coverage. Read each report’s limitations before comparing numbers. An unavailable tool or unsupported surface should remain unknown; it must not become an automatic pass.

If a task remains active unusually long, use A run is stuck or failed. If the repository cannot be opened, use Repository is unavailable.

What to do next

Read base diagnostics first, then open the audit areas with the clearest red or yellow signals. Confirm the checked revision and evidence before starting an improvement. The goal is to choose a bounded next action and later rerun the affected audit—not to chase every visible number at once.