Problem

The Run type currently has two fields: status and log (a URL pointing to where run information is logged). There's no way to associate build artifacts with a completed run.

A natural use case is referencing build outputs — binaries, container images, signed checksums, etc. — from a job run. I initially considered encoding a hash or CID into the log URL field, but that breaks its semantics: log is meant to point to where information is logged by the node, not to reference produced artifacts.

Proposal

Add an optional artifact field to Run that can store a content-addressed reference (hash, multihash, or CID) to a build artifact.

pub struct Run {
    status: Status,
    log: Url,
    /// Optional content-addressed reference to a build artifact.
    artifact: Option<String>, // or a dedicated type for CID/multihash
}

Being optional keeps this backwards-compatible with existing job-cob data.

Open questions

1. Is there wider interest in an artifact field on Run? Are there other use cases beyond what's described here?
2. Should the field be a single value or a collection? A run might produce multiple artifacts (e.g. binaries for different architectures, plus checksums).
3. What type should it be? A plain String, a Url, or a dedicated content-addressed type (e.g. CID)? A CID would be self-describing (includes codec + hash algorithm) and could be serialised as a Url.
4. Prior art on evolving COBs? What's the expected approach for schema evolution — strictly optional/additive fields? Is there an existing pattern to follow?