docs(skills): add burn-in lessons from the 2026.08.1 soak

[vpetersson-bot]

Issues Fixed

No issue. Captures hard-won lessons from the 2026.08.1 pre-release burn-in so the next one does not repeat them.

Description

Adds a Burn-in / pre-release soak section to testbed-qa, plus a burn-in gate in cut-release. Every rule below is here because it actually bit during the 2026.08.1 soak:

• Verify the playlist is rotating, not just enabled. A board was soaking a single asset with a 300s dwell (fleet standard is 20s), left over from an earlier session. It exercised no asset-loop transition, no decode/teardown, no memory churn, and would have reported clean.
• Soak every supported asset type on every board. Quietly reducing the set per board is coverage loss disguised as caution; a board that cannot run a type is a finding, not a config.
• Never deviate from the shipping configuration without flagging it. Stopping celery to keep a 1 GB board off swap-zero makes the board survive, makes the result meaningless, buries the real finding, and skips whatever runs in celery.
• The lockfile is advisory and does not hold. Assets were enabled on a board by something other than the lock holder while the lockfile read the holder's id. A published finding had to be withdrawn. Capture and diff start/end playlist state; the server access log is the audit trail.
• Verify core dumps by file type, never filename. Every file named core on the fleet is a jsonschema vocabulary JSON, so a find -name 'core*' sweep reports ~100 phantom dumps per board and a -delete would strip package files out of the image layers. Also: Rock Pi 4 sets core_uses_pid=0, so its dumps are a bare core and a core.<pid> sweep skips it.
• ssh in a while read loop eats the loop's stdin and the loop runs once, silently processing only the first board; conversely ssh -n breaks ssh 'bash -s' script piping (empty script, exits 0, looks like a pass).
• Guarded destructive tests. Poll and back the load off at a memory threshold, so an expected OOM becomes a recorded measurement instead of a wedge needing a physical power cycle.

cut-release gains a step 5b placing the burn-in while the release is still a draft (a blocker then costs a deleted draft, not a published tag and a fleet OTA), and notes which commit is the correct soak target.

Docs only. No code paths touched. Section 6 renumbered to 7, cross-references updated.

Checklist

• I have performed a self-review of my own code.
• New and existing unit tests pass locally and on CI with my changes.
• I have done an end-to-end test for Raspberry Pi devices.
• I have tested my changes for x86 devices.
• I added a documentation for the changes I have made (when necessary).

[Copilot]

Pull request overview

Adds burn-in/soak guidance to the hardware testbed QA runbook and wires it into the release-cut checklist so pre-release validation is performed (and reported) before a tag/OTA is published.

Changes:

• Add a new “Burn-in / pre-release soak” section to the testbed-qa skill with concrete, experience-derived burn-in rules and pitfalls.
• Insert a “5b” burn-in gate into cut-release to run the soak while the GitHub release is still a draft, and clarify which commit hash should be soaked.

Reviewed changes

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

File	Description
.claude/skills/testbed-qa/SKILL.md	Adds a dedicated burn-in/soak section and renumbers the per-board quirks section accordingly.
.claude/skills/cut-release/SKILL.md	Adds a draft-stage burn-in gate referencing the new testbed-qa section and commit selection guidance.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.

Suppressed comments (1)

.claude/skills/testbed-qa/SKILL.md:272

• The burn-in guidance hardcodes the Docker bridge gateway as 172.18.0.1, but Docker’s bridge gateway can vary by network/subnet (the code generally treats the bridge range as 172.16.0.0/12). Hardcoding a single IP here may mislead readers when they compare access logs on different hosts.

  holder while the lockfile still read the holder's id, untouched. All API writes
  arrive from the docker bridge gateway (`172.18.0.1`), so the server access log
  cannot attribute them to a session. Consequence: a finding was published and had