🐝 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.

[castrojo]

🐝 Advisory Digest — 2026-08-20 17:07 EDT

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

Findings: 10

💡 Showing top 10 findings (by severity). 672 more exist. Set governor.advisory.show_all: true to see all.

Severity	Count
🔴 critical	10

🔴 CRITICAL (10)

• [advisory] :testing promotion gate has no circuit breaker: single flaky AT-SPI test blocks entire pipeline for 46+ days projectbluefin/bluefin#989 architect
• [advisory] finpilot: main promotion startup and image build failures finpilot/31892746048,31892801904,31892745630,issue#256 ci-maintainer
• [advisory] dakota-iso: Bluefin Live ISO boot verification fails repeatedly on main dakota-iso/31866113735,31870620952,issue#131 ci-maintainer
• [advisory] ci-maintainer: GitHub App token delivery unreadable; CI sweep blocked gh-auth-token-delivery ci-maintainer
• [advisory] dakota-iso: Bluefin Live ISO UEFI smoke boot cannot mount iso9660 dakota-iso/31150876357 ci-maintainer
• [coverage-gap] bluefin-lts#483: kernel-swap.sh 16 BATS tests + 2 set -e bug fixes (hold-gated PR open) tests/unit/kernel_swap_test.bats (reported 2×) quality

  16 tests covering: happy path, version detection, tsflags=noscripts, depmod+dracut, versionlock, dracut.conf.d lifecycle, fc vs el microcode config, missing RPMs error path, HWE skopeo/akmods/cleanup, Fedora version fallback. Two script bugs fixed: CACHED_VERSION and FEDORA_VERSION assignments unreachable fallbacks under set -e.

• [coverage-gap] bluefin-lts#359: kernel-swap.sh lacks BATS coverage — critical kernel install path untested build_scripts/scripts/kernel-swap.sh quality

  kernel-swap.sh: RPM removal, version detection, kernel install with noscripts, depmod/dracut, HWE akmods via skopeo, versionlock. Silent failure here bricks the image. Need tests with stubs for rpm/dnf/depmod/dracut/skopeo/ghcurl/jq/tar.

• [bug] dakota#981: dakota:next not upgrading — bootc upgrade may be referencing wrong registry target gh-dakota-981 scanner

  Issue labeled 3-human-queue indicating manual investigation needed. 'next' stream users on Dakota report no upgrades available. Possible causes: (1) next tag not publishing in CI, (2) bootc pinned to a digest that has no updates, (3) FSDK source junction not advancing. Dakota FSDK versioning was recently realigned (PR #1238) which may affect next-branch publish logic.

• [security] common/PR: ujust shellenv eval lacks input validation #902 scanner

  ujust fzf bootstrap uses eval on Homebrew shellenv output without validation. Malicious shellenv could execute arbitrary commands.

• [security] dakota#1182: pr-triage.yml uses pull_request_target with contents permission — token leakage risk #1182 scanner

  Workflow uses pull_request_target trigger which runs in the base repo context, combined with contents: write permission. This allows a forked PR to access and modify base repo secrets and code. In pull_request_target context, GITHUB_TOKEN has access to base repo data. If the workflow runs untrusted code from the PR (e.g., calling scripts), attackers can exfil secrets or push code. Impact: GitHub token and repo secrets leakage.

✅ Recently Resolved (2)

• actions: ghcr-cleanup.yml missing actions/checkout before local action — root cause confirmed actions/ghcr-cleanup.yml ci-maintainer — resolved Aug 19
• Dakota feat(factory): add cliff.toml to image repos for structured changelogs #609 already has Bluespeed probe and shared Bazaar hooks #609 scanner — resolved Aug 19

[castrojo]

🐝 Advisory Digest — 2026-06-23 11:38 EDT

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

Findings: 924

Severity	Count
🔴 critical	26
🟠 high	260
🟡 medium	508
🔵 low	129
⚪ info	1

🔴 CRITICAL (26)

• [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] 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).

• [coverage-gap] actions: No tests for resolve_digests.sh and verify_signatures.sh (release security) scripts/verify_signatures.sh quality

  scripts/resolve_digests.sh (52 lines) resolves OCI image tags to SHA digests via skopeo. scripts/verify_signatures.sh (75 lines) verifies cosign signatures on resolved digests. Both are critical to the release gate pipeline — a bug could allow unsigned/tampered images through. The actions repo already has bats tests for other scripts (generate_tags, retry, release_gate, check_token_health) showing the pattern exists.

• [coverage-gap] Release-gate scripts (resolve_digests.sh, verify_signatures.sh) have no unit tests scripts/resolve_digests.sh quality

  FALSE POSITIVE - tests already exist at tests/bats/test_release_gate.bats with comprehensive mocked coverage. Issue PassKey support on OS level #192 filed incorrectly - needs human closure.

• [coverage-gap] verify_signatures.sh has no unit tests (security-critical) projectbluefin/actions/scripts/verify_signatures.sh quality

  verify_signatures.sh validates cosign signatures for container images - a security-critical path with no test coverage. A malicious bypass would go undetected.

• [coverage-gap] resolve_digests.sh has no unit tests (supply-chain critical) projectbluefin/actions/scripts/resolve_digests.sh quality

  resolve_digests.sh resolves image tags to immutable digests for release pinning - supply-chain critical with no tests.

• [coverage-gap] dakota repo has zero test coverage projectbluefin/dakota quality

  Dakota repo has zero test files. The 193-line gen-filemap.py script has no unit tests. No CI test workflow exists. This is a complete blind spot.

• [missing-workflow] bluefin bats tests exist but are not run in CI projectbluefin/bluefin:tests/unit quality

  bluefin repo has 8 bats test files in tests/unit/ (17-cleanup_test, 18-workarounds_test, 19-initramfs_test, clean-stage_test, copr-helpers_test, disable-repos_test, package-lib_test, validate-repos_test) but NO unit-tests workflow in .github/workflows/. These tests never run automatically. A unit-tests.yml workflow should be added.

• [coverage-gap] bluefin: 04-install-kernel-akmods.sh (188 lines) has no unit test build_files/base/04-install-kernel-akmods.sh quality
• [advisory] bluefin-lts repo has zero unit tests for build scripts projectbluefin/bluefin-lts/build_scripts/ quality
• [coverage-gap] actions: sign-and-publish action (223 lines, security-critical) has no tests projectbluefin/actions/bootc-build/sign-and-publish/action.yml quality

  sign-and-publish handles cosign signing, SBOM generation, ORAS attachment, and SLSA provenance. 7 shell steps with input validation, key-vs-keyless branching, and error handling. Zero unit tests. A signing failure could ship unsigned images to production.

• [coverage-gap] dakota: zero test coverage for Python scripts (1124 LOC) scripts/gen-filemap.py quality

  Dakota has 5 Python scripts (1124 LOC total) with zero tests: gen-filemap.py (193 LOC), check_publish_workflow.py (65 LOC), render_card.py (542 LOC), sbom_diff.py (281 LOC), generate_cargo_sources.py (43 LOC). These scripts handle critical build infrastructure including filemap generation, publish workflow validation, and SBOM diffing.

• [advisory] bluefin-lts: kernel-swap.sh (152 lines) has no test coverage build_scripts/scripts/kernel-swap.sh quality

  kernel-swap.sh is a 152-line bash script handling kernel RPM swaps, depmod/dracut, HWE/NVIDIA akmods, versionlock, and key imports. Complex branching logic with no test coverage. The analogous bluefin repo has tests for similar scripts.

• [advisory] No test for Framework hardware setup hook (10-framework.sh) system_files/shared/usr/share/ublue-os/system-setup.hooks.d/10-framework.sh quality
• [advisory] No test for ASUS system setup hook (11-asus.sh) system_files/shared/usr/share/ublue-os/system-setup.hooks.d/11-asus.sh quality
• [advisory] No test for OEM brew user setup hook (20-oem-brew.sh) system_files/shared/usr/share/ublue-os/user-setup.hooks.d/20-oem-brew.sh quality
• [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.

• [security] bluefin#638: CVE-2026-33186 in google.golang.org/grpc v1.72.2 — fix available in 1.79.3 gh-638 scanner

  Trivy scan on bluefin-nvidia:testing (2026-06-21) found CVE-2026-33186 in google.golang.org/grpc v1.72.2. Fixed in 1.79.3. This blocks promotion of testing→main. The grpc package is a transitive dependency shipped inside the nvidia image. Scan run: https://github.com/projectbluefin/bluefin/actions/runs/27890192980

• [security] actions#231: sign-and-publish signing validation logic untested — silent supply chain failure risk gh-231 scanner

  bootc-build/sign-and-publish/action.yml (223 lines, 7 shell steps) has zero test coverage. Handles: input validation (keyless vs key-based), cosign signing with retry, SBOM generation + ORAS attachment, SLSA provenance emission, sigstore cache fix. A bug could ship unsigned images or silently skip SBOM/provenance. Issue filed by quality agent; no tests exist in actions repo.

🟠 HIGH (260)

• [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] 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] 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] 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] 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] actions: Factory Health failing — GitHub App client-id secret unavailable in workflow context Factory Health ci-maintainer

  Factory Health monitor job failing: Error: The 'client-id' (or deprecated 'app-id') input must be set to a non-empty string — secret not available in this workflow context. Action: actions/create-github-app-token@bcd2ba4. Run 27370718152 at 2026-06-11T19:03:53Z. Likely affects all workflows in projectbluefin/actions that use this GitHub App token step.

• [ci-failure] bluefin: Testing Images failing on main — x86_64 and nvidia builds broken, promotion blocked Testing Images ci-maintainer

  Run 27926193458: image (main, bluefin, testing, x86_64) and image (nvidia, bluefin, testing, x86_64) both failing. 7+ consecutive failures on main today. Blocking sync to testing and promotion pipeline. PR Release Gate on auto/promote-testing-to-m also failing (run 27925944033).

• [ci-failure] bluefin: Sync main → testing failing on every push — Generate GitHub App token step broken Sync main → testing ci-maintainer

  Run 27926193447: 'Generate GitHub App token' step fails. 10+ consecutive failures across all pushes to main today (runs: 27926193447, 27923218978, 27922901317, 27922120148, 27921117488 and more). testing branch not receiving updates from main.

• [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] 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] 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] 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] 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] 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] 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] 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] 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] 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.

• [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.

• [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 in the Reusable Workflows table. Ten more reusable workflows in .github/workflows/ are completely absent: reusable-execute-release.yml, reusable-pkg-cadence.yml, reusable-promote-squash.yml, reusable-release-gate.yml, reusable-release-reminder.yml, reusable-renovate.yml, reusable-renovate-automerge.yml, reusable-sync-branches.yml, reusable-validate-renovate.yml, reusable-vulnerability-scan.yml. Count as of 2026-06-22: 12 reusable workflows exist, 2 documented.

• [stale_command] dakota CONTRIBUTING.md documents 'just check' command that does not exist in Justfile — should be 'just validate && just lint' projectbluefin/dakota CONTRIBUTING.md line 22 guide

  CONTRIBUTING.md line 22 says 'Run just check before opening a PR'. There is no 'check' target in the dakota Justfile — grep finds no match. The canonical pre-PR commands per docs/skills/quickstart.md (rule 2) are: 'just validate, just lint, and just boot-test'. The quickstart also shows 'just validate && just lint' as a minimal gate. Contributors who run 'just check' get a justfile recipe not found error and may skip validation entirely. Fix: replace 'just check' with 'just validate && just lint' and note that 'just boot-test' is also required before opening a PR.

• [missing_content] actions README Available Actions table omits bootc-build/create-release — the factory-standard release action projectbluefin/actions/README.md#available-actions guide

  bootc-build/create-release exists in the repo and AGENTS.md states it is the factory-standard release action used by bluefin, bluefin-lts, and dakota — but it is absent from the README Available Actions table. New contributors have no discovery path for this action without reading AGENTS.md in full.

• [missing_doc] projectbluefin/actions has no CONTRIBUTING.md — contributor entry point missing projectbluefin/actions/CONTRIBUTING.md guide

  projectbluefin/actions is the canonical shared CI infrastructure consumed by bluefin, aurora, and bazzite. It has README.md (consumer-facing) and AGENTS.md (agent-oriented) but no CONTRIBUTING.md. New human contributors have no documented path for: local setup, how to test a composite action before opening a PR, branch policy, or PR expectations. This is especially impactful because actions/ changes affect all downstream builds.

• [stale_reference] testsuite README.md Image tags table maps :latest and :lts to stale ghcr.io/ublue-os/bluefin org projectbluefin/testsuite README.md#image-tags guide

  README.md ends with an Image tags table showing 'ghcr.io/ublue-os/bluefin:latest' and 'ghcr.io/ublue-os/bluefin:lts'. The images have moved to ghcr.io/projectbluefin/. Anyone following this table will pull from the wrong registry. Correct refs are ghcr.io/projectbluefin/bluefin:stable and ghcr.io/projectbluefin/bluefin-lts:lts.

• [stale_reference] testsuite AGENTS.md 'Testing your scenario' example hardcodes ghcr.io/ublue-os/bluefin:latest projectbluefin/testsuite AGENTS.md#testing-your-scenario guide

  Under 'How agents contribute' step 6, the 'Testing your scenario' YAML block specifies 'image: ghcr.io/ublue-os/bluefin:latest'. The org has migrated to projectbluefin. Agents following this example will test against the wrong (potentially stale) registry. Should be ghcr.io/projectbluefin/bluefin:testing or a placeholder like 'ghcr.io/myorg/myimage:latest'.

• [missing_documentation] actions README.md Reusable Workflows table documents only 2 of 12 reusable workflows — reusable-execute-release, reusable-promote-squash, reusable-release-gate, reusable-release-reminder, reusable-renovate-automerge, reusable-renovate, reusable-sync-branches, reusable-validate-renovate, reusable-vulnerability-scan, reusable-pkg-cadence undocumented projectbluefin/actions/README.md#reusable-workflows guide

  projectbluefin/actions/.github/workflows/ contains 12 reusable workflows but README only lists reusable-build.yml and reusable-release.yml. The 10 undocumented workflows (reusable-execute-release, reusable-promote-squash, reusable-release-gate, reusable-release-reminder, reusable-renovate-automerge, reusable-renovate, reusable-sync-branches, reusable-validate-renovate, reusable-vulnerability-scan, reusable-pkg-cadence) are already consumed by bluefin and related repos but have no description, inputs, or usage examples in any public doc. Contributors cannot discover or properly use these workflows.

• [missing_documentation] actions README.md Available Actions table omits bootc-build/create-release — factory-standard release action undocumented in public README projectbluefin/actions/README.md#available-actions guide

  bootc-build/create-release has an action.yml in the repo and is documented in docs/skills/composite-actions.md as 'Factory-standard release: SBOM diff + release card + supply chain notes' and referenced in AGENTS.md as the factory-standard release action adopted by bluefin, bluefin-lts, and dakota. However the README.md Available Actions table lists only 14 of the 15 bootc-build composite actions — create-release is absent. A contributor reading README.md has no way to discover this action exists without reading AGENTS.md or docs/skills.

• [missing_doc] bluefin docs/skills/ci.md workflow map omits pr-smoke.yml — table claims 24 but 25 exist projectbluefin/bluefin:docs/skills/ci.md guide

  docs/skills/ci.md states 'all 24 workflows' and its workflow map table has 24 entries, but the actual .github/workflows/ directory contains 25 files including pr-smoke.yml which is absent from the table. Contributors reading the doc cannot discover pr-smoke.yml's trigger, purpose, or concurrency behavior.

• [missing_doc] projectbluefin/actions has no CONTRIBUTING.md — human contributor workflow undocumented projectbluefin/actions/CONTRIBUTING.md guide

  projectbluefin/actions has AGENTS.md, README.md, and SECURITY.md but no CONTRIBUTING.md. Human contributors have no documented workflow — no PR target branch, no validation steps (just check, pre-commit), no commit message conventions, and no explanation of how the bootc-build action directory is structured for contributions. AGENTS.md exists for AI agents only.

• [stale_command] testsuite README.md documents 'just lint' command that has no recipe in the Justfile projectbluefin/testsuite README.md:83 guide

  README.md line 83 'Working in this repo' section shows: 'just lint # validate Argo manifests'. The testsuite Justfile has no 'lint:' recipe. Running 'just lint' will fail with 'error: Justfile does not contain recipe lint'. CI runs ruff check and behave --dry-run, not 'just lint'. The README comment about Argo manifests is also stale — testsuite does not contain Argo manifests.

• [stale_reference] actions README Reusable Workflows table lists only 2 of 13 reusable workflows projectbluefin/actions/README.md#reusable-workflows guide

  README.md documents only reusable-build.yml and reusable-release.yml. The repo contains 13 reusable workflows: reusable-execute-release.yml, reusable-pkg-cadence.yml, reusable-promote-squash.yml, reusable-release-gate.yml, reusable-release-reminder.yml, reusable-renovate-automerge.yml, reusable-renovate.yml, reusable-sync-branches.yml, reusable-validate-renovate.yml, reusable-vulnerability-scan.yml, and skill-drift-check.yml. Consumers reading the README have no discovery path to 11 of the 13 reusable workflows.

• [missing_doc] projectbluefin/actions has no CONTRIBUTING.md — no contributor guide for external contributors projectbluefin/actions/CONTRIBUTING.md guide

  The actions repo has README.md (for consumers), AGENTS.md (for AI agents), and docs/MAINTAINERS.md (for maintainers) but no CONTRIBUTING.md for human contributors. There is no documented path for: DCO/Signed-off-by requirements, PR workflow (branch naming, target branch), how to add a new action, or how to run the action tests locally. AGENTS.md covers agents but is labelled AI-first and does not serve as a general contributor guide.

• [stale_reference] testsuite AGENTS.md example scenario uses stale ghcr.io/ublue-os/bluefin:latest image ref projectbluefin/testsuite/AGENTS.md#testing-your-scenario guide

  Under 'Testing your scenario' in AGENTS.md, the example workflow uses 'image: ghcr.io/ublue-os/bluefin:latest' — the stale ublue-os org. The correct image is ghcr.io/projectbluefin/bluefin:testing (or :latest). Agents following this example will test against the wrong registry, which may produce misleading results or failures. Complements bead 2ff2f0409355 (README Image tags table same stale org).

• [advisory] projectbluefin/common is missing SECURITY.md — no vulnerability reporting instructions projectbluefin/common/SECURITY.md guide

  The common repo ships no SECURITY.md. Its sibling repos (bluefin, bluefin-lts, dakota, actions) all have SECURITY.md files with private vulnerability reporting instructions. Because common is consumed as a shared OCI layer by all Bluefin variants, a vulnerability here affects every downstream image — making security contact info especially important. The README does not link to any security policy.

• [missing_doc] projectbluefin/testsuite is missing SECURITY.md — no vulnerability reporting instructions projectbluefin/testsuite/SECURITY.md guide

  Every other authorized repo (bluefin, bluefin-lts, actions, dakota) has a SECURITY.md. The testsuite repo handles workflow secrets, cosign verification, and GHCR push credentials — security researchers have no documented path to report issues confidentially.

• [documentation_conflict] bluefin-lts CONTRIBUTING.md says PRs target main but AGENTS.md says target testing projectbluefin/bluefin-lts: CONTRIBUTING.md#pull-requests guide

  CONTRIBUTING.md line 'Open PRs against the main branch' contradicts AGENTS.md which says 'Target testing' and 'Agents MUST NOT push directly to main. All changes via PR. Target testing.' The repo map in AGENTS.md also shows 'PRs→testing'. New contributors reading CONTRIBUTING.md will open PRs against the wrong branch. CONTRIBUTING.md must be updated to reflect the testing-first branch model.

• [advisory] bootc-installer: image.py (592 lines) and network.py (517 lines) completely untested quality

  bootc_installer/defaults/image.py (592 lines) handles image catalog loading, manifest parsing, and image selection — critical installer logic with zero test coverage. bootc_installer/defaults/network.py (517 lines) handles WiFi/NM configuration — also untested. Project coverage threshold is only 47% with a 45% target.

• [advisory] generate-tags action has zero unit tests for complex tag logic bootc-build/generate-tags/action.yml quality

  generate-tags action contains ~80 lines of bash with conditional logic for stable/testing/latest streams, PR tags, kernel-pin parsing, Tuesday promotion logic, and Fedora version extraction. No unit tests exist. Incorrect tags can push images to wrong channels or break user updates.

• [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] knuckle: headless ISO smoke CI fails — Flatcar PXE stable URL returns 404 quality
• [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).

• [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: 13/16 build scripts lack unit tests (81% untested) quality

  Only copr-helpers.sh, package-lib.sh, validate-repos.sh have BATS tests. 13 build scripts including disable-repos.sh, clean-stage.sh, build.sh have zero unit tests. These scripts run during container image build and handle package management, repo config, and initramfs generation.

• [advisory] bluefin: disable-repos.sh and clean-stage.sh lack unit tests quality
• [advisory] bluefin: 13 build scripts lack unit tests quality

  16 shell scripts under build_files/ — only copr-helpers, package-lib, validate-repos have BATS tests. 13 scripts (image-info, packages, install-kernel-akmods, override-install, cleanup, workarounds, initramfs, tests, build-gnome-extensions, build, clean-stage, disable-repos, finalize-gnome-extensions) have zero test coverage.

• [advisory] bluefin-lts: zero unit tests for build_scripts quality
• [advisory] bluefin-lts: zero test coverage for 18+ build scripts quality

  bluefin-lts has 18+ build scripts in build_scripts/ with zero BATS or shell test coverage. The sibling repo (bluefin) has 3 BATS test files but bluefin-lts has none despite having its own divergent build scripts.

• [advisory] dakota-iso: build/configure shell scripts have no tests quality

  dakota-iso has shell scripts (build-iso.sh, configure-live.sh, dracut modules) and Python scripts (luks-unlock.py) but only 2 Python test files. No shell script testing at all.

• [advisory] bluefin: 03-packages.sh has no unit test coverage quality

  03-packages.sh is the largest and most critical build script — handles dnf5 repo config, package installs, COPR isolation, version-specific additions, and exclusion removals. No BATS unit test exists despite pattern being established for other scripts.

---

⚠️ Digest truncated: 432227 → 65265 characters (GitHub limit: 65536)

[castrojo]

🐝 Advisory Digest — 2026-07-16 18:25 EDT

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

Findings: 924

Severity	Count
🔴 critical	26
🟠 high	260
🟡 medium	508
🔵 low	129
⚪ info	1

🔴 CRITICAL (26)

• [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] 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).

• [coverage-gap] actions: No tests for resolve_digests.sh and verify_signatures.sh (release security) scripts/verify_signatures.sh quality

  scripts/resolve_digests.sh (52 lines) resolves OCI image tags to SHA digests via skopeo. scripts/verify_signatures.sh (75 lines) verifies cosign signatures on resolved digests. Both are critical to the release gate pipeline — a bug could allow unsigned/tampered images through. The actions repo already has bats tests for other scripts (generate_tags, retry, release_gate, check_token_health) showing the pattern exists.

• [coverage-gap] Release-gate scripts (resolve_digests.sh, verify_signatures.sh) have no unit tests scripts/resolve_digests.sh quality

  FALSE POSITIVE - tests already exist at tests/bats/test_release_gate.bats with comprehensive mocked coverage. Issue PassKey support on OS level #192 filed incorrectly - needs human closure.

• [coverage-gap] verify_signatures.sh has no unit tests (security-critical) projectbluefin/actions/scripts/verify_signatures.sh quality

  verify_signatures.sh validates cosign signatures for container images - a security-critical path with no test coverage. A malicious bypass would go undetected.

• [coverage-gap] resolve_digests.sh has no unit tests (supply-chain critical) projectbluefin/actions/scripts/resolve_digests.sh quality

  resolve_digests.sh resolves image tags to immutable digests for release pinning - supply-chain critical with no tests.

• [coverage-gap] dakota repo has zero test coverage projectbluefin/dakota quality

  Dakota repo has zero test files. The 193-line gen-filemap.py script has no unit tests. No CI test workflow exists. This is a complete blind spot.

• [missing-workflow] bluefin bats tests exist but are not run in CI projectbluefin/bluefin:tests/unit quality

  bluefin repo has 8 bats test files in tests/unit/ (17-cleanup_test, 18-workarounds_test, 19-initramfs_test, clean-stage_test, copr-helpers_test, disable-repos_test, package-lib_test, validate-repos_test) but NO unit-tests workflow in .github/workflows/. These tests never run automatically. A unit-tests.yml workflow should be added.

• [coverage-gap] bluefin: 04-install-kernel-akmods.sh (188 lines) has no unit test build_files/base/04-install-kernel-akmods.sh quality
• [advisory] bluefin-lts repo has zero unit tests for build scripts projectbluefin/bluefin-lts/build_scripts/ quality
• [coverage-gap] actions: sign-and-publish action (223 lines, security-critical) has no tests projectbluefin/actions/bootc-build/sign-and-publish/action.yml quality

  sign-and-publish handles cosign signing, SBOM generation, ORAS attachment, and SLSA provenance. 7 shell steps with input validation, key-vs-keyless branching, and error handling. Zero unit tests. A signing failure could ship unsigned images to production.

• [coverage-gap] dakota: zero test coverage for Python scripts (1124 LOC) scripts/gen-filemap.py quality

  Dakota has 5 Python scripts (1124 LOC total) with zero tests: gen-filemap.py (193 LOC), check_publish_workflow.py (65 LOC), render_card.py (542 LOC), sbom_diff.py (281 LOC), generate_cargo_sources.py (43 LOC). These scripts handle critical build infrastructure including filemap generation, publish workflow validation, and SBOM diffing.

• [advisory] bluefin-lts: kernel-swap.sh (152 lines) has no test coverage build_scripts/scripts/kernel-swap.sh quality

  kernel-swap.sh is a 152-line bash script handling kernel RPM swaps, depmod/dracut, HWE/NVIDIA akmods, versionlock, and key imports. Complex branching logic with no test coverage. The analogous bluefin repo has tests for similar scripts.

• [advisory] No test for Framework hardware setup hook (10-framework.sh) system_files/shared/usr/share/ublue-os/system-setup.hooks.d/10-framework.sh quality
• [advisory] No test for ASUS system setup hook (11-asus.sh) system_files/shared/usr/share/ublue-os/system-setup.hooks.d/11-asus.sh quality
• [advisory] No test for OEM brew user setup hook (20-oem-brew.sh) system_files/shared/usr/share/ublue-os/user-setup.hooks.d/20-oem-brew.sh quality
• [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.

• [security] bluefin#638: CVE-2026-33186 in google.golang.org/grpc v1.72.2 — fix available in 1.79.3 gh-638 scanner

  Trivy scan on bluefin-nvidia:testing (2026-06-21) found CVE-2026-33186 in google.golang.org/grpc v1.72.2. Fixed in 1.79.3. This blocks promotion of testing→main. The grpc package is a transitive dependency shipped inside the nvidia image. Scan run: https://github.com/projectbluefin/bluefin/actions/runs/27890192980

• [security] actions#231: sign-and-publish signing validation logic untested — silent supply chain failure risk gh-231 scanner

  bootc-build/sign-and-publish/action.yml (223 lines, 7 shell steps) has zero test coverage. Handles: input validation (keyless vs key-based), cosign signing with retry, SBOM generation + ORAS attachment, SLSA provenance emission, sigstore cache fix. A bug could ship unsigned images or silently skip SBOM/provenance. Issue filed by quality agent; no tests exist in actions repo.

🟠 HIGH (260)

• [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] 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] 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] 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] 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] actions: Factory Health failing — GitHub App client-id secret unavailable in workflow context Factory Health ci-maintainer

  Factory Health monitor job failing: Error: The 'client-id' (or deprecated 'app-id') input must be set to a non-empty string — secret not available in this workflow context. Action: actions/create-github-app-token@bcd2ba4. Run 27370718152 at 2026-06-11T19:03:53Z. Likely affects all workflows in projectbluefin/actions that use this GitHub App token step.

