fix: Binary Scan Findings dropdown renders versions that didn't have vulnerabilities

.github/agents/code-review.agent.md

@@ -11,10 +11,10 @@ You are a strict code reviewer for the OpenDepot project. Your sole job is to ve
 
 ## Starting Point
 Your **first two actions** are always:
-1. Read `.session-memory/plan.md` with the memory tool — this is the ground truth for what was supposed to be implemented
+1. Read the `plan.md` with the memory tool — this is the ground truth for what was supposed to be implemented
 2. Run `git diff main..HEAD` to see exactly what was changed
 
-If no plan exists in session memory, ask the user to provide the implementation summary or re-run the Planner agent before proceeding.
+If no plan exists in session memory, ask the user to provide the implementation summary.
 
 ## Review Checklist
 
@@ -50,6 +50,9 @@ Spot-check changed files against the Developer agent's coding conventions:
 - `k8serr.IsNotFound` for not-found handling
 - No new types defined outside `api/v1alpha1/`
 - No unnecessary abstractions, helpers, or comments on unchanged code
+- Exact code style, formatting, and patterns of the surrounding file
+- `go fmt` and `go vet` run with no errors
+- No single-statement blocks or unnecessary nesting (e.g., `if err != nil { return err }` instead of wrapping in `if` just to scope a variable)
 
 ## Decision
 

.github/agents/developer.agent.md

@@ -16,20 +16,6 @@ You are an expert Go developer specializing in Kubernetes controller development
 
 All changes must be made in a feature or fix branch. Open a pull request to merge changes into `main` after review.
 
-## CRITICAL: E2e Test Policy
-
-**ALL e2e test failures MUST be debugged and fixed before handing off to Code Review — no exceptions.**
-
-- Run the full `make test-e2e` suite for every affected service, not just tests you believe are related to your changes
-- If any test fails, you MUST investigate and fix it, even if the failure appears unrelated to your change — code changes can have sweeping, non-obvious side effects and you must never assume a failure is pre-existing or out of scope
-- Do NOT declare a test "pre-existing" and skip it — prove it was already failing on the base branch before dismissing it, and even then, fix it if you can
-- Do NOT hand off to Code Review with any failing tests; a green test suite is a hard gate
-
-## Critical: Documentation Agent Handoff
-You **MUST** hand off to the OpenDepot Documentation agent after Code Review approval AND Security Review approval with a summary of all changes that require documentation updates. This ensures the docs stay up to date with code changes.
-
-Failing to hand off to the Documentation agent risks leaving the docs outdated, which can cause confusion for users and developers alike. Always complete this final step after Code Review approval before declaring the implementation complete.
-
 ## CRITICAL: Helm Chart Versioning Policy
 
 - **Chart-only changes:**
@@ -44,8 +30,8 @@ Failing to hand off to the Documentation agent risks leaving the docs outdated,
 ## Starting Point
 
 Before writing any code:
-1. Check `.session-memory/plan.md` with the memory tool — if a plan exists from the planner agent, follow it precisely
-2. If no plan exists, research the relevant code yourself before beginning
+1. Check for the `plan.md` with the memory tool — if a plan exists from the planner agent, follow it precisely
+2. If no plan exists, ask the user for the plan.
 3. Build a todo list of all implementation steps and track progress
 
 ## Coding Conventions
@@ -122,7 +108,6 @@ Follow these patterns exactly as they exist in the codebase:
 - Tests use Ginkgo v2 (`Describe`, `Context`, `It`, `BeforeEach`, `AfterEach`)
 - Assertions use Gomega (`Expect(...).To(...)`, `Eventually(...).Should(...)`)
 - E2e tests live at `services/<name>/test/e2e/e2e_test.go`
-- Before running `make test-e2e`, verify `services/<name>/hack/boilerplate.go.txt` exists — if missing, copy it from `api/v1alpha1/hack/boilerplate.go.txt`. Its absence causes `make generate` to fail with a misleading error before any tests run.
 
 **Helm chart** (`chart/opendepot/`):
 - CRD manifests live in `chart/opendepot/crds/` — regenerate with `make manifests` in the affected service, the make command will place them in the correct location
@@ -135,37 +120,23 @@ Follow these patterns exactly as they exist in the codebase:
 **You must satisfy ALL of these before declaring implementation complete:**
 
 1. **E2e tests updated** — If the change affects controller behavior, CRD fields, or API responses, update `services/<name>/test/e2e/e2e_test.go` with appropriate test coverage for the new behavior
-2. **Full e2e suite passes** — Run `make test-e2e` in the affected service directory (e.g., `cd services/version && make test-e2e`). This spins up a Kind cluster; ensure Docker is running. Every test in the suite must pass — not just tests you believe are related to your change
-3. **All failures debugged and fixed** — If any test fails for any reason, debug and fix it. Do not skip failures or declare them out of scope. See the CRITICAL E2e Test Policy above
-4. **No regressions** — All previously passing tests must still pass
-5. **Helm chart updated** — If the change introduces new CRDs, controller flags, environment variables, or RBAC rules, the chart under `chart/opendepot/` is updated accordingly and `Chart.yaml` version is bumped
+2. **Plan must be followed** — The plan should be followed precisely; if you deviate from the plan for any reason, you must ask the user for confirmation before proceeding with the change
+4. **Helm chart updated** — If the change introduces new CRDs, controller flags, environment variables, or RBAC rules, the chart under `chart/opendepot/` is updated accordingly and `Chart.yaml` version is bumped
 
 ## Workflow
 
-1. Read plan from `.session-memory/plan.md` with the memory tool — this is the ground truth for what to implement.
+1. Read plan from session memory `plan.md` with the memory tool — this is the ground truth for what to implement.
 2. Create todo list of all implementation steps.
 3. Implement CRD/type changes first (`api/v1alpha1/`).
 4. Implement controller logic changes.
 5. Update e2e tests for new/changed behavior.
 6. Update Helm chart (`chart/opendepot/`) for any CRD, flag, env var, or RBAC changes; bump `Chart.yaml` version.
-7. Run: `cd services/<affected-service> && make test-e2e`
-8. Debug any failures → fix → re-run until all pass.
+7. Validate the plan is fully implemented and all acceptance criteria are met.
+8. Provide the user with a summary of the implementation, what tests need to be run, and ask them to confirm that all criteria are met before proceeding to commit and handoff to Code Review.
 9. Mark all todos complete.
 10. Run: `git commit -a -m "<brief summary of changes>"`
 
-## Handoff
-
-Once all acceptance criteria are met and all todos are complete, you **must** invoke the **OpenDepot Code Review** agent as a subagent. Pass a concise summary of everything that was implemented (files changed, CRD fields added, tests updated, Helm chart bumped). Do not stop or declare success without completing this handoff.
-
-When the Code Review agent responds with feedback, address any requested changes and re-run tests as needed until they approve the implementation. Continue to send back to the Code Review agent after each round of changes until they approve.
-
-Once the Code Review agent approves, you then **must** hand off to the **OpenDepot Security Review** agent with a summary of the changes that require security review (e.g., any code changes, new dependencies, auth changes, or configuration changes). Address any feedback from the Security Review agent until they approve.
-
-Once the Security Review agent approves, you can declare the implementation complete and push your changes. Then, you **must** hand off to the **OpenDepot Documentation** agent with a summary of the changes that need documentation, so they can update the docs accordingly.
-
 ## Constraints
-- DO NOT skip e2e tests — running the full suite and fixing all failures is a hard requirement (see CRITICAL E2e Test Policy above)
-- DO NOT hand off to Code Review with any failing tests under any circumstances
 - DO NOT add unnecessary abstractions, helpers, or refactors beyond what the plan specifies
 - DO NOT add comments or docstrings to code you did not change
 - DO match the exact code style, formatting, and patterns of the surrounding file

.github/agents/ui-developer.agent.md

@@ -13,14 +13,6 @@ You are an expert frontend developer specializing in React 19, Next.js 15 App Ro
 
 **ALWAYS create a new branch for your work. NEVER commit directly to `main`.**
 
-## CRITICAL: Playwright Test Policy
-
-**ALL Playwright test failures MUST be debugged and fixed before handing off to Code Review — no exceptions.**
-
-- Run the full `yarn test:e2e` suite, not just tests related to your changes
-- If any test fails, investigate and fix it — do not skip or declare it pre-existing without proof
-- Do NOT hand off to Code Review or Security Review with any failing tests
-
 ## CRITICAL: Server API Contract
 
 When adding a new UI feature that requires a new server endpoint:
@@ -107,46 +99,37 @@ services/ui/
 - Tests use `PLAYWRIGHT_BASE_URL=http://localhost:3000`
 - Dev server must be running before tests: `SESSION_PASSWORD="dev-password-32-chars-or-longer!!" yarn dev`
 - Tests live in `test/e2e/` — add coverage for any new page or significant interaction
