---
title: "2026-09-02 Factory packaging and deployment review"
description: "Adversarial review found Factory image build, selection, CI, and dashboard rollout blockers."
image: "https://docs.virdx.dev/img/virdx-social-card.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://docs.virdx.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# 2026-09-02 Factory packaging and deployment review

## Work Done

Reviewed the staged Factory campaign prototype in the `virdx/mono` worktree without editing it. Checked the split Pixi workspaces and locks, Hatch wheel contents and console scripts, Docker build and runtime paths, Nx targets, Tekton build submissions, the deployed `infra_k8s` image-name policy, Argo `run-image` selection, the current Factory deployment, and dashboard API callers.

Found that both new Dockerfile paths are absent from the deployed Tekton image-name map, so their PipelineRuns receive an empty image name. The controller also selects `factory-worker`, which the current registry flow does not publish. The new Nx target names are not called by the PR gate and their Docker commands omit the required BuildKit secret. The existing dashboard still uses the removed `/rules` API.

Both Pixi locks passed `pixi lock --check`. The controller and worker distributions built successfully. The worker wheel contained the expected modules and both console scripts. Controller tests, lint, typecheck, and format checks passed. Docker images were not built.

## Lessons Learned: Pitfalls

The initial product workstream classification was too narrow. Factory packaging and cluster rollout depend mainly on infrastructure material. The product workstream also has no SOP index. Reading the infrastructure execution SOP and checking the live `infra_k8s` checkout exposed the decisive image-name behavior quickly.

## Lessons Learned: Improvements

The infrastructure execution SOP should state that the `tekton-image-name` mapping has no usable fallback: an unmapped build gets an empty image name. It should also require every monorepo Dockerfile rename to land with its `infra_k8s` mapping and runtime image reference update. The mono PR gate convention that container validation only invokes an exact `container` target should be documented near app packaging guidance.

Source: https://docs.virdx.dev/knowledge/inbox/2026-09-02-infrastructure-factory-packaging-deployment-review/index.mdx