Repository navigation
Open
Labels
enhancementNew feature or product improvementNew feature or product improvementsecuritySecurity hardening or vulnerability workSecurity hardening or vulnerability work
Milestone
Description
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
- portable CLI specification artifact
- language-neutral conformance runner
- [v1.1] Add provider-neutral ecosystem integrations #250
- [v1.0] Expand maintainer capacity and document project governance #252
Project Fields
- Status: Backlog
- Priority: P2
- Area: Product
- Initiative: Adoption Polish
- Size: L
Ownership
- Assignee: @codeforester
Metadata
Metadata
Assignees
Labels
enhancementNew feature or product improvementNew feature or product improvementsecuritySecurity hardening or vulnerability workSecurity hardening or vulnerability work
Type
Projects
- StatusShow more project fieldsBacklog
Activity
codeforester commentedon Oct 22, 2026
Scope decision for the narrow v1.0.0 release: this work is intentionally deferred to the v1.1.0 platform/extension follow-up. The v1.0 train is limited to the stable Python core, lifecycle/JSON contracts, security, starter experience, governance, and release integrity. Revisit this issue after the v1.0.0 release evidence is complete.