Skip to content

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

@svelderrainruiz

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
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions