Skip to content

[governance]: codify comparevi capabilities manifest as a checked-in schema contract #46

Description

@svelderrainruiz

Summary

The template now distributes .github/comparevi/capabilities.json as a real descendant-facing contract, but it is still validated only by ad-hoc field assertions in tests/Test-TemplateSmokeRender.ps1. The next bounded slice is to formalize that manifest as a checked-in schema contract and validate hosted/docker/mixed renders against it.

Scope

  • Add a checked-in schema for labview-template/comparevi-capabilities@v1 in the canonical template repo.
  • Cover the always-present viHistory manifest contract and the optional dockerProfile manifest contract for docker and mixed renders.
  • Point generated consumer docs at the canonical schema source for .github/comparevi/capabilities.json.
  • Make tests/Test-TemplateSmokeRender.ps1 validate hosted, docker, and mixed capability manifests against the checked-in schema instead of relying only on ad-hoc assertions.
  • Keep this slice contract-and-proof only; no producer/runtime behavior changes.

Acceptance

  • The canonical template repo owns a checked-in capability-manifest schema.
  • Hosted renders validate against that schema with no dockerProfile entry.
  • Docker and mixed renders validate the emitted dockerProfile contract through the schema.
  • Generated docs reference the canonical schema location for .github/comparevi/capabilities.json.
  • No new runtime or release-publication behavior is introduced.

Why this is next

  • #42 formalized the Docker receipt.
  • #44 formalized the Docker lane policy.
  • The remaining obvious unchecked contract in the distributed proving surface is the capability manifest itself.
  • This fits the larger #1497 release-grade downstream consumer proving direction by making the distributed consumer contract more machine-verifiable.

Parent umbrella:

Metadata

Metadata

Assignees

No one assigned

    Labels

    ciCI/CD, workflows, and pipeline changesenhancementNew feature or requestgovernancePolicy, approvals, and operating modelstanding-priorityCurrent top objective for automation agentstoolingTooling, automation, and developer workflow changes

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions