Goal
Define how an organization discovers and governs trusted CLI specifications and conformance evidence without turning base-cli into a source-code crawler or control plane.
Background
A comprehensive CLI platform eventually needs discoverability, ownership, support status, compliance evidence, freshness, and deprecation views across languages. That system has a different lifecycle and trust boundary from the Python runtime library.
The Catalog should consume artifacts produced and attested by CI. It should not clone arbitrary repositories, import packages, or execute CLIs to infer truth.
Scope
- Decide the Catalog's owning repository/service and keep the base-cli adapter boundary narrow.
- Define provider-neutral ingestion for signed CLI specs and conformance reports.
- Define identity, digest, issuer, source revision, freshness, history, revocation, and trust-state models.
- Define ownership overrides, exception approvals, expiry, audit trails, and conflict resolution.
- Define read APIs and human views for platform/SRE/development consumers.
- Threat-model malicious artifacts, stale evidence, replay, confused-deputy, and cross-tenant cases.
Acceptance Criteria
- An architecture decision separates runtime, contract/conformance, and Catalog ownership.
- The Catalog never executes discovered source or binaries during ingestion.
- Every accepted record is tied to an immutable digest, source revision, issuer, contract version, and verification result.
- Trust states distinguish self-declared, CI-validated, attested, expired, revoked, and policy-exempt evidence.
- Overrides require owner, reason, expiry, approver, and an append-only audit record.
- GitHub is supported through an adapter, not embedded as the universal data model.
- Retention, deletion, privacy, availability, and incident-response policies are documented.
- A minimal offline/read-only prototype proves ingestion and query semantics before service expansion.
Validation
Threat-model review, signed/tampered/replayed/stale fixture tests, provider-adapter tests, and audit-log verification.
Non-Goals
- Do not build a full developer portal in the first increment.
- Do not add a Go/Rust/Node runtime merely to populate the Catalog.
- Do not make base-cli responsible for organization-wide authorization.
Dependencies
Project Fields
- Status: Backlog
- Priority: P2
- Area: Product
- Initiative: Adoption Polish
- Size: L
Ownership
Goal
Define how an organization discovers and governs trusted CLI specifications and conformance evidence without turning base-cli into a source-code crawler or control plane.
Background
A comprehensive CLI platform eventually needs discoverability, ownership, support status, compliance evidence, freshness, and deprecation views across languages. That system has a different lifecycle and trust boundary from the Python runtime library.
The Catalog should consume artifacts produced and attested by CI. It should not clone arbitrary repositories, import packages, or execute CLIs to infer truth.
Scope
Acceptance Criteria
Validation
Threat-model review, signed/tampered/replayed/stale fixture tests, provider-adapter tests, and audit-log verification.
Non-Goals
Dependencies
Project Fields
Ownership