Skip to content

[platform] Define signed CLI Catalog ingestion and governance boundaries #277

Open

Description

@codeforester

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

Activity

  1. added this to the v1.0.0 milestone on Aug 30, 2026
  2. self-assigned this
    on Aug 30, 2026
  3. added
    enhancementNew feature or product improvement
    securitySecurity hardening or vulnerability work
    on Aug 30, 2026
  4. modified the milestones: v0.5.0, v1.0.0 on Sep 26, 2026
  5. modified the milestones: v1.0.0, v1.1.0 on Oct 22, 2026
  6. codeforester commented on Oct 22, 2026

    @codeforester
    ContributorAuthor

    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.

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

Metadata

Metadata

Assignees

Labels

enhancementNew feature or product improvementsecuritySecurity hardening or vulnerability work

Type

No type

Projects

  • Status
    Backlog

Relationships

None yet

Development

No branches or pull requests

Issue actions