• [ci-failure] bluefin: Testing Images failing on main — x86_64 and nvidia builds broken, promotion blocked Testing Images ci-maintainer

  Run 27926193458: image (main, bluefin, testing, x86_64) and image (nvidia, bluefin, testing, x86_64) both failing. 7+ consecutive failures on main today. Blocking sync to testing and promotion pipeline. PR Release Gate on auto/promote-testing-to-m also failing (run 27925944033).

• [ci-failure] bluefin: Sync main → testing failing on every push — Generate GitHub App token step broken Sync main → testing ci-maintainer

  Run 27926193447: 'Generate GitHub App token' step fails. 10+ consecutive failures across all pushes to main today (runs: 27926193447, 27923218978, 27922901317, 27922120148, 27921117488 and more). testing branch not receiving updates from main.

• [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] 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] 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] 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] 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] 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] 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] 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] 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] 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.

• [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.

• [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 in the Reusable Workflows table. Ten more reusable workflows in .github/workflows/ are completely absent: reusable-execute-release.yml, reusable-pkg-cadence.yml, reusable-promote-squash.yml, reusable-release-gate.yml, reusable-release-reminder.yml, reusable-renovate.yml, reusable-renovate-automerge.yml, reusable-sync-branches.yml, reusable-validate-renovate.yml, reusable-vulnerability-scan.yml. Count as of 2026-06-22: 12 reusable workflows exist, 2 documented.

• [stale_command] dakota CONTRIBUTING.md documents 'just check' command that does not exist in Justfile — should be 'just validate && just lint' projectbluefin/dakota CONTRIBUTING.md line 22 guide

  CONTRIBUTING.md line 22 says 'Run just check before opening a PR'. There is no 'check' target in the dakota Justfile — grep finds no match. The canonical pre-PR commands per docs/skills/quickstart.md (rule 2) are: 'just validate, just lint, and just boot-test'. The quickstart also shows 'just validate && just lint' as a minimal gate. Contributors who run 'just check' get a justfile recipe not found error and may skip validation entirely. Fix: replace 'just check' with 'just validate && just lint' and note that 'just boot-test' is also required before opening a PR.

• [missing_content] actions README Available Actions table omits bootc-build/create-release — the factory-standard release action projectbluefin/actions/README.md#available-actions guide

  bootc-build/create-release exists in the repo and AGENTS.md states it is the factory-standard release action used by bluefin, bluefin-lts, and dakota — but it is absent from the README Available Actions table. New contributors have no discovery path for this action without reading AGENTS.md in full.

• [missing_doc] projectbluefin/actions has no CONTRIBUTING.md — contributor entry point missing projectbluefin/actions/CONTRIBUTING.md guide

  projectbluefin/actions is the canonical shared CI infrastructure consumed by bluefin, aurora, and bazzite. It has README.md (consumer-facing) and AGENTS.md (agent-oriented) but no CONTRIBUTING.md. New human contributors have no documented path for: local setup, how to test a composite action before opening a PR, branch policy, or PR expectations. This is especially impactful because actions/ changes affect all downstream builds.

• [stale_reference] testsuite README.md Image tags table maps :latest and :lts to stale ghcr.io/ublue-os/bluefin org projectbluefin/testsuite README.md#image-tags guide

  README.md ends with an Image tags table showing 'ghcr.io/ublue-os/bluefin:latest' and 'ghcr.io/ublue-os/bluefin:lts'. The images have moved to ghcr.io/projectbluefin/. Anyone following this table will pull from the wrong registry. Correct refs are ghcr.io/projectbluefin/bluefin:stable and ghcr.io/projectbluefin/bluefin-lts:lts.

• [stale_reference] testsuite AGENTS.md 'Testing your scenario' example hardcodes ghcr.io/ublue-os/bluefin:latest projectbluefin/testsuite AGENTS.md#testing-your-scenario guide

  Under 'How agents contribute' step 6, the 'Testing your scenario' YAML block specifies 'image: ghcr.io/ublue-os/bluefin:latest'. The org has migrated to projectbluefin. Agents following this example will test against the wrong (potentially stale) registry. Should be ghcr.io/projectbluefin/bluefin:testing or a placeholder like 'ghcr.io/myorg/myimage:latest'.

• [missing_documentation] actions README.md Reusable Workflows table documents only 2 of 12 reusable workflows — reusable-execute-release, reusable-promote-squash, reusable-release-gate, reusable-release-reminder, reusable-renovate-automerge, reusable-renovate, reusable-sync-branches, reusable-validate-renovate, reusable-vulnerability-scan, reusable-pkg-cadence undocumented projectbluefin/actions/README.md#reusable-workflows guide

  projectbluefin/actions/.github/workflows/ contains 12 reusable workflows but README only lists reusable-build.yml and reusable-release.yml. The 10 undocumented workflows (reusable-execute-release, reusable-promote-squash, reusable-release-gate, reusable-release-reminder, reusable-renovate-automerge, reusable-renovate, reusable-sync-branches, reusable-validate-renovate, reusable-vulnerability-scan, reusable-pkg-cadence) are already consumed by bluefin and related repos but have no description, inputs, or usage examples in any public doc. Contributors cannot discover or properly use these workflows.

• [missing_documentation] actions README.md Available Actions table omits bootc-build/create-release — factory-standard release action undocumented in public README projectbluefin/actions/README.md#available-actions guide

  bootc-build/create-release has an action.yml in the repo and is documented in docs/skills/composite-actions.md as 'Factory-standard release: SBOM diff + release card + supply chain notes' and referenced in AGENTS.md as the factory-standard release action adopted by bluefin, bluefin-lts, and dakota. However the README.md Available Actions table lists only 14 of the 15 bootc-build composite actions — create-release is absent. A contributor reading README.md has no way to discover this action exists without reading AGENTS.md or docs/skills.

• [missing_doc] bluefin docs/skills/ci.md workflow map omits pr-smoke.yml — table claims 24 but 25 exist projectbluefin/bluefin:docs/skills/ci.md guide

  docs/skills/ci.md states 'all 24 workflows' and its workflow map table has 24 entries, but the actual .github/workflows/ directory contains 25 files including pr-smoke.yml which is absent from the table. Contributors reading the doc cannot discover pr-smoke.yml's trigger, purpose, or concurrency behavior.

• [missing_doc] projectbluefin/actions has no CONTRIBUTING.md — human contributor workflow undocumented projectbluefin/actions/CONTRIBUTING.md guide

  projectbluefin/actions has AGENTS.md, README.md, and SECURITY.md but no CONTRIBUTING.md. Human contributors have no documented workflow — no PR target branch, no validation steps (just check, pre-commit), no commit message conventions, and no explanation of how the bootc-build action directory is structured for contributions. AGENTS.md exists for AI agents only.

• [stale_command] testsuite README.md documents 'just lint' command that has no recipe in the Justfile projectbluefin/testsuite README.md:83 guide

  README.md line 83 'Working in this repo' section shows: 'just lint # validate Argo manifests'. The testsuite Justfile has no 'lint:' recipe. Running 'just lint' will fail with 'error: Justfile does not contain recipe lint'. CI runs ruff check and behave --dry-run, not 'just lint'. The README comment about Argo manifests is also stale — testsuite does not contain Argo manifests.

• [stale_reference] actions README Reusable Workflows table lists only 2 of 13 reusable workflows projectbluefin/actions/README.md#reusable-workflows guide

  README.md documents only reusable-build.yml and reusable-release.yml. The repo contains 13 reusable workflows: reusable-execute-release.yml, reusable-pkg-cadence.yml, reusable-promote-squash.yml, reusable-release-gate.yml, reusable-release-reminder.yml, reusable-renovate-automerge.yml, reusable-renovate.yml, reusable-sync-branches.yml, reusable-validate-renovate.yml, reusable-vulnerability-scan.yml, and skill-drift-check.yml. Consumers reading the README have no discovery path to 11 of the 13 reusable workflows.

• [missing_doc] projectbluefin/actions has no CONTRIBUTING.md — no contributor guide for external contributors projectbluefin/actions/CONTRIBUTING.md guide

  The actions repo has README.md (for consumers), AGENTS.md (for AI agents), and docs/MAINTAINERS.md (for maintainers) but no CONTRIBUTING.md for human contributors. There is no documented path for: DCO/Signed-off-by requirements, PR workflow (branch naming, target branch), how to add a new action, or how to run the action tests locally. AGENTS.md covers agents but is labelled AI-first and does not serve as a general contributor guide.

• [stale_reference] testsuite AGENTS.md example scenario uses stale ghcr.io/ublue-os/bluefin:latest image ref projectbluefin/testsuite/AGENTS.md#testing-your-scenario guide

  Under 'Testing your scenario' in AGENTS.md, the example workflow uses 'image: ghcr.io/ublue-os/bluefin:latest' — the stale ublue-os org. The correct image is ghcr.io/projectbluefin/bluefin:testing (or :latest). Agents following this example will test against the wrong registry, which may produce misleading results or failures. Complements bead 2ff2f0409355 (README Image tags table same stale org).

• [advisory] projectbluefin/common is missing SECURITY.md — no vulnerability reporting instructions projectbluefin/common/SECURITY.md guide

  The common repo ships no SECURITY.md. Its sibling repos (bluefin, bluefin-lts, dakota, actions) all have SECURITY.md files with private vulnerability reporting instructions. Because common is consumed as a shared OCI layer by all Bluefin variants, a vulnerability here affects every downstream image — making security contact info especially important. The README does not link to any security policy.

• [missing_doc] projectbluefin/testsuite is missing SECURITY.md — no vulnerability reporting instructions projectbluefin/testsuite/SECURITY.md guide

  Every other authorized repo (bluefin, bluefin-lts, actions, dakota) has a SECURITY.md. The testsuite repo handles workflow secrets, cosign verification, and GHCR push credentials — security researchers have no documented path to report issues confidentially.

• [documentation_conflict] bluefin-lts CONTRIBUTING.md says PRs target main but AGENTS.md says target testing projectbluefin/bluefin-lts: CONTRIBUTING.md#pull-requests guide

  CONTRIBUTING.md line 'Open PRs against the main branch' contradicts AGENTS.md which says 'Target testing' and 'Agents MUST NOT push directly to main. All changes via PR. Target testing.' The repo map in AGENTS.md also shows 'PRs→testing'. New contributors reading CONTRIBUTING.md will open PRs against the wrong branch. CONTRIBUTING.md must be updated to reflect the testing-first branch model.

• [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] PR feat: add a simple uupd config #308 — probe resolveByIDPath success path (7 tests) quality
• [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] knuckle: headless ISO smoke CI fails — Flatcar PXE stable URL returns 404 quality
• [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).

• [advisory] bootc-installer: image.py (592 lines) and network.py (517 lines) completely untested quality

  bootc_installer/defaults/image.py (592 lines) handles image catalog loading, manifest parsing, and image selection — critical installer logic with zero test coverage. bootc_installer/defaults/network.py (517 lines) handles WiFi/NM configuration — also untested. Project coverage threshold is only 47% with a 45% target.

• [advisory] bluefin: 13/16 build scripts lack unit tests (81% untested) quality

  Only copr-helpers.sh, package-lib.sh, validate-repos.sh have BATS tests. 13 build scripts including disable-repos.sh, clean-stage.sh, build.sh have zero unit tests. These scripts run during container image build and handle package management, repo config, and initramfs generation.

• [advisory] bluefin: disable-repos.sh and clean-stage.sh lack unit tests quality
• [advisory] bluefin: 13 build scripts lack unit tests quality

  16 shell scripts under build_files/ — only copr-helpers, package-lib, validate-repos have BATS tests. 13 scripts (image-info, packages, install-kernel-akmods, override-install, cleanup, workarounds, initramfs, tests, build-gnome-extensions, build, clean-stage, disable-repos, finalize-gnome-extensions) have zero test coverage.

• [advisory] bluefin-lts: zero unit tests for build_scripts quality
• [advisory] bluefin-lts: zero test coverage for 18+ build scripts quality

  bluefin-lts has 18+ build scripts in build_scripts/ with zero BATS or shell test coverage. The sibling repo (bluefin) has 3 BATS test files but bluefin-lts has none despite having its own divergent build scripts.

• [advisory] dakota-iso: build/configure shell scripts have no tests quality

  dakota-iso has shell scripts (build-iso.sh, configure-live.sh, dracut modules) and Python scripts (luks-unlock.py) but only 2 Python test files. No shell script testing at all.

• [advisory] bluefin: 03-packages.sh has no unit test coverage quality

  03-packages.sh is the largest and most critical build script — handles dnf5 repo config, package installs, COPR isolation, version-specific additions, and exclusion removals. No BATS unit test exists despite pattern being established for other scripts.

• [advisory] bluefin: no BATS coverage gate in CI — test regressions pass silently quality

  bluefin pr-validation.yml runs BATS tests but does not enforce coverage thresholds. Tests can be deleted or degraded without CI failing. knuckle has 'just cover-check' as a model.

---

⚠️ Digest truncated: 416276 → 65215 characters (GitHub limit: 65536)

[castrojo]

🐝 Advisory Digest — 2026-07-16 18:25 EDT

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

Findings: 924

Severity	Count
🔴 critical	26
🟠 high	260
🟡 medium	508
🔵 low	129
⚪ info	1

🔴 CRITICAL (26)

• [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] 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).

• [coverage-gap] actions: No tests for resolve_digests.sh and verify_signatures.sh (release security) scripts/verify_signatures.sh quality

  scripts/resolve_digests.sh (52 lines) resolves OCI image tags to SHA digests via skopeo. scripts/verify_signatures.sh (75 lines) verifies cosign signatures on resolved digests. Both are critical to the release gate pipeline — a bug could allow unsigned/tampered images through. The actions repo already has bats tests for other scripts (generate_tags, retry, release_gate, check_token_health) showing the pattern exists.

• [coverage-gap] Release-gate scripts (resolve_digests.sh, verify_signatures.sh) have no unit tests scripts/resolve_digests.sh quality

  FALSE POSITIVE - tests already exist at tests/bats/test_release_gate.bats with comprehensive mocked coverage. Issue PassKey support on OS level #192 filed incorrectly - needs human closure.

• [coverage-gap] verify_signatures.sh has no unit tests (security-critical) projectbluefin/actions/scripts/verify_signatures.sh quality

  verify_signatures.sh validates cosign signatures for container images - a security-critical path with no test coverage. A malicious bypass would go undetected.

• [coverage-gap] resolve_digests.sh has no unit tests (supply-chain critical) projectbluefin/actions/scripts/resolve_digests.sh quality

  resolve_digests.sh resolves image tags to immutable digests for release pinning - supply-chain critical with no tests.

• [coverage-gap] dakota repo has zero test coverage projectbluefin/dakota quality

  Dakota repo has zero test files. The 193-line gen-filemap.py script has no unit tests. No CI test workflow exists. This is a complete blind spot.

• [missing-workflow] bluefin bats tests exist but are not run in CI projectbluefin/bluefin:tests/unit quality

  bluefin repo has 8 bats test files in tests/unit/ (17-cleanup_test, 18-workarounds_test, 19-initramfs_test, clean-stage_test, copr-helpers_test, disable-repos_test, package-lib_test, validate-repos_test) but NO unit-tests workflow in .github/workflows/. These tests never run automatically. A unit-tests.yml workflow should be added.

• [coverage-gap] bluefin: 04-install-kernel-akmods.sh (188 lines) has no unit test build_files/base/04-install-kernel-akmods.sh quality
• [advisory] bluefin-lts repo has zero unit tests for build scripts projectbluefin/bluefin-lts/build_scripts/ quality
• [coverage-gap] actions: sign-and-publish action (223 lines, security-critical) has no tests projectbluefin/actions/bootc-build/sign-and-publish/action.yml quality

  sign-and-publish handles cosign signing, SBOM generation, ORAS attachment, and SLSA provenance. 7 shell steps with input validation, key-vs-keyless branching, and error handling. Zero unit tests. A signing failure could ship unsigned images to production.

• [coverage-gap] dakota: zero test coverage for Python scripts (1124 LOC) scripts/gen-filemap.py quality

  Dakota has 5 Python scripts (1124 LOC total) with zero tests: gen-filemap.py (193 LOC), check_publish_workflow.py (65 LOC), render_card.py (542 LOC), sbom_diff.py (281 LOC), generate_cargo_sources.py (43 LOC). These scripts handle critical build infrastructure including filemap generation, publish workflow validation, and SBOM diffing.

• [advisory] bluefin-lts: kernel-swap.sh (152 lines) has no test coverage build_scripts/scripts/kernel-swap.sh quality

  kernel-swap.sh is a 152-line bash script handling kernel RPM swaps, depmod/dracut, HWE/NVIDIA akmods, versionlock, and key imports. Complex branching logic with no test coverage. The analogous bluefin repo has tests for similar scripts.

• [advisory] No test for Framework hardware setup hook (10-framework.sh) system_files/shared/usr/share/ublue-os/system-setup.hooks.d/10-framework.sh quality
• [advisory] No test for ASUS system setup hook (11-asus.sh) system_files/shared/usr/share/ublue-os/system-setup.hooks.d/11-asus.sh quality
• [advisory] No test for OEM brew user setup hook (20-oem-brew.sh) system_files/shared/usr/share/ublue-os/user-setup.hooks.d/20-oem-brew.sh quality
• [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.

• [security] bluefin#638: CVE-2026-33186 in google.golang.org/grpc v1.72.2 — fix available in 1.79.3 gh-638 scanner

  Trivy scan on bluefin-nvidia:testing (2026-06-21) found CVE-2026-33186 in google.golang.org/grpc v1.72.2. Fixed in 1.79.3. This blocks promotion of testing→main. The grpc package is a transitive dependency shipped inside the nvidia image. Scan run: https://github.com/projectbluefin/bluefin/actions/runs/27890192980

• [security] actions#231: sign-and-publish signing validation logic untested — silent supply chain failure risk gh-231 scanner

  bootc-build/sign-and-publish/action.yml (223 lines, 7 shell steps) has zero test coverage. Handles: input validation (keyless vs key-based), cosign signing with retry, SBOM generation + ORAS attachment, SLSA provenance emission, sigstore cache fix. A bug could ship unsigned images or silently skip SBOM/provenance. Issue filed by quality agent; no tests exist in actions repo.

🟠 HIGH (260)

• [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] 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] 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] 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] 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] actions: Factory Health failing — GitHub App client-id secret unavailable in workflow context Factory Health ci-maintainer

  Factory Health monitor job failing: Error: The 'client-id' (or deprecated 'app-id') input must be set to a non-empty string — secret not available in this workflow context. Action: actions/create-github-app-token@bcd2ba4. Run 27370718152 at 2026-06-11T19:03:53Z. Likely affects all workflows in projectbluefin/actions that use this GitHub App token step.

