Define successful repository scope evidence for Analysis ingestion

[fproulx-boostsecurity]

Question

What engine-neutral Analysis result contract should distinguish repositories whose workflow Analysis succeeded from repositories whose deep secret detection completed, failed, or was skipped, so reconciliation can replace evidence only for explicitly successful scopes?

Resolve the field shape and invariants for repository, organization, and partial Analysis; treatment of non-fatal per-repository errors; deep Analysis with partial secret-detection completion; and compatibility behavior for results that lack the new scope evidence.

[fproulx-boostsecurity]

Resolution

Canonical Analysis results carry explicit terminal outcomes for every repository discovered or explicitly targeted by the run:

type RepositoryAnalysisOutcome struct {
    Repository       string
    WorkflowAnalysis AnalysisPhaseOutcome
    SecretDetection  AnalysisPhaseOutcome
}

type AnalysisPhaseOutcome struct {
    Status     CompletionStatus
    Diagnostic string
}

The terminal statuses are succeeded, failed, skipped, and not_requested:

• succeeded means the phase produced a complete authoritative result, including a valid empty result.
• failed means the phase was attempted but did not produce a complete result.
• skipped means the phase was requested but intentionally not attempted for that repository.
• not_requested means the phase was disabled for the run.
• There is no partial phase status. Partial organization Analysis is represented by different terminal outcomes across repositories.

Only an explicit succeeded phase grants replacement authority. Workflow Analysis and secret detection grant authority independently. A valid workflow result may reconcile while failed secret detection preserves existing secret evidence, and vice versa.

Each phase executor records its own outcomes. Poutine records workflow Analysis outcomes, and the Kitchen secret-detection runner records secret-detection outcomes. Ingestion validates and consumes outcomes but never infers authority from findings, counts, top-level success, or error strings.

Every discovered or explicitly targeted repository must have a terminal outcome. Absence means outside or unknown scope. Empty or invalid repository identities, unknown or non-terminal statuses, and conflicting duplicate outcomes fail reconciliation closed. Exact duplicate outcomes may be collapsed. The Analysis result remains valid when this validation causes reconciliation to fail.

RepositoryOutcomes becomes the sole canonical representation. One normalization seam accepts legacy results by translating AnalyzedRepos entries to workflow succeeded outcomes while treating secret-detection completion as unknown and non-authoritative. Other repositories retain existing evidence, and an empty legacy SecretFindings list never grants replacement authority. New producers populate canonical outcomes, all consumers use normalized outcomes, and direct AnalyzedRepos usage is removed.

Phase-local sanitized diagnostics explain failed or skipped outcomes but never determine authority. Top-level errors are reserved for run-level diagnostics.

ReposAnalyzed is derived from the count of workflow succeeded outcomes and is not an independent source of truth. The mutable top-level Success flag is removed after callers migrate; the run summary is derived from repository outcomes and run-level errors.

A trustworthy terminal result may contain no successful repositories. Kitchen returns that result, performs no destructive reconciliation, preserves Pantry, and Counter presents completion with errors. Request-level failure is reserved for cases where no trustworthy terminal result can be produced.

[fproulx-boostsecurity]

Superseding correction from the ownership decision

Define the Analysis reconciliation ownership matrix refined this contract in two material ways:

• The modernization uses a clean Kitchen schema 3.0 cutover. Remove the legacy AnalyzedRepos normalization fallback and all other legacy Pantry compatibility handling. Existing 2.x data requires purge.
• Add explicit entity-existence evidence. Each repository outcome carries Existence, and the requested Repository or Organization carries TargetExistence, with confirmed_present, confirmed_gone, or unknown. Confirmed absence authorizes current Pantry cleanup; omission, permission failure, and ambiguous not-found responses do not.

These corrections supersede the legacy compatibility paragraph in the original resolution. The remaining per-phase terminal-outcome and independent-authority decisions still apply.