Skip to content

Add third-party asset provenance to release preflight #168

Description

@BaseInfinity

Problem

Release proof can establish behavior while still missing whether bundled non-code assets are distributable. VisualHUD v1.2 spent roughly ten hours completing RED/GREEN work, frozen proof, independent review, package inspection, CI, and a supervised real-terminal canary before the final publication audit found 55 bundled Pokémon/TMNT PNGs without documented redistribution permission. The exact artifact then had to be quarantined.

This is reusable release-engineering evidence: asset provenance is cheaper and clearer as a definition-of-ready check than as the last publication gate.

Goal

Teach an early, evidence-based third-party asset inventory for release-oriented repositories so expensive proof and canary work starts only after distributable inputs are identified or explicitly excluded.

Scope

  • For release/publish slices, inventory packaged non-code assets before broad proof or live acceptance.
  • Record source/author, governing license or written permission, package inclusion, and intended distribution channel where third-party assets exist.
  • Treat missing evidence as an explicit release gate; do not make a legal determination or pretend attribution alone grants permission.
  • Permit a documented exclusion/replacement path that preserves generic code and product behavior.
  • Recheck the exact final package inventory because source-tree intent is not proof of artifact contents.
  • Keep the guidance adaptable for repositories with no third-party assets or no distribution step.

Acceptance criteria

  • Generated release guidance places asset/provenance inventory before expensive broad proof and supervised canaries.
  • A fixture with uncleared packaged assets surfaces a clear preflight gate and safe exclusion path.
  • A fixture with first-party or documented licensed assets proceeds without false blocking.
  • Exact-package inspection detects assets added or omitted after the initial inventory.
  • Guidance is explicitly release engineering, not legal advice.
  • The normal proof and review gates pass.

Evidence

Related: #100 for release lifecycle ordering and #112 for consumer-pilot evidence.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions