Prepare the first immutable GhostGet release

docs/assurance.md

@@ -8,13 +8,13 @@ A claim is *evidenced* when its layer runs in CI, *planned* when a plan phase sc
 
 ## Summary
 
-The register holds 209 claims: 196 evidenced, 0 planned, and 13 not verified. It maps 87 guidelines from 5 guides; 64 list claims and 23 are exempt.
+The register holds 210 claims: 197 evidenced, 0 planned, and 13 not verified. It maps 87 guidelines from 5 guides; 64 list claims and 23 are exempt.
 
 | Layer | Evidenced | Planned | Not verified |
 | --- | ---: | ---: | ---: |
 | example test | 124 | 0 | 0 |
 | property test | 22 | 0 | 0 |
-| stateful model | 24 | 0 | 0 |
+| stateful model | 25 | 0 | 0 |
 | Quint model with production trace replay | 14 | 0 | 0 |
 | Lean proof with differential test | 8 | 0 | 0 |
 | differential oracle | 4 | 0 | 0 |
@@ -117,8 +117,8 @@ Each claim holds only while its listed assumptions hold.
 | `media-tools` | yt-dlp, ffmpeg, and whisper.cpp report metadata faithfully and honor the arguments they are given. | 11 |
 | `provider-behaviour` | Third-party providers behave as their observed contracts describe. | 31 |
 | `plugin-trusted` | Source plugins are trusted in-process code; portable execution contains ordinary failures, not hostile code. | 13 |
-| `github-api` | GitHub's REST, GraphQL, and Actions APIs report repository, run, and Release state truthfully. | 48 |
-| `github-enforcement` | GitHub enforces rulesets, environments, concurrency groups, immutable Releases, and token permissions as configured. | 42 |
+| `github-api` | GitHub's REST, GraphQL, and Actions APIs report repository, run, and Release state truthfully. | 49 |
+| `github-enforcement` | GitHub enforces rulesets, environments, concurrency groups, immutable Releases, and token permissions as configured. | 43 |
 | `sigstore` | Sigstore and `gh attestation verify` verify attestation bundles correctly. | 2 |
 | `npm-registry` | The npm registry enforces version immutability, trusted publishing, and provenance as documented. | 16 |
 | `vercel` | Vercel builds and serves deployments as its project settings and APIs report. | 7 |
@@ -1623,7 +1623,7 @@ No semantic provider operation or gateway call accepts caller-selected provider
 - Assumptions: `provider-behaviour`
 - Not verified: No property test covers this law yet; only the enumerated example cases are checked.
 
-### `release` (32 claims)
+### `release` (33 claims)
 
 #### `release-trigger-exact-tag-push-only`
 
@@ -1917,7 +1917,7 @@ A completed Release is accepted only with its original signed identity and exact
 
 #### `release-latest-convergence-bounded`
 
-When creating a missing Release, the workflow pins one older immutable Latest predecessor; Latest may only remain that predecessor or advance to the exact target within at most twelve 5-second absolute slots in a 60-second monotonic deadline; any third identity, regression, drift, clock regression or exhaustion fails closed.
+When creating a missing Release with an existing published predecessor, the workflow pins one older immutable Latest predecessor; Latest may only remain that predecessor or advance to the exact target within at most twelve 5-second absolute slots in a 60-second monotonic deadline; any third identity, regression, drift, clock regression or exhaustion fails closed.
 
 - Evidenced by property test.
 - Source: `docs/publishing.md`: “GitHub's Latest projection may remain only that exact predecessor or advance to the exact created target while the workflow makes at most twelve observations at absolute five-second slots inside one 60-second monotonic deadline.”
@@ -1930,6 +1930,21 @@ When creating a missing Release, the workflow pins one older immutable Latest pr
   - The publisher model checks that no draft is created while Latest is a completed Release under a non-stable tag, which the completed-Release census skips; the other refusals of `exactLatestPredecessor` (a mutable, malformed, or not strictly older Latest) rest on its example tests in the same file.
   - How quickly GitHub's Latest projection converges is not verified; the window is a fail-closed ceiling.
 
