Issue Backlog

This document indexes the GitHub issues and merged proof surfaces that must not be lost in the planning docs. GitHub remains the execution tracker; this file keeps reviewers aligned with the written plan.

For current priority and workstream shape, start with Roadmap. This file is the issue mirror that supports that roadmap.

Last synced with planning docs: 2026-06-23.

Rule

P0 issues are gates for the scope they name.
P1 issues strengthen the proof after P0.
P2 issues preserve important design depth without blocking the first proof.

Issue closure should be outcome-based:

Name the chart choices, variants, or lanes covered.
Commit the receipt, matrix row, generated report, or verified doc that proves
the outcome.
Add or update the verifier that fails if the evidence becomes stale.
Do not close an issue because a command, tutorial, or proposal merely exists.

The catalog-wide target is that every supported Helm chart default and declared main choice becomes reproducible, ConfigHub-reviewable, live-cluster verified, and tied to receipts. If a lane is still missing, track it as missing backlog instead of converting the issue into a broad "verified" claim.

The original P0 proof gates are now closed and verified by the harness. Issue #76 is closed as the import-path definition and proof-contract issue:

New to cub? Install the cub CLI first. You can pull and render public catalog packages without an account. Commands that save or change ConfigHub data require you to sign in.

#76 Define Helm import path from cub helm template / cub helm install to cub installer recipes.

The downstream product command is still future work, but it should be tracked as implementation work rather than keeping the definition issue open. The current command story is:

The public proof remains valid without that future bridge because the repo currently builds and verifies the same artifact chain through generators and proof scripts.

Do not maintain issue counts by hand here. Use GitHub labels for counts, and use this file only for the issue groups that affect doctrine, roadmap, or product claims.

Current Canonical Trackers Added Or Confirmed 2026-06-16

Current Canonical Trackers Added Or Confirmed 2026-06-23

Current Canonical Trackers Added Or Confirmed 2026-06-24

Current Operational Issue Groups

Capability Roadmap

The active roadmap now separates existing cub / ConfigHub capabilities from missing product verbs. These lanes should become GitHub issues when they move from roadmap shape to implementation work.

Existing ConfigHub capabilities to use now:

Missing product verbs:

Configuration-As-Data And Derived-Variant Issues Added 2026-06-04

Configuration-as-data work is now represented as helm-expt execution work, with derived ConfigHub variants pulled forward instead of treated as an appendix.

Completed Redis Proof Gates

These P0s are complete for the Redis proof slice and should stay closed unless the evidence regresses:

Current Harness Proof Slice

The scale-out harness now exists across:

recipes/
packages/
runs/
data/adversarial10/
data/top500-catalog-analysis/
data/production-disposition/

It closes the original proof gates #24, #25, and #4:

• 100 proof-grade recipe/package artifacts;
• 20 top-chart catalog entries with bespoke variants;
• 20/20 local kind live/e2e receipts;
• 20/20 ConfigHub proof receipt sets;
• 20 catalog-supported Helm pain reports;
• 80 generated full default proofs;
• adversarial10 and next80 tamper-detection self-tests;
• top-500 catalog analysis outputs;
• production disposition and legacy patch review outputs;
• verifier and negative golden checks through npm run verify.

The next harness step is not "prove that anything exists." It is to make how the harness works easier to explain and productize. The compact explanation lives in How The Harness Works.

Hook / Lifecycle Risk Lane

The top-500 source scan found 54 hook-using charts among 495 scanned charts. A first-pass risk estimate classifies 42 as likely problematic, 6 as needs-review, and 6 as probably benign/test-only. This should remain visible in planning because hook execution is cluster-dependent and cannot be hidden inside normal render equivalence.

Current planning home:

docs/user/hook-lifecycle-strategy.md

Current implementation evidence:

data/hook-lifecycle/summary.md
data/lifecycle-observations/cert-manager-eso/summary.md
npm run hooks:lifecycle:verify
npm run lifecycle:cert-manager-eso:verify

The hook queue is still inventory and required-receipt planning. The cert-manager / External Secrets lane proves a lifecycle-observation pattern for CRD ownership, webhook readiness, controller-populated data, and server dry-run checks. It does not prove all hook-using charts.

Execution work still needed:

Add hook risk buckets and lifecycle dispositions to top-500 catalog analysis.
Add hook/lifecycle receipt expectations for catalog-supported hook charts.
Add safe Argo/GitOps lifecycle translation proof for at least one hook-heavy chart.

Do not make this a P0 gate for all public-catalog work. Make it a production support gate for hook-using charts.

Current Promoted Chart Proofs

Rows promoted from readiness evidence into full proof slices:

Execution Order

The review made the first implementation slice explicit:

1. #24 Schema and verifier first. Without this, artifacts and spreadsheets are decorative.
2. Redis complete proof. Redis now has the first complete proof slice. Keep it green while the next issues scale the pattern.
3. Five-minute UX proof. The first demo script exists under docs/demo/redis/. Keep refining the UX without inventing non-existent commands.
4. Close the missing determinism/freshness gates: #29, #28, #30, and #27.
5. #25 Top-N adversarial harness. The next milestone is 20 full public-chart proofs, not just a readiness spreadsheet. Only scale after the artifact chain and UX proof work. Use known-adversarial-charts.md to choose public charts that exercise CRDs, hooks, generated facts, capabilities, tpl, raw manifests, RBAC/webhooks/APIService, and stateful behavior.

Closed P0 Proof Gates

These issues are closed. Keep them listed because they define what the current proof corpus must continue to satisfy.

P1 Strong Next Proof

P2 Design Depth

Planning Sync Checklist

When a GitHub issue is added, closed, or reclassified:

• update this file
• update docs/planning/current-handover.md or the relevant archived snapshot if it changes P0 gates
• update docs/planning/agreed-execution-plan.md if it changes doctrine or acceptance
• update docs/planning/independent-review-brief.md if it changes review scope

Do not let the written plan describe a proof path that ignores open P0 gates. When future P0s are about productization rather than current proof validity, say that explicitly rather than letting reviewers infer the proof corpus is broken.