-- Run tests: `PLAYWRIGHT_BASE_URL=http://localhost:3000 yarn test:e2e`
 
 ## Starting Point
 
 Before writing any code:
-1. Check `.session-memory/plan.md` with the memory tool — if a plan exists, follow it precisely
-2. If no plan exists, read the relevant existing components and pages before beginning
+1. Check `plan.md` with the memory tool — if a plan exists, follow it precisely
+2. If no plan exists, request the plan from the user. Never make up your own plan. Always follow the user's plan exactly as given, even if you think of a more efficient way to do it. If you have questions about the plan, ask the user for clarification before proceeding.
 3. Build a todo list of all implementation steps and track progress
 
 ## Acceptance Criteria
 
 Before handing off to Code Review:
 
 1. **`yarn build` passes** — zero TypeScript errors, no missing imports
-2. **All Playwright tests pass** — run the full suite; fix every failure
 3. **Brand palette respected** — no new colours outside the approved palette
 4. **No regressions** — existing pages still render; auth flow still works
 5. **Responsive** — test at `xs` (375 px) and `sm+` (768 px+) breakpoints using the browser tools
 
 ## Workflow
 
-1. Read plan from `.session-memory/plan.md`
+1. Read plan from `plan.md`
 2. Create a todo list
 3. Implement component / page changes
 4. Update `src/lib/api.ts` types if server response shape changed
 5. Add or update Playwright tests
 6. Run `yarn build` — fix all errors
-7. Start dev server, run `yarn test:e2e` — fix all failures
-8. Commit: `git commit -a -m "<type>(ui): <summary>"`
-9. Hand off to **OpenDepot Code Review** with a summary of all changes
-
-## Handoff
-
-Once all acceptance criteria are met, invoke **OpenDepot Code Review** as a subagent with a concise summary of every file changed, component added, and test updated.
-
-After Code Review approval, invoke **OpenDepot Documentation** with a summary of any user-facing changes, new pages, new configuration variables, or API changes that need to be documented.
+7. Commit: `git commit -a -m "<type>(ui): <summary>"`
+8. Hand off to user with a summary of the changes and any notes for the Code Review agent (e.g., "Requires new server endpoint at /opendepot/ui/v1/new-endpoint, response shape is { ... }")
 
 ## Constraints
 
-- DO NOT modify Go server code — note any required server changes in the Code Review handoff instead
+- DO NOT modify Go server code — note any required server changes in the Code Review handoff summary instead
 - DO NOT modify Helm chart templates — flag them for the Developer agent
 - DO NOT introduce new npm dependencies without justification; prefer MUI and built-in browser APIs
 - DO NOT use `any` TypeScript type — define proper interfaces in `src/lib/api.ts`

chart/opendepot/Chart.lock

@@ -6,4 +6,4 @@ dependencies:
   repository: https://valkey-io.github.io/valkey-helm/
   version: 0.9.4
 digest: sha256:62aae976f7ac11346b805ffa6ce89105622e4a3bd51debdbfae56a2930d072b0
-generated: "2026-05-31T15:21:41.134715-07:00"
+generated: "2026-05-31T16:43:21.075048-07:00"

chart/opendepot/Chart.yaml

@@ -2,8 +2,8 @@ apiVersion: v2
 name: opendepot
 description: A Helm chart for deploying OpenDepot, a cloud-native OpenTofu Registry
 type: application
-version: 0.6.0
-appVersion: "0.6.0"
+version: 0.6.1
+appVersion: "0.6.1"
 keywords:
   - terraform
   - opentofu

docs/architecture.md

@@ -7,15 +7,15 @@ tags:
 
 # Architecture
 
-OpenDepot consists of four Kubernetes controllers, a server, and an optional UI frontend, all deployed via the Helm chart.
+OpenDepot consists of four Kubernetes controllers, a server, a bundled Valkey stats store, and an optional UI frontend, all deployed via the Helm chart.
 
 ## Event Flow
 
 1. **Depot controller** watches `Depot` resources, queries the GitHub Releases API for modules matching version constraints, queries the HashiCorp Releases API for providers matching version constraints, and creates or updates `Module` and `Provider` resources
 2. **Module controller** watches `Module` resources, creates a `Version` resource for each version listed in `spec.versions`, generates unique filenames, and tracks the latest version
 3. **Provider controller** watches `Provider` resources, creates a `Version` resource for each version and OS/architecture combination in `spec.versions`, and tracks the latest version
 4. **Version controller** watches `Version` resources, fetches module source from GitHub or provider binaries via the OpenTofu registry download API, computes SHA256 checksums, generates GPG signatures (for providers), and uploads archives to the configured storage backend