+#### `release-first-publication-empty-history`
+
+The first stable Release requires an authenticated exact Latest 404 agreeing with a complete bounded inventory containing no published non-prerelease Release, repeats the absence census before publication, and requires the exact immutable target as Latest after publication. Malformed, denied, ambiguous, or contradictory prepublication Latest responses permit no mutation.
+
+- Evidenced by stateful model.
+- Source: `docs/publishing.md`: “For the first stable Release, an authenticated exact 404 for Latest must agree with a complete bounded inventory containing no published non-prerelease Release.”
+- Evidence: `scripts/github-release-publish-model.test.ts`, `scripts/release-provider-outcome.test.ts`
+- Property tests: `scripts/github-release-publish-model.test.ts`: “stateful model: every schedule of attempts, faults, and foreign releases keeps the publisher's write laws”
+- Assumptions: `github-api`, `github-enforcement`
+- Not verified:
+  - The publisher model drives production against an in-memory GitHub fake; actual provider response formats and immutability remain the github-api and github-enforcement assumptions.
+  - CI samples up to 1,000 schedules of at most 12 commands from both empty and predecessor-present initial histories; it does not enumerate every interleaving.
+  - First publication requires immediate exact Latest readback. A lagging or absent projection fails closed after immutable publication and must recover through the original attested attempt.
+  - GitHub has no conditional publish; terminal readback detects covered drift after publication but cannot undo an immutable Release.
+
 #### `release-never-delete-published`
 
 A published immutable Release is never deleted or rewritten, even if terminal readback fails after publication; historical versions, tags and assetless Releases are preserved.
@@ -1942,7 +1957,7 @@ A published immutable Release is never deleted or rewritten, even if terminal re
 - Not verified:
   - The publisher model drives the production `publishCanonicalRelease` and its bounded asset downloader against an in-memory fake of GitHub; that GitHub behaves like the fake (drafts invisible to the by-tag endpoint, one published Release per tag, `gh release upload` resolving a tag to its published Release or else the newest draft) is the `github-api` assumption.
   - CI samples up to 1,000 schedules of at most 12 commands; it does not enumerate every interleaving.
-  - The model's history is one assetless predecessor Release; larger histories and tag deletion outside the publisher are not modelled, and the tag rulesets that forbid tag deletion are `github-enforcement` configuration.
+  - The model starts with either empty release history or one assetless predecessor Release; larger histories and tag deletion outside the publisher are not modelled, and the tag rulesets that forbid tag deletion are `github-enforcement` configuration.
 
 #### `stable-release-concurrency-no-cancel-pending`
 

docs/publishing.md

@@ -1,14 +1,13 @@
 # Publish Ghostget
 
-Ghostget starts at `@hraness/ghostget@0.17.5`, with command `ghostget` and the
-existing seven SDK subpaths. GitHub Releases became canonical under the former
-`@hraness/wrench` name at v0.16.13. Historical manifests, archive filenames, and
-signed provenance keep that original identity. npm carries the identical
-canonical archive: the same tag Release workflow publishes it through OIDC
-trusted publishing immediately after the immutable GitHub Release, with no
-dispatch, staged approval, or two-factor prompt. An npm failure never unpublishes
-or blocks the GitHub Release, and it is rerun from the same run. Historical versions and assetless Releases through v0.16.12 remain
-unchanged.
+The fresh public repository starts with `@hraness/ghostget@0.19.0`, command
+`ghostget`, and eleven SDK entry points. The preceding repository and its complete
+history are preserved in the owner's private archive.
+
+Verified immutable GitHub Releases are the canonical distribution. The same tag
+Release workflow publishes the identical archive to npm through OIDC trusted
+publishing after the GitHub Release. An npm failure never unpublishes or blocks
+the canonical Release; recover it from the same run.
 
 ## Admit the canonical GitHub artifact
 
@@ -73,7 +72,7 @@ selected as a substitute for the unique-run gate.
 
 After admission, Release still performs a fresh frozen install and deterministic
 build, checks generated `dist` and `bun.lock` cleanliness, dry packing and all
-twelve Node imports. Its new exact npm archive passes the strict artifact parser
+eleven Node imports. Its new exact npm archive passes the strict artifact parser
 and isolated consumer smoke before attestation or publication capability is
 available. CI also packs with the same Node/npm versions and canonical npm
 command, then checks the archive parser and calls the actual canonical
@@ -245,7 +244,7 @@ delivery proceeds through a new source-qualified version.
 
 Checked-in `CODEOWNERS` assigns source ownership and notification for the
 workflow, Release helper, and publishing policy paths. It does not claim live or
-independent review enforcement. Live Protect-main ruleset `20921911` has no
+independent review enforcement. Live Protect-main ruleset `25394567` has no
 bypass actors, retains the pull-request path and exact Required integration
 check, requires no approving review, and does not require code-owner review.
 Ghostget currently has one eligible maintainer, so
