@hraness/message-like-me 0.8.2 → 0.8.4

package/CHANGELOG.md

@@ -1,5 +1,37 @@
 # Changelog
 
+## 0.8.4 (2026-09-06)
+
+- Make the exact public `@hraness/message-like-me@0.8.4` npm package the
+  supported default install, with the same reviewed bytes mirrored in the
+  immutable GitHub Release. The product is unchanged from 0.8.3.
+- Let the GitHub Release writer wait briefly for its freshly created draft
+  instead of failing on the first inventory read, so an automated release no
+  longer needs a manual rerun.
+- Fetch the release tag with one more commit of history than the admitted
+  workflow range and prove the production commit is its ancestor before the
+  leased fast-forward, so Git attributes the push instead of reporting a forced
+  update. Every job after promotion path selection carries an explicit
+  skip-aware condition, and a terminal admission fails unless verification and
+  provider admission both succeeded.
+
+## 0.8.3 (2026-09-06)
+
+- Let Beeper users bring a finished private Wrench bundle into the same local
+  evidence corpus as Apple Messages and the other supported sources. The exact
+  public producer is `@hraness/wrench@0.16.7` with adapter
+  `beeper-local@2.4.0`.
+- Pin the reviewed Beeper surface at 32 operations: 26 run through one Beeper
+  CLI 0.6.2 executable, including supported actions and writes, plus six fixed
+  Desktop loopback reads. The upstream tagged source package's 0.6.1
+  declaration is provenance only; executable 0.6.2 is runtime authority.
+- State the process boundary consistently: Message Like Me receives no provider
+  credentials, never calls Wrench or Beeper operations, never sends, and keeps
+  every ingest path read-only with respect to its source.
+- Make the exact public `@hraness/message-like-me@0.8.3` npm package the
+  supported default install, with the same reviewed bytes mirrored in the
+  immutable GitHub Release.
+
 ## 0.8.2
 
 - Fix the automated release admission so the npm provenance signer policy

package/README.md

@@ -11,6 +11,12 @@ The CLI owns ingestion, storage, measurement, and export. Its copied Message
 Like Me and Ensoul Agent Skills teach Codex, Claude, and other coding agents how
 to interpret those artifacts through the agent environment you already use.
 
+Beeper users can bring a bounded observation from supported connected accounts
+into the same private evidence layer as Apple Messages. Wrench writes a finished
+local bundle; Message Like Me verifies and ingests that directory. It receives
+no provider credentials, never calls Wrench or a Beeper operation, and never
+sends. Every ingest path is read-only with respect to its source.
+
 The result is an inspectable evidence layer for relationship-aware drafting,
 not a model of your identity. Your current meaning, facts, and intent outrank
 historical style.
@@ -37,7 +43,7 @@ Message Like Me requires Bun 1.3.14 or newer. Install the exact public npm
 package, then install both bundled Agent Skills:
 
 ```sh
-bun add --global @hraness/message-like-me@0.8.2
+bun add --global @hraness/message-like-me@0.8.4
 messagelikeme skill install
 ```
 
@@ -101,8 +107,8 @@ visibly instead of being treated as current.
 | --- | --- | --- |
 | Apple Messages | The current macOS user's native `chat.db` history | Read-only ingestion from an ownership-checked stable local copy; Messages is never operated or changed. |
 | X data archive | Direct-message history in a caller-owned archive ZIP | X Chat is not included; the importer does not contact X, extract the archive, or download media. |
-| Beeper via Wrench | A bounded local bundle produced by verified Wrench v0.16.5 with Beeper adapter 2.3.0 and executable runtime 0.6.2 | Message Like Me owns zero Beeper operations, credentials, or live sessions; it reads the finished bundle, never sends, and does not claim complete history. |
-| WhatsApp via Wrench | A one-account native bundle produced by Wrench v0.16.5 with official Wacli 0.15.0 | Reaction-shaped rows are omitted with `reaction-state-unproven` when current state cannot be proved. Message Like Me verifies the finished bundle and never operates WhatsApp. |
+| Beeper via Wrench | A finished local bundle from Wrench v0.16.7 and adapter 2.4.0; its reviewed surface has 32 operations: 26 through one pinned Beeper CLI 0.6.2 executable, including supported actions and writes, plus six fixed Desktop loopback reads | Message Like Me receives no provider credentials, never calls Wrench or a Beeper operation, and never sends; it reads only the finished bundle and does not claim complete history. |
+| WhatsApp via Wrench | A one-account native bundle produced by Wrench v0.16.7 with official Wacli 0.15.0 | Reaction-shaped rows are omitted with `reaction-state-unproven` when current state cannot be proved. Message Like Me verifies the finished bundle and never operates WhatsApp. |
 | macOS Contacts | Optional names and exact email or phone handles from AddressBook | Label enrichment only; Contacts is not a messaging-history source and is never changed. |
 
 ## Add private local history