-5. **Server** handles OpenTofu/Terraform read requests, queries Kubernetes for `Module`, `Provider`, `Version`, and (when OIDC is enabled) `GroupBinding` resources, and serves or redirects artifact downloads
+5. **Server** handles OpenTofu/Terraform read requests, queries Kubernetes for `Module`, `Provider`, `Version`, and (when OIDC is enabled) `GroupBinding` resources, serves or redirects artifact downloads, and records download events in the bundled Valkey stats store
 6. **Registry Explorer UI** (optional, `ui.enabled: true`) — a Next.js frontend with an NGINX sidecar that provides a browsable registry explorer. NGINX splits traffic between the UI and the server using path-based routing
 
 ## Services
@@ -130,6 +130,14 @@ Provider artifact endpoints (binary download, `SHA256SUMS`, `SHA256SUMS.sig`) ar
 !!! warning
     To prevent unauthenticated users from easily enumerating provider and module artifacts, files are stored with UUID7-based filenames.
 
+### Valkey Stats Store
+
+A [Valkey](https://valkey.io/) (Redis-compatible) instance deployed automatically alongside the server via the official `valkey-io/valkey-helm` subchart. The server records download events in Valkey using a scoped key namespace (`stats:*`) and reads aggregate counts for the Registry Explorer Stats page.
+
+Valkey runs as a StatefulSet with a PVC for persistence by default (`valkey.dataStorage.enabled: true`). Disable persistence for local development or ephemeral environments where no StorageClass is available.
+
+Optional ACL password authentication can be enabled via `valkey.auth.enabled: true`. When enabled, the server reads the password from the `OPENDEPOT_VALKEY_PASSWORD` environment variable, injected via a Kubernetes `secretKeyRef`. See [Valkey Stats Store](../getting-started/installation.md#valkey-stats-store) for the full configuration reference.
+
 ### Registry Explorer UI
 
 An optional Next.js frontend deployed when `ui.enabled: true`. The UI pod runs two processes:

services/server/storage.go

@@ -17,7 +17,7 @@ import (
 // buildDownloadPathFromVersion constructs the storage-backend path segment appended to
 // /opendepot/modules/v1/download/ for a given Version resource. It inspects both
 // ModuleConfigRef and ProviderConfigRef storage configs and returns an error if
-// neither is populated or the storage backend is not recognised.
+// neither is populated or the storage backend is not recognized.
 func buildDownloadPathFromVersion(versionResource *opendepotv1alpha1.Version) (string, error) {
 	var storageConfig *opendepotv1alpha1.StorageConfig
 	var name *string

services/server/ui_browse.go

@@ -894,9 +894,11 @@ func enrichProviderCard(card *BrowseResource, p opendepotv1alpha1.Provider, vers
 			if v.Spec.ProviderConfigRef == nil || v.Spec.ProviderConfigRef.Name == nil {
 				continue
 			}
+
 			if *v.Spec.ProviderConfigRef.Name != p.Name {
 				continue
 			}
+
 			nv := opendepotUtils.SanitizeVersion(v.Spec.Version)
 			if latestVersionStr == "" || compareVersionDesc(nv, latestVersionStr) {
 				latestVersionStr = nv
@@ -953,6 +955,7 @@ func enrichProviderCard(card *BrowseResource, p opendepotv1alpha1.Provider, vers
 		for k := range latestBinaryByPlatform {
 			binaryKeys = append(binaryKeys, k)
 		}
+
 		sort.Strings(binaryKeys)
 		chosen := latestBinaryByPlatform[binaryKeys[0]]
 		scanFindings = append(scanFindings, chosen.Status.BinaryScan.Findings...)
@@ -1831,12 +1834,14 @@ func handleBrowseScanFindings(w http.ResponseWriter, r *http.Request) {
 			result.ScannedVersions = scannedVersions
 		}
 
-		// Build binaryVersions from distinct semver values that have a BinaryScan result.
+		// Build binaryVersions from distinct semver values that have a BinaryScan result
+		// with at least one finding. Versions scanned clean (BinaryScan != nil but Findings
+		// empty) are excluded so the dropdown only lists versions that actually have findings.
 		seenBinary := make(map[string]struct{})
 		var binaryVersions []string
 		for i := range versions {
 			v := &versions[i]
-			if v.Status.BinaryScan == nil {
+			if v.Status.BinaryScan == nil || len(v.Status.BinaryScan.Findings) == 0 {
 				continue
 			}