• [ci-failure] bluefin: Testing Images failing on main — x86_64 and nvidia builds broken, promotion blocked Testing Images ci-maintainer

  Run 27926193458: image (main, bluefin, testing, x86_64) and image (nvidia, bluefin, testing, x86_64) both failing. 7+ consecutive failures on main today. Blocking sync to testing and promotion pipeline. PR Release Gate on auto/promote-testing-to-m also failing (run 27925944033).

• [ci-failure] bluefin: Sync main → testing failing on every push — Generate GitHub App token step broken Sync main → testing ci-maintainer

  Run 27926193447: 'Generate GitHub App token' step fails. 10+ consecutive failures across all pushes to main today (runs: 27926193447, 27923218978, 27922901317, 27922120148, 27921117488 and more). testing branch not receiving updates from main.

• [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] 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] 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] 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] 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] 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] 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] 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] 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] 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.

• [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.

• [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 in the Reusable Workflows table. Ten more reusable workflows in .github/workflows/ are completely absent: reusable-execute-release.yml, reusable-pkg-cadence.yml, reusable-promote-squash.yml, reusable-release-gate.yml, reusable-release-reminder.yml, reusable-renovate.yml, reusable-renovate-automerge.yml, reusable-sync-branches.yml, reusable-validate-renovate.yml, reusable-vulnerability-scan.yml. Count as of 2026-06-22: 12 reusable workflows exist, 2 documented.

• [stale_command] dakota CONTRIBUTING.md documents 'just check' command that does not exist in Justfile — should be 'just validate && just lint' projectbluefin/dakota CONTRIBUTING.md line 22 guide

  CONTRIBUTING.md line 22 says 'Run just check before opening a PR'. There is no 'check' target in the dakota Justfile — grep finds no match. The canonical pre-PR commands per docs/skills/quickstart.md (rule 2) are: 'just validate, just lint, and just boot-test'. The quickstart also shows 'just validate && just lint' as a minimal gate. Contributors who run 'just check' get a justfile recipe not found error and may skip validation entirely. Fix: replace 'just check' with 'just validate && just lint' and note that 'just boot-test' is also required before opening a PR.

• [missing_content] actions README Available Actions table omits bootc-build/create-release — the factory-standard release action projectbluefin/actions/README.md#available-actions guide

  bootc-build/create-release exists in the repo and AGENTS.md states it is the factory-standard release action used by bluefin, bluefin-lts, and dakota — but it is absent from the README Available Actions table. New contributors have no discovery path for this action without reading AGENTS.md in full.

• [missing_doc] projectbluefin/actions has no CONTRIBUTING.md — contributor entry point missing projectbluefin/actions/CONTRIBUTING.md guide

  projectbluefin/actions is the canonical shared CI infrastructure consumed by bluefin, aurora, and bazzite. It has README.md (consumer-facing) and AGENTS.md (agent-oriented) but no CONTRIBUTING.md. New human contributors have no documented path for: local setup, how to test a composite action before opening a PR, branch policy, or PR expectations. This is especially impactful because actions/ changes affect all downstream builds.

• [stale_reference] testsuite README.md Image tags table maps :latest and :lts to stale ghcr.io/ublue-os/bluefin org projectbluefin/testsuite README.md#image-tags guide

  README.md ends with an Image tags table showing 'ghcr.io/ublue-os/bluefin:latest' and 'ghcr.io/ublue-os/bluefin:lts'. The images have moved to ghcr.io/projectbluefin/. Anyone following this table will pull from the wrong registry. Correct refs are ghcr.io/projectbluefin/bluefin:stable and ghcr.io/projectbluefin/bluefin-lts:lts.

• [stale_reference] testsuite AGENTS.md 'Testing your scenario' example hardcodes ghcr.io/ublue-os/bluefin:latest projectbluefin/testsuite AGENTS.md#testing-your-scenario guide

  Under 'How agents contribute' step 6, the 'Testing your scenario' YAML block specifies 'image: ghcr.io/ublue-os/bluefin:latest'. The org has migrated to projectbluefin. Agents following this example will test against the wrong (potentially stale) registry. Should be ghcr.io/projectbluefin/bluefin:testing or a placeholder like 'ghcr.io/myorg/myimage:latest'.

• [missing_documentation] actions README.md Reusable Workflows table documents only 2 of 12 reusable workflows — reusable-execute-release, reusable-promote-squash, reusable-release-gate, reusable-release-reminder, reusable-renovate-automerge, reusable-renovate, reusable-sync-branches, reusable-validate-renovate, reusable-vulnerability-scan, reusable-pkg-cadence undocumented projectbluefin/actions/README.md#reusable-workflows guide

  projectbluefin/actions/.github/workflows/ contains 12 reusable workflows but README only lists reusable-build.yml and reusable-release.yml. The 10 undocumented workflows (reusable-execute-release, reusable-promote-squash, reusable-release-gate, reusable-release-reminder, reusable-renovate-automerge, reusable-renovate, reusable-sync-branches, reusable-validate-renovate, reusable-vulnerability-scan, reusable-pkg-cadence) are already consumed by bluefin and related repos but have no description, inputs, or usage examples in any public doc. Contributors cannot discover or properly use these workflows.

• [missing_documentation] actions README.md Available Actions table omits bootc-build/create-release — factory-standard release action undocumented in public README projectbluefin/actions/README.md#available-actions guide

  bootc-build/create-release has an action.yml in the repo and is documented in docs/skills/composite-actions.md as 'Factory-standard release: SBOM diff + release card + supply chain notes' and referenced in AGENTS.md as the factory-standard release action adopted by bluefin, bluefin-lts, and dakota. However the README.md Available Actions table lists only 14 of the 15 bootc-build composite actions — create-release is absent. A contributor reading README.md has no way to discover this action exists without reading AGENTS.md or docs/skills.

• [missing_doc] bluefin docs/skills/ci.md workflow map omits pr-smoke.yml — table claims 24 but 25 exist projectbluefin/bluefin:docs/skills/ci.md guide

  docs/skills/ci.md states 'all 24 workflows' and its workflow map table has 24 entries, but the actual .github/workflows/ directory contains 25 files including pr-smoke.yml which is absent from the table. Contributors reading the doc cannot discover pr-smoke.yml's trigger, purpose, or concurrency behavior.

• [missing_doc] projectbluefin/actions has no CONTRIBUTING.md — human contributor workflow undocumented projectbluefin/actions/CONTRIBUTING.md guide

  projectbluefin/actions has AGENTS.md, README.md, and SECURITY.md but no CONTRIBUTING.md. Human contributors have no documented workflow — no PR target branch, no validation steps (just check, pre-commit), no commit message conventions, and no explanation of how the bootc-build action directory is structured for contributions. AGENTS.md exists for AI agents only.

• [stale_command] testsuite README.md documents 'just lint' command that has no recipe in the Justfile projectbluefin/testsuite README.md:83 guide

  README.md line 83 'Working in this repo' section shows: 'just lint # validate Argo manifests'. The testsuite Justfile has no 'lint:' recipe. Running 'just lint' will fail with 'error: Justfile does not contain recipe lint'. CI runs ruff check and behave --dry-run, not 'just lint'. The README comment about Argo manifests is also stale — testsuite does not contain Argo manifests.

• [stale_reference] actions README Reusable Workflows table lists only 2 of 13 reusable workflows projectbluefin/actions/README.md#reusable-workflows guide

  README.md documents only reusable-build.yml and reusable-release.yml. The repo contains 13 reusable workflows: reusable-execute-release.yml, reusable-pkg-cadence.yml, reusable-promote-squash.yml, reusable-release-gate.yml, reusable-release-reminder.yml, reusable-renovate-automerge.yml, reusable-renovate.yml, reusable-sync-branches.yml, reusable-validate-renovate.yml, reusable-vulnerability-scan.yml, and skill-drift-check.yml. Consumers reading the README have no discovery path to 11 of the 13 reusable workflows.

• [missing_doc] projectbluefin/actions has no CONTRIBUTING.md — no contributor guide for external contributors projectbluefin/actions/CONTRIBUTING.md guide

  The actions repo has README.md (for consumers), AGENTS.md (for AI agents), and docs/MAINTAINERS.md (for maintainers) but no CONTRIBUTING.md for human contributors. There is no documented path for: DCO/Signed-off-by requirements, PR workflow (branch naming, target branch), how to add a new action, or how to run the action tests locally. AGENTS.md covers agents but is labelled AI-first and does not serve as a general contributor guide.

• [stale_reference] testsuite AGENTS.md example scenario uses stale ghcr.io/ublue-os/bluefin:latest image ref projectbluefin/testsuite/AGENTS.md#testing-your-scenario guide

  Under 'Testing your scenario' in AGENTS.md, the example workflow uses 'image: ghcr.io/ublue-os/bluefin:latest' — the stale ublue-os org. The correct image is ghcr.io/projectbluefin/bluefin:testing (or :latest). Agents following this example will test against the wrong registry, which may produce misleading results or failures. Complements bead 2ff2f0409355 (README Image tags table same stale org).

• [advisory] projectbluefin/common is missing SECURITY.md — no vulnerability reporting instructions projectbluefin/common/SECURITY.md guide

  The common repo ships no SECURITY.md. Its sibling repos (bluefin, bluefin-lts, dakota, actions) all have SECURITY.md files with private vulnerability reporting instructions. Because common is consumed as a shared OCI layer by all Bluefin variants, a vulnerability here affects every downstream image — making security contact info especially important. The README does not link to any security policy.

• [missing_doc] projectbluefin/testsuite is missing SECURITY.md — no vulnerability reporting instructions projectbluefin/testsuite/SECURITY.md guide

  Every other authorized repo (bluefin, bluefin-lts, actions, dakota) has a SECURITY.md. The testsuite repo handles workflow secrets, cosign verification, and GHCR push credentials — security researchers have no documented path to report issues confidentially.

• [documentation_conflict] bluefin-lts CONTRIBUTING.md says PRs target main but AGENTS.md says target testing projectbluefin/bluefin-lts: CONTRIBUTING.md#pull-requests guide

  CONTRIBUTING.md line 'Open PRs against the main branch' contradicts AGENTS.md which says 'Target testing' and 'Agents MUST NOT push directly to main. All changes via PR. Target testing.' The repo map in AGENTS.md also shows 'PRs→testing'. New contributors reading CONTRIBUTING.md will open PRs against the wrong branch. CONTRIBUTING.md must be updated to reflect the testing-first branch model.

• [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] PR feat: add a simple uupd config #308 — probe resolveByIDPath success path (7 tests) quality
• [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] knuckle: headless ISO smoke CI fails — Flatcar PXE stable URL returns 404 quality
• [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).

• [advisory] bootc-installer: image.py (592 lines) and network.py (517 lines) completely untested quality

  bootc_installer/defaults/image.py (592 lines) handles image catalog loading, manifest parsing, and image selection — critical installer logic with zero test coverage. bootc_installer/defaults/network.py (517 lines) handles WiFi/NM configuration — also untested. Project coverage threshold is only 47% with a 45% target.

• [advisory] bluefin: 13/16 build scripts lack unit tests (81% untested) quality

  Only copr-helpers.sh, package-lib.sh, validate-repos.sh have BATS tests. 13 build scripts including disable-repos.sh, clean-stage.sh, build.sh have zero unit tests. These scripts run during container image build and handle package management, repo config, and initramfs generation.

• [advisory] bluefin: disable-repos.sh and clean-stage.sh lack unit tests quality
• [advisory] bluefin: 13 build scripts lack unit tests quality

  16 shell scripts under build_files/ — only copr-helpers, package-lib, validate-repos have BATS tests. 13 scripts (image-info, packages, install-kernel-akmods, override-install, cleanup, workarounds, initramfs, tests, build-gnome-extensions, build, clean-stage, disable-repos, finalize-gnome-extensions) have zero test coverage.

• [advisory] bluefin-lts: zero unit tests for build_scripts quality
• [advisory] bluefin-lts: zero test coverage for 18+ build scripts quality

  bluefin-lts has 18+ build scripts in build_scripts/ with zero BATS or shell test coverage. The sibling repo (bluefin) has 3 BATS test files but bluefin-lts has none despite having its own divergent build scripts.

• [advisory] dakota-iso: build/configure shell scripts have no tests quality

  dakota-iso has shell scripts (build-iso.sh, configure-live.sh, dracut modules) and Python scripts (luks-unlock.py) but only 2 Python test files. No shell script testing at all.

• [advisory] bluefin: 03-packages.sh has no unit test coverage quality

  03-packages.sh is the largest and most critical build script — handles dnf5 repo config, package installs, COPR isolation, version-specific additions, and exclusion removals. No BATS unit test exists despite pattern being established for other scripts.

• [advisory] bluefin: no BATS coverage gate in CI — test regressions pass silently quality

  bluefin pr-validation.yml runs BATS tests but does not enforce coverage thresholds. Tests can be deleted or degraded without CI failing. knuckle has 'just cover-check' as a model.

---

⚠️ Digest truncated: 416276 → 65215 characters (GitHub limit: 65536)

[castrojo]

🐝 Advisory Digest — 2026-07-16 19:43 EDT

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

Findings: 940

Severity	Count
🔴 critical	27
🟠 high	262
🟡 medium	519
🔵 low	131
⚪ info	1

🔴 CRITICAL (27)

• [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] 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).

• [coverage-gap] actions: No tests for resolve_digests.sh and verify_signatures.sh (release security) scripts/verify_signatures.sh quality

  scripts/resolve_digests.sh (52 lines) resolves OCI image tags to SHA digests via skopeo. scripts/verify_signatures.sh (75 lines) verifies cosign signatures on resolved digests. Both are critical to the release gate pipeline — a bug could allow unsigned/tampered images through. The actions repo already has bats tests for other scripts (generate_tags, retry, release_gate, check_token_health) showing the pattern exists.

• [coverage-gap] Release-gate scripts (resolve_digests.sh, verify_signatures.sh) have no unit tests scripts/resolve_digests.sh quality

  FALSE POSITIVE - tests already exist at tests/bats/test_release_gate.bats with comprehensive mocked coverage. Issue PassKey support on OS level #192 filed incorrectly - needs human closure.

• [coverage-gap] verify_signatures.sh has no unit tests (security-critical) projectbluefin/actions/scripts/verify_signatures.sh quality

  verify_signatures.sh validates cosign signatures for container images - a security-critical path with no test coverage. A malicious bypass would go undetected.

• [coverage-gap] resolve_digests.sh has no unit tests (supply-chain critical) projectbluefin/actions/scripts/resolve_digests.sh quality

  resolve_digests.sh resolves image tags to immutable digests for release pinning - supply-chain critical with no tests.

• [coverage-gap] dakota repo has zero test coverage projectbluefin/dakota quality

  Dakota repo has zero test files. The 193-line gen-filemap.py script has no unit tests. No CI test workflow exists. This is a complete blind spot.

• [missing-workflow] bluefin bats tests exist but are not run in CI projectbluefin/bluefin:tests/unit quality

  bluefin repo has 8 bats test files in tests/unit/ (17-cleanup_test, 18-workarounds_test, 19-initramfs_test, clean-stage_test, copr-helpers_test, disable-repos_test, package-lib_test, validate-repos_test) but NO unit-tests workflow in .github/workflows/. These tests never run automatically. A unit-tests.yml workflow should be added.

• [coverage-gap] bluefin: 04-install-kernel-akmods.sh (188 lines) has no unit test build_files/base/04-install-kernel-akmods.sh quality
• [advisory] bluefin-lts repo has zero unit tests for build scripts projectbluefin/bluefin-lts/build_scripts/ quality
• [coverage-gap] actions: sign-and-publish action (223 lines, security-critical) has no tests projectbluefin/actions/bootc-build/sign-and-publish/action.yml quality

  sign-and-publish handles cosign signing, SBOM generation, ORAS attachment, and SLSA provenance. 7 shell steps with input validation, key-vs-keyless branching, and error handling. Zero unit tests. A signing failure could ship unsigned images to production.

• [coverage-gap] dakota: zero test coverage for Python scripts (1124 LOC) scripts/gen-filemap.py quality

  Dakota has 5 Python scripts (1124 LOC total) with zero tests: gen-filemap.py (193 LOC), check_publish_workflow.py (65 LOC), render_card.py (542 LOC), sbom_diff.py (281 LOC), generate_cargo_sources.py (43 LOC). These scripts handle critical build infrastructure including filemap generation, publish workflow validation, and SBOM diffing.

• [advisory] bluefin-lts: kernel-swap.sh (152 lines) has no test coverage build_scripts/scripts/kernel-swap.sh quality

  kernel-swap.sh is a 152-line bash script handling kernel RPM swaps, depmod/dracut, HWE/NVIDIA akmods, versionlock, and key imports. Complex branching logic with no test coverage. The analogous bluefin repo has tests for similar scripts.

• [advisory] No test for Framework hardware setup hook (10-framework.sh) system_files/shared/usr/share/ublue-os/system-setup.hooks.d/10-framework.sh quality
• [advisory] No test for ASUS system setup hook (11-asus.sh) system_files/shared/usr/share/ublue-os/system-setup.hooks.d/11-asus.sh quality
• [advisory] No test for OEM brew user setup hook (20-oem-brew.sh) system_files/shared/usr/share/ublue-os/user-setup.hooks.d/20-oem-brew.sh quality
• [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.

• [security] bluefin#638: CVE-2026-33186 in google.golang.org/grpc v1.72.2 — fix available in 1.79.3 gh-638 scanner

  Trivy scan on bluefin-nvidia:testing (2026-06-21) found CVE-2026-33186 in google.golang.org/grpc v1.72.2. Fixed in 1.79.3. This blocks promotion of testing→main. The grpc package is a transitive dependency shipped inside the nvidia image. Scan run: https://github.com/projectbluefin/bluefin/actions/runs/27890192980

• [security] actions#231: sign-and-publish signing validation logic untested — silent supply chain failure risk gh-231 scanner

  bootc-build/sign-and-publish/action.yml (223 lines, 7 shell steps) has zero test coverage. Handles: input validation (keyless vs key-based), cosign signing with retry, SBOM generation + ORAS attachment, SLSA provenance emission, sigstore cache fix. A bug could ship unsigned images or silently skip SBOM/provenance. Issue filed by quality agent; no tests exist in actions repo.

• [security] bluefin-lts#213: common image used in LTS build without cosign signature verification — supply chain gap gh-213 scanner

  bluefin builds call 'just verify-container common:latest@${common_image_sha} ghcr.io/projectbluefin keys/projectbluefin-common.pub' before using common as a base. bluefin-lts Justfile has no equivalent verify-container call — COMMON_IMAGE_REF is passed directly to podman build --build-arg. A compromised or accidentally unsigned common image (as happened in common#697) silently passes into every LTS build. bluefin correctly failed with 'no signatures found' during that regression; LTS did not.

🟠 HIGH (262)

• [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] 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] 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] 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] 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] actions: Factory Health failing — GitHub App client-id secret unavailable in workflow context Factory Health ci-maintainer

  Factory Health monitor job failing: Error: The 'client-id' (or deprecated 'app-id') input must be set to a non-empty string — secret not available in this workflow context. Action: actions/create-github-app-token@bcd2ba4. Run 27370718152 at 2026-06-11T19:03:53Z. Likely affects all workflows in projectbluefin/actions that use this GitHub App token step.

