Implement the Workers Static Assets provider with verified postconditions

[forkwright]

Finding

Typikon embeds Cloudflare deployment behavior in generated workflows. It has no typed provider implementation, provider-neutral request/result schema, or provider fixture corpus — deployment postconditions are verified only by fixture-tested shell/Python, not by a typed, portable boundary.

Evidence

Deployment logic is distributed across workflow templates and shell/Python checks. Two of the five absences originally named here have since landed:

• ci/check-cf-deploy-gate.py extracts the deploy step's run: block verbatim from ci/github-workflow.yml.tmpl and proves it halts before Wrangler runs unless Cloudflare's PATCH response reports .success == true and .result.production_branch exactly matches the branch being shipped — a postcondition readback, fixture-tested against 5 response shapes, not transport-success-as-proof (Assert the Cloudflare production-branch mutation before deploy #63).
• ci/deploy-manifest.toml + ci/validate-deploy-bundle.py require and syntax-check _headers/_redirects/404.html before deploy and hash the bundle into a receipt, covered by 12 deletion/corruption fixtures in ci/check-deploy-bundle-gate.py — the exact bundle inventory (Require and verify deployment control files before deploy #48).

Still genuinely absent: crates/typikon-provider-workers, a provider-neutral request/result schema, and a provider fixture corpus in that crate — i.e. the typed, portable provider. #48 and #63 own the shell-level v1 defects that produced the two landed mechanisms above; neither owns the durable typed provider.

Why this matters

Portability and a compile-time contract do not follow from a fixture-tested shell script, however well it is tested. Without a typed boundary, a second provider cannot reuse the request/result contract, and nothing prevents the shell path and a future typed path from silently diverging.

Desired correction

Implement a provider-neutral bundle/deploy/postcondition contract in core and a Workers Static Assets provider in crates/typikon-provider-workers. Accept only a validated exact-digest bundle, perform the bounded provider mutation, read authoritative state back, redact credentials, and emit a content-addressed receipt binding request, artifact, response, and observed deployment identity.

Done when fixtures cover malformed/unsuccessful responses, missing assets, upload mismatch, wrong branch or project state, readback disagreement, retry/idempotency behavior, and credential redaction, in the typed crate; deploy success requires postcondition support, not transport success, at the typed boundary as it already does at the shell boundary. This durable mechanism extends rather than closes #48 and #63 by intent alone.

Program: ardent-web-triad. Refs #48 #63.

[forkwright]

Scoping concern: this asks for a provider-neutral contract behind exactly one provider

Raised while sequencing the v2 program, which the operator has ratified running in full. This is not a request to drop the issue — it is a request to build the concrete half first and let the abstraction be earned.

The concern

This issue's Done when requires a provider-neutral bundle/deploy/postcondition contract in core plus a concrete crates/typikon-provider-workers. There is no second provider anywhere in the fleet, and none proposed.

That is the same speculative-generality shape #66 correctly objected to for renderers — supporting a boundary "no current consumer requires" — and the fleet has already ratified the answer for that case. D-065 (kanon/projects/kanon/planning/discussion-queue.md, status: resolved, ratified 2026-08-07, whose issue_refs include this cluster) says:

add an Eleventy or other adapter only after a real consumer adopts it and a cross-adapter fixture plus consumer receipt proves the boundary. Defer Astro entirely while it has no subject.

and, more generally:

Core should contain neutral semantic primitives and stable composition seams; Leather's craft skin, Tools' evidence language, and consulting-specific compositions remain consumer-owned until reuse proves a narrower abstraction.

The principle is that an abstraction enters core when a second real case proves its shape, not when someone anticipates one. Applied consistently, it lands on providers exactly as it landed on renderers.

What to build instead

Build the concrete Cloudflare Workers implementation with clean internal seams. Do not publish a provider-neutral contract in core until a second provider is real. When one arrives, the seams are where the boundary gets extracted — and it will be shaped by two actual cases rather than one plus a guess.

One thing already correct that should be preserved

The current shell path is not merely a placeholder to be discarded. ci/check-cf-deploy-gate.py extracts the run: block from ci/github-workflow.yml.tmpl verbatim and stubs curl/wrangler to test it — so the branch-mutation assertion and control-file verification are already correctly implemented and fixture-tested. That behaviour is the oracle this crate must reproduce. Diff the new implementation against it on the same fixtures before deleting the old path, for the same reason recorded on #67.

Dependencies

HARD on #65 (the request/result schema is a core type). Practically hard on #67 — the "validated exact-digest bundle" this consumes is #67's bundle output, so the crate's internals can be unit-tested against a stubbed bundle shape, but nothing here is proven end-to-end until #67 exists.

[forkwright]

This issue's Finding is substantially stale, and the stale half is the part that makes it sound
urgent.

"currently treats transport success as proof of requested provider state"

Not at main. ci/check-cf-deploy-gate.py exists precisely to prove otherwise — the generated deploy
step reads Cloudflare's PATCH response and halts before Wrangler runs unless the body reports
.success == true and .result.production_branch exactly equals the branch being shipped
(landed for #63). The fixture extracts that step's run: block verbatim from the template and
executes it under stubbed curl/npm/wrangler, so it exercises the literal shipped shell rather
than a paraphrase of it.

That is a postcondition readback with fixture coverage. It is not the typed provider this issue asks
for, but it is not "transport success as proof" either.

Also landed since filing: the "exact bundle inventory" named among the absences. ci/deploy-manifest.toml
plus ci/validate-deploy-bundle.py require and syntax-check _headers, _redirects and 404.html
before deploy, hash the bundle into a receipt, and are covered by twelve deletion/corruption fixtures
in ci/check-deploy-bundle-gate.py (#48).

What remains genuinely absent: crates/typikon-provider-workers, a provider-neutral
request/result schema, and a provider fixture corpus — i.e. the typed, portable provider. Three of
the five named absences, not five.

The distinction is not pedantry. As written, this reads as "deployment is unverified", which would
make it urgent and sequence it early. What is actually missing is portability and typing on top of
verification that already exists, which is a different priority.

Recommend re-reading #65, #66, #67 against main before B-068 sequences any of them; #69 has the same
problem and now carries a note.

[forkwright]

Body edited to match main at d1d9b5e, per the 2026-08-21 comment above. Re-verified independently before editing: ci/check-cf-deploy-gate.py has 5 CASES (success/unsuccessful/malformed/missing-result/wrong-branch) exercising the postcondition halt; ci/check-deploy-bundle-gate.py has 12 CASES exercising the bundle-manifest checks. Evidence now lists exactly the three absences that remain (crates/typikon-provider-workers, the request/result schema, the provider fixture corpus); Desired correction and Done-when are otherwise unchanged, since they describe what to build rather than what currently exists.