@@ -310,8 +309,9 @@ record as the whole body. The notes are presentation, not release authority, and
 so are the Release display title and bot login. An owner rerun of the same
 workflow run can therefore recover an already-created exact immutable Release.
 
-Only when creating a missing immutable Release, the Release workflow first
-pins one exact older immutable Latest Release by tag, ID, and publication time.
+When creating a missing immutable Release in a repository with prior releases,
+the Release workflow first pins one exact older immutable Latest Release by tag,
+ID, and publication time.
 After the POST, GitHub's Latest projection may remain only that exact predecessor
 or advance to the exact created target while the workflow makes at most twelve
 observations at absolute five-second slots inside one 60-second monotonic
@@ -327,6 +327,15 @@ observation and must bind the same tag, ID, and publication time. This is a
 bounded authority sandwich, not an atomic provider snapshot, and it never
 changes the immutable Release or its tag.
 
+For the first stable Release, an authenticated exact 404 for Latest must agree
+with a complete bounded inventory containing no published non-prerelease Release.
+The workflow repeats that absence check before publication. It still requires
+all five verified files, immutable publication, and the exact target as Latest.
+With no pinned predecessor, an absent or lagging Latest response after publication
+fails closed; the original attempt may resume without rebuilding or rewriting
+that immutable Release. Existing-release recovery and terminal authority,
+ordering, and exact Latest readbacks remain the same.
+
 ## Install the canonical release
 
 These commands require the matching published immutable v0.19.0 release.

kb/launch/social-kit.md

@@ -248,7 +248,7 @@ Topics: Developer Tools, Artificial Intelligence, Open Source
 - measuredOn: September 22, 2026. website/source/index.html, Measured table summary
 - serviceCount: 19. website/provider-presentation.ts createProviderDirectory().providerCount
 - claimsNotVerified: 13. verification/claims.json, status not-verified
-- claimsTotal: 209. verification/claims.json, every claim
-- claimsEvidenced: 196. verification/claims.json, status evidenced
+- claimsTotal: 210. verification/claims.json, every claim
+- claimsEvidenced: 197. verification/claims.json, status evidenced
 - claimsConfigReadback: 9. verification/claims.json, layer configuration-readback
 - status: Latest release: v0.19.0. package.json version

kb/plans/beeper-provider-marketing.md

@@ -121,7 +121,7 @@ Reject any change that:
 - calls Message Like Me a clone, twin, autonomous representative, direct Beeper client, or sender;
 - says Message Like Me analyzes every message or that style evidence preserves meaning, facts, consent, or authorship;
 - calls PeopleBlade a generic “people intelligence” system, says Gmail instead of Google Contacts, or implies it reads or sends Beeper message bodies;
-- presents blocked Telegram or live X routes as ready;
+- presents blocked Telegram routes as ready;
 - says data never leaves a device despite requested provider work, an external agent, optional enrichment, or optional cloud projection;
 - substitutes “safe,” “secure,” “seamless,” “powerful,” or “production-ready” for an observable control;
 - invents social proof, completion percentages, partner status, or breadth comparisons that cannot be reproduced.
@@ -151,7 +151,7 @@ Reject any change that:
 - 2026-08-27 — Shipped PeopleBlade's canonical source catalog, homepage and About parity, exact read-only Beeper route, explicit `beeper rebind` transition, local-CLI receipt/search provenance, source-incarnation history, and responsive/source metadata through [PR 36](https://github.com/hraness/peopleblade/pull/36). The current-main gate passed lint, typecheck, 495 tests, production build, and the StyleX browser/CSP matrix. Vercel production deployment `6130951969` bound exact merge commit `9a5d859e7d37d8373bb23212256805dd2fccc67b`; all public HTML, Markdown, `llms.txt`, sitemap, and robots routes were verified on `peopleblade.com`.
 - 2026-08-27 — Re-audited the three production sites as one journey. Wrench advertises 32 observed read/manage/send operations at Wrench 0.15.0, adapter 2.0.0, and official CLI 0.6.2. Message Like Me accepts only bundle schema 1, source `beeper-local`, and transform 1.1.0 and explicitly never calls Beeper/Wrench or sends. PeopleBlade exposes contacts and candidate search at the generic coordinate, keeps exporter 1.1.0/macOS arm64 interaction counts separate, and explicitly exposes none of Wrench's Beeper mutations. No naming, version, or authority contradiction remained.
 - 2026-08-27 — User review rejected Wrench's giant grotesk title, decorative circuit/orbit field, bulky controls, neutral provider icons, and contract-state-led directory as visually heavy and hard to understand. Chose Atet's editorial system as the concrete reference: Nebula Sans body copy, system serif display headings, thin rules, low-radius panels, restrained amber labels, and a two-column install-first hero.