@@ -181,12 +187,12 @@ same or a later archive preserves proven deduplication; archive absence does not
 delete retained history.
 
 To study accounts connected through Beeper, install the currently verified
-[`@hraness/wrench@0.16.5`](https://www.npmjs.com/package/@hraness/wrench/v/0.16.5)
+[`@hraness/wrench@0.16.7`](https://www.npmjs.com/package/@hraness/wrench/v/0.16.7)
 package from npm, then use Wrench to create a new private Message Like Me
 bundle:
 
 ```sh
-bun add --global @hraness/wrench@0.16.5
+bun add --global @hraness/wrench@0.16.7
 wrench beeper export-message-like-me \
   --auth <beeper-auth-id> \
   --output /absolute/private/path/beeper-bundle \
@@ -195,19 +201,21 @@ wrench beeper export-message-like-me \
 
 The optional `--limit-chats`, `--limit-messages`, and `--max-participants`
 flags lower the export bounds. The output path must be a normalized absolute
-path to a directory that does not already exist. Wrench v0.16.5 adapter
-`beeper-local@2.3.0` exposes 32 reviewed Beeper operations: 27 use the pinned
-CLI and 5 use fixed Desktop loopback reads. Message Like Me owns none of
-those operations. The bundle command enters Wrench's separate internal bounded
-export, which fixes the raw export arguments, excludes attachments, and
+path to a directory that does not already exist. Wrench v0.16.7 adapter
+`beeper-local@2.4.0` exposes 32 reviewed Beeper operations: 26 through one
+pinned Beeper CLI 0.6.2 executable, including supported actions and writes, plus
+six fixed Desktop loopback reads. Message Like Me never calls Wrench or any of
+those Beeper operations. The bundle command enters Wrench's separate internal
+bounded export, which fixes the raw export arguments, excludes attachments, and
 preserves explicit incomplete-coverage evidence instead of claiming full
 history.
 
 Wrench calls the pinned
 [official Beeper CLI 0.6.2 release](https://github.com/beeper/cli/releases/tag/v0%2E6%2E2)
-directly. The exact executable reports version `0.6.2`; the tagged source file
-`packages/cli/package.json` declares `0.6.1`. That source value is provenance
-only and never overrides the executable runtime identity. Wrench enumerates
+directly. The executable reports version `0.6.2`, which is the runtime
+authority. At the upstream tag, `packages/cli/package.json` declares `0.6.1`;
+that source-package value is provenance only and never overrides the executable
+runtime identity. Wrench enumerates
 the connected account realm, invokes `export --no-attachments` once per
 account in deterministic order, and reports the account ordinal, elapsed-time
 heartbeats, and cumulative validated chat and message counts on stderr. It
@@ -239,7 +247,7 @@ iMessage and prior bundle sources remain alongside it.
 The interchange, integrity, identity, and reimport laws are in the
 [version-one local message bundle contract](docs/local-message-bundle-v1.md).
 Message Like Me accepts bundle schema `1` with source ID `beeper-local` and
-source-transform version `1.1.0`. Wrench v0.16.5 is the currently verified
+source-transform version `1.1.0`. Wrench v0.16.7 is the currently verified
 producer. Compatibility is determined by those exact manifest coordinates,
 not by an open-ended Wrench package range.
 
@@ -250,11 +258,11 @@ reappearance restores it. Older snapshots cannot overwrite newer state. Use
 `sources show <source-id> --private --json` only when you deliberately need the
 private provider account and source metadata.
 
-For native WhatsApp evidence, install Wrench v0.16.5 and let its official
+For native WhatsApp evidence, install Wrench v0.16.7 and let its official
 Wacli 0.15.0 adapter create the one-account v2 bundle:
 
 ```sh
-bun add --global @hraness/wrench@0.16.5
+bun add --global @hraness/wrench@0.16.7
 wrench whatsapp export-message-like-me \
   --auth <whatsapp-auth-id> \
   --output /absolute/private/path/whatsapp-bundle \
@@ -274,7 +282,7 @@ surfaces are excluded. The complete contract is in
 [local message bundle v2](docs/local-message-bundle-v2.md).
 
 Wacli v0.15.0 may retain an earlier emoji after a reaction is removed, so its
-local rows cannot prove current active reaction state. Wrench v0.16.5 omits
+local rows cannot prove current active reaction state. Wrench v0.16.7 omits
 every reaction-shaped row and adds `reaction-state-unproven` when it observes
 one. An empty `reactions.ndjson` from this producer means reaction behavior was
 unobservable, not that the account had no reactions. The v2 wire contract keeps

package/dist/cli.js

@@ -6214,7 +6214,7 @@ class LocalStore {
 }
 
 // src/version.ts
-var MESSAGE_LIKE_ME_VERSION = "0.8.2";
+var MESSAGE_LIKE_ME_VERSION = "0.8.4";
 
 // src/x-archive.ts
 import { createHash as createHash4 } from "crypto";

package/docs/local-message-bundle-v1.md

@@ -1,18 +1,19 @@
 # Local message bundle version 1
 
-`message-like-me.local-message-bundle` is a private directory interchange for
-moving a bounded local provider observation into Message Like Me. It separates
-provider capture from analysis: a producer handles provider access and writes
-the bundle, while `messagelikeme ingest bundle` verifies and normalizes it. The
-importer never receives provider credentials, starts Wrench, invokes a Beeper
-operation, or sends a message.
+Beeper users can bring a bounded provider observation into Message Like Me's
+private local evidence layer without giving Message Like Me a provider
+credential or send access. Wrench writes a finished
+`message-like-me.local-message-bundle`; `messagelikeme ingest bundle` verifies
+and normalizes that directory. The importer never starts or calls Wrench, never
+invokes a Beeper operation, and never sends. Like every Message Like Me ingest
+path, it is read-only with respect to its source.
 
 The currently verified producer is the local Beeper export in the
-[`@hraness/wrench@0.16.5`](https://www.npmjs.com/package/@hraness/wrench/v/0.16.5)
+[`@hraness/wrench@0.16.7`](https://www.npmjs.com/package/@hraness/wrench/v/0.16.7)
 npm package:
 
 ```sh
-bun add --global @hraness/wrench@0.16.5
+bun add --global @hraness/wrench@0.16.7
 wrench beeper export-message-like-me \
   --auth <beeper-auth-id> \
   --output <normalized-absolute-new-directory> \
@@ -31,16 +32,18 @@ express.
 ## Compatibility coordinates
 
 Message Like Me accepts schema version `1` with source ID `beeper-local` and
-source-transform version `1.1.0`. Wrench v0.16.5 emits those coordinates through
-adapter `beeper-local@2.3.0`. That adapter has 32 reviewed Beeper operations:
-27 use the pinned CLI and 5 use fixed Desktop loopback reads. The Message
-Like Me bundle is made by Wrench's separate internal bounded export, not by a
-Message Like Me provider operation. It fixes the raw export arguments, excludes
-attachments, and preserves incomplete-coverage evidence. It does not claim a
-complete Beeper history.
-
-The pinned Beeper CLI executable reports version `0.6.2`. At the corresponding
-source tag, `packages/cli/package.json` declares `0.6.1`; that source value is
+source-transform version `1.1.0`. Wrench v0.16.7 emits those coordinates through
+adapter `beeper-local@2.4.0`. That adapter has 32 reviewed Beeper operations:
+26 through one pinned Beeper CLI 0.6.2 executable, including supported actions
+and writes, plus six fixed Desktop loopback reads. The Message Like Me bundle is
+made by Wrench's separate internal bounded export, not by a Message Like Me
+provider operation. It fixes the raw export arguments, excludes attachments,
+and preserves incomplete-coverage evidence. It does not claim a complete
+Beeper history.
+
+The pinned Beeper CLI executable reports version `0.6.2`; that executable is
+the runtime authority. At the upstream source tag,
+`packages/cli/package.json` declares `0.6.1`; that source-package value is
 provenance only and never overrides executable runtime identity. A later Wrench
 package release remains compatible only while its manifest still declares the
 same bundle schema, source ID, and `source.version: "1.1.0"`. Package age,
@@ -49,8 +52,9 @@ coordinates. The provider version records the pinned Beeper CLI used for
 capture and may change without changing the bundle contract.
 
 Message Like Me owns zero Beeper operations, credentials, or live sessions. It
-does not start Wrench, call the provider, or support sending. Its authority
-begins at strict verification of the already finished private directory.
+does not start or call Wrench, call the provider, or support sending. Its
+authority begins at strict verification of the already finished private
+directory.
 
 The dependency-free package subpath is the executable contract authority for
 producers and consumers:

package/docs/local-message-bundle-v2.md

@@ -10,7 +10,7 @@ network, or sends a message.
 The intended producer flow is:
 
 ```sh
-bun add --global @hraness/wrench@0.16.5
+bun add --global @hraness/wrench@0.16.7
 wrench whatsapp export-message-like-me \
   --auth <whatsapp-auth-id> \
   --output /absolute/private/path/whatsapp-bundle
@@ -20,7 +20,7 @@ messagelikeme ingest bundle \
   --json
 ```
 
-The checked compatibility coordinates are Wrench v0.16.5 and official Wacli
+The checked compatibility coordinates are Wrench v0.16.7 and official Wacli
 v0.15.0. Wrench owns that executable dependency and its authentication state;
 neither enters Message Like Me.
 
@@ -89,7 +89,7 @@ byte disagreement, and SHA-256 disagreement. The same public bounds as v1
 apply, except v2 admits exactly one account.
 
 The v2 wire contract retains the fixed `reactions.ndjson` artifact and strict
-reaction parser for proven records. The checked Wrench v0.16.5/Wacli v0.15.0
+reaction parser for proven records. The checked Wrench v0.16.7/Wacli v0.15.0
 producer leaves that artifact empty because it cannot prove current reaction
 state.
 
@@ -162,7 +162,7 @@ duplicates cannot prove equivalence.
 
 Both source provenances and all source-unique history remain stored. Proven
 message duplicates contribute once. A reaction can deduplicate only when a
-conforming producer supplies a proven reaction record; Wrench v0.16.5 supplies
+conforming producer supplies a proven reaction record; Wrench v0.16.7 supplies
 none, so this overlap path does not reconcile reaction state. The native Wacli
 conversation is the preferred action route and carries the exact private
 `whatsappJid` coordinate. Its proven Beeper duplicate remains evidence with

package/docs/publishing.md

@@ -164,51 +164,145 @@ App-pinned status context, integration ID, enforcement state, and empty bypass
 sets before admitting a release. Any drift blocks promotion until it is reviewed
 and repaired out of band.
 
-### Bootstrap one workflow-control epoch
+### Review one workflow-control epoch
 
-The routine promotion is intentionally incapable of crossing a change to
+Routine promotion remains incapable of silently crossing a change to
 `.github/workflows/**`. Its complete-history gate rejects that range before the
-key environment even though GitHub may allow a contents-capable token to move a
-ref to an existing workflow-changing commit. The permanent App has only
-`statuses:write` plus `metadata:read`; it cannot move any ref. The checked
-workflow must never mint persistent App `contents` or `workflows` authority or
-treat permission omission alone as the workflow-control boundary.
-
-When an already-established `website-production` ref predates reviewed workflow
-control changes, perform one separately approved control-epoch bootstrap after
-the target's immutable Release and public npm bytes have passed admission:
-
-1. Record the exact current production SHA, exact release SHA, annotated tag,
-   immutable Latest Release, ruleset readbacks, and the complete reviewed commit
-   range. Let the routine promotion fail at its workflow-range gate; do not
-   approve the key environment for that rejected run.
-2. In an owner-operated, out-of-band procedure, explicitly authorize a single
-   control-epoch credential selected to numeric repository ID `1342143606` with
-   only the temporary permissions needed to post the pinned status and move the
-   workflow-changing ref. Keep that credential out of Actions and preserve the
-   required-status-check and ref-lifecycle rulesets.
-3. Post the exact App-sourced success status for the release SHA, then use the
-   same fixed repository, exact annotated-tag target, and nonempty
-   `--force-with-lease=refs/heads/website-production:<expected-old-sha>` contract
-   to make exactly one fast-forward. Immediately replace the success with the
-   terminal non-success status, revoke the credential, and prove the ref is the
-   exact release SHA. Never leave a reusable success context behind.
-4. Restore and read back the permanent App's exact `statuses:write` plus
-   `metadata:read` closure, absence of `contents` and `workflows` authority, and
-   singleton repository set. Generate a fresh App private key, replace
-   `MLM_RELEASE_APP_PRIVATE_KEY`, and delete the control-epoch key. Routine
-   automation must remain paused until both the App downgrade and key rotation
-   are proven.
-5. Dispatch `Promote website production` for the same immutable tag. Because
-   the external bootstrap made the ref already exact, recovery stays outside
-   `production-ref-writer-key`, mints no token, and accepts only the bounded
-   exact-SHA Vercel Production outcome that postdates the Release.
-
-That bootstrap closes one workflow-control epoch; it is not precedent for a
-routine broad token, a persistent ref bypass, or an unleased manual ref move.
-Any later release whose newly reachable history contains a workflow-tree change
-starts a new control epoch and requires its own explicit review and
-authorization.
+key environment. A reviewed workflow change uses the v2 control-epoch digest;
+it does not use an out-of-band ref write or broaden either credential. The
+permanent App remains exactly `statuses:write` plus `metadata:read`, and only the
+job-scoped `GITHUB_TOKEN` may perform the existing explicit-lease ref move after
+the pinned App status exists.
+
+When an established protected ref predates reviewed workflow-control changes:
+
+1. Keep the workflow disabled except during each separately bound dispatch. Record the
+   exact protected-ref SHA, target SHA, current workflow-source SHA, repository
+   ID, tag coordinate, ruleset readbacks, and public release admission. Dispatch
+   the production or canary workflow once with an empty
+   `control_epoch_digest`. That run must fail at the complete-history gate before
+   the contents-writer environment is admitted and before any status-only App
+   token is minted.
+2. Preserve the failed step summary. It must contain the exact v2
+   domain, protected ref, old SHA, target SHA, current workflow-source SHA, tag
+   (or canary `no-tag` sentinel), ordered old-through-workflow-source commit inventory,
+   every corresponding `.github/workflows` tree OID, the derived ordered change
+   list, and the canonical lowercase SHA-256 digest. Independently reconstruct
+   that inventory from only the governed refs and review every workflow-tree
+   transition. Failed-step command-file outputs are not retrievable review
+   evidence. Do not trust the digest without reviewing its complete preimage.
+   In a disposable, complete, non-shallow clone populated only with the exact
+   advertised `main`, protected branch, and (for production) stable annotated-tag
+   refs, substitute the recorded values and reconstruct the ordered inventory:
+
+   ```sh
+   protected_ref=refs/heads/website-production # use the canary ref for a canary run
+   old_sha=<40-hex-protected-ref-sha>
+   target_sha=<40-hex-target-sha>
+   workflow_sha=<40-hex-current-main-sha>
+   tag=<stable-tag-or-no-tag>
+
+   test "$(git rev-parse --is-shallow-repository)" = false
+   test "$(git rev-parse --verify "${protected_ref}^{commit}")" = "$old_sha"
+   test "$(git rev-parse --verify 'refs/heads/main^{commit}')" = "$workflow_sha"
+   git merge-base --is-ancestor "$old_sha" "$target_sha"
+   git merge-base --is-ancestor "$target_sha" "$workflow_sha"
+   if [ "$tag" = no-tag ]; then
+     test "$target_sha" = "$workflow_sha"
+   else
+     test "$(git rev-parse --verify "refs/tags/${tag}^{commit}")" = "$target_sha"
+   fi
+   test "$(git rev-list --count "$old_sha..$workflow_sha")" -le 250
+   {
+     printf '%s\n' "$old_sha"
+     git rev-list --topo-order --reverse "$old_sha..$workflow_sha"
+   } | while IFS= read -r commit_sha; do
+     printf '%s %s\n' "$commit_sha" \
+       "$(git rev-parse --verify "${commit_sha}:.github/workflows")"
+   done
+   ```
+
+   Compare every printed commit/tree pair, in order, with the failed-run summary;
+   adjacent rows with different tree OIDs must exactly match its changed-row
+   markers. The target must appear in that inventory. Then use the reviewed
+   helper from that same audited workflow-source checkout to reconstruct the
+   canonical receipt and digest:
+
+   ```sh
+   MODE=production \
+   PREVIOUS_SHA="$old_sha" \
+   TARGET_SHA="$target_sha" \
+   WORKFLOW_SHA="$workflow_sha" \
+   PROTECTED_REF="$protected_ref" \
+   VERIFIED_TAG="$tag" \
+   node --input-type=module -e '
+     import { describeControlEpoch } from "./scripts/release-workflow-range.mjs";
+     const receipt = describeControlEpoch({
+       currentMainSha: process.env.WORKFLOW_SHA,
+       mode: process.env.MODE,
+       previousSha: process.env.PREVIOUS_SHA,
+       protectedRef: process.env.PROTECTED_REF,
+       repository: "hraness/message-like-me",
+       repositoryId: 1342143606,
+       tag: process.env.VERIFIED_TAG,
+       targetSha: process.env.TARGET_SHA,
+       workflowSha: process.env.WORKFLOW_SHA,
+     });
+     process.stdout.write(JSON.stringify(receipt) + "\n");
+   '
+   ```
+
+   The resulting JSON's domain, ref, coordinates, ordered `inventory`, derived
+   `changes`, and `digest` must exactly match the human-readable failed-step
+   summary. Use `MODE=canary`, the canary ref, `tag=no-tag`, and a target equal to
+   the workflow source for a canary review. Do not fetch an unbounded ref
+   namespace, hand-assemble a digest, use a different checkout, or reorder the
+   inventory.
+3. Dispatch one fresh manual attempt 1 from exact current `main` with that exact
+   digest. Automatic `workflow_run` events, rerun attempts, already-exact refs,
+   and unchanged-workflow ranges must reject any digest. The gate recomputes the
+   complete inventory and digest before environment admission; any source, tag,
+   ref, target, ancestry, inventory, or digest drift fails closed.
+4. Before approving `production-ref-writer-key`, compare the fresh run title,
+   tag, v2 domain, protected ref, old SHA, target SHA, workflow-source SHA,
+   ordered inventory, change list, and digest with both the independently
+   reviewed failed-run summary and the locally reconstructed receipt. Reject the
+   environment admission if any field or ordered
+   inventory row differs. After approval, the hash-pinned helper
+   recomputes and revalidates the same transition before reading the key. The
+   normal split-authority sequence then applies unchanged: terminalize the status
+   to the exact App-authored `error`, then prove the writer is denied with one exact
+   `GH013: Repository rule violations found for refs/heads/website-production.`
+   payload and one exact `remote: - Required status check "message-like-me/website-production-authority" is errored.`
+   reason. Before exact comparison, normalize only one consistent known Git
+   non-TTY display suffix: zero, one, or eight ASCII spaces on both semantic
+   remote lines. Any other trailing byte, suffix length, or mixed framing is a
+   rejection. Mutable
+   Git progress, transport ordering, and helper-label framing are diagnostic
+   only; the hash-pinned helper's fixed executable, remote, arguments, and
+   refspec bind the operation.
+   Post and read back one App-authored success,
+   revoke that App token, make one exact non-force fast-forward with a nonempty
+   expected-old lease, replace success with the terminal non-success status
+   using a separately minted status-only token, revoke it, and complete the
+   read-only provider outcome gate.
+5. After provider success, read back the protected ref at the exact target and
+   treat that target's `.github/workflows` tree OID as the baseline for the next
+   routine range. Re-read the permanent App's exact `statuses:write` plus
+   `metadata:read` permissions, absence of `contents` and `workflows` authority,
+   singleton `{hraness/message-like-me}` repository selection, and the terminal
+   non-success status. A completed epoch requires no key rotation because it
+   created or replaced no credential and every short-lived App token was revoked;
+   an interrupted run still follows the separate quarantine and cleanup
+   procedure.
+
+The digest is scoped to one exact transition and is never permission to reuse a
+stale run, skip fresh ref and source readbacks, expand the App, add a personal
+token or deploy key, recreate a protected ref, force a move, or mutate a
+ruleset. If a run is interrupted, follow the quarantine and cleanup procedure;
+never treat the digest as retry authority. A later range with any different
+coordinate or inventory requires a new no-digest rejection and independent
+review.
 
 ### Prove the split status-and-writer boundary before product release
 
@@ -217,16 +311,34 @@ release, precreate persistent ref
 `refs/heads/website-production-writer-canary` at the reviewed control commit.
 Apply separate active rulesets with the same no-bypass protections and the same
 App-pinned required status check to that exact canary ref. Prove every side of
-the split credential contract after the App downgrade and key rotation:
-
-1. The negative workflow-delta canary targets a reviewed descendant that
-   changes `.github/workflows/**`. The complete-history gate must reject it
-   before environment admission and before token minting. Permission omission
-   is not the gate: record the complete-history rejection itself.
-2. The positive non-workflow canary targets a reviewed descendant for which
+the split credential contract:
+
+1. The workflow-delta canary targets exact current `main`, which changes
+   `.github/workflows/**`. First prove the empty-digest rejection before
+   environment admission, independently review the complete v2 receipt, then
+   prove that one fresh manual attempt 1 with its exact digest recomputes the
+   transition before and after environment admission and advances only that
+   target. Permission omission is not the gate: retain both runs and their exact
+   receipts as evidence.
+2. A later positive non-workflow canary targets a reviewed descendant for which
    every newly reachable commit preserves the baseline workflow-tree OID. Prove
-   the status-only App token cannot update the ref and the job-scoped writer
-   token cannot update it before the exact App-sourced success exists.
+   it accepts no digest and uses the unchanged v1 routine receipt. Prove
+   the status-only App token cannot update the ref. After posting and reading
+   back the App-authored terminal `error`, prove the job-scoped writer token is
+   rejected with exactly one `GH013: Repository rule violations found for
+   refs/heads/website-production-writer-canary.` payload and exactly one
+   `remote: - Required status check "message-like-me/website-production-writer-canary-authority" is errored.`
+   reason. Before exact comparison, normalize only one consistent known Git
+   non-TTY display suffix: zero, one, or eight ASCII spaces on both semantic
+   remote lines. Any other trailing byte, suffix length, or mixed framing is a
+   rejection.
+   Mutable Git progress, transport ordering, and helper-label framing are
+   diagnostic only; the hash-pinned helper's fixed executable, remote,
+   arguments, and refspec bind the operation.
+   An `is expected` reason, a missing-status interpretation, another state,
+   branch, context, duplicate GH013 payload, or multiple rule reasons is not
+   this proof. The writer must remain unable to update until the exact
+   App-sourced success exists.
 3. Post one success status on the exact positive target under context
    `message-like-me/website-production-writer-canary-authority`, prove its exact
    readback, and revoke that short-lived status-only token. With the success
@@ -394,17 +506,23 @@ recovery. Both paths use the same checks. That workflow:
 3. enters `production-ref-writer-key` with `deployment:false` only when the
    baseline and a separate read-only preflight prove that the ref must advance.
    That preflight first imports complete exact governed history and enumerates
-   every commit newly reachable in `<expected-old>..<verified-release>`, capped
-   at 250 commits. It rejects shallow or incomplete history, non-fast-forwards,
-   malformed or oversized inventories, and any commit whose
-   `.github/workflows` tree OID differs from the expected-old baseline. Checking
-   every newly reachable commit catches merge-side changes and an edit followed
-   by a revert even when the two endpoint trees match. The fresh secret-bearing
-   job installs no dependencies; in a step that does not receive the private
-   key, it verifies hard-coded SHA-256 pins for the seven reviewed helpers,
-   repeats the exact complete-history proof, and emits a bounded receipt binding
-   the expected-old SHA, release SHA, commit count and digest, and baseline
-   workflow-tree OID. The promotion helper validates that receipt before it may
+   every commit from the expected-old protected-ref SHA through the exact
+   current workflow-source SHA, capped at 250 newly reachable commits. It proves
+   the tagged release target is an advancing ancestor inside that range and
+   rejects shallow or incomplete history, non-fast-forwards, and malformed or
+   oversized inventories. Checking every ordered `.github/workflows` tree OID
+   catches merge-side changes and an edit followed by a revert even when two
+   endpoint trees match. If every tree preserves the baseline, any supplied
+   digest is forbidden and the frozen v1 receipt binds the expected-old and
+   release SHAs, transition commit count and digest, and baseline workflow-tree
+   OID. If any tree changes, the empty-digest attempt publishes the full v2
+   inventory, derived tree transitions, current workflow source, tagged target,
+   and canonical digest, then rejects before the writer environment. Only a
+   fresh manual attempt 1 carrying that independently reviewed exact digest may
+   continue. The secret-bearing job installs no dependencies; in a step that
+   does not receive the private key, it verifies hard-coded SHA-256 pins for the
+   seven reviewed helpers and recomputes the selected v1 or v2 receipt before
+   reading the key. The promotion helper validates that receipt before it may
    enter the App-token lifecycle. A checked local helper then signs a
    bounded RS256 App JWT, authenticates the exact App ID, client ID, slug, and
    organization owner, then reads the checked installation ID and requires its
@@ -605,9 +723,19 @@ exact existing npm version and immutable artifact-complete Latest Release. It
 never creates, replaces, or edits an npm version or GitHub Release.
 
 If `website-production` still precedes the release commit, recovery performs
-the same checked explicit-lease fast-forward only when every newly reachable
-commit preserves the baseline workflow-tree OID, and requires one new provider
-outcome.
+the same checked explicit-lease fast-forward and requires one new provider
+outcome. A baseline-preserving range uses the frozen v1 no-digest receipt; a
+workflow-changing range requires the exact independently reviewed v2 digest and
+recomputes its old-through-current-workflow-source inventory before authority.
+The sterile writer fetches only the exact verified tag, with one more commit of
+history than the admitted workflow range, and proves the expected production
+commit is its ancestor before pushing. Missing ancestry or a non-fast-forward
+target fails before the ref can move; the push receipt must still report one
+ordinary fast-forward rather than a forced update. Because exactly one of the
+advance and already-exact jobs is intentionally skipped, every job after path
+selection has an explicit skip-aware status condition. The final public
+admission runs as a terminal sentinel and fails unless verification and provider
+admission both succeeded, so a skipped tail cannot make the workflow green.
 If the ref is already exact, the baseline marks advancement false, skips the
 entire `production-ref-writer-key` job, and mints no App token. A separate
 read-only job accepts only the unique latest exact-SHA Production deployment in
@@ -616,9 +744,10 @@ itself must be provider-accepted. A newer terminal failure, error, or inactive
 attempt blocks recovery instead of allowing an older success to be reused.
 Recovery then repeats the terminal authority readbacks. A missing ref is a hard
 failure and must not be recreated by the workflow. If the desired transition
-crosses any workflow change, use the separately approved control-epoch
-bootstrap above; after that exact external advancement, the already-exact
-recovery path supplies the provider proof without reading the App key.
+crosses any workflow change, use the reviewed v2 control-epoch digest above.
+The exact-digest attempt performs the normal checked lease advancement; it does
+not externally advance the ref. A later already-exact recovery, if needed,
+supplies only the provider proof and remains outside the key environment.
 
 When a tag run fails after its exact draft or immutable Release exists, preserve
 its evidence and rerun that same workflow. Re-running only failed jobs is
@@ -629,5 +758,5 @@ the same tag, commit, deterministic draft, and tarball; npm provenance must bind
 the same run ID and an allowed actual positive attempt. Correct only the failed
 control and use the website recovery path after public admission succeeds. Do
 not retag, delete the immutable Release or exact residual draft, manually move
-`website-production` outside the one separately approved control-epoch
-bootstrap, redeploy from Vercel, or weaken a ruleset to make the run pass.
+`website-production`, reuse a stale control-epoch digest as retry authority,
+redeploy from Vercel, or weaken a ruleset to make the run pass.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@hraness/message-like-me",
-  "version": "0.8.2",
+  "version": "0.8.4",
   "description": "A local-first CLI and Agent Skill for studying private messaging history and drafting messages that sound like you.",
   "license": "MIT",
   "type": "module",

package/skills/message-like-me/SKILL.md

@@ -116,7 +116,7 @@ messagelikeme ingest bundle --input <absolute-private-whatsapp-bundle> --json
 Do not request or handle Wacli session state or WhatsApp linked-device
 authentication, call Wacli, inspect its database, synchronize the account, or
 open bundle records in agent context. Wrench owns those provider operations.
-The Wrench v0.16.5/Wacli v0.15.0 producer omits every reaction-shaped row and
+The Wrench v0.16.7/Wacli v0.15.0 producer omits every reaction-shaped row and
 reports `reaction-state-unproven` when it encounters one because current active
 or removed state is not durable. Treat that warning, and an empty reaction
 artifact from this producer, as unobservable reaction behavior. Do not infer

package/skills/message-like-me/references/privacy.md

@@ -21,7 +21,7 @@ sensitive local data.
   synchronize a linked device, inspect its database, or expose exact JIDs.
   Wrench owns that provider boundary. `--overlap-source` requires explicit
   intent and exact CLI proof; it never authorizes fuzzy account or contact
-  matching. The Wrench v0.16.5 producer omits reaction-shaped Wacli rows with
+  matching. The Wrench v0.16.7 producer omits reaction-shaped Wacli rows with
   `reaction-state-unproven`; never turn that missing evidence into a claim that
   no reactions occurred.
 - Treat a caller-owned X data archive ZIP as private source evidence. Pass only