🐝 Hive Advisory Report

[kubestellar-hive]

This issue collects advisory findings from Hive agents.

At lower ACMM levels, some agents work in advisory mode — they analyze code and post findings here but do not create issues or PRs. At higher levels, designated agents (e.g. quality) can open issues and PRs directly, while other agents remain advisory-only.

The governor posts periodic digest comments summarizing what advisory agents found.

Do not close this issue. It is a living document.

Common · issue pipeline

  ▶  triage     needs kind/ + area/ then /approve
  ·  discussing —
  ·  queued     —
  ·  claimed    —
  ·  done       —

area: —   priority: —
maintainer: set kind/ + area/ labels, then comment /approve
reporter: answer questions; add repro steps if a bug

[castrojo]

🐝 Advisory Digest — 2026-06-11 10:55 EDT

Automated code review findings from Hive agents. Each finding includes a file reference and suggested fix. This comment is updated periodically.

Findings: 720

Severity	Count
🔴 critical	16
🟠 high	203
🟡 medium	401
🔵 low	99
⚪ info	1

🔴 CRITICAL (16)

• [advisory] knuckle CI: headless ISO boot smoke failing on ALL active branches (7+ PRs blocked) ci-maintainer

  knuckle CI headless ISO boot smoke failing on all branches. Latest runs: 26980467867 (main, 19h ago) X at 'install coreos-installer' — curl 404 from GitHub releases URL. All 5 CI queue runs also failing. Only non-ISO checks pass (shellcheck, build+test, bats, coverage, govulncheck). coreos-installer download URL returns HTTP 404.

• [advisory] bluefin Generate Release workflow broken — workflow file error on testing branch ci-maintainer

  Generate Release workflow reports 'likely failed because of a workflow file issue' on both testing (run 27047596606) and feat/create-release (run 27047593582) branches. Release pipeline is blocked. Workflow file likely has a syntax error introduced recently.

• [ci-failure] bluefin + bluefin-lts: Promote testing to main startup_failure — workflow YAML error on testing branch Promote testing to main ci-maintainer

  Promote testing to main workflow now shows startup_failure (workflow YAML parse/config error) on both bluefin (run 27316364061, 2026-06-11T00:52) and bluefin-lts (run 27316360290, same time) on the testing branch. Both repos simultaneously broken. Previously was 'failure' (15+ consecutive runs since Jun 9). The ci/promote-squash-thin-caller PR branch lifecycle-caller.yml also failing with 0 jobs — likely source of regression. Releases from testing blocked on both repos.

• [advisory] bluefin-lts README bootc switch commands use ublue-os registry and wrong NVIDIA LTS tag guide

  Two bugs in the Images section: (1) All bootc switch commands reference ghcr.io/ublue-os/ instead of ghcr.io/projectbluefin/. (2) The 'LTS — NVIDIA' command uses :latest tag instead of :lts ('sudo bootc switch ghcr.io/ublue-os/bluefin-nvidia-open:latest') — users requesting LTS stability get the rolling latest image instead. Fix: update org to projectbluefin AND change :latest to :lts on the NVIDIA LTS line.

• [advisory] dakota-iso docs/r2-promotion.md contains hardcoded Cloudflare R2 credentials guide

  docs/r2-promotion.md rclone config example contains what appear to be real Cloudflare R2 credentials: access_key_id and secret_access_key are hex strings consistent with actual API keys, not placeholder values (compare: other example configs in the codebase use literal placeholder text like 'your-key-here'). The file also embeds the R2 account ID and endpoint URL. If these are real keys, they grant write access to the dakota ISO bucket. The file should use redacted placeholder values and instruct contributors to obtain credentials from the project maintainers or a password manager. Immediate key rotation recommended if real.

• [advisory] bootc-installer nvidia.py defaults untested — hardware detection path quality

  defaults/nvidia.py handles NVIDIA GPU detection and driver selection during install. Zero test coverage on hardware detection path that affects many users. Should mock hardware queries.

• [advisory] bootc-installer defaults/disk.py (1192 LOC) has zero test coverage quality

  defaults/disk.py is 1192 lines handling disk partitioning, filesystem selection, battery check, loopback setup — all untested. This is the most critical install path.

• [advisory] bootc-installer Builder class (utils/builder.py) has zero tests — complex logic with subprocess calls quality

  Builder.__load() uses subprocess.check_output with shell=True to evaluate display-conditions. It orchestrates all wizard step creation. Zero test coverage. Highest-risk untested module in bootc-installer. Needs mocking of subprocess, RecipeLoader, and GTK widgets to test.

• [advisory] BLOCKED: quality agent has no write access to projectbluefin repos quality
• [coverage-gap] luks-tpm2-autounlock handles disk encryption with no test validation system_files/shared/usr/bin/luks-tpm2-autounlock quality

  luks-tpm2-autounlock handles LUKS disk encryption via TPM2. Critical security-adjacent script with no tests. Logic for device discovery, PIN setup, and wipe operations is untested.

• [coverage-gap] rechunker-group-fix script untested — modifies /etc/gshadow system_files/shared/usr/bin/rechunker-group-fix quality

  rechunker-group-fix modifies /etc/gshadow by iterating /etc/group entries and appending missing shadow entries. This runs during boot via systemd. A bug here could lock out user groups or break authentication. Zero test coverage. High risk due to system-level impact.

• [coverage-gap] bluefin: 05-override-install.sh downloads binaries without unit test verification build_files/base/05-override-install.sh quality

  05-override-install.sh downloads starship binary with sha256 verification, configures firewalld, modifies sudoers. The sha256 verification logic and sed operations are testable. Priority 0 because it handles security-sensitive operations (sudoers modification, integrity verification).

• [advisory] bootc-installer: phone_companion.py reads unbounded POST body (OOM/DoS) and accepts arbitrary JSON keys into GLOBAL_CONFIG scanner

  (1) do_POST reads int(self.headers['Content-Length']) bytes with no upper bound — any device on the same LAN segment can send a multi-GB POST and OOM the installer process. (2) JSON body is deserialized and keys are merged into GLOBAL_CONFIG without a schema allowlist — an attacker can inject arbitrary configuration keys. (3) When openssl binary is absent the code falls back to HTTP, transmitting the installation password in clear text over the network.

• [bug] common#621: scan-image exit-code '1' on push kills entire build pipeline — one CVE advisory halts factory gh-621 scanner

  reusable-build.yml scan-image step sets exit-code to '1' on push events: exit-code=${{ github.event_name == 'pull_request' && '0' || '1' }}. Any upstream CVE advisory in Trivy's DB causes scan-image to exit 1 on a push build, killing the entire run — E2E never runs, release gate sees no green E2E, promote fails. Issue docs 55% bluefin build success rate and 10% promote success rate, all tracing to this gate. Fix: change exit-code to always '0', add a post-scan step to auto-file P0 issue when CRITICAL CVEs detected (SARIF still uploads to Security tab). PR actions#169/fix: update brewfiles with latest homebrew packages #173 address the downstream promote retry but not this root cause.

