docs(e2e-ci): spec installer post-boot assertions for fisherman e2e gaps

[onlydole]

Summary

dakota#651 is a tracking issue for e2e coverage gaps against a fisherman-driven
(the bootc-installer Go backend) install, filed here because issues are
disabled on tuna-os/fisherman. The three source fixes it tracks
(fisherman #1, fisherman #2, projectbluefin/common#385) live in other repos
Dakota doesn't own — but the installed system those fixes affect is still
Dakota's problem to verify, per the installer.md repo-boundary rule.

This PR adds the missing spec so the testsuite install-flow suite (or
whoever implements the actual assertions) has a single documented reference:

• docs/skills/e2e-ci.md — new "Installer Post-Boot Assertions
  (fisherman)" section with a table of all three assertions, which upstream
  fix each depends on, and an explicit rule that these belong in the
  testsuite install-flow suite, not Dakota's own generic-image boot-check
  gate (different code path — bootc install to-disk/to-filesystem via
  fisherman with LUKS vs. Dakota's --via-loopback raw-disk build). Also
  adds a sequencing note: land as xfail/skip-until-fixed against current
  fisherman, flip to blocking once each source fix ships in a nightly.
• docs/skills/installer.md — cross-link from Lessons Learned back to
  the new e2e-ci.md section.

No workflow/Justfile changes — this is documentation only, scoping the work
so the actual assertion implementation (which lives in
projectbluefin/testsuite, per this repo's "Dakota does not own any
behave/step code" rule) has a clear, agreed spec to build against.

Closes #651

Verification

• Docs-only change; no build/lint required for this diff.

• Cross-checked against docs/skills/e2e-ci.md's existing Testsuite Rule and
  docs/skills/installer.md's Dakota vs Dakota-ISO boundary table to keep
  the new section consistent with established conventions.

• I am using an agent and I take responsibility for this PR

[github-actions]

Thanks for the PR! A maintainer will review it.

While you wait, make sure these pass locally:

just validate        # element graph check
just build default   # build the image
just boot-test       # confirm the desktop boots (exits 0 = pass)
just lint            # bootc container lint

If this PR fixes a bug, add verify steps to the linked issue so users can confirm the fix on their hardware after the next nightly ships:

```verify
ujust <something>   # what users should run to confirm the fix
```

[Copilot]

Pull request overview

This PR documents the missing post-boot E2E assertion spec for fisherman-driven (bootc-installer backend) installs, so projectbluefin/testsuite’s install-flow suite has a single, repo-local reference for closing Dakota’s installer verification gaps tracked in dakota#651.

Changes:

• Add a new “Installer Post-Boot Assertions (fisherman)” section to docs/skills/e2e-ci.md, specifying three required post-boot assertions and a sequencing rule (land as xfail/skip until upstream fixes ship).
• Cross-link the new E2E spec from docs/skills/installer.md under Lessons Learned to keep installer boundary guidance and verification expectations connected.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
docs/skills/e2e-ci.md	Adds a dedicated fisherman installer post-boot assertion spec and reinforces that it belongs in testsuite install-flow (not the inline boot-check gate).
docs/skills/installer.md	Adds a Lessons Learned cross-link to the new fisherman post-boot assertion spec and reiterates repo boundary ownership.

Suppressed comments (1)

docs/skills/e2e-ci.md:137

• The “Source fix tracked at” column currently references “fisherman issue 1/2”, but fisherman issues are disabled (and these aren’t resolvable links). Consider describing these as fisherman PR/commit fixes and pointing back to dakota#651 as the canonical place to keep the live upstream references.

| # | Assertion (post-boot, on the installed target) | Source fix tracked at |
|---|---|---|
| 1 | `flatpak list --system --app` must **not** list `org.bootcinstaller.Installer` (or `.Devel`) — `CopyFlatpaks` must exclude the installer's own Flatpak from the copied system store, not just rely on the firstboot `bluefin-remove-installer.service` cleanup as the only backstop. | fisherman issue 1 |
| 2 | `efibootmgr -v` must show `BootCurrent` plus a Boot entry for the install — requires the installer's `podman run` to bind-mount host `/sys/firmware/efi/efivars` (`-v /sys/firmware/efi/efivars:/sys/firmware/efi/efivars`) so `efibootmgr` can reach host UEFI variables from inside the install container. | fisherman issue 2 |
| 3 | `/proc/cmdline` must contain a parseable LUKS UUID via **either** `rd.luks.uuid=` or `rd.luks.name=` — confirms the `luks-tpm2-autounlock` `rd.luks.name=` parsing fix works against what fisherman actually writes to the bootloader config on a LUKS install. | projectbluefin/common issue 385 |

[castrojo]

Mostly accurate and well-placed — but two factual claims need fixing before merge:

1. "Issues are disabled on tuna-os/fisherman" is false. The GitHub API reports has_issues: true for tuna-os/fisherman, and issues exist there. This claim appears in both e2e-ci.md and installer.md (inherited from dakota#651's body, which has the same error).
2. The "Source fix tracked at" column references the wrong issues. fisherman issue 1 is "feat: Flatpak-packaged installer for installing any bootc image to disk or VM image" [CLOSED] and fisherman issue 2 is "feat: support composefs-native and plain ostree images" — neither is the Flatpak-exclusion or efibootmgr/efivars bind-mount fix described in the table. Either link the real upstream issues/PRs or drop the specific numbers.

What I verified as accurate: dakota#651 exists and matches the three assertions; projectbluefin/common#385 (rd.luks.name parsing) is real and MERGED (so the sequencing note may need updating — the source fix for assertion 3 has landed, "skip-until-fixed" may be closer to flippable than stated); the testsuite reusable e2e.yml does support an installer suite; and the "keep it out of the inline boot-check gate" guidance is consistent with the doc's existing Hard Gate Pattern.

Docs-only, CI green — fix the fisherman references and this is an approve.