Decide Shipyard Ledger’s metrics contract and delivery boundary

[dymoo]

Question

For a repository using Shipyard, what is the smallest trustworthy first version of a static Shipyard Ledger: a tracker page that reports Cloud Coder and Cloud Reviewer outcomes, merged PRs, token usage and cost?

Resolve the decision, not the implementation:

• What structured event contract must Cloud Coder, Cloud Reviewer and GitHub merge events emit before any dashboard exists?
• Which outcome definitions and denominators make success rate and accepted PRs meaningful?
• Should the repository publish to a dedicated shipyard branch, gh-pages, or defer publication until the product needs it?
• What aggregate data may be public, what must remain private, and how are prompts, source content and credentials excluded?
• What retention, idempotency and concurrent-write rules keep the ledger accurate?
• Is the first dashboard in this map destination, or a follow-on after the core coder/reviewer pilot?

Constraint

Shipyard is driven by the user’s local Codex or Claude Code session using Matt Pocock’s skills. The ledger must observe that workflow; it must not become a third orchestration product or make merge decisions.