Delivery and operations

This is the cross-repository operating model for this Homelab. Scanning, image and bundle builds, signing, publication, and deployment run through reviewed Forgejo Actions pipelines in the owning repositories. Their runbooks name the protected manual workflows, inputs, release evidence, prerequisites, and validation steps. Local source checks help prepare a change but are not production delivery.

Repository boundaries

Implementation issues remain in the owning repository and are prioritized on the internal Homelab Roadmap; this site's dated roadmap snapshot shows its current columns without linking to the private project. Avoid duplicate resource ownership across repositories. The generic wiki is no longer updated with this instance's changing facts.

Artifact path

Disposable dev selected 2026-10-10 (owner direction). Dev is for quick iteration on the shared cluster; resource limits rule out a separate disposable node pool. Removed dev bundles need no retained data, including PVC contents, in-bundle databases and explicitly declared external dev databases. Production keeps the full delivery gates and data recovery requirements below.

Prepared source changes add a dev-only scan profile that retains secret checks, signed provenance, immutable image references, target preflight and application health checks, while skipping the heavier source/image scans and SBOM generation. Dev-only releases cannot authorize production. Production promotion still uses one fully scanned archive tested in dev and deployed unchanged to prod. New bundle repositories retain their normal repository security scans; reduced scans apply only to bundle operations targeting dev.

The owning application's protected manual cleanup workflow defaults to preview, checks the exact installed signed release and dev namespace ownership, and discards the dev package, namespace and disposable storage. External PostgreSQL targets must be declared with dev-only credentials and verified TLS; other engines and static/NAS storage need their own reviewed erasure procedure. Cleanup is opt-in per application, with production and unflagged app permissions unchanged. The source is prepared for review; library publication, caller adoption, platform reconciliation and live removal/recreation acceptance remain pending. The proposed source and detailed procedures are recorded in workflows #83, the workflow implementation, private Homelab/bundles template source at f0a4991654b3eaa38873900c1cd4cf973fa15d74 and private Homelab/platform onboarding source at dcee8464b7c955c0c9551455ab254b8df9fe35bc. These references describe prepared source rather than an installed workflow release or verified live state.

1. Review source/configuration on a protected branch and run repository checks.
2. Pin upstream sources and image digests. Run source, dependency, Dockerfile and full-image security gates appropriate to the artifact. A finding mitigation must be reviewed, scoped and expiring; scanner errors and real credential leaks do not become success.
3. Build and scan a large image in one disposable job; publish the same scanned archive by immutable digest. Do not transfer a multi-gigabyte image through an Actions artifact cache.
4. Sign scan evidence and the exact package/bundle release; keep source commit, image digest, scan report hashes and bundle identity together.
5. Build the versioned Zarf package and UDS bundle, validate them, then deploy the same tested artifact. Promotion must not silently rebuild it.
6. Verify the target environment's route, trusted TLS, identity, storage, rollout and application behavior. Keep the prior signed release plus data backup for rollback.

Existing workflow callers retain their reviewed exact-release pins until an explicit channel migration is accepted; check the owning workflow before quoting a version. UDS bundles are the target deployment unit. Raw manifests and Kustomize remain for reconciliation, migration or diagnostics rather than a parallel routine deploy path. The detailed delivery guide is in private Homelab/platform.