• [bug] common#619: reusable-promote and post-testing-e2e have zero retry — single transient failure stalls factory indefinitely gh-619 scanner

  Retry composite action exists (actions#155, deployed) but is adopted in only 1 common workflow and 3 dakota workflows. bluefin and bluefin-lts have 0 retry in any workflow. Cascade: transient DNF/network build fail → E2E skipped → release gate blocks → promote fails → factory stalls. Manual re-run required each time. Issue quotes 85% promote failure rate for bluefin. Actions#169 (add retry to E2E/promote) and actions#173 (stale gate re-dispatch) are open PRs directly addressing this, both needs-review.

• [bug] common#624: reusable-promote exits immediately on gate failure — no backoff, no E2E re-trigger, no diagnostic issue gh-624 scanner

  reusable-promote.yml gate job calls reusable-release-gate.yml; if gate says 'not ready' the promote workflow just fails — no retry, no backoff re-check, no re-trigger of E2E if stale, no auto-filed diagnostic issue. Combined with the scan-image cascade (common#621), promote success rate is ~10% for bluefin. PR actions#173 adds stale gate re-dispatch logic: if E2E coverage is >120 minutes old it re-dispatches post-testing-e2e and waits (up to 120-minute job timeout), retries gate check 3x with 600/1200/1800s intervals, auto-files P1 issue if all retries exhausted. Actions#173 is the correct fix and subsumes the simpler retry in actions#168.

🟠 HIGH (203)

• [advisory] Automated OS Factory Vision inception/scan-common brainstorm
• [advisory] OS Factory Constitution inception/scan-common brainstorm
• [advisory] CLI-Driven OS Provisioning inception/scan-common brainstorm
• [advisory] Automated and Reproducible OS Build Pipeline inception/scan-common brainstorm
• [advisory] Unit and Integration Test Coverage Requirement inception/scan-common brainstorm
• [advisory] website: sk-SK locale has 43 extra i18n keys blocking quality/tests-615 CI ci-maintainer

  PR quality/tests-615 CI failing consistently on every run (run IDs 26424783659 and 26423748642, ~45 min apart). Test src/tests/locales.test.ts:48 asserts sk-SK.json must not have keys absent from reference locale — but sk-SK has 43 extra keys including new sections ParallaxQuote, NewsTitle, Faq and many translation keys. The reference locale (likely en-US) has not yet received these keys, or sk-SK was updated ahead of the reference. Fix: either add the new keys to the reference locale first, or remove the extra keys from sk-SK.json until the reference is updated.

• [advisory] multi-repo: Node.js 20 actions deprecated — forced Node.js 24 migration deadline June 16 affects bootc-installer, documentation ci-maintainer

  Node.js 20 actions deprecated across multi-repo. Forced Node.js 24 migration deadline: 2026-06-16 (11 days from now). Affects: actions/checkout@v4, actions/setup-python@v5, actions/upload-artifact@v3 in bootc-installer, documentation (Copilot Setup Steps), bluefin, bluefin-lts. Node.js 20 removed from runner: 2026-09-16.

• [advisory] documentation: Generate Docs PDF failed twice in a row (2026-05-24 and 2026-05-31) ci-maintainer

  Generate Docs PDF now failed 3 consecutive scheduled runs: 2026-05-24 (run/25983788967 was last success), then failures on 2026-05-31 (26354436718), 2026-06-01 (26706076346). All fail in ~30s. Workflow runs on schedule. Root cause not yet determined — check Playwright/PDF generation deps or playwright config.

• [advisory] testsuite: Nightly Test Matrix 25/36 jobs failing — GNOME 50 across all bluefin/bazzite variants ci-maintainer

  26/47 GNOME 50 jobs failing as of 2026-06-05 nightly run #26995616788. Test matrix expanded (was 25/36), failures persist/grew. 4+ consecutive nightly failures Jun 2-5. All failing jobs are GNOME 50 across bluefin, bazzite, dakota, gnomeos variants.

• [advisory] testsuite: E2E — GNOME in QEMU workflow file issue — 5+ consecutive failures across branches ci-maintainer

  testsuite E2E — GNOME in QEMU workflow failing. Latest: run/26929611330 (2026-06-04, fix/e2e-enable-toolkit branch). Prior failures: 26884681785, 26859715339, 26859486390, 26859427520. Multiple fix branches attempted, all still failing.

• [advisory] knuckle: VM E2E failing — bunzip2 cache collision when Flatcar image cache hits ci-maintainer

  knuckle VM E2E failing daily. Latest: run/26980441336 (2026-06-04T21:23). Prior: 26919347926, 26917385078, 26916744730. Fails at Download Flatcar base image step. Blocking VM integration testing.

• [advisory] knuckle: CI coreos-installer download returns 404, blocking main merges ci-maintainer

  headless ISO boot smoke job downloads coreos-installer from https://github.com/coreos/coreos-installer/releases/latest/download/coreos-installer_amd64 — returns curl 404. Affects runs on main and merge queue (pr-744, 743, 741). Fix: pin to a specific release tag or mirror the binary.

• [advisory] bluefin: Next Images (sealed) rechunk failing on next branch — both bluefin and nvidia-open variants ci-maintainer

  Run 26990564509 on next branch (push from feat: add sealed image build path for next branch). 'Rechunk Image' step fails for both variants: image(main, bluefin, next, x86_64) and image(nvidia-open, bluefin, next, x86_64). Build steps (including SBOM generation) succeed; failure occurs specifically at rechunk. Could be rechunker OOM, API issue, or incompatibility with new next-branch sealed build path.

• [advisory] testsuite: Migration Test now failing on main branch (26992213122) ci-maintainer

  Migration Test — ublue-os → projectbluefin workflow now failing on main branch (run 26992213122, 2026-06-05). Previously only failing on feature branches (26856111755, 26855972529). Main branch failure blocks nightly integration and is an escalation from existing bead 1b5bdd7d-303.

• [advisory] knuckle: TestRealRunnerRunWithInputCancelMidWrite failing in Nightly Tests on main ci-maintainer

  TestRealRunnerRunWithInputCancelMidWrite failed in knuckle/internal/runner (run/26995477700, Jun 5 04:31Z). Single data point — race condition test. Next nightly ~04:30Z Jun 6 will confirm if persistent. Current priority lowered to medium pending recurrence.

• [advisory] bootc-installer: Flatpak dev build persistently failing — immutable release upload blocked ci-maintainer

  softprops/action-gh-release@v2 fails with: 'Cannot upload asset org.bootcinstaller.Installer.Devel.flatpak to an immutable release.' Release 'continuous-dev' is published/immutable. Fix: switch to draft:true for the continuous-dev prerelease, or delete and recreate the release. Failing on every push to dev branch.

• [advisory] bootc-installer: Build Multi-Variant Flatpaks failing on Build gnome variant — 10+ consecutive failures over 16h ci-maintainer

  Build Multi-Variant Flatpaks has failed on every run since at least 2026-06-04T22:08 UTC (10+ runs, all on dev branch). Job 'build-variants (gnome, org.bootcinstaller.Installer, flatpak/org.bootcinstaller.Installer.json)' fails at 'Build gnome variant' step. Flatpak workflow (devel) also had a separate failure at 'Publish dev pre-release' step.

• [advisory] bootc-installer Flatpak and Build Multi-Variant Flatpaks failing repeatedly — 4 failures today ci-maintainer

  bootc-installer flatpak.yml and build-flatpaks.yml both failing. 4 failures in last 10 flatpak.yml runs (14:38, 14:22, 13:28 today + prior). build-flatpaks.yml mirrors same pattern. Python and Go tests pass; failure is isolated to Flatpak build steps. Persistent across multiple PRs/pushes.

• [advisory] multi-repo: GNOME 50 E2E test failures systemic — testsuite, bluefin, bluefin-lts all affected ci-maintainer

  GNOME 50 breaking E2E tests across 3 repos: testsuite (25/36 Nightly Test Matrix jobs failing, all bluefin/bazzite variants), bluefin (Nightly E2E common+smoke failing), bluefin-lts (PR Validation E2E smoke failing on multiple PRs). Root cause: GNOME 50 compatibility with test framework. Upstream fix needed in testsuite shared test infra.

• [advisory] knuckle: Nightly Tests failing 5+ consecutive nights — escalated from single-failure bead ci-maintainer
• [advisory] bluefin: generate-release.yml failing on testing and feat/create-release — workflow file issue ci-maintainer

  generate-release.yml reports 'workflow file issue' on both testing and feat/create-release branches — 3 failures today (2026-06-06). Blocking PR feat(fastfetch): enhance color scheme with consistent Bluefin branding #359. Last success was backport/264-stable on 2026-06-02.

• [advisory] bootc-installer Build Multi-Variant Flatpaks persistent failure on dev — 5+ days ci-maintainer

  Build Multi-Variant Flatpaks has failed on every push to dev branch since at least 2026-06-04T23:04Z (5 consecutive failures, runs: 27021326572, 27020498850, 27017686234, 26985672115, 26984864235). Most recent run 27021326572. The related Flatpak workflow also fails on dev with 'Cannot upload asset to immutable release' — pre-release asset upload workflow design issue.

• [advisory] bootc-installer actions using Node.js 20 — forced upgrade deadline June 16 2026 ci-maintainer

  bootc-installer Flatpak workflow uses Node.js 20 actions (actions/checkout@v4, actions/upload-artifact@v4, softprops/action-gh-release@v2) that will be force-upgraded to Node.js 24 on June 16 2026 (11 days away). Actions will fail or behave unexpectedly if pinned versions don't support Node.js 24. Upgrade to latest versions of each action: actions/checkout@v4 → @v4.2.x or latest, similarly for upload-artifact and action-gh-release.

• [advisory] testsuite Nightly Test Matrix failing — bazzite-gnome:testing GNOME 50 bazzite job ci-maintainer

  Nightly Test Matrix in projectbluefin/testsuite fails consistently on main (runs 27033505216, 27029041413) and on fix/dbus-run-session-shim. Failing job: bazzite-gnome:testing / GNOME 50 — bazzite (job ID 79791548446). All other matrix jobs pass. Pattern suggests bazzite-gnome:testing image or the bazzite-specific GNOME 50 test is broken. Two cancelled runs (27032407917, 27032292250) preceded recent failures. Nightly matrix cancelled likely due to earlier test failures triggering re-runs.

• [advisory] testsuite: Nightly Test Matrix failing on main — 3 job types failing ci-maintainer

  Nightly Test Matrix on main failed 2026-06-05T18:43. 3 job failures: (1) bazzite-gnome:testing / GNOME 50 — bazzite: tests failed; (2) bluefin:lifecycle — upgrade & rollback lifecycle tests failed; (3) bluefin-gdx:stream10 / GNOME 50 — smoke: 'Load runner container into VM' step failed. Indicates both test failures and infrastructure issues in the runner VM setup.

• [advisory] testsuite: Nightly Test Matrix failing on main — 3 test categories ci-maintainer

  Nightly Test Matrix on main failed with 3 distinct test jobs: bazzite-gnome:testing GNOME 50 ('Fail job if tests failed'), bluefin lifecycle upgrade/rollback ghcr.io/ublue-os/bluefin:latest GNOME 50 ('Fail job if tests failed'), bluefin-gdx:stream10 GNOME 50 smoke ('Load runner container into VM'). Smoke infra issue or test regression on GNOME 50.

• [ci-failure] bluefin-lts: Build Bluefin LTS image failing on main — x86_64 testing variant Build Bluefin LTS ci-maintainer

  Run 27281136200 failed at 'Build bluefin-lts image / image (main, bluefin-lts, testing, x86_64)'. Other LTS variants (LTS HWE, GDX) succeeded in the same triggered batch. Prior run 27279793598 on main was success. Only the standard LTS x86_64 testing job is failing. Likely a transient build issue or a new regression introduced since the last successful main run.

• [ci-failure] bluefin + bluefin-lts: Scan image for vulnerabilities failing — 3 consecutive failures since 2026-06-10T22:09 Testing Images ci-maintainer

  Vulnerability scan failing across bluefin (Testing Images), bluefin-lts (Build LTS), and common (Build). Status as of 2026-06-11T14:34: bluefin/testing branch still not run since 01:16 failure; bluefin-lts still failing on main/testing/chore branches (chore/validate-scan-image-non-blocking PR exists — fix in progress); common Build failing on main (14:32, 14:34) but succeeding on some PR branches. Suggests CVE is in main branch base image. PR E2E also failing (Build common layer candidate). 7+ days blocking testing→main promotion pipeline.

• [ci-failure] dakota: Publish Bluefin dakota failing at Sign image and create attestation — 6 consecutive failures since 2026-06-10T21:28 Publish Bluefin dakota ci-maintainer

  dakota/Publish Bluefin dakota failing on 'Sign image and create attestation' step for both nvidia and default variants. 6 consecutive failures: runs 27305455335 (21:28), 27304482056 (21:07→21:28), 27307616231 (21:43), 27308932791 (22:40), 27313963560 (00:37), 27315208415 (01:19). Last success was 2026-06-10T16:26 (run 27287975904). Affects both publish (nvidia) and publish (default) jobs. Image attestation/signing pipeline broken — published images lack signatures.

• [ci-failure] common: e2e.yml startup_failure on all branches — 0 jobs, systemic workflow config break .github/workflows/e2e.yml ci-maintainer

  common/e2e.yml returning 0 jobs (startup_failure) on all branches and events since at least 2026-06-11T13:56. Affected runs: main/push (27354171510, 27354211907 region), PR branches (fix/lifecycle-caller-sha, fix/doc-link-pdf, docs/deprecate-housekeeping, fix/vscode-extensions-brewfile), merge queue (gh-readonly-queue/main/pr-543). 10+ consecutive failures. Workflow file has a YAML parse or configuration error. E2E coverage completely absent for common — no test gating on any PR or main push.

• [advisory] bootc-installer README and CLAUDE.md build steps omit git submodule init for fisherman guide

  README.md 'Building' section shows 'flatpak run org.flatpak.Builder ...' and 'meson setup build' but neither command is preceded by 'git submodule update --init --recursive'. fisherman/ is a git submodule (see .gitmodules: url=https://github.com/projectbluefin/fisherman.git). On a bare clone the fisherman/ directory is empty; the Flatpak manifest references fisherman/ source and the meson build links against fisherman binaries, so both build paths fail immediately with missing files. CLAUDE.md mentions 'fisherman that runs as a git submodule' but its Build commands section also omits the init step. Fix: prepend 'git submodule update --init --recursive' to both the Flatpak and Meson build steps in README.md and CLAUDE.md. File: README.md (Building section), CLAUDE.md (Build commands section).

• [advisory] website/tests/navbar-visual.mjs imports Playwright from hardcoded personal path /var/home/jorge/src/... guide

  tests/navbar-visual.mjs line 12: 'import { chromium } from "/var/home/jorge/src/documentation/node_modules/playwright/index.mjs"' — absolute path to a developer-specific local filesystem. CONTRIBUTING.md 'Testing' section (line ~80) instructs contributors to run 'node tests/navbar-visual.mjs' after any change to TopNavbar.vue. The test will fail with MODULE_NOT_FOUND for every contributor except the original author. Fix: replace the hardcoded import with 'import { chromium } from "playwright"' and add '@playwright/test' or 'playwright' to devDependencies in package.json, or add an 'npx playwright install chromium' prerequisite note.

• [advisory] bootc-installer README.md install URLs point to stale tuna-os/bootc-installer releases — will 404 for users guide
• [advisory] knuckle Justfile release-preflight has no CHANGELOG.md promotion step guide

  The release-preflight Justfile target (the canonical pre-release gate) runs catalog_check, nvidia_check, and ci but has no reminder to promote CHANGELOG.md [Unreleased] to a versioned entry before tagging. The docs/RELEASE.md file that previously held the release checklist no longer exists. v0.7.0 was previously tagged without a CHANGELOG update (documented in a now-closed bead). Without a prompt in release-preflight, the same mistake can recur. Should add an echo reminder: '- [ ] Promote CHANGELOG.md [Unreleased] to ## [vX.Y.Z] - YYYY-MM-DD and update compare links'.

• [advisory] bootc-installer README install commands reference tuna-os org instead of projectbluefin guide

  Both Production and Devel install curl commands in README point to github.com/tuna-os/bootc-installer releases. The repo lives at projectbluefin/bootc-installer. Users following the README get binaries from the wrong org.

• [advisory] contributing.md references stale ublue-os/bluefin GitHub repo guide

  Multiple places in contributing.md (lines 80, 181, 193, 203-204) link to https://github.com/ublue-os/bluefin and use git remote URLs pointing to ublue-os/bluefin.git. The project has migrated to projectbluefin/bluefin. First-time contributors following the fork/clone workflow will hit a 404 or clone the wrong repo.

• [advisory] local.md build instructions point to stale ublue-os/bluefin.git clone URL guide

  The git clone command in local.md uses https://github.com/ublue-os/bluefin.git — the old org. Should be https://github.com/projectbluefin/bluefin.git. Anyone following the local build guide will clone the wrong or non-existent repo and immediately fail.

• [advisory] administration.md uses stale ghcr.io/ublue-os/bluefin image paths throughout guide

  administration.md contains multiple bootc switch and skopeo commands using ghcr.io/ublue-os/bluefin (lines ~115, 118, 124, 137, 143, 149, 155, 161). Also references github.com/ublue-os/bluefin release notes and cosign.pub. If the image registry has migrated to ghcr.io/projectbluefin/bluefin, users running these commands will pull from the wrong or non-existent path.

• [advisory] testing-lab WORKFLOWS.md default image uses stale ghcr.io/ublue-os/bluefin org guide

  WORKFLOWS.md bluefin-qa-pipeline entry documents default image as 'ghcr.io/ublue-os/bluefin' — should be 'ghcr.io/projectbluefin/bluefin'. The actual argo/workflow-templates/bluefin-qa-pipeline.yaml also carries this stale default. Contributors copy examples from WORKFLOWS.md and pass the wrong image registry.

• [advisory] bluefin docs/ci.md post-testing-e2e section omits lifecycle upgrade-test gate added in PR feat: add Files to custom command menu #275 guide

  PR feat: add Files to custom command menu #275 wired a run-upgrade-test job into post-testing-e2e.yml (SHA bumped to 0527fe28 in PR Add sigstore verification for registry.access.redhat.com #276). The job calls projectbluefin/actions@0527fe28 with suites: lifecycle. The final gate job now needs: [e2e, run-e2e, run-upgrade-test] — all three must pass before post-testing-e2e completes. docs/ci.md step 2 says post-testing-e2e 'runs the smoke suite from projectbluefin/testsuite' — it no longer only runs smoke; it now also runs the lifecycle suite from projectbluefin/actions. The lifecycle upgrade-test is a new hard gate: if it fails, promotion cannot proceed. Contributors and maintainers diagnosing a stalled promotion need to know this gate exists and where it comes from (projectbluefin/actions, not testsuite). Update step 2 and add a note about the upgrade-test gate.

• [advisory] Ghost port scheme conflict: GHOST-LAB.md uses ports 2300-2315, PR-TEST-MATRIX.md uses 20000+PR# guide

  Two docs describe incompatible ghost port allocation schemes. GHOST-LAB.md line 139 says ports 2300-2315 (auto-allocated by script). PR-TEST-MATRIX.md line 33 says 'port = 20000 + PR_NUMBER' with examples like PR fix(bluefin, rebase-helper): re-enable rebase helper for bluefin LTS #170 → port 22170. These cannot both be correct. An agent following PR-TEST-MATRIX.md will collide with real sshd (port 22) or use ports that GHOST-LAB.md doesn't reserve. One scheme must be canonical; the other doc must be updated.

• [advisory] website CI workflow runs only unit tests — CONTRIBUTING.md-required lint and typecheck are not enforced guide

  ci.yml runs only 'npm ci' and 'npm run test:run --coverage'. CONTRIBUTING.md tells contributors to run 'npm run lint' and 'npm run typecheck' before PRs, but neither check is validated by CI. PRs with lint or type errors can merge without any automated gate.

• [advisory] bluefin CONTRIBUTING.md omits 2-human-approval gate required for production (:stable) promotion guide

  AGENTS.md documents: 'Production promotion (weekly-testing-promotion.yml) requires 2 distinct human approvals in the GitHub production Environment before :stable is updated. No agent may trigger, approve, or bypass this gate. Every admin bypass is permanently logged in Environment deployment history.' CONTRIBUTING.md Stream promotion section describes the weekly promotion workflow (smoke tests, e2e suite, fast-forward) but never mentions this mandatory 2-human-approval gate. Contributors who merge PRs into testing have no visibility into the security controls that govern whether their change reaches stable users.

• [advisory] bluefin docs/ci.md missing skill-drift.yml — undocumented PR-blocking check for skill/code sync guide

  .github/workflows/skill-drift.yml runs on every PR to main via projectbluefin/actions/.github/workflows/skill-drift-check.yml. It checks whether code paths (.github/workflows/, build_files/, Justfile, recipes/) have drifted from skill docs (docs/skills/, docs/*.md, AGENTS.md). A contributor whose PR touches build_files/ or Justfile without updating docs/skills/ will see an unexpected CI failure with no documentation explaining why or how to resolve it. docs/ci.md pipeline table lists 8 workflows but omits skill-drift.yml entirely. Fix: add skill-drift.yml row to the pipeline table explaining its trigger and resolution path (update docs/skills/ to match code changes).

• [advisory] knuckle AGENTS.md describes knuckle as Flatcar-only but FCOS support added via DispatchingInstaller and DispatchingClient guide

  AGENTS.md line 12 says 'A TUI installer for Flatcar Container Linux' and line 89 describes internal/install as 'flatcar-install orchestration via runner' and internal/bakery as 'sysext catalog + Flatcar release/SBOM fetchers'. But internal/model/model.go now defines OSFCOS='fcos' and FCOSUpdateStrategy constants (immediate, disabled for zincati). internal/install/dispatch.go introduces DispatchingInstaller that routes to FlatcarInstaller or FCOSInstaller based on cfg.OS. internal/bakery has DispatchingClient dispatching FetchCatalogForOS to Flatcar or FCOS bakery clients. Neither the repo description, package table, nor any instruction in AGENTS.md mentions FCOS, leaving contributors unaware of the dual-OS architecture. Fix: update AGENTS.md intro, package table descriptions for install and bakery, and add a note about the OS dispatch pattern.

• [advisory] bluefin README missing migration guide for users switching from ublue-os to projectbluefin images guide

  THEPATTERN.md explains projectbluefin/bluefin is a rebuilt fork of ublue-os/bluefin. Existing Bluefin users on ghcr.io/ublue-os/bluefin images have no documented path to migrate to ghcr.io/projectbluefin/bluefin. The README jumps straight to new installs without addressing current users. Add a migration section with a 'sudo bootc switch ghcr.io/projectbluefin/...' command, a note about the relationship between the two orgs, and what changes to expect.

• [advisory] bluefin-lts CONTRIBUTING.md missing LTS-specific stream, promotion, and build docs guide

  bluefin-lts CONTRIBUTING.md is only 1096 bytes and largely defers to docs.projectbluefin.io/contributing. It lacks: (1) LTS-specific stream model — how LTS tracks CentOS Stream vs Fedora, promotion cadence; (2) a build reference (no docs/build.md equivalent — bluefin mainline has docs/build.md with full tool table, repo layout, and dev loop); (3) what 'conservative, low-risk changes' means in practice for the CentOS Stream base; (4) guidance on when a change belongs in projectbluefin/common vs bluefin-lts. Contributors touching LTS have no build-level reference and must reverse-engineer from the Justfile.

• [advisory] docs/administration.md bootc switch and skopeo commands use stale ghcr.io/ublue-os registry — will fail for users guide

  administration.md lines 137, 143, 149, 155: 'sudo bootc switch ghcr.io/ublue-os/bluefin:*' commands point to stale registry. Line 161: 'skopeo inspect docker://ghcr.io/ublue-os/bluefin' also stale. Lines 115, 118, 124: descriptive example output shows ublue-os org. Line 328: 'cosign verify --key cosign.pub ghcr.io/ublue-os/bluefin' stale. These are copy-paste commands users run to switch streams or verify signatures — they will fail if images are no longer published to ublue-os. Existing bead 93ba6983-ad9 covers only static links (release notes, cosign.pub download). These are the ACTIONABLE commands. All ghcr.io/ublue-os/bluefin refs should be ghcr.io/projectbluefin/bluefin.

• [advisory] bluefin docs/ci.md: testing→main handoff undocumented — contributors cannot trace PR journey to image build guide

  docs/ci.md acknowledges the split: 'Contribution branch: PRs land on testing' vs 'Image promotion: main → latest/stable' but never documents the testing→main step. build-image-testing.yml triggers on push to main, pr-validation.yml runs on PRs to testing — no automation exists for testing→main and it is undocumented. Contributors who follow CONTRIBUTING.md submit PRs to testing but cannot understand how or when their change reaches a built image.

• [advisory] docs/local.md references wrong repo URL and stale build commands from ublue-os/bluefin guide

  docs/local.md clones from github.com/ublue-os/bluefin.git (wrong repo), uses 'just build bluefin' with positional args that don't match new format (should be 'just build bluefin latest main'), lists hwe/hwe-nvidia flavors that don't exist in projectbluefin/bluefin, and references ublue-os/devcontainer and ublue-os/forge. The entire page needs to be rewritten for projectbluefin/bluefin using docs/build.md as the authoritative reference.

• [advisory] bootc-installer README references tuna-os org and is not adapted for projectbluefin guide

  README.md title says 'BootcOS Installer', install commands pull from github.com/tuna-os/bootc-installer, and JSON recipe examples reference ghcr.io/tuna-os/ images. The repo was forked/imported into projectbluefin but README was not updated to reflect its role in the Bluefin ecosystem. Needs: updated title, Bluefin-specific install commands or clear framing as an upstream dependency, and a CONTRIBUTING pointer.

• [advisory] bootc-installer README omits XFCE and KDE variants — CI builds three variants, docs cover one guide

  .github/CI_CD_GUIDE.md documents three published Flatpak variants: org.bootcinstaller.Installer (GNOME), org.xfceinstaller.Installer (XFCE), org.kdeinstaller.Installer (KDE). The README's Installation section only shows the GNOME install commands with a tuna-os URL. XFCE and KDE variants are not mentioned, not linked, and have no install instructions. Users choosing a non-GNOME desktop environment have no discoverable install path.

• [advisory] bluefin-lts docs/skills/testlab.md hardcodes personal paths and maintainer name guide

  testlab.md PR test loop hardcodes ~/src/skills/ghost-testlab/scripts/titan-lts-setup.sh, ~/src/skills/dakota-testlab, ~/VMs/titans/image, ghost IP 192.168.1.102, and report header template hardcodes 'castrojo' as Guardian on Duty. Contributors cannot reproduce the setup or understand where ghost-testlab scripts live. Should genericize paths or document that ghost homelab is maintainer-only and provide CI-only alternative.

• [advisory] bootc-installer has no CONTRIBUTING.md — no contributor entry point guide

  No CONTRIBUTING.md exists at repo root. Contributing info is split between MULTI_VARIANT_BUILD.md and .github/CI_CD_GUIDE.md — not discoverable. New contributors have no clear on-ramp: no branch target, no validation steps, no PR checklist.

• [advisory] bootc-installer README references stale tuna-os org — install commands are broken guide

  README.md installation curl commands reference github.com/tuna-os/bootc-installer releases (not projectbluefin). Recipe examples use ghcr.io/tuna-os/yellowfin:gnome50 image reference. Project lives under projectbluefin org — these links likely produce 404s for users following the install guide.

• [advisory] bluefin-lts README references SECURITY.md which does not exist guide

  bluefin-lts README.md says 'Report security vulnerabilities via SECURITY.md' but SECURITY.md does not exist in the repo. projectbluefin/bluefin has a SECURITY.md (1682 bytes) that should be mirrored or linked.

• [advisory] bluefin AGENTS.md mandatory gates omit install-hooks.sh — pre-push guard not installed by agents guide

  AGENTS.md mandatory gates (line 62+) say 'Run just check && pre-commit run --all-files before every commit' but do not mention running 'bash .github/scripts/install-hooks.sh' first. PR #2bcb843 added install-hooks.sh which installs a pre-push hook blocking accidental pushes to 'origin' (ublue-os/bluefin). A documented incident on 2026-06-01 shows this push trap is active. Agents reading AGENTS.md will miss the hook installation step and remain vulnerable to the origin push trap. AGENTS.md mandatory gates should include: 'Run bash .github/scripts/install-hooks.sh once after cloning' as the first step.

• [advisory] bootc-installer: no CONTRIBUTING.md for human contributors guide

  Repo has README.md, AGENTS.md, and CLAUDE.md but no CONTRIBUTING.md. The README has partial contributor info (image catalog additions, building, dev loop) but no dedicated guide covering branch naming, PR etiquette, commit conventions (Conventional Commits), or test requirements. GitHub surfaces CONTRIBUTING.md prominently; its absence leaves human contributors without a clear entry point.

• [advisory] bluefin: CONTRIBUTING.md omits git remote trap (origin → ublue-os/bluefin) guide

  In this repo 'origin' points to ublue-os/bluefin (the forbidden external org). A bare 'git push' or 'git push origin' silently violates policy. This is called out prominently in docs/build.md (with a confirmed-incident warning dated 2026-06-01) and AGENTS.md, but CONTRIBUTING.md — the first file most contributors read — never mentions it. New contributors will reliably hit this trap before they reach docs/build.md. CONTRIBUTING.md should warn to always use 'git push projectbluefin ' and to run 'bash .github/scripts/install-hooks.sh' after cloning.

• [advisory] bootc-installer README install commands download from tuna-os org, not projectbluefin guide

  The Installing section curl commands point to github.com/tuna-os/bootc-installer/releases/download/... but the repo lives at projectbluefin/bootc-installer. Users following the README get redirected to the wrong/old org's releases. Should reference projectbluefin releases.

• [advisory] documentation/docs/contributing.md architecture links still point to ublue-os org for bluefin and bluefin-lts guide

  Contributing guide 'Images' section lists 'Bluefin stable: @ublue-os/bluefin' and 'Bluefin LTS @ublue-os/bluefin-lts' linking to the old org. Both repos have moved to projectbluefin/bluefin and projectbluefin/bluefin-lts. Contributors clicking these links land on the archived/old org.

• [advisory] bootc-installer repo missing human-contributor CONTRIBUTING.md guide

  bootc-installer has AGENTS.md and CLAUDE.md for AI agents but no CONTRIBUTING.md for human contributors. The repo has a detailed README and meson build system but no guidance on prerequisites, how to build locally, PR expectations, or code style.

• [advisory] No org-wide repo map explaining how all projectbluefin repos relate guide

  No document maps all 8 org repos to their roles: bluefin (main image), bluefin-lts (CentOS LTS), knuckle (Flatcar bare-metal installer), testsuite (GNOME e2e), documentation (Docusaurus site), website (marketing pages), bootc-installer (GNOME installer UI), dakota-iso (Dakota live ISO). New contributors have no entry point to understand what to work on and which repo serves which purpose. Should be added to docs.projectbluefin.io/contributing or a dedicated architecture page.

• [advisory] bluefin-lts README: LTS NVIDIA image tags reference :latest instead of :lts guide

  The bluefin-lts README Images section shows 'LTS — NVIDIA' install commands but uses :latest tag: 'ghcr.io/ublue-os/bluefin-nvidia-open:latest'. Same error for 'LTS — NVIDIA' under Bluefin DX LTS. Users following this guidance will land on the rolling :latest stream instead of LTS, defeating the purpose of choosing LTS.

• [advisory] bluefin-lts: SECURITY.md referenced in README but file does not exist guide

  README.md Contributing section says 'Report security vulnerabilities via SECURITY.md' but no SECURITY.md exists in projectbluefin/bluefin-lts. The main bluefin repo has a SECURITY.md. Contributors and users who click this link will hit a 404. A SECURITY.md should be added or the link should point to projectbluefin/bluefin/SECURITY.md.

• [advisory] bootc-installer: no CONTRIBUTING.md — PR workflow and branch conventions undocumented guide

  projectbluefin/bootc-installer has no CONTRIBUTING.md. The README covers building and image catalog contributions but does not document: which branch to target for PRs, commit message conventions, how to run the test suite before submitting, or the review/merge process. All peer repos (bluefin, bluefin-lts, documentation, dakota-iso, testsuite) have CONTRIBUTING.md files. New contributors to bootc-installer have no standardized entrypoint.

• [advisory] bootc-installer README: fisherman submodule not mentioned — 'Contributing Images' steps will fail without --recurse-submodules guide

  The 'Contributing Images' section instructs contributors to edit 'fisherman/data/images.json', but 'fisherman' is a git submodule (visible in .gitmodules and the root listing). A plain 'git clone' leaves the submodule empty; contributors must run 'git clone --recurse-submodules' or 'git submodule update --init'. Neither the README nor the 'Contributing Images' section mentions this. All image-catalog edits will fail with 'no such file' until the submodule is populated.

• [advisory] bootc-installer has no CONTRIBUTING.md for human contributors guide

  bootc-installer has AGENTS.md and CLAUDE.md for AI agents but no CONTRIBUTING.md for human contributors. Missing: branch workflow, PR target, build/test prereqs, commit conventions. Blocks first-time contributors.

• [advisory] bootc-installer missing CONTRIBUTING.md — no contributor onboarding path guide

  Repo has CLAUDE.md (AI-agent guidance only), .github/CI_CD_GUIDE.md (CI/CD ops reference), and MULTI_VARIANT_BUILD.md (variant builds), but no CONTRIBUTING.md for human contributors. New contributors have no documented path for: prerequisites, getting started, local build, submitting a PR, or commit conventions.

• [advisory] bootc-installer missing human-facing CONTRIBUTING.md guide

  Repo has AGENTS.md and CLAUDE.md (AI-agent-facing) and AGENTS.md but no CONTRIBUTING.md for human contributors. README documents building but has no contributor guide, issue filing process, PR expectations, or code style expectations. The only contributor-facing guidance lives inside CLAUDE.md which is intended for AI agents.

• [advisory] bootc-installer has no CONTRIBUTING.md — contributor workflow undocumented guide

  bootc-installer repo has CLAUDE.md (LLM-agent-only) and MULTI_VARIANT_BUILD.md but no CONTRIBUTING.md. Human contributors have no documented path for: forking, branch naming, PR process, commit conventions, or which branch to target. README has build commands but no contribution workflow. QUALIFY_SOFTWARE.sh and tests/integration/ exist but no contributor-facing doc explains how to run them or what they gate.

• [advisory] bluefin-lts README: NVIDIA LTS bootc switch commands use :latest tag instead of :lts guide

  Under 'Bluefin LTS > Images', the NVIDIA variants show '# LTS — NVIDIA' in the comment but reference :latest not :lts. Affected lines: 'sudo bootc switch ghcr.io/ublue-os/bluefin-nvidia-open:latest' (Bluefin LTS) and 'sudo bootc switch ghcr.io/ublue-os/bluefin-dx-nvidia-open:latest' (Bluefin DX LTS). Users following these commands will silently switch to the non-LTS rolling image instead of the LTS stream, defeating the purpose of choosing bluefin-lts. Should be :lts to match the non-NVIDIA commands on the same page.

• [advisory] bootc-installer has no CONTRIBUTING.md guide

  bootc-installer has MULTI_VARIANT_BUILD.md, CLAUDE.md, and a .github/CI_CD_GUIDE.md but no CONTRIBUTING.md. New contributors have no single entry point for: how to set up the dev environment, how to run tests, PR expectations, or code style. The QUALIFY_SOFTWARE.sh and run-dev.sh scripts are undiscoverable without documentation.

• [advisory] bootc-installer missing CONTRIBUTING.md — no human contributor onboarding guide guide

  The repo has AGENTS.md (AI agent guide) and CLAUDE.md (Claude-specific) but no CONTRIBUTING.md for human contributors. There is no guidance on prerequisites, local build setup (flatpak build, fisherman Go submodule), test workflow, or PR expectations. New contributors have no entry point.

• [advisory] bootc-installer README references tuna-os org — stale install URLs and image refs guide

  README Installation section points to https://github.com/tuna-os/bootc-installer/releases/... for both production and devel Flatpak downloads. Recipe examples use ghcr.io/tuna-os/yellowfin:gnome50 images. The project has migrated to projectbluefin org; these references should point to projectbluefin equivalents.

• [advisory] bootc-installer: missing CONTRIBUTING.md — no contributor entry point guide

  bootc-installer has no CONTRIBUTING.md. The repo accepts community contributions (image catalog PRs explicitly welcomed in README) but provides no contributor entry point: no setup steps, no PR workflow, no branch policy, no code style guidance. Contrast with dakota-iso, bluefin, and knuckle which all have CONTRIBUTING.md files.

• [advisory] bootc-installer missing CONTRIBUTING.md — no contributor workflow documented guide

  bootc-installer has no CONTRIBUTING.md. The README documents installation and building but there is no contributor onboarding: no branch target (dev vs prod), no PR process description, no commit conventions, no code review expectations. The only contributor-relevant prose is in the README's Building section and the hidden .github/CI_CD_GUIDE.md.

• [advisory] bluefin docs/skills/iso.md references non-existent projectbluefin/bluefin-iso — should be dakota-iso guide

  docs/skills/iso.md lines 5/17/38/43 reference projectbluefin/bluefin-iso in all ISO build/promote commands: 'gh workflow run build-iso-stable.yml --repo projectbluefin/bluefin-iso'. This repo does not exist in the org. The ISO repo is projectbluefin/dakota-iso. Agents following this skill will run failing gh CLI commands and won't find the correct build-iso.yml workflow.

• [advisory] bootc-installer: no CONTRIBUTING.md — contribution workflow undocumented guide

  No CONTRIBUTING.md exists. README.md:288-330 has a 'Contributing Images' section but covers only image submission, not general PR flow, branching, code style, or CI requirements. New contributors have no workflow guidance.

• [advisory] bootc-installer: CLAUDE.md has hardcoded personal dev path and stale app ID guide

  CLAUDE.md:75 hardcodes '/var/home/james/dev/bootc-installer' as a local path. CLAUDE.md:13,16,20 uses app ID 'org.bootcos.Installer' but README.md uses 'org.bootcinstaller.Installer'. Both issues mislead contributors and agents using this file as authoritative guidance.

• [advisory] bootc-installer: no CONTRIBUTING.md — only CLAUDE.md (agent-only) for contributor guidance guide

  No CONTRIBUTING.md exists in bootc-installer. CLAUDE.md covers build/run steps but is written for AI agents (Claude Code), not human contributors. Human contributors have no guide covering: PR workflow, branch targets, commit conventions, test expectations, or how to run the Flatpak build locally. README has a Recipe Format reference but no contributor workflow.

• [advisory] bootc-installer has no CONTRIBUTING.md — new contributors have no onboarding path guide

  No CONTRIBUTING.md exists in projectbluefin/bootc-installer. The repo has a README with recipe format and install commands, but nothing tells contributors how to build from source, run tests, open PRs, or understand the fisherman backend. Every other projectbluefin repo (bluefin, bluefin-lts, knuckle, testsuite, dakota-iso, documentation, website) has a CONTRIBUTING.md.

• [advisory] bootc-installer README download URLs point to tuna-os org, not projectbluefin guide

  README.md contains 9 references to 'tuna-os' including production and devel install curl commands (https://github.com/tuna-os/bootc-installer/releases/...) and example image refs (ghcr.io/tuna-os/yellowfin:gnome50). These URLs are unreachable for users installing from the projectbluefin org. The Dakota example at the bottom correctly uses ghcr.io/projectbluefin/dakota:latest, showing the migration was partial.

• [advisory] bootc-installer missing CONTRIBUTING.md — no PR workflow or contributor guide guide

  bootc-installer has no CONTRIBUTING.md. Build instructions exist in README (Flatpak/Meson sections) and CLAUDE.md, but there is no contributor guide covering PR workflow, branch naming, testing requirements, or how to run fisherman integration tests. New contributors have no single entry point for how to participate.

• [missing_security_gate_doc] dakota AGENTS.md does not document weekly-testing-promotion.yml 2-human-approval gate projectbluefin/dakota/AGENTS.md guide

  dakota AGENTS.md states 'Production promotion requires 2 distinct human approvals in the GitHub production Environment' and 'No agent may trigger, approve, or bypass this gate'. However docs/ci.md describes the weekly-testing-promotion.yml workflow in detail, including the manual stable promotion procedure, without restating the 2-human gate requirement. An agent or contributor reading only ci.md would miss this requirement. The gate count (2 approvals) and the production Environment reference should appear in ci.md as well as AGENTS.md.

• [stale_reference] bluefin CONTRIBUTING.md Stream promotion section cites wrong workflow name, stale schedule, and incorrect mechanism projectbluefin/bluefin/CONTRIBUTING.md#stream-promotion guide

  CONTRIBUTING.md says 'Every Tuesday at 06:00 UTC the weekly-testing-promotion workflow: 1) Verifies smoke e2e tests, 2) Runs full developer + vanilla-gnome e2e suite, 3) Fast-forwards latest and stable branches, 4) Triggers image builds.' Three errors: (1) Workflow is named promote-testing-to-main.yml not weekly-testing-promotion. (2) Schedule is daily at 23:00 UTC (cron: 0 23 * * *) not weekly on Tuesdays. (3) Mechanism is not an automatic fast-forward — it opens a PR against main that requires 2 projectbluefin/maintainers to merge, after which execute-release.yml handles promotion. Contributors following this doc will have a false mental model of the release pipeline.

• [missing_contributor_guide] projectbluefin/actions has no CONTRIBUTING.md — external contributors have no onboarding path CONTRIBUTING.md guide

  The projectbluefin/actions repo has a README, AGENTS.md, and docs/MAINTAINERS.md but no CONTRIBUTING.md. New external contributors who want to add or modify composite actions have no dedicated onboarding document that explains code style, PR expectations, or the consumer-validation gate. AGENTS.md targets agents; MAINTAINERS.md targets the four named maintainers. There is no document bridging first-time human contributors.

• [stale_reference] testsuite RUNBOOK.md Nightly CI job table uses stale ghcr.io/ublue-os image refs for all bluefin and bazzite jobs projectbluefin/testsuite:RUNBOOK.md#nightly-ci guide

  RUNBOOK.md lines 46-49: the Nightly CI job table lists bluefin:latest/gts/lts as ghcr.io/ublue-os/bluefin:{tag}, bluefin-dx as ghcr.io/ublue-os/bluefin-dx:{tag}, bluefin-nvidia-open as ghcr.io/ublue-os/bluefin-nvidia-open:latest, and bazzite-gnome as ghcr.io/ublue-os/bazzite-gnome:latest. After the org migration the production images live at ghcr.io/projectbluefin/. Operators following this runbook will pull old images and get incorrect nightly results.

• [missing_documentation] actions README.md Reusable Workflows table omits 8 of 10 reusable workflows projectbluefin/actions/README.md#reusable-workflows guide

  README.md lists only reusable-build.yml and reusable-release.yml. Eight more reusable workflows in .github/workflows/ are completely absent: reusable-execute-release.yml, reusable-promote.yml, reusable-promote-squash.yml, reusable-release-gate.yml, reusable-release-reminder.yml, reusable-renovate.yml, reusable-renovate-automerge.yml, reusable-sync-branches.yml. Consumers who rely on these for promotion, Renovate automerge, or branch-sync have no in-repo reference for inputs, required secrets, or expected behavior.

• [advisory] knuckle: headless ISO smoke CI fails — Flatcar PXE stable URL returns 404 quality
• [advisory] bluefin: 00-image-info.sh has no unit test — generates image-info.json and rewrites os-release quality

  00-image-info.sh writes /usr/share/ublue-os/image-info.json and rewrites /usr/lib/os-release with sed. Incorrect sed patterns silently produce broken os-release. High-value test target — can mock env vars (IMAGE_NAME, IMAGE_VENDOR etc) and validate JSON output + os-release format.

• [advisory] PR fix: adjust font size to match upstream #309 — install WriteIgnitionFile error paths (4 tests) quality
• [advisory] website CI does not run vitest — PR test(scripts): add bats coverage for ublue-image-info.sh #627 fixes quality

  deploy.yml builds but never runs vitest. ci.yml added in PR test(scripts): add bats coverage for ublue-image-info.sh #627 runs npm run test:run on push/PR/merge_group.

• [advisory] testing-lab: no unit-tests CI workflow for Python helpers quality

  testing-lab has only lint.yaml (Argo YAML linter). No unit-tests CI workflow exists. Python helpers (service_catalog/shared/kube.py, shared/wait_for_shell.py) have no automated unit test runs. These run in real cluster/VM context so unit-testable pure logic (env var defaults, path construction, JSON parsing) goes unvalidated.

• [advisory] bootc-installer: Builder class (builder.py) has no unit tests quality

  Builder.__load() walks recipe steps, evaluates display-conditions via shell commands, and registers widgets. This is the central wiring layer and has no unit tests. Errors in template-dispatch logic or display-condition evaluation would only surface in UI or integration tests.

• [advisory] testsuite: ssh_steps.py shared helper has no unit tests quality

  ssh_steps.py is imported by 8+ test suites. Contains run_ssh(), run_ssh_command(), vm_reachable_over_ssh(). test_shared.py only checks string presence of function names — does not test behavior.

• [advisory] testing-lab: kube.py shared helpers have no unit tests quality

  tests/service_catalog/shared/kube.py contains run_kubectl, require_kubectl, get_pods_json, restart_workload, first_pod_name, and http_get - all shared by homelab test suites - but has zero unit tests. Failures in these helpers will silently corrupt test results.

• [advisory] dakota-iso: shell scripts lack shellcheck CI linting quality

  dakota-iso has 5+ shell scripts (build-iso.sh, configure-live.sh, install-flatpaks.sh, show-screenshot.sh, dracut modules) with no shellcheck linting in CI. These scripts handle critical ISO build and boot logic.

• [advisory] tui/tui.go: 158 uncovered stmts — Update/handleKey/startInstall paths quality
• [advisory] dakota-iso: configure-live.sh (383 lines) has zero test coverage quality
• [advisory] Probe resolveByIDPath success path untested (disk identity) quality

  resolveByIDPath success path (symlink iteration+matching) untested. Safety-critical: determines which disk path is shown to user and stored in config. Regression could cause install to wrong disk.

• [advisory] bluefin-lts: pr-testsuite E2E smoke consistently failing — VM never boots quality
• [advisory] documentation: Deploy broken — package-lock.json missing search-insights@2.17.3 quality

  npm ci fails: package-lock.json out of sync with package.json, missing search-insights@2.17.3. Needs npm install to regenerate lockfile.

• [advisory] bootc-installer coverage at 28% threshold — key modules untested quality

  bootc-installer CI only enforces 28% coverage. 25+ source modules have zero unit tests including defaults/keyboard.py, defaults/timezone.py, layouts/, windows/, and views/. This represents significant untested installer logic.

• [advisory] bootc-installer utils/builder and utils/finals have no unit tests quality

  utils/builder.py and utils/finals.py contain install orchestration logic with no tests. builder.py constructs install commands; finals.py handles post-install cleanup. Both are critical paths.

• [advisory] dakota-iso luks-unlock.py has 11 functions with thin test coverage quality

  luks-unlock.py has 11 functions (virsh_screenshot_size, virsh_send_passphrase, qemu_screendump, etc.) with only one test file. Functions dealing with LUKS passphrase entry and VM interaction need error path testing.

• [advisory] dakota-iso: build-iso.sh and configure-live.sh have no test coverage quality

  build-iso.sh (221 lines) and configure-live.sh (382 lines) are critical scripts that handle ISO build, LUKS setup, dracut integration, and live-environment config. Only luks-unlock.py has unit tests. These scripts handle error-prone operations (partitioning, bootloader install, encryption) with no validation beyond the E2E test.

• [advisory] bootc-installer: 26 modules lack unit tests (28% coverage gate) quality

  bootc-installer has 115 Python source files but only 28% coverage gate. 26 modules have no corresponding unit test including: defaults/nvidia, defaults/vm, utils/builder, utils/finals, utils/phone_companion, views/confirm_data, views/tour, widgets/page_header, windows/dialog*, layouts/preferences, layouts/yes_no. These include encryption handling and hardware detection code.

• [advisory] bootc-installer: utils/builder.py (core wizard orchestration) has no unit tests quality

  builder.py orchestrates the entire installer wizard flow (widget registration, step loading from recipe). Zero test coverage for a module that is central to the user experience.

• [advisory] testing-lab: no pytest CI workflow — 34 test files never run in CI quality

  testing-lab has 34 Python test files across tests/ but only a lint.yaml CI workflow that checks Argo template syntax. No pytest or behave runner in CI. Tests are effectively dead code.

• [advisory] testing-lab: No CI workflow validates Python test code quality

  testing-lab has 30+ Python test files across tests/ but no CI workflow validates syntax, imports, or correctness. Only lint.yaml exists (Argo YAML lint). Tests use dogtail/SSH and run in VMs, but a basic pytest --collect-only or pyflakes check would catch broken imports/syntax before VM execution.

• [advisory] bootc-installer coverage threshold at 28% — regression risk quality

  bootc-installer CI coverage gate is --cov-fail-under=28 (28%). With 74 source modules and only ~29 test files, many critical modules (nvidia defaults, disk encryption, builder utils) could regress silently.

• [advisory] bootc-installer utils/builder, utils/finals, utils/phone_companion lack unit tests quality

  bootc_installer/utils/builder.py, utils/finals.py, and utils/phone_companion.py contain logic with no corresponding unit tests. builder.py likely handles install recipe construction — high regression risk.

• [advisory] testing-lab: No CI test runner workflow quality

  testing-lab has test files (tests/developer/, tests/smoke/, tests/system/) but only a lint.yaml CI workflow - no test runner. Tests never execute in CI.

• [advisory] bootc-installer: Coverage threshold at 28% with 39 untested modules quality

  Coverage threshold is only 28% (--cov-fail-under=28). 39 of 64 source modules have no matching test file. Key untested: utils/builder.py (core wizard logic), defaults/nvidia.py, defaults/timezone.py, layouts/, windows/*

• [advisory] knuckle CI has no coverage gate or reporting quality
• [advisory] knuckle internal/validate package has zero test coverage quality

  The validate package contains pure-logic input validation (hostname, IP, username, timezone, auth keys) with zero tests. These functions are highly testable table-driven candidates and protect against malformed user input.

• [advisory] knuckle CI has no coverage gate or coverage reporting quality

  knuckle CI runs go test -race but does not generate coverage profiles, report coverage %, or gate on a minimum threshold. Coverage regressions go undetected.

• [advisory] bootc-installer: phone_companion.py has zero test coverage quality
• [advisory] bootc-installer coverage gate is 28% — well below useful quality

  Coverage gate is --cov-fail-under=28. This is too low to catch regressions. Should incrementally raise to 40+ as tests are added.

• [advisory] bootc-installer defaults/ modules lack unit tests (nvidia, theme, timezone, vm, language, keyboard) quality

  Multiple defaults/ modules have zero dedicated tests: nvidia.py, theme.py, timezone.py, vm.py, language.py, keyboard.py. Also utils/builder.py, utils/finals.py, utils/phone_companion.py untested.

• [advisory] bootc-installer: 6 defaults modules have zero unit tests quality

  Six defaults modules (keyboard, language, nvidia, theme, timezone, vm) have zero unit test coverage. nvidia.py is highest risk as GPU detection logic directly impacts install UX.

• [advisory] bootc-installer: utils/builder.py and utils/finals.py untested quality

  utils/builder.py (install flow orchestration), utils/finals.py (post-install actions), and utils/phone_companion.py have no tests. builder and finals are on the critical install path.

• [advisory] bootc-installer CI coverage gate is only 28% — should be raised quality

  python-test.yml sets --cov-fail-under=28. With 28 untested modules this gate is too low to catch regressions.

• [advisory] bootc-installer defaults/user.py user-creation logic untested quality

  User validation, password strength, username suggestion logic in defaults/user.py (185 LOC) — testable without GTK.

• [advisory] Coverage scan: bootc-installer 28% gate, testsuite step gaps, PR blocked by perms quality

  Scan identified 39/64 untested modules in bootc-installer (28% gate), 10+ untested step definitions in testsuite (65% gate). Filed issues Apply new labels to ublue-os/bluefin #140 (bootc-installer) and Action Required: Fix Renovate Configuration #293 (testsuite). PR with test code prepared but could not push — token lacks write access.

• [advisory] bootc-installer unit test coverage floor at 39% quality

  CI floor is 39%. 19+ modules lack unit tests. Recommend incremental raise to 45%.

• [advisory] bluefin shell build scripts lack bats tests beyond package-lib.sh quality

  Only package-lib.sh has bats tests. copr-helpers.sh, validate-repos.sh, disable-repos.sh untested.

• [advisory] TestFetchKeys_RealUser fails without network — needs integration build tag quality

  TestFetchKeys_RealUser makes live HTTP call to github.com without //go:build integration tag. Fails in environments without direct TLS (x509 cert error). testing.Short() guard is insufficient — CI runs without -short. Should use integration build tag like other network tests in the repo.

• [advisory] bootc-installer missing codecov integration and low coverage threshold (39%) quality
• [advisory] bootc-installer Builder class (utils/builder.py) has zero unit test coverage quality
• [advisory] bootc-installer utils/finals.py and utils/phone_companion.py have zero test coverage quality

  utils/finals.py is a pure-logic module (no GTK deps) with _extract_icon_and_name() that has zero tests. utils/phone_companion.py has get_local_ip(), CompanionServer, HTTP handler logic - all testable with mocking, but zero tests exist. These are high-impact: phone_companion handles user credentials over HTTP.

• [advisory] bootc-installer utils/builder.py has zero test coverage quality

  Builder class orchestrates the entire installation flow (recipe loading, widget creation, display-condition evaluation, finals collection). No unit tests exist. Subprocess calls and display-condition logic are particularly risky without tests.

• [advisory] bootc-installer utils/builder.py has no unit tests quality

  Builder class orchestrates the entire install wizard. It loads recipe, creates widgets, evaluates display-conditions via subprocess, and collects finals. No unit tests exist. Key testable logic: template lookup, display-condition evaluation, get_finals() aggregation, distro_info property.

• [advisory] bootc-installer coverage at 42% — views/windows/widgets untested quality

  42% unit coverage gate. views/, windows/, widgets/, layouts/, kde/ modules have no unit tests. These contain critical install flow logic.

• [advisory] bootc-installer coverage at 47% — utils/builder.py, views, windows untested quality

  bootc-installer overall coverage is 47%. High-impact untested modules: utils/builder.py (orchestrates wizard step loading), utils/finals.py, views/confirm_data.py, windows/ dialogs, defaults/nvidia.py. Builder has complex subprocess logic and display-condition evaluation that could silently break.

• [advisory] bootc-installer pure-logic modules confirm_data.py and finals.py have zero tests quality

  UPDATED: finals.py already has tests (test_finals.py). confirm_data.py still has zero tests. Issue Lets add mise to development #169 filed with complete test implementation (9 tests covering _ENC_LABELS and _SENNA_QUOTES).

---

⚠️ Digest truncated: 352548 → 65292 characters (GitHub limit: 65536)