Unified Catalog and Workshop execution plan

Status: active, reconciled 2026-09-11. This is the single execution plan for the Catalog backend and the Compose, Adapt and Match user journeys. It combines the 42 tasks from the original backend checklist with the eight Workshop acceptance blocks. The original checklist is a historical record; update this plan for current work. This plan does not change data verdicts.

Execution order and ownership

The goal is a trustworthy configuration catalog that a person or assistant can use easily: select, inspect, change, retain, deliver and observe exact configurations. Backend integrity and useful successor configurations are prerequisites for that experience, not a separate backlog to forget when a demo is being built.

Work packages below join related tasks without discarding their acceptance criteria. B01–B42 retain their original identities. W1–W8 refer to the Workshop blocks in the acceptance table below. A package is complete only when every applicable backend task and journey criterion is accepted. Open PRs are implemented, not landed; unavailable target facts remain unknown. Do not derive progress from PR count or elapsed calendar days.

Priority is the default selection order, not a dependency forcing idle time. When one task needs access or review, pick the next ready task in U1–U6. Work on independent branches from main. Website implementation is authorized for these journeys; generated files still change only through their generators.

Current execution batch

1. Reconcile all B-task statuses against data, receipts and landed changes. Preserve historical evidence and identify partial tasks rather than redoing their completed portions. The ledger below replaces the stale seven-day completion count.
2. B38's bounded diagnostics landed in #1857 and #1859. Their failure conditions and the known-red register are unchanged; fresh live Kubara receipts remain separately blocked by target access.
3. Take the first remaining independently runnable source/successor task identified by the audit. The existing draft PR owns its scope; update it where practical.
4. Cub-workshop #10–#17 are merged and the direct Compose/Match check is retained. Preserve the historical assistant trials at their tested source revisions; repeating the expanded selection with both assistants remains separate.
5. #1876 completes the local Compose, Adapt and Match Guides and direct demonstrations. Fresh assistant interface trials and a human continuation trial remain separate acceptance. Live access and a human participant do not block U1–U3.

The lead owns planning, prioritization, source/claim review and integration. Use lower-cost agents for bounded evidence inventories, command/test execution and small well-specified fixes. Each writer has a separate worktree; no agent runs a live lane or edits shared generated output concurrently. The lead checks every agent's evidence and diff before publishing. Run the appropriate narrow gates, then the full repository gate once per reviewed change; avoid duplicate full runs for unchanged source. Each PR records actual results and person dependencies.

Backend task ledger, 2026-09-11

Accepted means the original bounded deliverable has landed with supporting records; it does not imply production support or current live health. Partial means some acceptance remains. Active means work is currently assigned; blocked names an external prerequisite. The thirteen previously accepted tasks remain accepted; B10, B12, B34 and B40 now also have their bounded audit and integrated-main verification evidence recorded (17 accepted tasks). Broader journey acceptance remains separate. The current work packages above determine what runs next, not the old day grouping.

Source-consumer audit: B10 execution result

On 2026-09-10, traced both committed source-fetch receipts through the refresh queue and live rerun generator. No demonstrated scheduling defect was found in this scope. Historical HTTP failure and successful anonymous OCI byte retrieval remain separate observations; neither proves future availability or whether credentials would repair a failed URL.

Focused offline checks passed: source-fetch verification for four pins, refresh source verification for seven candidates (including fifteen negative cases), action-queue verification for seven update rows, and rerun-plan verification for 108 rows. Commands: node scripts/audit-bitnami-source-fetch.mjs --verify, node scripts/audit-refresh-candidate-sources.mjs --verify, node scripts/generate-latest-refresh-action-queue.mjs --verify, and node scripts/generate-live-parity-rerun-plan.mjs --verify. These inspect retained observations; no new fetch or live lane ran. This result completes the bounded consumer audit, independently reviewed on 2026-09-11. B09 classification work and the separate B12 retirement reconciliation below retain their own scope.

Six-pin retirement reconciliation: B12 execution result

Reviewed on 2026-09-11 against the retained replacement decisions. B12 asks for an actual retirement decision or its precise remaining prerequisites; this records the latter. Closed #1381 supplies no blanket retirement authority. The historical four-pin source receipt and the subsequently merged six-pin follow-up #1877 establish different dated observations, not current runtime or image support.

No pin, replacement verdict or support record changes in this reconciliation.

Outcome

A person or their assistant brings configuration, an app, or platform requirements and leaves with a useful, retained result. The direct command-line route must be clear enough to use without AI. Claude Code and Codex use the same operations, checks, and evidence, with fewer decisions for the user. Each website page explains one task completely and leads to a working next step.

