{
  "summary": "[P1] Candidate identity is not bound to the bytes accepted on all three hosts. `ci/publish/release-acquire-int.sh:43-74` accepts a release using only repository/tag, registration text, install-directory text, manifest version, and one shared string; it never downloads or hashes `adapter.spt`. The positive fake in `tests/release-acquire.sh:21-48,103-112` therefore passes all three targets without providing any release-asset bytes. Independently, `ci/release/validate-release-evidence.py:99-110` checks only that each record contains an artifact named `adapter.spt`, while the cross-record identity tuple at `:113-135` contains version/tag/commit/tree but omits that artifact's SHA-256. Passing-invalid example: Windows accepts archive A, GNU accepts a tag-replaced archive B, and musl accepts replacement C; all expose version `0.3.0` and the expected label. Give the three otherwise-valid records identical release fields but `adapter.spt` SHA values `11…11`, `22…22`, and `33…33`. Every acquisition check and the combined evidence validator pass, although the final hosted C was never accepted on Windows or GNU. Release impact: a stable asset can be promoted without one candidate having passed the advertised target matrix. Discrete fix: require an operator-supplied expected adapter SHA-256, download the exact tagged `adapter.spt` with `gh`, hash and compare it before `spt adapter add`, report that verified digest, and include the named `adapter.spt` digest in the validator's cross-record identity. Add wrong-download-digest and mixed-adapter-digest rejection tests.\n\n[P2] The runbook promotes before the mandatory machine records are authored, validated, or attached. `docs-site/src/reference/release-evidence.md:4-15` says a release is promotable only after every supported-target record exists and that records/referenced logs belong on the same GitHub release. In contrast, `docs/RELEASE-RUNBOOK.md:264-273` executes `gh release edit --prerelease=false --latest`; the `Release record` procedure does not begin until `:309`, validation is at `:313-320`, and attachment is only instructed at `:321`. Passing-invalid example: an operator follows the ordered runbook, all informal endpoint checks appear green, and promotion succeeds; the subsequently authored GNU record then fails the validator for a mixed source identity or malformed evidence reference. The release is already stable/latest without a valid complete record set, and the procedure supplies no rollback. Release impact: the documented evidence contract can be violated by following the canonical release procedure exactly. Discrete fix: move record authoring/validation ahead of section 8, explicitly upload the three records and every referenced log while the release is still a prerelease, verify those assets, and only then permit promotion.\n\n[P2] The release-binary validator labels and packages files that an OS loader cannot execute. The PE path at `ci/publish/validate-release-binary.py:30-61` checks only signatures, machine, a nonzero section count, the first two optional-header bytes, and `IMAGE_FILE_EXECUTABLE_IMAGE`; it does not validate the full PE32+ optional header or section table, does not reject `IMAGE_FILE_DLL`, and does not require an entry point in an executable section. The ELF path unpacks but discards `e_entry` at `:75-91`, discards `p_flags` at `:107-118`, and treats any `PT_LOAD` as sufficient at `:147-168`. The repository itself contains passing-invalid examples: `tests/adapter-archive.sh:57-65` creates a 512-byte pseudo-PE with a zeroed optional header and no valid section image, while `:68-113` creates ET_DYN ELF files with `e_entry = 0`; `:239-250` expects the packer to accept all three as release helpers. Release impact: the packer can emit a structurally exact, reproducible archive whose selected native helper immediately fails to launch; the documented malformed-binary guard is therefore a false pass. Discrete fix without cross-executing binaries: for PE, require a complete bounded PE32+ optional header and section table, reject `IMAGE_FILE_DLL`, and require a nonzero `AddressOfEntryPoint` mapped into a bounded executable section; for ELF, retain a nonzero `e_entry`, require it to fall inside a `PF_X` `PT_LOAD`, and enforce `p_filesz <= p_memsz`. Turn the current pseudo-images into negative fixtures and replace the positive fixtures with minimally loader-valid images.",
  "files": [
    {
      "path": "ci/publish/release-acquire-int.sh",
      "description": "P1: tagged acquisition validates version and registration metadata but not the acquired archive's SHA-256 (`43-74`)."
    },
    {
      "path": "tests/release-acquire.sh",
      "description": "P1 passing-invalid proof: fake acquisition succeeds for every target with no asset bytes (`21-48,103-112`)."
    },
    {
      "path": "ci/release/validate-release-evidence.py",
      "description": "P1: requires an `adapter.spt` name but excludes its digest from cross-record candidate identity (`99-135`)."
    },
    {
      "path": "tests/release-evidence.py",
      "description": "P1 coverage gap: the complete-target positive records are exercised, but no mixed-`adapter.spt`-digest case is rejected (`27-67,92-98,151-155`)."
    },
    {
      "path": "docs-site/src/reference/release-evidence.md",
      "description": "P1/P2 contract: rebuilt artifact bytes define a new candidate, and complete attached target records are prerequisites to promotion (`4-20,39-50`)."
    },
    {
      "path": "docs/RELEASE-RUNBOOK.md",
      "description": "P2: stable/latest promotion precedes record authoring, validation, and attachment (`264-321`)."
    },
    {
      "path": "ci/publish/validate-release-binary.py",
      "description": "P2: PE and ELF validation omits loader-critical entry-point/section/segment checks (`30-61,75-118,147-168`)."
    },
    {
      "path": "tests/adapter-archive.sh",
      "description": "P2 passing-invalid proof: intentionally synthetic non-loader-valid PE and zero-entry ELF fixtures are treated as successful release inputs (`57-151,239-250`)."
    }
  ],
  "architecture": "The P1 defect spans both ends of candidate custody: acquisition does not establish the downloaded archive digest, and aggregate evidence does not require one archive digest across targets. The two P2 defects are independent: the canonical procedure crosses the promotion boundary before its evidence gate, and the archive gate's native-format parser proves labels/linkage fragments rather than the documented executable contract."
}