Complete the pre-Compile semantic read-back

[raghubetina]

Summary

• make the pre-Compile approval read-back a canonical six-part checklist
• preserve staged subject identities while keeping new-subject UUID guidance strict
• record the failed earlier 0.1.2 qualification and refresh the unpublished candidate digest

Verification

• sh script/check (70/70)
• exact CLI-backed package check at d37d8b6775a0b97ce10bd651485bd308fed1dda2
• Skill validator
• deterministic package SHA-256 074e9cd2b88cf86e1b0c3e737c94ab03c8b1328df0d299818d09dd919f50aed2
• conversation-aware and adversarial documentation reviews
• fresh blind read-back

Public npm and marketplace state remains 0.1.1; this PR does not publish or promote 0.1.2.

[raghubetina]

Post-merge review, hosted CI green. Two durable contributions here, one now-compacted structure.

The durable parts: first, the failure evidence file
(evidence/2026-08-17-claude-plugin-0.1.2-approval-flow-failure.md), which records the failed earlier
qualification with exact identities for every component (Skills commit, tarball SHA-256, CLI, service, runner,
even the Claude executable hash) plus hashes of the retained sanitized transcript and per-phase responses. It
is labeled failure evidence, never PASS evidence, which is exactly the discipline the repository's
evidence-boundary rules ask for. Second, the digest refresh correctly treats the revised unpublished candidate
as a new exact identity.

The six-part canonical read-back checklist this PR introduced was later compacted by #40 into the two-turn
smoke's "complete semantic read-back" plus the execution-consequences sentence (Compile does not deploy;
Publication creates one private repository). The substance survived; the enumerated structure did not. Read
the checklist portion as historical.

[raghubetina]

The most instructive file in this PR is the one recording a failure. Most teams write up successes and let
failures evaporate into chat scrollback. This repo commits failure evidence with the same rigor as passing
evidence, and the shape of that file is worth copying.

Look at what it pins: the exact commit of every involved component, the SHA-256 of the candidate tarball, the
CLI version, the local service commit, the evaluation runner hash, and then hashes of the retained transcript
and of each phase's response. Credentials, raw Plan contents, and model traces are excluded, and the file says
so. The header states its epistemological status outright: "failure evidence, never PASS or release evidence."

Why bother hashing a transcript nobody may ever reread? Because a failure record without exact identities
decays into an anecdote. Six weeks later, someone asks "did the approval flow ever fail, and was that before
or after we changed the gate?" With this file the answer is checkable: the failure happened at Skills commit
c27ca527 against candidate e89a14b7..., so any run after the gate changed is a different experiment. Without
it, the answer is somebody's memory.

The practical recipe: when an important process fails, record the exact versions of everything involved,
retain the artifacts, hash what you retain, sanitize before storing, and label the record as failure evidence
so it can never be miscited as proof the process works. The hashing habit is cheap (shasum -a 256) and turns
"we kept some logs" into "we can prove which logs."