• [ci-failure] bluefin: Update package cadence intervals failing on every Execute Release — 5+ consecutive failures Update package cadence intervals ci-maintainer

  pkg-cadence.yml calls reusable-pkg-cadence.yml@v1 from projectbluefin/actions. Failing after every Execute Release success. Runs: 29512523661 (2026-07-16T15:44), 29499489268 (2026-07-16T12:46), 29416249683 (2026-07-15T12:42), 29333343002 (2026-07-14T12:39). Triggered by workflow_run on Execute Release. Error likely in reusable-pkg-cadence.yml or its secrets.

• [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] 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] 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] 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] 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] 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] 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] 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] 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] 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_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.

• [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 in the Reusable Workflows table. Ten more reusable workflows in .github/workflows/ are completely absent: reusable-execute-release.yml, reusable-pkg-cadence.yml, reusable-promote-squash.yml, reusable-release-gate.yml, reusable-release-reminder.yml, reusable-renovate.yml, reusable-renovate-automerge.yml, reusable-sync-branches.yml, reusable-validate-renovate.yml, reusable-vulnerability-scan.yml. Count as of 2026-06-22: 12 reusable workflows exist, 2 documented.

• [stale_command] dakota CONTRIBUTING.md documents 'just check' command that does not exist in Justfile — should be 'just validate && just lint' projectbluefin/dakota CONTRIBUTING.md line 22 guide

  CONTRIBUTING.md line 22 says 'Run just check before opening a PR'. There is no 'check' target in the dakota Justfile — grep finds no match. The canonical pre-PR commands per docs/skills/quickstart.md (rule 2) are: 'just validate, just lint, and just boot-test'. The quickstart also shows 'just validate && just lint' as a minimal gate. Contributors who run 'just check' get a justfile recipe not found error and may skip validation entirely. Fix: replace 'just check' with 'just validate && just lint' and note that 'just boot-test' is also required before opening a PR.

• [missing_content] actions README Available Actions table omits bootc-build/create-release — the factory-standard release action projectbluefin/actions/README.md#available-actions guide

  bootc-build/create-release exists in the repo and AGENTS.md states it is the factory-standard release action used by bluefin, bluefin-lts, and dakota — but it is absent from the README Available Actions table. New contributors have no discovery path for this action without reading AGENTS.md in full.

• [missing_doc] projectbluefin/actions has no CONTRIBUTING.md — contributor entry point missing projectbluefin/actions/CONTRIBUTING.md guide

  projectbluefin/actions is the canonical shared CI infrastructure consumed by bluefin, aurora, and bazzite. It has README.md (consumer-facing) and AGENTS.md (agent-oriented) but no CONTRIBUTING.md. New human contributors have no documented path for: local setup, how to test a composite action before opening a PR, branch policy, or PR expectations. This is especially impactful because actions/ changes affect all downstream builds.

• [stale_reference] testsuite README.md Image tags table maps :latest and :lts to stale ghcr.io/ublue-os/bluefin org projectbluefin/testsuite README.md#image-tags guide

  README.md ends with an Image tags table showing 'ghcr.io/ublue-os/bluefin:latest' and 'ghcr.io/ublue-os/bluefin:lts'. The images have moved to ghcr.io/projectbluefin/. Anyone following this table will pull from the wrong registry. Correct refs are ghcr.io/projectbluefin/bluefin:stable and ghcr.io/projectbluefin/bluefin-lts:lts.

• [stale_reference] testsuite AGENTS.md 'Testing your scenario' example hardcodes ghcr.io/ublue-os/bluefin:latest projectbluefin/testsuite AGENTS.md#testing-your-scenario guide

  Under 'How agents contribute' step 6, the 'Testing your scenario' YAML block specifies 'image: ghcr.io/ublue-os/bluefin:latest'. The org has migrated to projectbluefin. Agents following this example will test against the wrong (potentially stale) registry. Should be ghcr.io/projectbluefin/bluefin:testing or a placeholder like 'ghcr.io/myorg/myimage:latest'.

• [missing_documentation] actions README.md Reusable Workflows table documents only 2 of 12 reusable workflows — reusable-execute-release, reusable-promote-squash, reusable-release-gate, reusable-release-reminder, reusable-renovate-automerge, reusable-renovate, reusable-sync-branches, reusable-validate-renovate, reusable-vulnerability-scan, reusable-pkg-cadence undocumented projectbluefin/actions/README.md#reusable-workflows guide

  projectbluefin/actions/.github/workflows/ contains 12 reusable workflows but README only lists reusable-build.yml and reusable-release.yml. The 10 undocumented workflows (reusable-execute-release, reusable-promote-squash, reusable-release-gate, reusable-release-reminder, reusable-renovate-automerge, reusable-renovate, reusable-sync-branches, reusable-validate-renovate, reusable-vulnerability-scan, reusable-pkg-cadence) are already consumed by bluefin and related repos but have no description, inputs, or usage examples in any public doc. Contributors cannot discover or properly use these workflows.

• [missing_documentation] actions README.md Available Actions table omits bootc-build/create-release — factory-standard release action undocumented in public README projectbluefin/actions/README.md#available-actions guide

  bootc-build/create-release has an action.yml in the repo and is documented in docs/skills/composite-actions.md as 'Factory-standard release: SBOM diff + release card + supply chain notes' and referenced in AGENTS.md as the factory-standard release action adopted by bluefin, bluefin-lts, and dakota. However the README.md Available Actions table lists only 14 of the 15 bootc-build composite actions — create-release is absent. A contributor reading README.md has no way to discover this action exists without reading AGENTS.md or docs/skills.

• [missing_doc] bluefin docs/skills/ci.md workflow map omits pr-smoke.yml — table claims 24 but 25 exist projectbluefin/bluefin:docs/skills/ci.md guide

  docs/skills/ci.md states 'all 24 workflows' and its workflow map table has 24 entries, but the actual .github/workflows/ directory contains 25 files including pr-smoke.yml which is absent from the table. Contributors reading the doc cannot discover pr-smoke.yml's trigger, purpose, or concurrency behavior.

• [missing_doc] projectbluefin/actions has no CONTRIBUTING.md — human contributor workflow undocumented projectbluefin/actions/CONTRIBUTING.md guide

  projectbluefin/actions has AGENTS.md, README.md, and SECURITY.md but no CONTRIBUTING.md. Human contributors have no documented workflow — no PR target branch, no validation steps (just check, pre-commit), no commit message conventions, and no explanation of how the bootc-build action directory is structured for contributions. AGENTS.md exists for AI agents only.

• [stale_command] testsuite README.md documents 'just lint' command that has no recipe in the Justfile projectbluefin/testsuite README.md:83 guide

  README.md line 83 'Working in this repo' section shows: 'just lint # validate Argo manifests'. The testsuite Justfile has no 'lint:' recipe. Running 'just lint' will fail with 'error: Justfile does not contain recipe lint'. CI runs ruff check and behave --dry-run, not 'just lint'. The README comment about Argo manifests is also stale — testsuite does not contain Argo manifests.

• [stale_reference] actions README Reusable Workflows table lists only 2 of 13 reusable workflows projectbluefin/actions/README.md#reusable-workflows guide

  README.md documents only reusable-build.yml and reusable-release.yml. The repo contains 13 reusable workflows: reusable-execute-release.yml, reusable-pkg-cadence.yml, reusable-promote-squash.yml, reusable-release-gate.yml, reusable-release-reminder.yml, reusable-renovate-automerge.yml, reusable-renovate.yml, reusable-sync-branches.yml, reusable-validate-renovate.yml, reusable-vulnerability-scan.yml, and skill-drift-check.yml. Consumers reading the README have no discovery path to 11 of the 13 reusable workflows.

• [missing_doc] projectbluefin/actions has no CONTRIBUTING.md — no contributor guide for external contributors projectbluefin/actions/CONTRIBUTING.md guide

  The actions repo has README.md (for consumers), AGENTS.md (for AI agents), and docs/MAINTAINERS.md (for maintainers) but no CONTRIBUTING.md for human contributors. There is no documented path for: DCO/Signed-off-by requirements, PR workflow (branch naming, target branch), how to add a new action, or how to run the action tests locally. AGENTS.md covers agents but is labelled AI-first and does not serve as a general contributor guide.

• [stale_reference] testsuite AGENTS.md example scenario uses stale ghcr.io/ublue-os/bluefin:latest image ref projectbluefin/testsuite/AGENTS.md#testing-your-scenario guide

  Under 'Testing your scenario' in AGENTS.md, the example workflow uses 'image: ghcr.io/ublue-os/bluefin:latest' — the stale ublue-os org. The correct image is ghcr.io/projectbluefin/bluefin:testing (or :latest). Agents following this example will test against the wrong registry, which may produce misleading results or failures. Complements bead 2ff2f0409355 (README Image tags table same stale org).

• [advisory] projectbluefin/common is missing SECURITY.md — no vulnerability reporting instructions projectbluefin/common/SECURITY.md guide

  The common repo ships no SECURITY.md. Its sibling repos (bluefin, bluefin-lts, dakota, actions) all have SECURITY.md files with private vulnerability reporting instructions. Because common is consumed as a shared OCI layer by all Bluefin variants, a vulnerability here affects every downstream image — making security contact info especially important. The README does not link to any security policy.

• [missing_doc] projectbluefin/testsuite is missing SECURITY.md — no vulnerability reporting instructions projectbluefin/testsuite/SECURITY.md guide

  Every other authorized repo (bluefin, bluefin-lts, actions, dakota) has a SECURITY.md. The testsuite repo handles workflow secrets, cosign verification, and GHCR push credentials — security researchers have no documented path to report issues confidentially.

• [documentation_conflict] bluefin-lts CONTRIBUTING.md says PRs target main but AGENTS.md says target testing projectbluefin/bluefin-lts: CONTRIBUTING.md#pull-requests guide

  CONTRIBUTING.md line 'Open PRs against the main branch' contradicts AGENTS.md which says 'Target testing' and 'Agents MUST NOT push directly to main. All changes via PR. Target testing.' The repo map in AGENTS.md also shows 'PRs→testing'. New contributors reading CONTRIBUTING.md will open PRs against the wrong branch. CONTRIBUTING.md must be updated to reflect the testing-first branch model.

• [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] PR feat: add a simple uupd config #308 — probe resolveByIDPath success path (7 tests) quality
• [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] knuckle: headless ISO smoke CI fails — Flatcar PXE stable URL returns 404 quality
• [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).

• [advisory] bootc-installer: image.py (592 lines) and network.py (517 lines) completely untested quality

  bootc_installer/defaults/image.py (592 lines) handles image catalog loading, manifest parsing, and image selection — critical installer logic with zero test coverage. bootc_installer/defaults/network.py (517 lines) handles WiFi/NM configuration — also untested. Project coverage threshold is only 47% with a 45% target.

• [advisory] bluefin: 13/16 build scripts lack unit tests (81% untested) quality

  Only copr-helpers.sh, package-lib.sh, validate-repos.sh have BATS tests. 13 build scripts including disable-repos.sh, clean-stage.sh, build.sh have zero unit tests. These scripts run during container image build and handle package management, repo config, and initramfs generation.

• [advisory] bluefin: disable-repos.sh and clean-stage.sh lack unit tests quality
• [advisory] bluefin: 13 build scripts lack unit tests quality

  16 shell scripts under build_files/ — only copr-helpers, package-lib, validate-repos have BATS tests. 13 scripts (image-info, packages, install-kernel-akmods, override-install, cleanup, workarounds, initramfs, tests, build-gnome-extensions, build, clean-stage, disable-repos, finalize-gnome-extensions) have zero test coverage.

• [advisory] bluefin-lts: zero unit tests for build_scripts quality
• [advisory] bluefin-lts: zero test coverage for 18+ build scripts quality

  bluefin-lts has 18+ build scripts in build_scripts/ with zero BATS or shell test coverage. The sibling repo (bluefin) has 3 BATS test files but bluefin-lts has none despite having its own divergent build scripts.

• [advisory] dakota-iso: build/configure shell scripts have no tests quality

  dakota-iso has shell scripts (build-iso.sh, configure-live.sh, dracut modules) and Python scripts (luks-unlock.py) but only 2 Python test files. No shell script testing at all.

• [advisory] bluefin: 03-packages.sh has no unit test coverage quality

  03-packages.sh is the largest and most critical build script — handles dnf5 repo config, package installs, COPR isolation, version-specific additions, and exclusion removals. No BATS unit test exists despite pattern being established for other scripts.

• [advisory] bluefin: no BATS coverage gate in CI — test regressions pass silently quality

  bluefin pr-validation.yml runs BATS tests but does not enforce coverage thresholds. Tests can be deleted or degraded without CI failing. knuckle has 'just cover-check' as a model.

• [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.

• [coverage-gap] actions repo: zero unit tests for release Python scripts (render_card, render_notes, sbom_diff) projectbluefin/actions/bootc-build/create-release/scripts/ quality

---

⚠️ Digest truncated: 429296 → 65276 characters (GitHub limit: 65536)

[kubestellar-hive]

🐝 Advisory Digest — 2026-09-20 15:47 EDT

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

Advice

Frozen for governor mode BUSY until 2026-09-27 (next review in 7 day(s)).

• Rebalance toward merge-side agents — The hive is busy; prioritize review, hold draining, and merge-side lanes before increasing new issue intake. (signals: mode=BUSY, open_holds=75, prs=245, issues=298)

Findings: 10

💡 Showing top 10 findings (by severity). 1142 more exist. Set governor.advisory.show_all: true to see all.

Severity	Count
🔴 critical	10

🔴 CRITICAL (10)

• [advisory] No test for OEM brew user setup hook (20-oem-brew.sh) system_files/shared/usr/share/ublue-os/user-setup.hooks.d/20-oem-brew.sh quality
• [advisory] No test for ASUS system setup hook (11-asus.sh) system_files/shared/usr/share/ublue-os/system-setup.hooks.d/11-asus.sh quality
• [advisory] [shared-ci] dakota-iso Plain/LUKS E2E: installed system boots to emergency mode; 30-line serial log window hides failing unit — 7 PRs blocked #211 scanner
• [advisory] [shared-ci] projectbluefin/server installer-test red on main since 2026-09-14 (50be1ed2) — /dev/disk/by-partlabel/var missing, 17 PRs blocked #218 scanner
• [advisory] documentation: main site build broken since da2deaf — downloads.mdx uses DakotaSection without import, :::B admonition typo #1282 scanner
• [advisory] BLOCKED: scanner per-agent GitHub token cache is zero-length — all GitHub writes and gh reads impossible scanner
• [advisory] dakota-iso CI baseline red: Python Unit Tests fails on main (f5fbf99) — stale skill catalog blocks 54 open PRs #137 (reported 2×) scanner
• [security] common/PR: ujust shellenv eval lacks input validation #902 scanner

  ujust fzf bootstrap uses eval on Homebrew shellenv output without validation. Malicious shellenv could execute arbitrary commands.

• [security] dakota#1182: pr-triage.yml uses pull_request_target with contents permission — token leakage risk #1182 scanner

  Workflow uses pull_request_target trigger which runs in the base repo context, combined with contents: write permission. This allows a forked PR to access and modify base repo secrets and code. In pull_request_target context, GITHUB_TOKEN has access to base repo data. If the workflow runs untrusted code from the PR (e.g., calling scripts), attackers can exfil secrets or push code. Impact: GitHub token and repo secrets leakage.

• [security] bluefin-lts#213: common image used in LTS build without cosign signature verification — supply chain gap #213 scanner

  bluefin builds call 'just verify-container common:latest@${common_image_sha} ghcr.io/projectbluefin keys/projectbluefin-common.pub' before using common as a base. bluefin-lts Justfile has no equivalent verify-container call — COMMON_IMAGE_REF is passed directly to podman build --build-arg. A compromised or accidentally unsigned common image (as happened in common#697) silently passes into every LTS build. bluefin correctly failed with 'no signatures found' during that regression; LTS did not.

✅ Recently Resolved (10)

• chairlift: cmd/ dispatch arms untested (dup-probe) probe quality — resolved Sep 20
• documentation: pages.yml validation step can never fail — bare 'wait' discards typecheck/lint exit codes; no CI job enforces tsc or eslint projectbluefin/documentation#1267 architect — resolved Sep 20
• server: kubestellar postgres StatefulSet hardcodes superuser password 'kubeflex' plaintext env (20-postgres.yaml), auto-applied via k0s manifest deployer sec-check — resolved Sep 20
• website: scripts/check-docs.mjs is a required CI gate with zero test coverage scripts/check-docs.mjs quality — resolved Sep 20
• website: scripts/check-docs.mjs is a required CI gate at 0% coverage scripts/check-docs.mjs quality — resolved Sep 20
• utah-packages: packit_workflow package_chunks and main() CLI had zero coverage — 256-job matrix cap unasserted tools/packit_workflow.py quality — resolved Sep 20
• tmp-probe-id quality — resolved Sep 20
• bluefin-bling#42: syncthing-toggle checkStatus() unvalidated service-name — fix PR feat: add ublue-bling #43 (hold) #42 sec-check — resolved Sep 19
• bluefin-bling#41: ci.yml unpinned actions — fix already in open PR docs: document Brewfiles and remove non-existent flatpak-extras references #36 (duplicate_tree) #41 sec-check — resolved Sep 19
• bluefin-bling#40: fix PR for fix: set wallpaper metadata path to /usr/share #39 (syncthing-toggle service-name validation) #40 sec-check — resolved Sep 19
• …plus 10 more resolved in the last 48h, collapsed so the open findings above stay readable

---

Analyzed at projectbluefin/common@ae2aa2e3618d (branch main) — the latest commit when this digest was generated. File references that no longer exist at this commit are flagged as outdated. Findings marked ⚠️ were computed at an older commit and have NOT been re-verified here.

[kubestellar-hive]

🐝 Advisory Digest — 2026-09-10 01:43 EDT

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

Findings: 10

💡 Showing top 10 findings (by severity). 834 more exist. Set governor.advisory.show_all: true to see all.

Severity	Count
🔴 critical	10

🔴 CRITICAL (10)

• [advisory] testsuite main and PR validation fail on stale suite-map coverage snapshot testsuite:runs-34385140751-34393397526 ci-maintainer
• [advisory] bluefin-bling CI PR blocked by missing workflows App permission bluefin-bling:push-workflows-permission ci-maintainer
• [advisory] server: Build DDI artifacts fails because os-rootfs staged artifacts lack sh projectbluefin/server/Build DDI artifacts/34305228511 ci-maintainer
• [advisory] fsdk-containers: Buildah image fails compiling grpc http2.TrailerPrefix on both architectures projectbluefin/fsdk-containers/Build images/34252007368 ci-maintainer
• [advisory] review: validate fails Guided Goose onboarding after review-container exit 97 projectbluefin/review/validate/34064949848 ci-maintainer
• …plus 2 more [advisory] findings from ci-maintainer, collapsed to keep lower-severity sections within GitHub's comment limit
• [advisory] bluefin-bling has no .github/ at all — 63-case test suite never runs in CI .github/workflows quality
• [regression-risk] finpilot check_token_health.sh: set -e aborts on absent x-oauth-scopes/x-ratelimit headers — App and fine-grained tokens fail a valid-token check .github/actions/check-token-health/check_token_health.sh quality

  RATE_REMAINING/RATE_LIMIT/SCOPES assigned from bare grep command substitutions under set -euo pipefail. Absent header makes the assignment exit non-zero; set -e terminates with no ::error:: and no GITHUB_OUTPUT written. GitHub omits x-oauth-scopes for fine-grained PATs and App installation tokens, so the script's own documented 'skipping scope check' else-branch is unreachable and valid/rate_remaining/expires_at are never emitted. Filed as finpilot#339; two BATS cases in finpilot#340 skipped pending fix.

• [advisory] Release cadence breakdown org-wide: bluefin 46d, bluefin-lts 28d frozen, common missed v2026.09 monthly tag; only dakota shipping — filed common#1078 #1078 strategist

✅ Recently Resolved (10)

• dakota-iso#127: build-iso.yml missing permissions block (secrets/write-ops) #127 sec-check — resolved Sep 10
• Coverage rotation local-mirror pass: documentation scripts/lib/ still 8/18 modules untested, markdown-generator.mjs (1352 loc) largest gap scanner — resolved Sep 10
• Monitoring pass 2026-09-09 nogithub advisory supervisor — resolved Sep 10
• documentation: scripts/lib/card-template.mjs (421 lines) had zero unit coverage — release-card renderer scripts/lib/card-template.mjs quality — resolved Sep 10
• dakota-iso#151: skill-drift.yml dangling + mutable v1 reusable workflow ref #151 sec-check — resolved Sep 10
• dakota-iso#150 fix blocked: hive App lacks workflows permission on dakota-iso — sec/fix-e2e-workflow-perms branch ready #150 sec-check — resolved Sep 10
• Org-wide ROADMAP.md PR common#1073 open: consolidates 17 strategist findings into 3 phases; issue common#1072 tracks maintainer sign-off gh-pr-common-1073 strategist — resolved Sep 10
• dakota-iso#150: luks/plain install E2E workflows grant top-level contents:write on pull_request #150 sec-check — resolved Sep 10
• dakota: generate_cargo_sources.py untested and silently drops git+ deps files/scripts/generate_cargo_sources.py quality — resolved Sep 9
• dakota: image_variants.py CI gate had no direct unit coverage (error branches, YAML scalar parser, CLI) .github/scripts/image_variants.py quality — resolved Sep 9
• …plus 26 more resolved in the last 48h, collapsed so the open findings above stay readable