Mitigation identity selected 2026-09-25 (owner direction; private Homelab/platform issue #47). Match a reviewed mitigation to a stable CVE/GHSA or scanner rule/finding ID and its affected path, package/version, component and severity as appropriate. Commit, build-input and image hashes belong to provenance and evidence, not mitigation identity; unrelated pushes or source-line movement must not invalidate the review. Retain the owner, reason, compensating control, review reference and expiry. Repeated source findings may use an exact reviewed occurrence count when the pinned library supports it; changed counts, rules, paths or severities require reassessment. Review policy and caller-version migrations together. The reusable library's security procedure owns the schema details; this decision is not evidence that the pending platform migration or GitchAuth image has been published.

Each application repository owns its build and deploy callers. Homelab/workflows supplies reusable workflow_call implementations; dispatching an Action in that library repository does not deploy another repository's release. A deploy caller selects an immutable signed release, verifies it, obtains scoped target credentials, and deploys that same archive. If an application has no caller or approved credential contract, establish those through review before deployment.

Forgejo Actions and security

Shared stable workflow channel

Historical first promotion, verified 2026-10-13. The owner reported a successful Promote workflow channel run. The remote stable-v1 tag and its annotated audit selected published v1.36.0 through immutable snapshot c025748ca41b6525b2e1f6ab1ed00c95571df0a6, named workflow-channel-v1-v1.36.0. The audit tag workflow-channel-promotion-v1-r7086 records dispatcher gitchegumi, canary 7087 and the reviewed release checks. This establishes the first protected channel write, separately from numbered-release publication.

Current channel binding, verified 2026-10-17: the owner reported promotion of v1.44.1. The authenticated stable-v1 RKE2 adapter binds workflow_release to v1.44.1 and workflow_release_sha to 6999b5326fb4c4ac7a06114c592f0d69a0b4873b through snapshot 2716c0bde2095d7a77986fb98b6daffaac38075c. Owner-authorized Platform controller retry 5015 exercised automatic release selection and safe permission diagnostics, identifying a denied exemption-list operation; controller acceptance remains pending. This library commit is distinct from the owning Platform source commit.

Prior promotion, verified 2026-10-16: workflows promotion run 854 selected published v1.42.3 on stable-v1, with passing canary 7545 and workflow_release_sha 2f32073eb071e372c93a495d47d90f6468751dd6. This is the shared workflow repository's commit; it is separate from an owning Terraform source candidate or plan fingerprint. The release retains the workload-identity profile, RKE2 delivery, Seaweed bootstrap, Semgrep rule-lock repair and reusable RKE2 event fix. It includes the known-marker review correction from workflows #107 and the narrow UI-hint ordering correction from workflows #108. Plan run 72 and specifically approved apply run 75 created/converged the eight original OpenBao resources. The promoted release also includes workflows #109, preserving an existing RKE2 operation error when OpenBao cleanup also fails. Fresh plan 80 contained only three self-revocation policy updates; owner-authorized apply 81 applied them and its post-apply plan reported no managed-resource changes. Those Terraform runs used the previous promoted v1.42.2, source 2418f947a9339774a674bf4b7f1a9f577d3882ea. That release added workflows #110: exact Core/init compatibility profiles and safe installed-init version diagnostics.

The owner selected incremental consumer adoption as bundles are updated, starting with Harbor and its direct Terraform provisioning dependencies. Callers select @stable-v1 and omit optional library_ref, retaining names, required checks, operation inputs and credential boundaries. Documentation's source-security caller now uses checkout-based security.yml@stable-v1; the owner selected checkout-based scans for this batch until the embedded image path is rebuilt and reviewed. Runtime image digests remain separate pins. Library promotion does not prove a consumer's signed publication or deployment; use its owning checks and acceptance record.

Compatible future upgrades dispatch the central manual promotion workflow with a published vX.Y.Z. Its frozen adapters bind expanded YAML and source checkouts to that numbered release. The immutable snapshot and audit retain prior evidence; stable-v1 is the moving selection. Start a fresh owning workflow run after promotion; channel adapters reject reruns. Preinstalled images retain their separate embedded payload provenance. Breaking input or policy changes still require reviewed consumer migration. See the owning channel procedure.

The earlier protected-tag authorization blocker was addressed by merged PR #96 and the owner-approved native workflow-release-v1/workflow-channel-v1 integrations. Each retains its exact workflow/main/manual-event and repository scope, using short-lived kiyi writes while the human dispatcher remains allowed through DEPLOY_ACTORS. The setup receipt records configuration. No standing PAT or additional CI secret was introduced. The successful channel write does not establish a later numbered-release write.

Rollback, queued-run behavior and actual consumer identity/check acceptance still need their separate hosted evidence in workflows #93. The first promotion does not close that acceptance tracker. Channel rollback affects future workflow execution; application rollback still selects an exact signed bundle and handles retained data independently.

External-service provisioning

Selected and source-prepared 2026-10-13; not provisioned. The owner requires reusable external-service IaC for all future applications, starting with Harbor. Private Homelab/terraform-modules#8 tracks caller-selected PostgreSQL database, login and runtime-secret mapping alongside the generic bucket/access-policy work. The owner reconfirmed on 2026-10-13 that backend/KMS, the dedicated PostgreSQL provisioning login, its OpenBao entry and Harbor dev resources are all unset. One private administrator bootstrap will create a dedicated non-superuser login; only that new provisioning credential needs to be stored in OpenBao. The existing administrator credential can remain outside both OpenBao and Forgejo CI. This one-time boundary does not authorize routine per-application manual database creation.

The prepared modules use ephemeral/write-only password paths and a saved OpenBao seed. A single runtime-record owner must compose database and object-store fields without competing writers. Database/role creation permissions remain powerful cluster capabilities; verify actual PostgreSQL version, grants and authentication before setup. Detailed public SQL, private credential entry and recovery steps belong in that repository's docs/postgresql.md.

Protected state/backend readiness, the shared engine's PostgreSQL resource profile, owning manual callers, scoped OIDC policies and hosted dev acceptance remain prerequisites. The released storage-only workflow cannot yet provision databases. Private Terraform PR #9 now avoids the pinned provider's revoke-before-grant membership path through a role-specific startup setting and adds a disposable PostgreSQL 18.6 provider regression inside the existing Terraform check. Local validation covers ten roots, 18 mocked tests and 14 Python tests. Hosted private Terraform run 36 then passed at ea60bc5bab2fd160e7255dd5d7bafe45db9f5272: two non-superuser applies with unchanged plans, retained ADMIN/SET ownership access, PUBLIC revokes, application schema writes and password-free state. The reviewer accepted the specific SQL-behavior fix; this does not establish Homelab bootstrap, OpenBao seed preservation or end-to-end database provisioning. Local schema/mocked checks are not live permission or persistence evidence. Application deployment continues through its own signed UDS delivery caller.

Security tool image

Selected 2026-10-11; image published and startup tested 2026-10-13. The dedicated security job image contains released workflows v1.33.0, commit d931629df1170ec8b141f98562474016addc778a, and its verified toolchain, allowing opted-in jobs to skip library checkout and tool installation. Private Homelab/base-images PR #40 merged and its pipeline published signed release tool-security-v2026.10.13-r6990 from source 30ac6cb5762abffe98f6f5b1101e2c716947c116. Its registry digest is sha256:67cb01038ac30c796e45c894db75689bc70ec1b750736a6f99beac457fd03cbc; the release retains source/image decisions, mitigations, SBOM and signed receipt. The owning definition and publication procedure remain in private Homelab/base-images, tools/security/README.md, tracked by #39.

The pinned Forgejo Runner v13.1.0 rejects a present pull-credentials map with empty values before any step starts. The correction in workflows PR #87, commit 15ebb699e2e8e01077cc5de65eb6d4b86163866d, restores all eight existing reusable entry points to reviewed main with no container override or pull-credentials map. Eight explicit preinstalled-* entry points require security_image_digest and authenticate only the fixed owned registry/image. Workflow names, job IDs, display names, outputs and operation/credential boundaries are preserved. The detailed workflow procedure is linked at that commit until merged.

Hosted compatibility run 587 passed both credential-free legacy startup and authenticated image startup on the actual runner at that commit. Image activation, offline tool smoke checks and embedded-provenance assertions passed; sanitized startup/runtime evidence was retained. Contract tests compare the fixtures with all eight production entry points. Hosted acceptance 585, source-security 586 and library 588 also passed. This proves the bounded startup paths; application source/image scans, bundle delivery, deployment compatibility, measured setup savings and caller adoption remain pending under workflows #86.

Workflow release published 2026-10-13: v1.34.0 at a805c195e2eba27e31e78ea3e083c74a4c85a176 contains the merged correction. Review each owning caller's paired workflow/library release pins, corresponding preinstalled-* path and accepted image digest. Accept signed image evidence with the existing signing public key, and scope the existing registry host/credential pair to that host. The wrappers verify the older embedded payload explicitly; build receipts retain its actual library commit. Runtime reports retain the separately patched toolchain versions and hashes. The existing reviewed Go OpenPGP mitigation keeps its exact image scope and expiry.

The image contains no credentials or cached scan decisions. Vulnerability databases, malware signatures and licensed Semgrep rules retain their runtime updates. The ci, deploy and deploy-k8s pools keep their credential boundaries, and the bootstrap pipeline remains independent. Roll back an adopted caller by selecting its original reusable entry point and removing the image input to restore checkout/installation, or select a previously accepted compatible digest. Never rewrite an immutable release. Reviewed caller adoption and application delivery acceptance remain pending; the initial Harbor adoption proposal is recorded in applications.

Local secret prevention

Selected and locally tested 2026-10-12 (owner direction). Homelab repositories must install a native Gitleaks pre-commit hook before their first commit. The reviewed hook pins Gitleaks 8.30.1, matching the shared workflow tool lock, scans staged changes with full redaction, and blocks findings, missing/wrong scanner versions and scanner errors. Its default-rule policy follows the combined CI gate: local config, ignore baselines and allow-comments cannot hide a new finding.

Retain the reviewed .githooks/ source files in each repository and run sh .githooks/install.sh from its root (Git Bash on Windows). The installer uses clone-local configuration and the shared Git directory so existing and future linked worktrees remain protected across branch changes. Preserve and integrate any existing hook/custom hooks path. New clones and template-derived repositories need their own installation; Git does not activate copied hooks. The bundle template includes the source files and setup step. Other new projects copy the reviewed directory from Homelab/workflows before committing.

The owning implementation and setup procedure are prepared for review in Homelab/workflows; repository copies contain the same installer. workflows #91 tracks repository adoption. The existing shared security policy records the CI scan policy. This records local installation and synthetic-fixture validation, not a merged repository rollout or a hosted CI result. Existing Forgejo source/history scans, schedules and required-check names continue unchanged; browser/automation commits and deliberately bypassed hooks still need those checks.

Documentation chart image build

Observed 2026-10-17: Documentation image run 337, attempt 1 stopped at source scanning because the v1.24.0 library's Semgrep rules checksum no longer matched upstream. No chart image was built or published by that run. The image caller now selects the reviewed stable-v1 channel with its default library binding; inspection selected v1.44.2, snapshot c010d2e350.

Image run 342, attempt 1 passed source scanning on 2026-10-17, then failed the image build's Markdown link check: README.md links to .githooks/README.md, which was absent from the build stage. The Dockerfile now copies that document before validation.

Published 2026-10-17: documentation-image-v0.0.1 records the chart image at git.gitchegumi.com/homelab/documentation@sha256:6ae179adf61bf21b224330eeb0cbee4ada47f4deab031da1426993c26087cc55, with signed scan evidence attached. The workload and Zarf package now select that same digest. This publication does not establish deployed rendering.

Bundle run 349 and run 350 failed before npm installation because inline Node setup tried to create the non-writable /opt/hostedtoolcache. The source and bundle validation callers now use the shared npm validator, preserving their existing npm commands and validate job/status names. Its writable-cache setup is present in promoted v1.44.5, snapshot dc4f42cecd. The paired bundle/deploy callers also select stable-v1 with the existing organization registry-secret bindings, production target and managed OIDC gates.

Owner-confirmed 2026-10-17: the chart correction was released and deployed; the owner spotted the incorrect Technitium label on the live chart. Browser inspection that day confirmed both SVGs load on the live architecture page. This supersedes the earlier pending-delivery status.

Chart content is linked to this repository's public media/branch/main SVGs, alongside Markdown fetched from reviewed main on each page request. Editing the Markdown or linked SVG and merging it updates the page after refresh, without an image build, bundle release or deployment. The existing renderer supports these absolute image URLs. Application code and layout changes still follow the signed release procedure in the README.

Release names

Selected by the owner 2026-09-27; implementation prepared for review. Every future image, bundle and recovery release must name its component and readable version, for example gitchauth-theme-v1, documentation-bundle-v1 or core-v1.13.1-r5850. Commit hashes, build-input hashes and image digests must not appear in release names or tags. Builds accept an unused operator-selected tag; automatic defaults also name the component and version. Deployment accepts that exact signed readable tag. Each new release needs a new tag.

Signed receipts continue to bind the exact source commit, image digest and artifact hashes, and additionally bind the readable release tag. Existing signed releases keep their original names and remain readable; renaming them would break their original evidence binding. The reusable implementation is workflows PR #64, proposed for v1.24.0. Review and publish that version before adopting paired publisher and deploy/evidence caller pins. Older pinned callers need a reviewed migration before their next release, including stable finding policy compatibility. The initial preparation did not establish a hosted named release. Platform run 4698 subsequently published a readable Core recovery release on 2026-09-27; its deployment was skipped (see Core maintenance below).

The accepted global Linux worker pools provide four ci slots and one deploy slot across Sager, OptiPlex and Media, scaling to zero. Windows workloads keep the Hyper-V runner. A runs-on: ci workflow is a build/scan job even if it publishes a registry artifact; it does not deploy to the cluster. The runner runbook is in private Homelab/platform.

Platform trigger policy prepared 2026-09-26, onboarding cadence revised by owner direction 2026-09-27: source security remains automatic on pull requests and main pushes, with its weekly and manual runs retained. Actual credential/onboarding/RBAC, registry trust, runner/controller/NVIDIA and Core delivery validation become manual suites to run when their components change. Existing image, Core delivery and PV provisioning workflows remain manual. Application onboarding is prepared for daily reconciliation at 11:23 UTC plus manual operations, replacing its five-minute schedule. New apps need a manual platform reconcile before their first deployment if they cannot wait for the daily pass; the managed credential consumer retains its six-minute registration wait. Existing deployment identities keep serving between passes. Certificate health retains its daily and manual checks; a platform push does not start onboarding. The source and review tracker are private Homelab/platform #63, .forgejo/workflows/*.yml and docs/workflow-triggers.md. The revised cadence takes effect after review and merge; hosted execution remains a separate verification step.

Forgejo Actions secrets hold CI credentials only, including signing, release-read and registry credentials. Use a dedicated registry writer for publication, a separate optional read identity for private image/package pulls, and scoped signing/release credentials. OpenBao/ESO holds application runtime secrets. OIDC-to-OpenBao issuance provides short-lived deployment credentials for accepted callers; check the issuer and permission tests in the owning app. Never put a standing shared cluster-admin kubeconfig or PAT value in this public repository.

Homelab-owned base and job images

The base-images publisher is manually dispatched from protected main, selecting an implemented image folder. Its Dockerfile/commit checks precede the source/build/full-image gate; the final image also receives ClamAV scanning. Published, signed PyTorch/CUDA and comfy-python bases are used by the accepted ComfyUI deployment, as recorded in applications. Publication and adoption are tracked separately for each base and consumer.

Ubuntu publication accepted 2026-10-06. The owner confirmed the Ubuntu foundation was built. The registry package and signed release in private Homelab/base-images agree on tag base-ubuntu-v2026.10.06-r6354, source commit 54eec707a9c505ab807239c80e66d44dad07d5b5 and published image git.gitchegumi.com/homelab/base-ubuntu@sha256:9d4616631eba8fad103ff4a45b019163630f635c6a4ba4a2e0ea3c9dc084de61. The publication evidence records passing source and full-image scans and a clean ClamAV scan with freshly updated signatures. This accepts the Ubuntu 26.04 LTS amd64 foundation in base-images #2; it does not establish that another image or runner already uses it. The Python and Node publication acceptance below completes base-images #3 and #4.

Python and Node publication accepted, 2026-10-10 (owner confirmation, registry packages and receipt-bound release decisions; private Homelab/base-images PR #35, issues #3/#4, merged source 57b92a1c30c0c9541b76ff3fe241250b43701764). The self-contained images/python and images/node definitions inherit the accepted Ubuntu digest. Python selects CPython 3.15.0 and the reviewed, updated pip 26.2.1+homelab.1 dependency set; Node selects 26.11.1 and npm 12.2.0+homelab.1. These are the newest stable Python/Node releases verified on that date against the official Python release and Node Current downloads. Both use verified upstream inputs, non-root defaults and separate build stages. Their hosted build-time smoke checks cover runtime versions, architecture, system CA trust and offline application packaging.

The registry packages agree with their release receipts. Downloaded source and full-image decisions match the receipt hashes; both gates pass with zero blocking findings, scanner errors or mitigations and fresh clean ClamAV scans. Signed receipts and SBOMs are retained with the releases. This review checked receipt-bound bytes and registry identity; it does not claim independent local cryptographic signature verification. Python retains 30 distinct non-blocking CVEs (28 Medium, 2 Low); Node retains 35 (33 Medium, 2 Low). Accepted scan gates do not mean zero remaining CVEs. No correction totals are inferred without a verified before/after baseline.

The definitions remove unused Pebble, update complete npm dependency packages and install Node's required libatomic1 without introducing mitigations. These accepted publications supersede the earlier candidate, missing-library and startup blockers. Both issues are closed and their Roadmap cards are Done; Ubuntu #2 remains closed/Done. The owning image READMEs record refresh, compatibility and rollback procedures. Consumer adoption remains a separate reviewed image/bundle change; publication does not establish an application rollout. The owner also directed closure of platform #56 and moved its meta card to Done for the initial image-family milestone. The operator subsequently closed runtime acceptance issue base-images #32 with its checklist complete and moved that card to Done. ComfyUI integration/timing stays with Comfy-UI #1.

Runner tool image direction selected 2026-10-06. The foundation is deliberately minimal and does not supply Node.js, Python, Git, CA certificates or Docker tools needed by existing jobs. The initially separate runner tool definitions had identical requirements and were consolidated to tools/main-runner in Homelab/base-images PR #30 on 2026-10-06. The shared image inherits the accepted Ubuntu digest. Its selected publication namespace is git.gitchegumi.com/homelab/tool-images/main-runner; source stays in base-images, and this OCI namespace requires no new source repository. The shared selected-context scan and namespace publication contract was released as workflows v1.30.0.

Main-runner publication verified 2026-10-07. The owner supplied package tool-main-runner-v2026.10.07-r6415; its stable signed evidence release and registry package agree on source c511ebfff4588e3c674fe0c41c37adbaa34c2dc2 and git.gitchegumi.com/homelab/tool-images/main-runner@sha256:6ea020b882475b23578c1c79e628bb7da86ce2966af3f87e7b958ace8656de4b. Both source and complete-image decisions pass, with clean freshly scanned ClamAV results and no scanner errors or malware warnings. Receipt-bound findings record 32 remaining CVEs (30 Medium, 2 Low), and the before/after dependency comparison records 29 corrected CVEs. The separate non-CVE GO-2026-5932 advisory is owner-approved as mitigated through 2026-11-06T00:00:00Z; it is neither corrected nor counted as a CVE.

All four release attachment hashes and the signature bundle's receipt message digest were checked. Independent public-key signature verification is not claimed by this documentation review. Platform acceptance must verify the signature against its trusted base-images public key, the exact image and current mitigation scope/expiry before candidate execution. The private base-images release and docs/security/main-runner.md retain the complete inventory, correction baseline and justification. This completes base-images #28; hosted compatibility and live adoption remain pending in platform #56.

Map both existing ci and deploy labels to that same main-runner digest only after the reviewed platform acceptance and delivery gates. Preserve their separate security pools, identities and permissions. Keep the runner daemon and its Docker-in-Docker service distinct from the container image used for a job.

Configuration and caller merged, 2026-10-07 (private Homelab/platform PR #99, source b46c3b74c817fc89aa871582032ede51582ad55e). Both Kubernetes pool labels and the validation override now select the published in-house digest in the merged source, with worker package/bundle 0.1.5. Platform's protected manual caller verifies job-image evidence, scans the actual packaged service digests, builds/signs/publishes a worker release and verifies its exact archive before UDS deployment. It includes target and required/forbidden permission checks and worker-resource postflight. Signing and deployment credentials remain in separate steps. Twenty-three offline regressions and repository renders passed; no hosted bundle build or live deployment is claimed.

Initial deployment correction merged, 2026-10-08 (private Homelab/platform PR #101, source fe2cf185bd7ebae05464c8424ee62b45de5038e4, merged main dc6c562acc6125a946126e205c627cc6dad108f0). The first signed worker deployment has no previous signed worker release to restore. The change makes rollback_release optional; leave it blank for first adoption. Any explicitly selected baseline still requires verified evidence matching both current pool images and the candidate service inventory. Retain the first accepted signed bundle for future recovery; no historical archive is a prerequisite. Thirty-six offline delivery/evidence/identity regressions and repository validation passed for this correction.

Privileged identity bootstrap, remaining variable configuration, initial registry pull and both-pool CI/dev compatibility remain pending. Platform run 4808 failed during job-image signature verification before bundle creation; its log did not expose Cosign's diagnostic. The operator confirmed an existing SIGNING_PUBLIC_KEY; the build step only supplied the separate base-images key setting. PR #101 uses only the existing SIGNING_PUBLIC_KEY for both platform and base-images receipts, reports verification errors and reuses CORE_DEPLOY_ACTORS. Run 4821 on 2026-10-08 verified the retained job-image signature with that key and passed the source scan, then stopped before service-image scanning because the caller omitted the registry hostname. The registry-host correction is prepared in platform PR #102, source 60617df303ea16559f29e90d3d9e2018126326d4: map the owner's existing organization REGISTRY_HOST to the shared scanner input alongside its credential pair. Thirty-seven offline regressions passed, including caller-to-scanner credential scope with mocked scanner commands; removing the mapping reproduced run 4821's exact exception. Fresh hosted service-image scans and bundle publication remain pending after merge. Existing accepted workers are not proven changed by source preparation. The owning runner identity runbook now includes the established k9s OpenBao pod shell procedure: prepare three public files locally, retain verified TLS and a private operator login, then install only the dedicated policy and role definitions with the container's native CLI. The role generator uses the existing Forgejo issuer at /api/actions. This OpenBao authorization does not deliver the Kubernetes service account/RBAC. At that checkpoint, the privileged bootstrap caller was missing; the later identity update below records its proposed replacement through the existing Core workflow. No live OpenBao writes or credential validation were established by the earlier source preparation. Detailed procedures remain in private Homelab/base-images and Homelab/platform docs/runner-job-images.md, tracked by base-images #28 and platform #56/PR #101.

Service-image ownership selected 2026-10-08 (owner direction; private base-images #32 and platform run 4826). After PR #102 merged, the caller reached the fresh upstream service-image gate. Main-runner's signed evidence passed; the runner and Docker-in-Docker services retained 185 blocking vulnerability occurrences and one configuration finding. Existing accepted main-runner mitigations apply to their recorded package/version/binary scope; they do not accept different service images or older dependencies.

Prepare two distinct Ubuntu-based tool contexts in base-images: forgejo-runner for the non-root one-job service and docker-engine for its private privileged daemon/runtime sidecar. Source stays under tools/; publication uses homelab/tool-images/ without a new repository. Prioritize fixed dependencies and omitted unnecessary plugins. The prepared engine update advances ocicrypt to its maintained OpenPGP implementation and rejects deprecated imports during build. Definitions and source checks are not complete-image acceptance.

The operator publishes each reviewed image through the owning base-images workflow after its existing shared required scan gate passes. Platform then pins the exact signed service releases, verifies their receipt/scan/mitigation evidence, updates the worker package/bundle together and validates both pools through its reviewed UDS pipeline. Preserve the last accepted signed bundle for recovery. Image publication, worker bundle publication and live deployment are separate milestones.

Publication verified 2026-10-08 (owner-supplied registry links and published base-images release assets). PR #33 is merged. The signed evidence releases tool-forgejo-runner-v2026.10.09-r6495 and tool-docker-engine-v2026.10.09-r6496 in private Homelab/base-images record passing full-image gates and clean ClamAV evidence. Their exact digests are recorded in platform status. Platform PR #103, merged at 7547d4a2f9fe299a96ae27d98258ac96f923c0bb, packages these two services in worker package/bundle 0.1.6, verifies their signed image receipts before building and again when consuming the retained bundle, and carries the existing reviewed Docker engine Go mitigation with its original paths/package/counts/expiry. Main-runner remains the shared CI/deploy job environment. The owning protected platform pipeline performs subsequent worker bundle build/sign/publication and deployment. Its main-branch docs/runner-job-images.md in private Homelab/platform is the durable operator reference; the 0.1.6 source is merged. Image publication is complete. Worker bundle publication and live deployment, including scoped identity setup, new jobs in both pools and cleanup, remain pending.

Identity bootstrap prepared, 2026-10-08 (private platform #104/PR #105, source b09aff22c7674665c092c701c5faf31bd1ab3531; run 4835 and operator diagnostic). Run 4835 passed OpenBao JWT login but Kubernetes denied openbao/openbao the TokenRequest permission for the runner deployment account. The operator confirmed that the forgejo-runner-deployer OpenBao engine role exists. That role alone cannot grant Kubernetes RBAC.

The proposed fix adds an image-free identity UDS package/bundle to platform's existing Build and deploy UDS Core caller, using its established Core OIDC role and deployment account. It installs only the scoped runner identity and permission bindings, including the issuer's TokenRequest binding. It does not build Core images or update Core workloads. The detailed durable procedure is private Homelab/platform's main-branch infrastructure/deployment/forgejo-runners/README.md.

After review and merge, the operator dispatches that existing Core workflow on main with deploy=runner-identity-build, then makes a fresh dispatch with deploy=runner-identity-deploy and recovery_release set to the exact signed identity release it published. Successful identity postflight is followed by Build and deploy Forgejo worker bundle, operation=credential-validate. Only after issuance and required/forbidden permission checks pass does the operator build and deploy the signed worker release through that same worker workflow. The first worker adoption leaves rollback_release blank. Keep the completed OpenBao setup; no additional OpenBao policy or provisioner role is needed for this path.

All 138 offline bootstrap/worker/Core regressions and repository source validation passed. Hosted build, identity deployment, fresh credential validation and both-pool runtime acceptance remain pending; platform #104 stays open until the identity is verified live.

Identity installation verified, 2026-10-09 (private platform run 4855, source a8fb5f89789ee3668cdebca5228db75214908eaf; retained deployment.json). The operator deployed signed identity release forgejo-runner-identity-bundle-v0.1.0-r6544 through UDS. Signature, hash, current-policy, reviewed-source and target preflight checks passed, followed by successful installation and verification of all 13 service-account/RBAC objects. This includes the existing OpenBao account's TokenRequest binding; the temporary Core OpenBao session was revoked afterward.

The next operator action is Build and deploy Forgejo worker bundle on current protected main with operation=credential-validate. Require fresh runner credential issuance and every required/forbidden permission probe to pass. Worker release forgejo-runners-bundle-v0.1.6-r6507 is already published from reviewed source 7547d4a2f9fe299a96ae27d98258ac96f923c0bb; its retained receipt and inventory select the in-house main-runner, forgejo-runner and docker-engine images. The later identity bootstrap leaves the worker bundle unchanged, and the deploy verifier accepts reviewed ancestor source commits. Use operation=deploy with release=forgejo-runners-bundle-v0.1.6-r6507 and leave the initial rollback_release blank. No rebuild is needed for the identity setup; deployment still rechecks signature, hashes, current mitigation policy and image release evidence. Platform #104 remains open until credential validation succeeds; worker image rollout and both-pool runtime acceptance remain pending in platform #56 and base-images #32.

Registry permission blocker, 2026-10-09 (private platform runs 4856/4857, source a8fb5f89789ee3668cdebca5228db75214908eaf). The original runner credential validation succeeded. The worker deployment verified the retained bundle and three image receipts and pushed the service images, then stopped at Zarf's Helm post-renderer because forgejo-runner-deployer cannot patch Secret private-registry in uds-policy-exemptions. Successful worker rollout and postflight are not established by that partial deployment.

The reviewed correction must deploy through a new, small identity bundle release (0.1.1), adding only a separate named-secret patch Role/RoleBinding. Follow the owning identity runbook to build/sign/publish that release with deploy=runner-identity-build, then install the exact tag with deploy=runner-identity-deploy and recovery_release=<identity release>. Revalidate credentials against the expanded required/forbidden contract. Finally deploy existing worker release forgejo-runners-bundle-v0.1.6-r6507 through its owning worker caller, with blank rollback_release and release_tag. No worker bundle rebuild or OpenBao role rewrite is needed for this RBAC correction. Review, identity publication/deployment and revised live credential acceptance remain pending under platform #104.

Worker deployment verified, 2026-10-10 (private platform runs 4863/4864/4865, workflow source 615a105e05b66b58953fcf248fbd8d69f7a80184). The operator deployed signed identity release forgejo-runner-identity-bundle-v0.1.1-r6562 through the existing Core caller. Its retained postflight verifies all 15 account/RBAC objects. Fresh worker credential validation then passed all 188 required and 22 forbidden permission probes, completing platform #104 and moving its Roadmap card to Done.

The worker caller subsequently verified and deployed retained release forgejo-runners-bundle-v0.1.6-r6507 from bundle source 7547d4a2f9fe299a96ae27d98258ac96f923c0bb. Worker postflight confirms both pool mappings and service templates select the three published in-house digests recorded in platform status. This completes the identity correction and bundle deployment described above; the existing worker release needed no rebuild or additional OpenBao setup.

The original deployment record left fresh CI/artifact retrieval, a fresh dev deployment, and worker cleanup/scale-to-zero pending. On 2026-10-10, the operator completed the checklist and closed base-images #32, moving its card to Done. This records operator acceptance; no new workload metrics were supplied in this documentation review. Installed image references alone do not establish successful new jobs. Keep forgejo-runners-bundle-v0.1.6-r6507 as the signed deployment baseline.

Startup recovered on rerun, 2026-10-10 (private base-images run 142 attempt 2; platform #55). The first attempts of runs 141/142/143 stopped with No such image for the configured main-runner digest. Run 142 attempt 2 then started that same image after 47s of setup and passed all definition checks in 3m7s. Its pull log still displays an empty username and git.***.com; that hostname is cosmetic masking, not a different registry address. The unmerged diagnostic proposal in platform PR #110 was not required for recovery. The original failure's cause is unconfirmed.

This verifies a successful job startup and source/definition validation at merged source 57b92a1c30c0c9541b76ff3fe241250b43701764. It does not build or scan the Python/Node images or establish artifact retrieval, dev deployment or worker cleanup. Complete those operations through the owning reviewed workflows and retain their separate evidence. The later accepted Python/Node publications are recorded above; platform #55 retains the intermittent-pull history in Backlog.

Renovate deployment identity

Selected and credential path verified 2026-10-02. Renovate uses the existing OpenBao issuance mode with a dedicated deployment service account, permission contract and roles. Its background CronJob does not use an HTTP gateway. This is an application-specific provisioning exception; the ordinary web-application reconciliation profile remains unchanged. No standing kubeconfig secret is required by the deployed application's deployment and operation callers.

The operator retains their OpenBao session and performs the reviewed initial authorization. Kubernetes provisioning runs through the protected platform Action; subsequent Renovate workflows obtain short-lived credentials. Validate both allowed and denied permissions before deploying a signed bundle. Source: private Homelab/platform issue #62, platform's infrastructure/deployment/renovate/README.md, and Renovate's docs/deployment-identity.md. Private Homelab/renovate run 73, job 1, attempt 1 verified OpenBao login, two-hour credential issuance, all 86 required and 21 forbidden permission checks, and target preflight. Its refreshed image scan blocked on two newly reported npm vulnerabilities before deployment, with zero scanner errors; malware and SBOM follow-ups were skipped. Source backports and two scoped, expiring mitigation records were then prepared for review in the owning repository (docs/security/renovate-npm-backports.md). At that checkpoint, hosted image validation, new signed image/bundle publication, live deployment and activation remained pending. New bundles must select a signed image release built from the current reviewed recipe; the existing release cannot inherit new mitigation evidence. Retire the old organization kubeconfig only after auditing remaining callers and accepting the replacement.

Deployment verified 2026-10-04 (private Homelab/renovate run 93, job 1, attempt 1). The protected Action installed signed release renovate-bundle-v0.1.0-r6133 after passing all 90 required and 33 forbidden permission checks. It verified the suspended CronJob, ESO-created bot credential readiness and the installed UDS egress policy. This supersedes run 73's deployment blocker. Its refreshed image gate passed with zero blockers, 170 reviewed mitigation occurrences and zero scanner errors. The signed image is renovate-patched-v2026.10.03-r6132; the bundle contains only Renovate and did not rebuild or redeploy Core.

Activation verified 2026-10-04 (owner acceptance and private Homelab/renovate run 103, job 0, attempt 1). Protected operations created extract/full dry-run Jobs in runs 95/96 and a one-off write Job in run 98. The owner recorded successful dry runs in platform #62 comment 4564 and accepted onboarding in comment 4616. The dependagumi onboarding PR #13 merged after source and image checks passed. Run 103 verified the signed image release and resumed the schedule using that acceptance. The bot subsequently created Dependency Dashboard #14. The committed manifest still defaults to suspend: true; the live schedule was explicitly enabled by the protected operation. A later bundle deployment deliberately suspends it again for review.

Platform #62 and Renovate #2 now record completed deployment and are in Done on the Roadmap. Renovate #15 retains the remaining evidence: representative user/private/new-repository access, a real lockfile-update PR and rerun behavior, manager coverage, scheduled Job/resource/overlap checks, tested failure alerts, token rotation and rollback. Dashboard #14 reports a GitHub-token lookup warning; that is tracked without assuming complete dependency-source coverage. Host-kernel applicability and deployed controls remain separate from image-header acceptance. The 168 header and two npm mitigation records require reassessment before 2026-10-31 00:00 UTC. The owning docs/renovate.md and docs/deployment-identity.md runbooks hold the detailed procedures.

Core maintenance caller

Installed versions, updated 2026-10-16: Core v1.13.1 and operator CLI v0.39.0 retain their owner-confirmed 2026-10-14 baseline. The owner's authenticated package list on 2026-10-16 confirms installed init v0.73.0, correcting the earlier v0.86.0 statement. Init v0.86.0 is the Core 1.14.1 upgrade target. Platform #128 merged that target and the Core Actions CLI 0.39.0 selector; the prepared follow-up explicitly deploys/upgrades init and verifies it afterward. Other pipeline pins and historical receipts keep their independently recorded tool versions. Merged source is not a new installed version. See platform versions.

Priority change, 2026-10-14 (owner direction); delivery status verified 2026-10-16: update the cluster first, then finish Harbor. Harbor is no longer a prerequisite. RKE2 upgrade packaging, owning callers, scoped OIDC/OpenBao credential/admission contracts and Core 1.14.1 source merged together in platform #128. Reusable RKE2 delivery was first published in workflows v1.40.0 and remains available through promoted v1.44.1, with separate privileged bootstrap, routine controller delivery and explicit Plan activation/pause. Deployment stages can be scheduled independently. Private Core inputs, remaining component builds/image scans and live upgrade acceptance remain pending; the bootstrap build and credential evidence is recorded below. Private platform #123 continues to track sequential minor upgrades to the latest stable target selected at implementation start; 1.14.1 is an intermediate step, not a version ceiling.

Recurring OpenBao policy/JWT/issuance-role setup uses the reusable Terraform module and protected owning caller merged in private Terraform #12. State bootstrap run 62 passed its initial private/versioned/default AES256 protection, encrypted readback and conditional-write checks. The owner installed the central plan/apply grants and scoped state keys after inspect run 64. Plan 72 and specifically approved apply 75 created/converged the eight original RKE2 OpenBao resources. Terraform #14 merged explicit self-revocation on all three RKE2 policies. Owner-authorized plan/apply 80/81 used promoted v1.42.2, applied only those three policy updates and reported no post-apply managed-resource changes. Storage evidence records the earlier guarded failures and current bounded acceptance.

Private platform build run 4972 published signed rke2-bootstrap-bundle-v0.1.0-r7501. Deployment run 4974 verified the release, obtained the bootstrap Kubernetes credential and passed five permission probes, then stopped before bootstrap deployment with an OpenBao cleanup HTTP 403. The original policies omitted self-revocation, and cleanup masked an earlier preflight error. The minimal policy correction is now applied/converged; workflows #109's error-preservation fix is promoted in v1.42.2. Kubernetes bootstrap acceptance, routine-role validation, bootstrap-login retirement, controller deployment, Core/RKE2 upgrades and full locking/recovery remain pending.

The owner-authorized bootstrap retry 4975 on 2026-10-15 reused that signed release with adoption disabled. Session revocation passed, exposing the original installed init guard: Preserve installed Zarf init 0.86.0. No bundle deployment occurred. The owner's package list on 2026-10-16 confirms the mismatch: installed init is 0.73.0, while 0.86.0 is the next Core target. Workflows #110 merged and publication 852 published v1.42.3, adding the exact initial Core 1.13.1/init 0.73.0 profile and safe version diagnostics. Promotion 854 selected it on stable-v1 with passing canary 7545. Platform #130 passed all five fresh head-bound checks (4982/4983/4984), received PorteGumi's approval, and the owner merged it on 2026-10-16 at ee5874e583e45ef5ef20025ef9aca2c4091dd8ba. Its signed inventory changes, so build/deploy a new owning bootstrap release; r7501 remains evidence for its old contract. Build 4988 passed and published signed rke2-bootstrap-bundle-v0.1.0-r7557 from the merged source under v1.42.3. Owner-authorized deployment 4989 used that exact tag with adoption disabled. Signature/source and credential checks passed, and init reported expected=0.73.0; observed=0.73.0. It stopped before adoption or bundle deployment because an unowned retained RKE2 resource needs explicit scoped adoption; session revocation succeeded. The log does not identify that object or verify its fields against source. Retained-resource review was the next gate at that checkpoint; no additional Terraform apply was needed. The following review and successful bootstrap deployment supersede the blocker. Detailed acceptance limits remain in storage evidence.

The later read-only inspection on 2026-10-16 identified five matching unowned cluster-scoped leftovers and 28 absent bootstrap objects. The released ownership checker passed for all 33 named objects with mutation disabled. The owner resumed the task through bootstrap completion. Private platform deployment 4992 passed on main using the same signed r7557 release with scoped adoption enabled. The namespace was created, matching retained objects adopted and exact archive deployed. Admission readiness, installed ownership, target checks and session revocation passed; init stayed 0.73.0. Current-state field and ownership guards remained active. Work stopped at bootstrap completion. Later private Platform credential checks 4993/4994 passed; Terraform plan/apply 86/87 retired only the temporary bootstrap JWT role/policy and converged. Controller build 4995 then stopped before publication at 26 image vulnerability occurrences. Private base-images PR 50 is merged and controller/helper releases tool-rke2-controller-v2026.10.16-r7589 / tool-kubectl-v2026.10.16-r7590 are published; their release pages and receipt fields were inspected on 2026-10-16. Workflows #111 and private Platform #131 are merged. Controller build 5004 published signed rke2-controller-bundle-v0.1.0-r7636. Deploy 5005 stopped at explicit adoption; deploy 5007 passed signature/source checks, fresh image scans with zero blocking findings, permissions and ownership, then failed during UDS archive deployment. The raw CLI error was not retained. Root cause, partial deployment and controller acceptance remain unverified. Plan build 5006 separately failed on 28 blocking findings in the Rancher upgrade image and published no bundle. No repeat bootstrap or Terraform setup is needed.

Workflows #114 is merged and released/promoted in v1.44.0, and private Platform #132 is merged. Blank release overrides select the newest compatible signed component build; a blank Plan controller override uses the controller already accepted on this cluster. Fresh controller deploy 5012 passed automatic selection, scans, 77 required/14 forbidden probes, init and ownership preflight, then UDS archive deployment failed with kubernetes_authorization. Session revocation passed. The denied operation and controller acceptance remain unverified. Workflows #115 is merged/promoted in v1.44.1. Fresh deploy 5015 on 2026-10-17 passed the same preflight and identified denied list access to uds.dev/exemptions in uds-policy-exemptions; session revocation passed. The pinned readiness informer needs list and watch. Workflows #116 and private Platform #133 prepare only those two namespaced reads and matching 79 required/14 forbidden probes. Terraform #16 prepares the existing temporary bootstrap login restoration. Review/release/promote the library, merge paired source, review/apply the temporary Terraform authorization, build/deploy a new signed bootstrap, verify routine credentials, retire the temporary login again and retry controller delivery. Every manual dispatch requires specific approval. The existing signed controller runtime bundle remains reusable; the old bootstrap archive lacks the Role update. No live correction or node upgrade is established. Detailed steps stay in the owning Platform runbook; the public delivery contract records the released selection boundaries. Node/Core upgrades remain pending. See storage evidence.

Owner-selected rollout order, 2026-10-16: first RKE2 1.36.5+rke2r1, then Core 1.14.1 plus init 0.86.0, Core 1.15.0, RKE2 1.37.1+rke2r1, RKE2 auto-update setup, Harbor deployment and image migration. The prepared Core correction accepts only the current/target init baseline, deploys init,gitchauth-config,core from the same signed 1.14.1 archive, and requires the exact target init version/components in postflight. Historical Core 1.13.1 delivery still excludes init. Later versions and auto updates remain planned.

The shared reusable-event fix from workflows #106 was promoted in v1.41.1 and is retained in v1.42.3. Private platform inspections 4969/4970/4971 at source 566e28aab888d547773b470d67c44c268912b458 supplied the exact workflow_call bindings merged in Terraform PR #13. Those diagnostics are distinct from run 4974's actual bootstrap login/issuance. Detailed steps remain in the private Terraform and platform runbooks, with the public workload identity delivery contract.

Fresh-build input check, 2026-10-15 (private platform run 4961, job 0, attempt 1): source scanning and OpenBao login/read succeeded, then the build guard rejected the saved bundle's historical Core 1.13.1 selection. No new bundle, signed publication or upgrade resulted. The operator must update the private bundle to the reviewed Core 1.14.1 inputs with target init v0.86.0 and preserved runtime configuration at the Core stage after the first RKE2 upgrade, then start a fresh owning verify-only run. Platform #129 merged the corrected docs/core-delivery.md instructions; the private payload remains operator-owned.

Selected/configured 2026-09-26 (owner setup and credential test; private Homelab/platform issue #47). Core's private operator-maintained config and bundle are stored as two YAML fields in OpenBao KV v2. The existing Forgejo JWT mount authenticates the protected platform manual workflow. Signing, release-read and registry credentials remain in Forgejo organization secrets. Temporary files supply runtime values; private values are excluded from Git, images, signed bundle archives and uploaded evidence.

The owner created the Core JWT role and confirmed that the existing Kubernetes secrets engine issued a credential for the dedicated Core service account. Core maintenance uses a two-hour token for an owner-approved cluster-admin identity because it manages CRDs, admission, shared networking and RBAC. Application identities remain separate. This verifies backend issuance; workflow Kubernetes issuance and live cluster acceptance are still pending.

The manual caller scans, builds, signs, retains a private recovery release and optionally deploys the same archive in one job. The operator selects verify-only or deploy; an unselected operation stops early, and the selected operation is logged before installing tools or scanning. Recovery verifies the retained signed bundle and reuses its signed scan reports by default, verifying artifact integrity and exact image coverage and re-evaluating current mitigation approvals and expiry. A fresh image scan is an optional manual selection; every new build still scans. Reused evidence retains its original date and cannot identify advisories published after that scan. There is no arbitrary age cutoff for the retained report; current verification and mitigation expiry still apply. The workflow depends on OpenBao availability, with no standing deployment token, alternate secret store or additional backup gate. Retained bundles reproduce software rather than database/storage data.

Recovery packaging, 2026-09-27 (private Homelab/platform issue #47, run 4708 and merged PR #79): The owner-supplied keycloak-0 inspection showed its configuration init container unable to pull the GitchAuth image from Zarf's local registry. The earlier signed Core bundle scanned GitchAuth but did not contain its image bytes. PR #79, merged that day, adds a small image-only Zarf package before Core in a three-package bundle and deploys both selected packages while preserving init. The earlier release cannot supply the missing image; recovery requires a new signed release and operator dispatch. The pod inspection did not establish the final state of run 4708 or the installed Core version. The later owner visual acceptance below records the deployed theme separately.

Historical delivery progress, 2026-09-27 (private Homelab/platform runs 4698 and 4699, job 0, attempt 1; issue #47). Run 4698 passed source/image scan gates, Core 1.13.1 Iron Bank bundle creation, signing and private recovery publication. Release core-v1.13.1-r5906 contains the signed bundle and scan evidence. Run 4699 verified a retained release and completed a fresh 29-image scan, but the deployment step was skipped. The job page does not establish the submitted checkbox value. At that checkpoint the installed Core record was 1.11.1; the current owner-confirmed version is recorded above. The earlier run records below describe prior blockers.

Verified progress 2026-09-26 (private Homelab/platform run 4439, job 0, attempt 1; issue #47). The hosted source scan, workflow OIDC login, private YAML read, bundle creation, archived image matching and signed GitchAuth evidence verification succeeded. The 35-image scan reported 765 blocking finding occurrences in upstream Core/init images, with no scanner errors or mitigations. GitchAuth passed its vulnerability, malware and SBOM gate. Signing, recovery publication and deployment were skipped; those stages and live maintenance acceptance remain pending.

Selected/prepared, updated 2026-09-27 (owner direction and private Homelab/platform run 4675; issue #47). The candidate is Core 1.13.1-registry1 (Iron Bank), using CLI 0.38.0 and preserving init v0.73.0, external-service configuration and TLS ownership. The owner selected Iron Bank after confirming Unicorn was unavailable to this account. Run 4675 matched 892 reviewed vulnerability occurrences and blocked on six configuration findings, with zero scanner errors. The owner subsequently accepted those six exact upstream findings through 2026-10-27. The policy/caller change is prepared for review; a fresh hosted run must complete the previously skipped malware/SBOM follow-ups and delivery gates. Signing, recovery publication and live upgrade acceptance remain pending. At that checkpoint the installed Core record was 1.11.1; the current owner-confirmed version is recorded above. See the upstream 1.13 release notes and 1.13.1 patch; detailed review and dispatch procedures remain in private Homelab/platform.

GitchAuth visual acceptance, 2026-09-28 (owner confirmation; private Homelab/platform#47 and Homelab/platform#84): The owner confirmed that the deployed theme, including its corrected dark charcoal background, works. The issue is closed and its Roadmap card is Done. The installed Core version and sign-in, MFA, reset and keyboard flows were not independently verified in this record. Earlier progress notes above retain their original dates.

The caller maintains the initialized Core baseline and preserves init. It checks the exact API/cluster/account, installed version/components and workload readiness. Detailed secret names, variables, dispatch and acceptance steps remain in private Homelab/platform's docs/core-delivery.md. Bundle creation does not establish a new Core deployment.

ComfyUI's selected update behavior is a weekly and manually triggerable check that skips unchanged upstream pins and publishes a signed candidate when there is a change. Forgejo issue watches/email provide ready/failure notification. Deployment stays manual; the owner chose direct-to-production routine updates after reviewing the candidate and backup. The private Homelab/Comfy-UI automatic-update runbook and issue #1 determine whether the current pin and end-to-end notice/publish path are accepted. A configured schedule is not proof a candidate was published.

Change and rollback discipline

• Review the exact source commit, image digest, signed bundle release and target environment; dispatch the owning repository's protected deployment Action with the immutable release tag and retain its validation record.
• Before DNS, public edge or per-host route changes, record current NAT/DNS/NPM values, expected new path, externally and internally observable tests, and the exact rollback. The admin VIP remains private.
• Before storage or app migration, take an application-consistent backup and test the needed restore path. Coordinate active writers; preserving the old workload does not make concurrent writes safe.
• For platform upgrades, compare live resource ownership before adopting Helm/Zarf resources. Keep the previous tested bundle and source of truth for rollback.
• A documentation PR records the date, source evidence, affected status and unresolved acceptance. Do not label prepared manifests as deployed.