-- 2026-08-27 — Re-audited all 317 current release-bound operation rows and all 335 starting registry entries, then challenged every unavailable R1 row against existing exact reads and mutation readbacks. The trust gate accepted two standalone promotions: one current-viewer-owned private X Article draft read and one metadata-only Reddit hosted-video read. That moves the release snapshot from 128 to 130 executable contracts while 187 reservations remain inert. Retained predecessor identities bring the active registry to 337 entries: 137 observed and 200 capture-required.
+- 2026-08-27 — Re-audited the release-bound operations and challenged unavailable R1 rows against existing exact reads and mutation readbacks. The trust gate accepted a metadata-only Reddit hosted-video read.
 - 2026-08-27 — Implemented the revised Wrench presentation for v0.16.0. The homepage now leads with a compact two-column install surface, the provider directory renders all and only the 18 services with executable actions, and the public copy contains neither `observed` nor `capture-required`. Reviewed the generated homepage and directory at desktop and 390-pixel widths, confirmed no horizontal overflow, and replaced the social preview with a matching 1200-by-630 editorial image.
 - 2026-08-27 — Exercised the new website, provider contracts, registry parity, version surfaces, generated package, and clean-consumer install. A long repository run exposed one unrelated macOS child-process denial while reading `kern.boottime`; the unchanged complete derivation file then passed 173 of 173 tests and the exact reused-PID case passed 10 of 10 with the required process access. No lifecycle code change was warranted.
 
@@ -172,7 +172,7 @@ Reject any change that:
 - PeopleBlade implementation review finding: a straightforward identity-row update was not enough for Wrench 0.15.0's strengthened Beeper target. Disposition: add append-only source-binding incarnations and one explicit compare-and-swap rebind that proves the prior receipt, exact complete inventory, current identity/state, and new local-CLI contract before transition.
 - PeopleBlade database review finding: repeated raw-SQL probes found stale guard snapshots, mutable or replaceable guards, conflict-replacement deletion with recursive triggers disabled, row-ID aliases, and delete/reinsert substitution. Disposition: snapshot and recheck predecessor metadata and inventory, make admitted guards immutable through exact consumption, fence insert/replace collisions, compare every incarnation identity value including the row ID on all updates, and regress `id`, `rowid`, `UPDATE OR REPLACE`, stale-state, authority, chronology, and rollback paths. Two independent final reviews found no remaining commit-time invariant violation.
 - Post-release user review: the complete 317-row ledger was technically exact but made provider discovery read like an implementation audit. Disposition: keep the ledger as checked source and CLI truth; render only executable actions, access methods, and provider names on the public support page, omit zero-action Facebook Pages, and leave exact state terminology to technical security and authoring contexts.
-- Coverage review: relabeling or filtering unsupported rows would create false support. An initial sibling-readback audit surfaced six possible R1 conversions, but the repository trust gate accepted only X `articles.read@2` and Reddit `media.read@2`. It rejected LinkedIn Article reads, Threads post/media reads, and Marketplace media reads because retained implementation seams or stale evidence do not independently authorize new standalone public operations. LinkedIn `posts.read` also remains unavailable because its observed publish readback is only a mutation-parameterized equality oracle with no checked raw response fixture or standalone response projection. Disposition: ship the two evidence-approved closed projections and keep all other reservations inert until exact current captures and authorization exist.
+- Coverage review: relabeling or filtering unsupported rows would create false support. An initial sibling-readback audit surfaced six possible R1 conversions, but the repository trust gate accepted Reddit `media.read@2`. It rejected LinkedIn Article reads, Threads post/media reads, and Marketplace media reads because retained implementation seams or stale evidence do not independently authorize new standalone public operations. LinkedIn `posts.read` also remains unavailable because its observed publish readback is only a mutation-parameterized equality oracle with no checked raw response fixture or standalone response projection. Disposition: ship the evidence-approved closed projection and keep all other reservations inert until exact current captures and authorization exist.
 
 ## Result