Deliver three journeys, in this order:

1. Compose: a bounded Kubara platform plus one app, checked against explicit requirements and a named target, then delivered when prerequisites are available.
2. Adapt: change an existing configuration, inspect the semantic difference, preserve local intent across an upstream change, and hand the result to a teammate.
3. Match: choose a workload configuration for specified NVIDIA hardware and constraints, separating static compatibility from observed GPU execution.

The first journey includes one small adaptation, so the first demo shows both composition and a meaningful change. Configs, charts, apps, and stacks remain first-class inputs; the first fixture does not define the product's format ceiling.

First slice: a Kubara platform and one app

User task: “Give me a small platform with GitOps and a web app; tell me what I need to supply, show me what will run, and help me change it.” Start with the existing Kubara platform manifest and the plugin’s existing shop-app scenarios. Keep the plain YAML app fixture as an alternative for the Adapt journey. Record the precise source revisions and effective component inventory before selecting supported options. Do not promise arbitrary platform synthesis from this bounded example.

The result must contain the selected components, exact materialized object identity, source provenance, explicit app requirements, target assumptions, findings, omitted checks, and a next action. Platform and app remain separately identifiable. A configuration result is useful before deployment; a claim that the app runs requires a fresh controller observation and an application response on the named target.

The initial variation changes one app field. Include one deliberately incompatible requirement and show the same actionable refusal in the CLI and both assistants. A missing capability must name what is missing and a supported repair, rather than returning a generic failure or guessing a different platform.

Reuse before building

Before publishing runnable instructions, capture the installed CLI and plugin versions and verify every command through help and execution. Stack and app prototype implementation work may belong in cub-workshop or the CLI repository; record the owner and linked change rather than introducing a shadow CLI here.

Workshop acceptance blocks (W1–W8)

Blocks 3 and 4 can start with the current command surface while missing checks are implemented. Website copy follows verified behavior, and can ship a useful local result before the live block. Each block may split into small independently based PRs; do not stack branches on unmerged work or wait for all journeys to be finished.

Current integration batch: cub-workshop #10–#17 are merged after fresh CI. The direct integration observation records source 4fd3f01a7a67238013cd3d613c1efe04c3339819 with cub v0.4.4: isolated installation, the 184-object GitOps selection, move/resume with a minimal runtime, replica-only edit, incompatible API refusal, and Match candidate/mismatch/unknown results. It is an agent-operated direct CLI check, not a new independent assistant or human trial.

Guide and demonstration checkpoint, 2026-09-11

Merged #1876 adds the complete Compose, Adapt and Match local Guides, with direct commands, assistant tasks, failure cases and recovery. Existing site hubs link them without changing navigation. The direct trial receipt and its artifact verifier retain the 184-object Compose edit/refusal, literal-move Adapt review and three Match decisions. Trial paths were adapted; these are agent-operated commands, not a fresh assistant-interface or independent human trial.

Cub-workshop #20 adds a read-only Match artifact acceptance checker and rejection tests. It pins the teaching inputs, checks the permitted edits, requires recorded command exits 0/1/3, and recomputes complete results. A copied complete trial can pass, so this does not authenticate execution or establish freshness.

Fresh interface acceptance remains open in #1861. Invalid launcher-directory attempts were discarded. A correctly launched Claude Match attempt reported a session safety gate and produced no result files; a Codex attempt produced no output before termination. Neither counts as success. No session control was bypassed and no simulated result was accepted. W4, W7, managed Adapt, live Match and the human continuation criteria remain open.

Autonomous continuation and UX readiness, 2026-09-11

