Summary

Attestation-level policies currently evaluate at both status and push phases unconditionally. This adds a mechanism for policy authors to control at which attestation phase(s) their policy runs via a new attestation_phases field on PolicySpecV2 (the per-kind policy definition).

Default behavior is preserved (all phases) for backwards compatibility — when no phases are specified, the policy runs at all phases as it does today.

Motivation

Some policies only make sense at specific points in the attestation lifecycle:

• A final approval check should only run at push time, not during status
• A quick lint/feedback policy might only need to run at status time for early feedback

Currently there is no way to express this — all attestation policies always run at both phases.

Proposed Changes

• Add an AttestationPhase enum (INIT, STATUS, PUSH) to the crafting schema proto
• Add repeated AttestationPhase attestation_phases field to PolicySpecV2 (alongside kind and source)
• Filter policies during evaluation based on the current phase
• Pass the current phase from the status and push CLI actions through to the policy verifiers

Example

apiVersion: workflowcontract.chainloop.dev/v1
kind: Policy
metadata:
  name: final-approval-check
spec:
  policies:
    - kind: ATTESTATION
      path: approval-check.rego
      attestation_phases:
        - PUSH

This policy would only be evaluated during attestation push, not during attestation status.