Handling separation of concerns for the CICD.

Signed-off-by: copilotcoder <copilotcoder@darkhelm.org>

docs/adr/ADR002-cicd_base_image_tagging.md

@@ -6,33 +6,45 @@
 ## Context
 
 CICD builds depend on a shared base image containing stable system dependencies.
-To optimize build times while preserving correctness, the pipeline uses cache-aware
-image reuse and fallback behavior.
+To optimize build times across a fleet of self-hosted runners while preserving
+correctness, the pipeline now separates base-image publication from application CI.
+The expensive base image should be built once per content change, pushed to the
+registry under an immutable tag, and then pulled by every runner that needs it.
 
 This branch reinforced the workflow by ensuring hash-driven base tags are always
 computed and non-empty before tagging/pushing, preventing invalid image references.
+It also expanded the base hash inputs to include `.dockerignore` so context changes
+that affect the base build invalidate the published tag.
 
 ## Decision
 
-Adopt hash-based tagging for the CICD base image with latest fallback:
+Adopt a hardened split workflow for the CICD base image:
 
-1. Compute a deterministic hash from Dockerfile.cicd-base content.
-2. Publish base image as both:
+1. Compute a deterministic hash from `Dockerfile.cicd-base` and `.dockerignore`.
+2. Publish the base image in a dedicated workflow as both:
    - hash-specific tag: cicd-base:<hash>
    - rolling tag: cicd-base:latest
-3. Prefer pulling hash-specific image; fallback to latest when needed.
-4. Validate/fallback hash propagation in workflow to avoid empty tag references.
+3. Treat the hash-specific tag as the source of truth for all CI consumers.
+4. Keep `latest` only as a convenience tag for humans and manual debugging.
+5. Make the main CI workflow consume only the immutable hash tag and fail clearly
+  if that base image has not been published yet.
+6. Add bounded polling in main CI to tolerate short publish/consume races between
+  the dedicated base workflow and the main workflow.
 
 ## Consequences
 
 Positive:
 - Faster CI via stable base-layer reuse
 - Better traceability from base image to Dockerfile content
+- Single publish, many pulls across the runner fleet
 - Reduced risk of malformed image references in workflow execution
+- Clearer separation of concerns between artifact publication and application CI
 
 Negative:
 - Slightly more workflow complexity
 - Registry stores additional hash-tagged images
+- Main CI now fails fast when the expected base image is missing instead of
+  rebuilding it locally
 
 ## Alternatives Considered
 
@@ -40,3 +52,6 @@ Negative:
   - Rejected due to reduced traceability and cache precision
 - Build base image every run
   - Rejected due to slower pipelines and wasted compute
+- Allow main CI to rebuild missing base images locally
+  - Rejected because it reintroduces split-brain behavior across runners and
+    defeats publish-once/consume-many optimization