The local Compose, Adapt and Match Guides and their direct demonstrations are implemented on main (#1876). Their 2026-09-11 receipt remains a dated, agent-operated local trial. The older block table below is a historical 2026-09-10 checkpoint; its outstanding page-publication work was subsequently completed by #1876. Fresh assistant interfaces, independent human continuation, managed Adapt and live Match are not accepted by that page work.

Merged #1880 passed all nine exact-head CI checks and preserves the historical Timoni receipts. #1882 is the separate parity run-consistency repair: 156 passing receipts have explicit namespace mappings; three older receipts omit them and need exact path/whole-file-hash compatibility witnesses. That repair does not prove independent target authenticity or close #1881. #1883 adds normal-chain coverage for the retained Guide demonstration checker. Both are open at this checkpoint and must pass CI before merge.

The first capability-inventory criterion in #1861 is recorded against helm-expt c5561281e33f39952f0cdd6ed13c7dc0340c375f and cub-workshop 571236484d3fb8e05273e4de22870114b6dd1baa:

Continue independently with the scoped integrity and regeneration audits. Keep the five successor PRs draft until real registry publication/signing succeeds. Live acceptance still needs selected Kubara targets/access, GPU resources where required and the representative fleet schema. d2 analysis needs the layout list; NGC terms and official Guide ownership need their respective maintainer decisions. These dependencies are not resolved by finishing local code or by a UX trial.

The local Guides can be used for the proposed UX exercise once its participant and protocol are agreed. Do not label that exercise as full-plan completion: B25–B30/B39 audits and the API/live/ownership requirements remain separately tracked. Preserve the original 17 accepted B-task count at this checkpoint.

Easy and sharp: observable requirements

• Ask only for facts needed for the next meaningful action. Discover available capabilities and versions before asking the user to diagnose the environment.
• Show what will be produced, where it is saved, and what runs remotely before requesting credentials or deployment approval.
• Give concise human output and structured results from the same operation. Keep identifiers and previous selections across steps and interruptions.
• Report checked, failed, unknown and not-run distinctly. Static certification, target qualification, controller sync and application health are separate facts.
• Let the user inspect and retain a local result without a ConfigHub account when the selected source permits it. Private registries and governed operations state their own authentication requirements at the point of use.
• A teammate handoff preserves object identity and declares access requirements. Sharing configuration is not the same as sharing a running application.

The assistants may propose a selection or edit. Deterministic tools produce the verdict; neither a fluent explanation nor a successful render overrides a refusal.

Website work alongside delivery

Improve one task page at a time: Kubara and its app continuation first, then the adaptation entry, then the NVIDIA entry. Keep navigation changes out of this slice. Every page must answer: what can I do here, what do I need, what is my first action, what result should I see, what if it fails, and what can I do next?

Offer a copyable direct path and a compact assistant task with the same bounded outcome. Keep evidence on GitHub and summarize its scope on the page. Test links, copyable commands and the complete journey, including empty or missing input. Generated pages change through their source generator; backend PRs regenerate data surfaces, while authored website changes remain with the website owner.

NVIDIA continuation and dependencies

Reuse the AICR ingestion stream's output rather than duplicating its work. The customer configuration journey selects retained workload and platform components against explicit chipset, capacity and environment requirements. The fleet-operator journey additionally needs disruption analysis, staged rollout and held-back targets; those are separate acceptance criteria, not consequences of a successful render.

Demonstration and trial gate

Each show-and-tell has a clean-start checklist, source versions, exact task, expected intermediate artifacts, one failure-and-repair example, one change, retained result, and cleanup. The CLI demo must succeed without an assistant. Both assistant demos must succeed without hidden maintainer intervention. Record setup time separately from task time and do not call a prepared transcript a user trial.

Proposed first trial: three pairs complete the same real task using their current workflow and the new route. Record time to first useful result, setup interruptions, requests for help, correct interpretation of missing evidence, and teammate handoff. Follow up on reuse after a week. A provisional advance criterion is two of three pairs completing without maintainer rescue; any mistaken safety or live-readiness claim requires investigation before expansion. These are proposed criteria, not measured outcomes or evidence of market demand.

Validation and decisions

Every implementation PR names the changed receipt or verifier, runs the narrowest relevant checks and then the full repository gate, and reports person-dependent blocks. Documentation additions update the doc map, freshness snapshot and generated site at the pinned timestamp. No new breakage is added to the known-red register.

Commercial packaging, marketplace design, hosted execution, MCP deployment and a new one-line product command remain decisions, not prerequisites for this trial. The umbrella, stories and AI API options retain that strategic discussion.

Workshop evidence checkpoint, 2026-09-10

Completion is measured against each block's acceptance evidence, not PR count. The local editing loop is implemented; the complete three-journey plan is not yet accepted. Open implementation PRs are not installed capabilities.

Do not count an Argo CD controller manifest as a working GitOps loop. Do not count NVIDIA model-profile coverage as image pull, model load or a GPU response. The credential boundaries of #1699 and #1639 remain in force. Website source ownership is authorized. Live target selection, access and the human-trial participant remain requested. Static work continues independently.

Independent handoff trial: ready-to-run protocol

This protocol is prepared, not an executed trial. Choose a participant who did not author the implementation. Give them the task page, the pinned plugin source revision and a fresh copy of the result directory. Do not give them the expected answers below until their attempt is recorded. A second assistant is not a human participant.

1. Record the journey, source revision, CLI/plugin versions, setup start and setup finish. Count setup interruptions separately from task time. Keep organization access out of a local exercise.
2. Ask the participant to explain the intended change, identify its exact inputs, rerun the local command into a new output file, and identify what remains unchecked. Record help requests verbatim after removing private information.
3. Ask them to move the directory, repeat the check, and make one additional requested edit. Compare hashes and findings before and after the move. Preserve the original input and the first result.
4. Present the deliberate refusal or unintended extra edit. Ask them to explain the finding and next action without the author repairing it for them.
5. Record task finish, observed result, assistance needed, and whether the participant could continue unaided. Never fill missing observations with an expected result. A mistaken live-readiness claim requires investigation.

For Adapt, use the pinned task and fixtures in cub-workshop at revision 569d74f968b0b60cc3d55bffe91aef22de10fa29. The requested edit is Deployment monitoring/prometheus-server replicas 1 to 2; the extra-edit candidate also changes revisionHistoryLimit from 10 to 5. The expected local result reports both changes for that candidate. The participant should distinguish comparison success from approval, upstream preservation and workload health.

The handoff record must name the input and output hashes, the exact task supplied, setup and task durations, assistance events, refusal interpretation, omitted live checks, and the observed continuation outcome. Keep real participant identities out of public records. For Compose and Match, bind this protocol to the final integrated source revision before the trial; the currently separate PRs are not that revision.

Fleet confidence and entry-path acceptance refinement

The NVIDIA fleet catalog requirements refine the existing blocks without marking any of them complete. Start with fleet-level declarative desired/live reconciliation and keep the four deployment/rollback confidence outcomes separate (#1582). The AICR v0.21.0 comparison reuses existing exact receipts and preserves the v0.20.0 chain (#1860).

Completion requires actual cub, command-line plugin and live-chat API paths for the supported Catalog/Workshop jobs, with the same digests, constrained inputs, evidence, approvals and refusals (#1861). A CLI-only demo or API design document does not complete live-chat access. Missing target, publication or runtime evidence stays explicitly unproved.

Workshop Guides: story coverage and evidence admission

The Workshop Guides proposal adds a learner-facing layer to this plan. Keep Compose → Adapt → Match in order and preserve the existing site navigation. A Guide teaches one bounded job; a Path links Guides into a larger story; Examples supply executable inputs; Stories explain relevance; Evidence supports specific claims. The portfolio map is planning coverage, not a count of published Guides or proven capabilities.

Cover the full progression, not only signup:

• Entry: inspect or find configuration, understand what it installs and needs, diagnose ignored values, and make a bounded change without an unnecessary fork.
• Midpoint: keep, share and resume a result; map source to ConfigHub; compare candidates; preserve intent across upgrades; handle lifecycle work; review, release and promote; distinguish configuration rollback from recovering data.
• Keystone: describe a platform and its apps and receive a checked bounded composition; match GPU workloads and operate declared fleet configuration with provenance, constrained inputs and distinct deploy/continuity/rollback evidence.

Experts may enter at a midpoint or keystone with explicit prerequisites. Each major story needs a Guide/Path mapping, accountable role, source/evidence links, implementation status and next step. The first published set stays small; the whole story map must remain visible. Current receipts outrank historical story claims. The GPU-fleet Path inherits #1582's four confidence requirements and #1581's runtime prerequisites; a story never lifts those gates.

Every taught journey explains authored source → materialization → ConfigHub representation → delivery/observation → authority and the next edit location. For anonymous completion, a ConfigHub mapping can be explicitly previewed rather than created. A retained local result or actionable refusal is a valid completion; SaaS activation is a separate outcome with actual product state and evidence.

#1869 owns the Guide metadata, portfolio, template and admission work. Reuse WorkshopResult and existing source/result identities; do not create a competing execution model. Keep editorial maturity separate from source, materialization, destination and live status. Official publication requires accountable ownership, supported versions, maintained pins, reproducibility and evidence for the promised outcome. Mapping a story does not satisfy those conditions. Runnable tasks stay in cub-workshop; Guide pages/evidence stay here; Hub owns product tours, auth continuation and user/organization-scoped resume. Actual direct cub/plugin and live-chat API acceptance remains #1861.

#1870 specifies the Argo Application Tree Path now, with supported handover deferred until proved. Preserve bootstrap, managed child definitions, generated desired objects and observed state as distinct nodes. Displaying a generated object does not make ConfigHub authoritative for it. Prove one canary change and bounded rollback, including removal of conflicting previous authority, before expanding adoption.