Enhancement: Promote operational metadata and local capacity diagnostics

[smiggleworth]

Audit classification

• Type: Enhancement
• Affected subsystem: Operational readiness, diagnostics, and recovery
• User/operator impact: The capability may exist only as Experimental or an unverified path, limiting operator confidence and making production support boundaries unclear.
• Current behavior: The relevant implementation or workflow is not yet promoted to the requested support level; existing behavior remains bounded by its documented status and evidence.
• Expected behavior/outcome: Verify the behavior against explicit promotion criteria, document supported and unsupported cases, and promote it only when the acceptance criteria are met.
• Deterministic evidence: Source-of-truth: the issue's linked repository documentation, tests, workflows, and benchmark contracts; baseline commit afb23d0. The existing scope and acceptance criteria below are the deterministic work record.
• Confidence and support status: Medium to high, based on repository documentation and existing contracts.; Experimental or promotion candidate; not a claimed bug.
• Related tracker: Audit: Cassie engine and Admin UI/UX gap backlog at afb23d0 #1

Scope

Promote the local operational metadata and capacity diagnostics surface only within Cassie’s single-node boundary.

Source of truth

docs/experimental-promotion-criteria.md:20-33 and docs/product-roadmap.md:39-44.

Acceptance criteria

• Document stable local metadata and diagnostic fields, freshness, restart behavior, and failure modes.
• Provide operator workflows for capacity, maintenance debt, drain state, and repair visibility.
• Keep routing, movement, capacity admission control, replication, and distributed repair external.
• Add compatibility, metrics/catalog, and deployment-profile evidence before promotion.

Tracking: #1.

[smiggleworth]

Grouped in PR #44 (#44): promotion evidence matrix records existing local tests, missing same-commit or hosted evidence, and explicit unsupported boundaries. The surface remains not promoted until its row's gates are met.

[smiggleworth]

Local-only acceptance update: operational metadata, local capacity categories, maintenance/repair reporting, restart persistence, and Kubernetes-style binary probe tests pass locally. Distributed routing, movement, admission control, replication, and repair remain out of scope.

[smiggleworth]

Full-history re-audit at current main d0874ff: docs/promotion-evidence-matrix.md explicitly marks issue #29 Not promoted and names missing closure evidence. The prior close recorded only a local correctness slice, while the original issue requires promotion evidence and a support/readiness update. Remaining criteria: retained deployment-profile thresholds and recovery, repair, and capacity evidence within the single-node boundary. Dependency: #7 and/or the relevant compatibility or deployment-profile evidence lane. Next action: retain the named evidence, re-run the focused and full validation gates, and update Feature Support only if every common promotion criterion passes.

[smiggleworth]

Current-main re-audit at 8b84ee936986f586567530a2decee949d2b8f14c: local operational metadata, capacity categories, maintenance-debt and repair reporting, restart persistence, health/metrics, and Kubernetes-style binary probes have deterministic coverage. Distributed routing, movement, capacity admission control, replication, and distributed repair remain explicitly outside Cassie's single-node contract.

The promotion gate is not complete. Production Readiness still names missing operational thresholds for disk growth, resource admission, backup/restore, rebuild/repair, failure injection, cancellation latency, and sustained mixed workloads, and representative native-Linux capacity/soak evidence remains pending. Canonical run 32505662069 is incomplete; PR #158 only addresses its current Tier 3 blocker and cannot by itself supply the missing threshold or recovery evidence.

Disposition: keep #29 open and the operational diagnostics surface Experimental. Dependencies: #7 for a complete retained benchmark artifact plus explicit deployment-profile threshold and recovery/repair evidence. Next action is evidence collection and contract publication, not a runtime feature expansion or a distributed-system claim.