diff --git a/.github/workflows/offline-verification.yml b/.github/workflows/offline-verification.yml
new file mode 100644
index 0000000..66c07b0
--- /dev/null
+++ b/.github/workflows/offline-verification.yml
@@ -0,0 +1,113 @@
+name: Phase 0 and Wallet Kernel offline verification
+
+on:
+ pull_request:
+ paths:
+ - 'phase0/**'
+ - 'prototype/**'
+ - 'spikes/pi-wielder/**'
+ - '.claude/skills/optimizing-claude-code-prompts/**'
+ - '.github/workflows/offline-verification.yml'
+ push:
+ branches: [main]
+ paths:
+ - 'phase0/**'
+ - 'prototype/**'
+ - 'spikes/pi-wielder/**'
+ - '.claude/skills/optimizing-claude-code-prompts/**'
+ - '.github/workflows/offline-verification.yml'
+ workflow_dispatch:
+
+permissions:
+ contents: read
+
+jobs:
+ phase0:
+ name: Phase 0 provenance CLI
+ runs-on: ubuntu-24.04
+ timeout-minutes: 20
+ defaults:
+ run:
+ working-directory: phase0
+ steps:
+ - name: Check out reviewed source
+ uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
+ with:
+ persist-credentials: false
+
+ - name: Install Node 22
+ uses: actions/setup-node@49933ea5288caeca8642d1e84afbd3f7d6820020 # v4.4.0
+ with:
+ node-version: 22.22.0
+ cache: npm
+ cache-dependency-path: phase0/package-lock.json
+
+ - name: Install locked dependencies
+ run: npm ci
+
+ - name: Run Phase 0 tests
+ run: npm test
+
+ - name: Typecheck Phase 0
+ run: npm run typecheck
+
+ - name: Verify the Phase 0 checkout stayed clean
+ working-directory: .
+ shell: bash
+ run: |
+ set -euo pipefail
+ git diff --check
+ test -z "$(git status --porcelain)"
+
+ wallet-kernel:
+ name: Wallet Kernel deterministic evidence
+ runs-on: ubuntu-24.04
+ timeout-minutes: 30
+ defaults:
+ run:
+ working-directory: spikes/pi-wielder
+ steps:
+ - name: Check out reviewed source
+ uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
+ with:
+ persist-credentials: false
+
+ - name: Install exact Wallet Kernel Node runtime
+ uses: actions/setup-node@49933ea5288caeca8642d1e84afbd3f7d6820020 # v4.4.0
+ with:
+ node-version: 24.18.1
+ cache: npm
+ cache-dependency-path: spikes/pi-wielder/package-lock.json
+
+ - name: Install locked dependencies
+ run: npm ci
+
+ - name: Run the complete offline spend-control story
+ run: npm run verify:spend-control
+
+ - name: Build and independently verify deterministic evidence
+ shell: bash
+ run: |
+ set -euo pipefail
+ evidence_parent="$(mktemp -d "${RUNNER_TEMP}/pi-wielder-evidence.XXXXXX")"
+ npm run evidence:offline -- \
+ --output "${evidence_parent}/bundle" \
+ --anchor-output "${evidence_parent}/manifest.sha256"
+ manifest_sha256="$(tr -d '\n' < "${evidence_parent}/manifest.sha256")"
+ npm run evidence:verify -- "${evidence_parent}/bundle" \
+ --expect-manifest-sha256 "${manifest_sha256}"
+
+ - name: Reject tracked secrets
+ run: npm run verify:no-secrets
+
+ - name: Run shared economics regressions
+ working-directory: prototype
+ run: npm test
+
+ - name: Verify the checkout stayed clean
+ working-directory: .
+ shell: bash
+ run: |
+ set -euo pipefail
+ git diff --check
+ test -z "$(git status --porcelain)"
diff --git a/.github/workflows/site.yml b/.github/workflows/site.yml
new file mode 100644
index 0000000..008fa56
--- /dev/null
+++ b/.github/workflows/site.yml
@@ -0,0 +1,52 @@
+name: Site verification
+
+on:
+ pull_request:
+ paths:
+ - 'README.md'
+ - 'site/**'
+ - '.github/workflows/site.yml'
+ push:
+ branches: [main]
+ paths:
+ - 'README.md'
+ - 'site/**'
+ - '.github/workflows/site.yml'
+
+permissions:
+ contents: read
+
+jobs:
+ verify:
+ runs-on: ubuntu-24.04
+ timeout-minutes: 20
+ defaults:
+ run:
+ working-directory: site
+ env:
+ NEXT_TELEMETRY_DISABLED: '1'
+ steps:
+ - name: Check out reviewed source
+ uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
+
+ - name: Install exact Node runtime
+ uses: actions/setup-node@49933ea5288caeca8642d1e84afbd3f7d6820020 # v4.4.0
+ with:
+ node-version: 22.23.2
+ cache: npm
+ cache-dependency-path: site/package-lock.json
+
+ - name: Install locked dependencies
+ run: npm ci
+
+ - name: Run dependency-free behavior tests
+ run: npm test
+
+ - name: Lint site source
+ run: npm run lint
+
+ - name: Build production site
+ run: npm run build
+
+ - name: Reject high and critical dependency advisories
+ run: npm audit --audit-level=high
diff --git a/README.md b/README.md
index b401027..afa7a1a 100644
--- a/README.md
+++ b/README.md
@@ -1,82 +1,127 @@
-
-
# Skill Asset Protocol
-A compensation, attribution, and metering layer for authored AI **Skills** — "Carta for AI
-work artifacts." Creators keep a durable economic claim each time others use their Skill,
-instead of handing the value over once under work-for-hire.
+## Agent Spend Control Plane
-This is a **research/spike repository**: design documents plus executable evidence, not a
-product. Every claim below is labeled measured, modeled, or hypothesis.
+Give AI agents a wallet without giving them the keys.
-**The manifesto is live — and it is a working protocol endpoint:
-[neverhandedover.com](https://neverhandedover.com)** (also at
-[skillassetprotocol.com](https://skillassetprotocol.com); source in [`site/`](site/)).
+The approved commercial direction is a customer-hosted **Agent Spend Control
+Plane**. Its central module, the **Wallet Kernel**, turns an Agent's ordinary
+HTTP request into a bounded Spend Intent, evaluates customer policy, obtains
+exact human approval when required, signs only an authorized x402 payment through
+a customer-owned wallet, and records a signed receipt for every outcome.
-## The demo result
+This remains a **design-and-spike repository**, not a production product. The
+current Wallet Kernel evidence is offline and deterministic. The networked mode
+is constrained by design to test USDC on Base Sepolia but has **not been run**;
+mainnet and real funds are unsupported. See the
+[approved design](docs/superpowers/specs/2026-07-31-agent-spend-control-plane-design.md)
+for the complete product, security, and acceptance boundaries.
-On 2026-07-12, one wallet paid per model call **and** per hosted-skill invocation over x402
-(Base Sepolia, real facilitator, real USDC), landing both asset classes in one attributed
-session ledger:
+The commercial v1 is spending policy, auditability, and reconciliation:
-```
-claude/plan $0.041 · skill $0.25 → creator $0.24375 / treasury $0.00625
+- customer-hosted policy enforcement and authoritative records;
+- a customer-owned wallet, with CDP as the first adapter;
+- default-deny budgets, allow-listed sellers, and exact one-time approvals;
+- x402 v2 `exact` payments only;
+- durable recovery and signed receipts for settled, failed, refunded, and
+ unresolved outcomes.
+
+It is not wallet custody, token trading, an inference reseller, or a
+marketplace. Skill attribution and Creator compensation are deferred expansion
+modules: they may later consume Wallet Kernel receipts, but they do not define
+the v1 operator experience.
+
+## Pre-release website candidate
+
+The source in [`site/`](site/) is an offline, deterministic candidate preview of
+the wallet-control product. It demonstrates policy loading, automatic allow,
+deny, exact approval, deliberate retry, and an unsigned session projection. It
+does not connect a wallet, sign a receipt, or broadcast a transaction.
+
+The approved design's release gate remains binding: this candidate must not
+replace the public homepage until the required implementation and fresh,
+recomputable evidence qualify. The separate `/proof` route is a static archive
+with one narrowly supported historical Base Sepolia receipt; the website no
+longer exposes a wallet or paid invocation endpoint.
+
+### Run the website locally
+
+Use Node 22, then run from the repository root:
+
+```bash
+cd site
+npm ci
+npm run dev
```
-On-chain balances reconciled to the cent (Wielder 20 → 19.668 USDC; sellers received exactly
-0.332). Measured x402 payment overhead across 48 settled calls (2026-07-15, two model providers):
-**p50 731 ms / p95 1206 ms per paid call** — facilitator verify/settle is nearly all of it
-(p50 729 ms); the 402 roundtrip + EIP-3009 signature add ~2 ms.
-Details and txHashes: [`spikes/pi-wielder/README.md`](spikes/pi-wielder/README.md).
+Open . The homepage needs no environment file, account,
+wallet, API key, network request, or payment.
-## Try it offline — zero keys, zero funds
+## First commercial offer
-All four proofs run with no API keys, no network payments, and no wallet. Where a
-`package-lock.json` exists, `npm ci` is the reproducible choice.
+The first paid offer is a customer-hosted design-partner pilot for one Pi
+workflow, one customer-owned CDP testnet wallet, and one or more allow-listed
+Base Sepolia x402 resource servers. The pilot adds customer-defined automatic
+and approval-required policy, durable budgets and restart recovery, a local
+operator console, signed receipt and reconciliation export, and a final control
+review.
-| Where | Commands | Proves |
+This pilot is intended to test whether an AI platform or gateway team will pay
+for governed autonomous spending. That demand has not yet been validated.
+
+## Evidence status
+
+One public historical claim is supported by the retained evidence manifest:
+on 2026-07-12, a successful Base Sepolia transaction transferred `250000`
+atomic units (`0.25`) of test USDC, and the repository's historical run log
+labels it as the Skill-leg settlement. See the
+[receipt manifest](spikes/pi-wielder/evidence/2026-07-12-skill-settlement/manifest.json).
+
+That receipt does **not** prove current endpoint behavior, latency,
+Royalty claim split correctness, Skill execution output, independent demand, or
+production readiness. A later aggregate timing summary is quarantined and is
+not used in product claims because its normalized samples were not retained;
+see its
+[non-publishable manifest](spikes/pi-wielder/evidence/2026-07-15-overhead/manifest.json).
+
+All current product-preview states and receipts are deterministic simulations.
+A future testnet product claim requires a fresh, immutable, recomputable
+evidence bundle as specified in the approved design.
+
+## Try the existing proofs offline
+
+The repository also retains earlier attribution, settlement, provenance, and
+clone-economics research. These are inputs to the Wallet Kernel work or deferred
+research; they are not proof that the commercial v1 is complete.
+
+| Where | Command | Scope |
|---|---|---|
-| `spikes/pi-wielder` | `npm install && npm run e2e` | 20 checks: 402-first on every leg, no skill-content leak, replay rejection, exact split match |
-| `spikes/clone-economics` | `npm run e2e` (no install) | 97 checks: deterministic clone-distillation harness, byte-identical reruns |
-| `prototype` | `node spike-fork-economics.mjs` (no install) | 64 invariants: fork/royalty economics on the settlement engine |
-| `phase0` | `npm install && npm test` | 18 tests: Story provenance registration against injected fakes |
+| `site` | `npm test` | Deterministic wallet-control preview and public-claim guards |
+| `spikes/pi-wielder` | `npm ci && npm test && npm run e2e` | Offline wallet policy, x402, journal, receipt, and failure-path spike |
+| `spikes/clone-economics` | `npm run e2e` | Deterministic clone-distillation research |
+| `prototype` | `npm test` | Settlement and attribution accounting invariants |
+| `phase0` | `npm ci && npm test` | Story provenance behavior against injected fakes |
+
+These automated paths require no funded wallet or network payment. Follow each
+directory's README for its exact environment and safety boundary.
## What's here
-- **`CONTEXT.md`** — the ubiquitous language: Skill, Creator, Wielder, Beneficiary, Collar,
- Invocation, Derivative, Royalty claim.
-- **`docs/adr/`** — 8 decision records, including 0007 (the closed-mode compensation layer is
- the terminal product) and 0008 (the Wielder is a wallet, not a harness).
-- **`spikes/`** — pi-wielder (one wallet, two asset classes, unified ledger) and
- clone-economics (how cheaply can N paid outputs be distilled into a clone?).
-- **`prototype/`** — the settlement engine (pure logic) plus fork-economics and CMA-latency
+- **`docs/superpowers/specs/2026-07-31-agent-spend-control-plane-design.md`**
+ — the approved Wallet Kernel and commercial-pilot design.
+- **`site/`** — the pre-release offline wallet-control candidate and a separate
+ static historical proof archive.
+- **`spikes/pi-wielder/`** — the hardened wallet, policy, x402, journal,
+ receipt, refund, and reconciliation evidence that the Wallet Kernel will
+ evolve from.
+- **`CONTEXT.md` and `docs/adr/`** — the canonical protocol language and prior
+ decisions. The compensation and attribution model remains longer-term
+ research rather than the v1 product interface.
+- **`prototype/`** — settlement and attribution accounting logic plus economic
spikes.
-- **`phase0/`** — Story Protocol provenance: register a Skill as an IP Asset and declare
- Derivatives (Aeneid testnet only).
-- **`.claude/skills/` and `.agents/skills/`** — the bundled example skill
- (`optimizing-claude-code-prompts`) is **intentionally public**. The protocol's claim is that
- a Wielder never receives the skill at runtime — output only — not that the skill is secret.
- The spikes host and meter this exact skill behind the Collar.
-
-## Evidence status
-
-The repo's discipline is to label every number:
-
-- **Measured (real network, n=48 settled calls + a live pi session):** the runs above — real
- 402 → sign → settle, real USDC per call, splits credited by the settlement engine, wallet
- reconciled on-chain to the cent; two failure modes documented (pay-then-fail, settled-but-rejected).
-- **Measured (n=3, one model):** hosted-agent cold start — first answer token p50 ~2.5 s;
- pay-then-run-async reads as usable on top of the ~0.8 s testnet payment gate.
-- **Measured (N=6, small fixtures):** the clone attack **failed on fidelity** — all 6 held-out
- cases failed critical gates — but modeled break-even is **8 invocations** if a clone ever
- passes. Cost is no defense; fidelity was. High-N behavior is **unknown**.
-- **Modeled (deterministic arithmetic, not observed behavior):** education-mode flow-through
- is dominated by free re-authoring — every school-paying royalty rate loses at parity, so
- Education mode is deferred.
-- **Validated arithmetically:** settlement splits, multi-level derivative flow-through, and
- payment gating ("no credential, no run") via the engine's invariants.
-
-Unvalidated: that employers will buy this. Design-partner interviews remain the open step.
+- **`phase0/`** — Story Protocol provenance experiments on Aeneid testnet only.
+- **`.claude/skills/` and `.agents/skills/`** — the intentionally public example
+ Skill used by earlier spikes.
## License
diff --git a/docs/README.md b/docs/README.md
new file mode 100644
index 0000000..02580c5
--- /dev/null
+++ b/docs/README.md
@@ -0,0 +1,28 @@
+# Documentation
+
+## Current v1 product design
+
+- [Agent Spend Control Plane — approved design](superpowers/specs/2026-07-31-agent-spend-control-plane-design.md)
+ — the current wallet-native direction: a customer-hosted **Wallet Kernel**
+ for x402 spending policy, exact approvals, signed receipts, and reconciliation.
+
+## Deferred expansion research
+
+- [Employer onboarding, retention, and monetization recommendations](product-onboarding-retention-and-monetization.md)
+ — superseded for v1 and retained as research for a possible future Skill
+ attribution and Creator-compensation module.
+
+## Security
+
+- [Dependency security audit](dependency-security-audit.md)
+
+## Architecture decisions
+
+- [ADR-0001 — Hosted invocation-rights](adr/0001-skills-as-hosted-invocation-rights.md)
+- [ADR-0002 — Story programmable IP](adr/0002-tokenize-skills-as-programmable-ip-on-story.md)
+- [ADR-0003 — Payment-gated execution](adr/0003-payment-gated-execution.md)
+- [ADR-0004 — Economic and network moats](adr/0004-compete-on-moats-not-secrecy.md)
+- [ADR-0005 — Two-leg settlement](adr/0005-two-leg-cross-chain-settlement.md)
+- [ADR-0006 — Closed modes first](adr/0006-phased-rollout-closed-modes-first.md)
+- [ADR-0007 — Closed-mode compensation as the terminal product](adr/0007-closed-mode-compensation-layer-as-terminal-product.md)
+- [ADR-0008 — The Wielder is a wallet](adr/0008-the-wielder-is-a-wallet.md)
diff --git a/docs/dependency-security-audit.md b/docs/dependency-security-audit.md
new file mode 100644
index 0000000..c8c2d6e
--- /dev/null
+++ b/docs/dependency-security-audit.md
@@ -0,0 +1,115 @@
+# Dependency security audit
+
+- Original dependency audit: 2026-07-26
+- Updated for the spend-control site revision: 2026-08-02
+
+Scope: the Next.js application in `site/`, including production and development
+dependencies, the image optimizer path, and deployment-adjacent server code.
+
+## Executive summary
+
+- The 2026-07-26 install reported 12 high-severity findings before remediation.
+- At that verified dependency snapshot, `npm audit --omit=dev` reported **0
+ vulnerabilities**.
+- At that snapshot, the full development tree reported 9 high-severity package
+ entries. They all traced to one `brace-expansion` denial-of-service advisory
+ in the ESLint tool chain, not nine independent defects.
+- `npm audit fix --force` was rejected because npm proposes incompatible major
+ changes and invalid historical downgrades of the Next.js lint configuration.
+
+Those dependency-audit results are a historical verification record. The
+current PR refreshed the lockfile on 2026-08-02 and now resolves the legacy
+`brace-expansion` path to patched 1.1.18 and the modern path to patched 5.0.9.
+The clean install reported zero vulnerabilities. Fresh tests and lint pass;
+the normal-environment production build and full audit also pass at the current
+pre-merge head. Final merged-head CI remains a release gate.
+
+## Remediation applied
+
+| Dependency | Before | After | Reason |
+|---|---:|---:|---|
+| `next` | 15.5.20 | 15.5.22 | Clears the direct Next.js advisories while staying on the existing release line. |
+| `eslint-config-next` | 15.5.20 | 15.5.22 | Keeps framework and lint configuration aligned. |
+| `postcss` | vulnerable transitive | 8.5.23 override | Pulls the patched same-major parser into the production tree. |
+| `sharp` | 0.34.5 transitive | 0.35.3 override | Pulls the patched image processor; requires Node 20.9 or newer. |
+| `brace-expansion` | 1.1.16 and 5.0.8 | 1.1.18 and 5.0.9 | Clears the high-severity development-only denial-of-service advisory on both dependency paths. |
+
+The project requires Node `22.x` so local and Vercel builds use the same
+supported major and satisfy Sharp's runtime requirement. CI pins
+[Node 22.23.2](https://nodejs.org/en/blog/release/v22.23.2), the Node 22 LTS
+security release published on 2026-07-29.
+
+The PostCSS and Sharp overrides are temporary compatibility controls. Remove
+them when the selected Next.js release declares patched versions directly.
+Sharp 0.35 is outside Next 15.5.22's declared `^0.34.3` range, so it received an
+explicit build, runtime, and image-optimization smoke test before release.
+
+## Resolved development advisory
+
+Advisory:
+[GHSA-mh99-v99m-4gvg](https://github.com/advisories/GHSA-mh99-v99m-4gvg),
+unbounded brace expansion causing an out-of-memory denial of service.
+
+Observed path: legacy `brace-expansion` 1.x through `minimatch` 3.x in ESLint,
+`@eslint/eslintrc`, and plugins bundled by `eslint-config-next`. The advisory
+was updated to identify patched 1.1.17; the refreshed lockfile resolves 1.1.18.
+The modern nested path also advanced from 5.0.8 to 5.0.9. No forced downgrade,
+unsupported major change, or direct dependency was introduced.
+
+## Website attack-surface reduction during review
+
+- The hosted Skill seller API, browser-wallet client, and payment-enablement
+ environment variables were removed. The website has no signing, facilitator,
+ transaction-broadcast, or model-provider path.
+- `/proof` is a static archive separated from the Wallet Kernel candidate. Its
+ single historical Base Sepolia receipt is bounded evidence, not proof of a
+ currently live endpoint, successful model execution, a completed split,
+ customer demand, or production readiness.
+- The archived manifesto explicitly says that the historical interface did not
+ directly return the Skill file while model output can still leak or enable
+ reconstruction. It makes no categorical extraction-resistance claim.
+- The spend-control sandbox is an offline deterministic state machine. It uses
+ no account, wallet, key, signature, network call, payment, saved data, or raw
+ prompt and labels its final artifact as an unsigned session projection.
+- Global responses disable the framework signature and add CSP frame/base/object
+ restrictions, clickjacking protection, MIME sniffing protection, a strict
+ referrer policy, and a restrictive permissions policy.
+
+## Verification records
+
+Current PR, 2026-08-02:
+
+- User-run `npm ci`: 325 packages installed; install-time audit reported 0
+ vulnerabilities.
+- `npm test`: 24/24 passing. This dependency-free suite covers the Wallet
+ Kernel allow/deny/approval/retry sandbox, unsigned projection boundaries, the
+ default-deny path, safe-integer atomic-money conservation, and public-claim
+ quarantine across the website and READMEs.
+- `npm run lint`: passing under Node 22.22.0 in the agent environment.
+- User-run `npm run build` under Node 22.22.0: passing; Next.js 15.5.22
+ compiled, checked types, generated all static pages, and emitted `/`,
+ `/_not-found`, `/icon.png`, and `/proof`.
+- User-run `npm audit --audit-level=high`: 0 vulnerabilities.
+- `.github/workflows/site.yml` now runs locked install, tests, lint, production
+ build, and a high/critical full-tree dependency audit for every pull request
+ that changes `site/**`, the root `README.md` scanned by the claim-quarantine
+ test, or the workflow itself. It uses immutable action pins and Node 22.23.2.
+- The CI audit command is `npm audit --audit-level=high`: high and critical
+ advisories in production or development dependencies fail the job; low and
+ moderate advisories remain visible without failing this gate.
+- The sandboxed Turbopack build reached optimization but could not bind its
+ local helper port (`EPERM`); the same command passed in the user's normal
+ environment. Production start, image optimization, and final merged-head CI
+ remain **pending final-head verification**.
+
+Previous dependency snapshot, 2026-07-26:
+
+- `npm test`: 6/6 passing.
+- `npm run lint`: passing.
+- Clean `npm run build`: passing in an isolated copy to avoid the active local
+ development server rewriting `.next` concurrently.
+- Production start smoke test: passing.
+- Next image optimizer request for `/icon.png` at 64 px: HTTP 200, `image/png`.
+- `npm audit --omit=dev`: 0 vulnerabilities.
+- Full `npm audit`: 9 high package entries, all from the single dev-only advisory
+ described above.
diff --git a/docs/product-onboarding-retention-and-monetization.md b/docs/product-onboarding-retention-and-monetization.md
new file mode 100644
index 0000000..bc5e3d9
--- /dev/null
+++ b/docs/product-onboarding-retention-and-monetization.md
@@ -0,0 +1,681 @@
+# Product onboarding, retention, and monetization recommendations
+
+**Status:** Superseded for v1 on 2026-08-02
+**Reviewed:** 2026-07-25
+**Scope:** Repository, public site, offline proofs, accepted ADRs, and current market
+benchmarks
+
+> **Historical product research.** The employer attribution, governance, and
+> reward program below is not the current v1 product or homepage direction. The
+> approved v1 is the customer-hosted, wallet-native **Agent Spend Control
+> Plane**, centered on a **Wallet Kernel** for x402 spending policy, exact human
+> approval, signed receipts, and reconciliation. Skill attribution and Creator
+> compensation are deferred expansion modules that may later consume Wallet
+> Kernel receipts. See the
+> [approved spend-control design](superpowers/specs/2026-07-31-agent-spend-control-plane-design.md).
+>
+> This document remains useful as a hypothesis ledger for that deferred
+> expansion. Its buyer, pricing, roadmap, and homepage recommendations are not
+> implementation commitments for v1.
+
+## Superseded executive recommendation
+
+Make the closed-mode product a **B2B attribution and compensation control plane for
+employee-authored AI Skills**:
+
+> Measure which reusable AI Skills create value inside an organization, preserve who
+> created and maintains them, and turn trusted evidence into fair, configurable rewards.
+
+The employer is the buyer. The employee-Creator is the emotional center. The Wielder
+should keep using the tools they already use.
+
+Monetize the control plane with an annual employer-paid program license, paid
+implementation, and enterprise add-ons. Pass internal creator rewards through at 100%.
+Keep x402, Story provenance, and external revenue sharing as optional infrastructure,
+not as the first product or the primary source of revenue.
+
+The immediate goal should be **three paid design-partner pilots**, not more protocol
+surface area.
+
+### The five decisions to make now
+
+1. **Fund internal compensation with an employer-controlled periodic reward pool.**
+ Invocation and outcome data should influence awards, but raw call count should not be
+ the payout formula.
+2. **Lead the product and site with the employer outcome.** Move the manifesto and
+ testnet wallet proof to an evidence path.
+3. **Offer a no-wallet, no-key sandbox that demonstrates the full loop:** import a Skill,
+ record use by a second person, preview attribution, and close a reward period.
+4. **Build the signed ledger, policy engine, creator portfolio, and monthly close before
+ on-chain settlement or a marketplace.**
+5. **Charge for the program, not participation or creator earnings.** Favor a platform
+ fee per program or business unit, with generous included event volume.
+
+## What is already strong
+
+The project has unusually good foundations for an early research repository:
+
+- It labels evidence as measured, modeled, or hypothesis and states plainly that employer
+ demand is unvalidated ([root README](../README.md)).
+- It has already made the correct strategic reframe: the closed compensation layer is
+ the terminal product, while the marketplace is optional
+ ([ADR-0007](adr/0007-closed-mode-compensation-layer-as-terminal-product.md)).
+- It proves the thin payer, settlement arithmetic, provenance graph, and clone-economics
+ questions with executable artifacts.
+- The Pi-Wielder proof has a clear architecture and runbook
+ ([Pi-Wielder README](../spikes/pi-wielder/README.md)).
+- The offline clone and fork-economics paths run successfully without credentials. In
+ this review, they passed 97 checks and 64 invariants respectively.
+- The corpus records uncomfortable findings—paid failures, clone economics, context loss,
+ securities exposure, and the Education bypass—instead of hiding them.
+
+These are credibility assets. The next step is to organize them around a customer journey
+rather than asking every newcomer to reconstruct the product thesis from the research
+corpus.
+
+## The core product gap
+
+The accepted product direction, public experience, and funding model do not yet agree.
+
+| Question | Current answer | Recommended answer |
+|---|---|---|
+| What is the product? | ADR-0007 says intra-org compensation; the site presents a sovereignty manifesto and a paid hosted Skill. | An employer-funded Skill attribution, governance, and reward program. |
+| Who buys? | Not shown. The site speaks to an unspecified wallet holder. | Head of AI Platform / DevEx, with Total Rewards or IP Operations as co-owner. |
+| Who receives value? | A one-time Wielder receives one output and receipt. | Admins get portfolio governance; Creators get durable evidence and rewards; Wielders get approved Skills in existing tools. |
+| Where does compensation come from? | [CONTEXT.md](../CONTEXT.md) says intra-org upside comes from external Wielders, while the marketplace may never ship. | The employer funds an internal pool; genuine external revenue uses a separate revenue-share policy. |
+| What is the billable product? | A 2.5% treasury split on a $0.25 Invocation in the demo. | Annual software license plus implementation and enterprise add-ons. |
+| What makes users return? | No persistent account, history, catalog, dashboard, close, or notification loop. | Adoption, feedback, maintenance, monthly reward close, and audit loops. |
+
+The funding contradiction is the most important product decision. A terminal intra-org
+product cannot require a future external marketplace to produce the employee benefit it
+promises.
+
+## Recommended product contract
+
+### Initial customer profile
+
+Treat this as a hypothesis to validate, not a settled market fact:
+
+- An AI-forward software, professional-services, or knowledge-work company.
+- Roughly 100–2,000 employees, large enough to have reusable internal AI artifacts but
+ small enough to run a design-partner program without a multi-year transformation.
+- A centralized AI platform, developer-productivity, or automation team.
+- A growing inventory of prompts, Skills, agents, plugins, or workflow automations.
+- An existing innovation award, inventor award, bonus, or employee-recognition budget is
+ a strong qualification signal.
+
+The ideal buying group is:
+
+| Role | Job to be done |
+|---|---|
+| Head of AI Platform / DevEx | Find, govern, distribute, and measure reusable AI Skills. |
+| VP Engineering / CIO | Show AI productivity and retain high-leverage contributors. |
+| Total Rewards / People | Run a consistent, budgeted creator-recognition program. |
+| Legal / IP / Finance | Approve ownership, departure, dispute, and payout rules. |
+| Employee-Creator | Prove authorship and impact; receive recognition or compensation. |
+| Employee-Wielder | Use approved Skills with almost no new workflow. |
+
+The creator is the beneficiary of the promise, but the employer has the budget and the
+administrative problem.
+
+### The minimum durable workflow
+
+```text
+Import → verify authorship → publish internally → use in existing tools
+ → collect outcome evidence → review attribution → close reward period
+ → notify Creator → improve/version Skill → more trusted reuse
+```
+
+The Phase-1 product should include:
+
+1. **Organization workspace**
+ - Organization, user, team, and role model.
+ - SSO or directory identity for enterprise deployments.
+ - Admin, policy reviewer, Creator, and viewer permissions.
+
+2. **Skill registry**
+ - Import from GitHub or a supported Skill directory.
+ - Canonical Skill ID, version hash, Creator, co-Creators, maintainer, status, and
+ lineage.
+ - Review, approve, deprecate, transfer maintainership, and archive flows.
+ - Searchable internal catalog with install or usage instructions.
+
+3. **Organization-native meter**
+ - Adapters for the customer's existing model gateway, agent runtime, or CLI.
+ - No individual wallet for internal use.
+ - Customer-hosted or VPC execution when repository or tool context is required.
+ - x402 only at the external payment edge.
+
+4. **Signed evidence ledger**
+ - Durable, idempotent Invocation records.
+ - Organization, Skill and version, Creator policy, Wielder or service identity,
+ timestamp, success, latency, cost, outcome signal, source, and adjustment status.
+ - Append-only policy and attribution history.
+ - No raw prompt or output storage by default; support redaction, hashing, retention
+ limits, and customer-controlled storage.
+
+5. **Reward policy and close**
+ - Fixed employer budget by month or quarter.
+ - Configurable weights, caps, eligibility, vesting, clawback, termination, and
+ co-authorship.
+ - Provisional allocation, anomaly review, manager/HR approval, dispute workflow, and
+ CSV/payroll export.
+ - Plain-language creator statement explaining why an award was calculated.
+
+6. **Creator and admin views**
+ - Creator: adoption, repeat users, teams reached, feedback, versions, maintenance
+ alerts, and provisional reward.
+ - Admin: active portfolio, duplication, failures, outcome evidence, budget, policy,
+ pending approvals, and audit export.
+
+ADR-0007 already identifies vesting, clawback, and termination as first-class design
+inputs. They should be part of the core domain model, not postponed until a marketplace.
+
+## Resolve compensation without rewarding spam
+
+Use an Invocation as an evidence event, not as a dollar counter.
+
+A quarantined historical summary reported seven paid Agent turns from one human
+prompt, but its normalized samples were not retained and it is not publishable
+evidence
+([Pi-Wielder evidence status](../spikes/pi-wielder/README.md#measured-results--overhead-distribution--live-pi-session-2026-07-15)).
+Treat the following as a hypothesis until a fresh run reproduces it: a literal
+per-call reward may favor chatty runtimes, create unpredictable employer cost,
+and be easy to game.
+
+For internal use:
+
+1. The employer commits a fixed reward budget for a period.
+2. Successful uses create provisional evidence points.
+3. The policy weights signals such as unique Wielders, second-team adoption, repeat use,
+ accepted output, a linked downstream artifact, quality, and maintenance.
+4. Caps and anomaly detection limit loops, retries, self-use, and synthetic traffic.
+5. An authorized reviewer approves the close.
+6. Payroll or the employer's reward system delivers the award.
+
+For genuine external revenue, a separate policy can split actual collected revenue. Do
+not mix an internal recognition award and an external royalty into one unexplained
+balance.
+
+This keeps the premise—Creators retain an economic claim on reuse—while making the
+closed-mode product viable without a public marketplace.
+
+## Onboarding review and enhancements
+
+### 1. Align the first 15 seconds with the accepted product
+
+The public site currently asks a visitor to absorb ten manifesto principles before the
+interactive proof and then presents a wallet, faucet, and testnet payment flow
+([site content](../site/app/content.ts),
+[manifesto UI](../site/app/manifesto.tsx)). That is memorable brand work, but it does not
+explain the employer workflow in ADR-0007.
+
+Recommended homepage hierarchy:
+
+1. **Outcome:** “Measure and reward the people who build the AI workflows your company
+ reuses.”
+2. **Proof:** a three-panel view of a registered Skill, verified team use, and creator
+ award statement.
+3. **Role paths:**
+ - Employer: “Run a design-partner pilot.”
+ - Creator: “See what your Skill portfolio could look like.”
+ - Platform team: “Inspect the meter and event schema.”
+4. **No-wallet interactive sandbox.**
+5. **Technical receipts and manifesto.**
+
+Keep “Never Handed Over” as a strong campaign or evidence page. It should not carry the
+entire product onboarding job.
+
+### 2. Replace the first paid experience with a truthful free one
+
+At the time of this review, the public Skill promised to inspect a repository
+and resolve actual files, patterns, and verification commands, while the hosted
+API sent only text and no repository, files, search tools, or execution tools.
+That mismatched paid endpoint was retired from the website on 2026-08-02; this
+observation remains here as the rationale.
+
+That means the paid first experience cannot reliably fulfill the Skill's defining
+contract.
+
+Choose one:
+
+- Use a genuinely stateless demonstration Skill that is valuable from pasted input alone;
+ or
+- Let the user connect a repository or use a preloaded sample repository, and execute with
+ the tools the Skill requires.
+
+The recommended sandbox should use a seeded fictional company:
+
+1. Choose or import a sample Skill.
+2. Confirm its Creator and version.
+3. Simulate use by three teammates.
+4. Mark one result as accepted and link one sample pull request.
+5. Show the creator-impact view and reward preview.
+
+Only after that should an interested technical evaluator opt into the wallet/testnet
+protocol proof.
+
+### 3. Give each persona a first-five-minutes path
+
+| Persona | First success | Target |
+|---|---|---|
+| Buyer | Completes the sandbox and sees a sample monthly close. | Under 3 minutes |
+| Organization admin | Imports one Skill, sets a sample policy, and records use by a second person. | Under 10 minutes |
+| Creator | Claims authorship and sees one attributed use and reward explanation. | Under 5 minutes |
+| Technical evaluator | Runs every offline proof from one root command. | Under 5 minutes after install |
+| Contributor | Finds current architecture, roadmap, issues, and verification commands. | Under 10 minutes |
+
+### 4. Create a repository-wide paved road
+
+The root currently has no workspace manifest, pinned Node version, CI workflow, or single
+verification command. The four proofs require directory hopping, and
+[`site/README.md`](../site/README.md) is still the generated Next.js starter text. The
+site has required environment variables but no committed `.env.example`.
+
+Recommended repository changes:
+
+- Add pinned Node/npm versions.
+- Add root commands such as `bootstrap`, `verify`, `demo:offline`, and `site:mock`.
+- Use `npm ci` consistently where a lockfile exists.
+- Add `site/.env.example` and a zero-key `dev:mock` mode.
+- Add CI for offline proofs, Phase 0 tests/typecheck, and site lint/build/tests.
+- Replace the deliberately failing `prototype` test script.
+- Print an expected success transcript and elapsed time.
+- Add `docs/START_HERE.md`, `docs/ARCHITECTURE.md`, `docs/ROADMAP.md`, and
+ `CONTRIBUTING.md`.
+- Publish sanitized product requirements instead of repeatedly referring contributors to
+ an unpublished PRD.
+
+### 5. Make paid failures explicit and recoverable
+
+The repository measured paid upstream failures and a settled-but-rejected
+payment with no output. At the time of this review, the hosted route settled
+before execution while its UI discarded some paid-failure state. The website
+payment surface was retired on 2026-08-02 instead of carrying that behavior
+forward.
+
+Before encouraging repeat paid use:
+
+- Preserve and display the receipt on every failure.
+- Represent uncertain settlement as `payment_status: unknown`, not “nothing charged.”
+- Add a durable idempotency key and Invocation state machine.
+- Issue an automatic retry credit or refund after post-settlement failure.
+- Validate configuration, input, and upstream readiness before authorization.
+- Expose success rate, paid-without-output rate, refund time, and reconciliation errors.
+- Do not show a declared split as if it were a completed payout. The current route settles
+ to one `payTo` address and returns a static split; creator balances and reconciliation
+ need their own ledger.
+
+For future external payments, current x402 documentation also describes usage-capped and
+batch-settlement schemes. Evaluate those instead of treating the prototype's v1 fixed-price
+path as a permanent product constraint
+([x402 seller quickstart](https://docs.x402.org/getting-started/quickstart-for-sellers)).
+
+### 6. Add basic return actions
+
+The current public output is ephemeral React state. Add:
+
+- Saved Invocation and receipt history.
+- Copy, download, rerun, feedback, and share actions.
+- A next step after success.
+- A design-partner/contact CTA.
+- Funnel instrumentation from page view through repeat successful use.
+
+## Retention: why organizations and people stay
+
+The durable product is a set of reinforcing loops, not a payment handshake.
+
+### Creator improvement loop
+
+```text
+Attributed use → outcome feedback → Creator sees impact → updates Skill
+ → Wielders adopt the new version → more verified value
+```
+
+Build version-specific feedback, update prompts, release notes, adoption lift, and stale
+dependency alerts.
+
+### Team adoption loop
+
+```text
+One Creator publishes → teammate succeeds → internal proof spreads
+ → another team adopts → more Creators contribute
+```
+
+Build a searchable catalog, clear install instructions, featured Skills, related Skills,
+team invitations, and cross-team milestones.
+
+### Compensation ritual
+
+```text
+Monthly evidence → policy calculation → reviewer approval → creator statement
+ → reward delivered → continued contribution and maintenance
+```
+
+This is the most defensible retention loop because it becomes an operational program, not
+a novelty dashboard. A monthly close, audit trail, payroll export, and dispute process make
+the system costly to replace for legitimate reasons.
+
+### Governance loop
+
+```text
+Portfolio evidence → identify valuable, duplicate, stale, or risky Skills
+ → assign action → improve portfolio quality → trust grows
+```
+
+Add owner-departure alerts, duplicate detection, deprecated-version use, policy exceptions,
+and maintainership transfer.
+
+### Return triggers
+
+- Weekly Creator digest: new users, teams, feedback, milestone, and update prompt.
+- Monthly admin impact and reward-close report.
+- First-five-users and first-second-team milestones.
+- Declining-success and stale-version alerts.
+- New-version notification for Wielders.
+- Quarterly portfolio and policy review.
+
+Do not rely on a leaderboard alone. It will amplify popularity and gaming unless it is
+quality-adjusted and reviewed.
+
+## Metrics
+
+### North star
+
+Use **weekly verified uses of shared Skills in retained organizations**.
+
+A verified use should be successful, performed by someone other than only the Creator,
+and carry either an acceptance signal or a downstream outcome reference. Raw Invocation
+count is a diagnostic, not the north star.
+
+### Activation
+
+- Visitor-to-sandbox-start and sandbox-completion rate.
+- Sandbox-to-pilot-request rate.
+- Time to first imported Skill.
+- Time to first successful use by a second person.
+- Percentage of workspaces that preview a reward policy.
+- Percentage of pilot organizations activated within 14 days.
+
+### Engagement and retention
+
+- W1, W4, and W12 active-organization retention.
+- Seven- and 28-day repeat-Wielder rate.
+- Percentage of registered Skills used by at least two people and two teams.
+- Verified uses per active organization.
+- 30- and 90-day Skill survival.
+- Monthly reward-close completion.
+- Department expansion and invited-user conversion.
+
+### Creator loop
+
+- Active Creators per organization.
+- Percentage receiving actionable feedback.
+- Version update rate and adoption lift after update.
+- Provisional, approved, and delivered compensation.
+- Creator dashboard return rate.
+- Perceived-recognition and intent-to-continue signals.
+
+### Buyer value
+
+- Estimated time or cost saved, with confidence level shown.
+- Reward pool as a percentage of approved value.
+- Duplicate or unowned Skills resolved.
+- Pilot-to-paid conversion.
+- Renewal and business-unit expansion.
+
+### Reliability and trust
+
+- Successful Invocation rate.
+- Paid-without-output rate.
+- Retry-credit or refund completion time.
+- Ledger/payment reconciliation error rate.
+- Attribution and policy dispute rate.
+- p50/p95 time to first useful output.
+
+Employee-retention impact will take months to establish. Early proxies are continued
+Creator participation, update frequency, cross-team reuse, perceived recognition, and
+intent-to-stay changes.
+
+## Monetization
+
+### Why the current take rate should not be the business
+
+The prototype's 2.5% treasury fee yields $0.00625 on a $0.25 Invocation.
+
+| Volume | Creator/payment volume | Protocol revenue |
+|---:|---:|---:|
+| 100,000 Invocations | $25,000 | $625 |
+| 1,000,000 Invocations | $250,000 | $6,250 |
+| 4,000,000 Invocations | $1,000,000 | $25,000 |
+| 160,000,000 Invocations | $40,000,000 | $1,000,000 |
+
+That is a poor base for enterprise implementation, security, support, and a compensation
+workflow. It also creates the wrong optics: a creator-sovereignty product funds itself by
+skimming creator rewards.
+
+Payment settlement is becoming low-cost infrastructure. Coinbase currently lists its x402
+facilitator at 1,000 free transactions per month and $0.001 thereafter
+([official pricing](https://docs.cdp.coinbase.com/x402/core-concepts/facilitator)).
+The attributed longitudinal ledger and policy workflow—not the payment handshake—must be
+the premium.
+
+### Recommended revenue model
+
+#### 1. Annual enterprise program license
+
+Charge the employer for:
+
+- Skill registry and version/lineage system.
+- Signed evidence ledger.
+- Policy and reward-close workflow.
+- Creator and administrator analytics.
+- Audit, privacy, security, and export controls.
+
+Price by program or business unit with unlimited employee participants. Include a generous
+event allowance; use event overages only to cover material infrastructure cost.
+
+This avoids penalizing adoption and matches an adjacent innovation-platform pattern.
+Wazoku lists a $15,000-per-admin annual license with unlimited end users
+([official pricing](https://www.wazoku.com/total-innovation-license/)).
+
+#### 2. Paid implementation and managed program services
+
+Offer:
+
+- Skill inventory and data mapping.
+- Event-source integration.
+- Reward-policy design and workflow configuration.
+- Identity, HRIS, and payroll export setup.
+- Admin training and first-close support.
+
+Wazoku separately lists enhanced onboarding at $5,450 and onboarding plus program setup at
+$12,000, which supports treating implementation as real work rather than burying it in
+software margin.
+
+#### 3. Enterprise add-ons
+
+- VPC, hybrid, or customer-managed data plane.
+- SSO, SCIM, advanced RBAC, and longer audit retention.
+- HRIS/payroll integrations.
+- Custom policy packs and multi-jurisdiction workflows.
+- SLA, premium support, and managed reconciliation.
+
+#### 4. OEM or metering API
+
+After the product works directly, sell the attributed meter to IP-management,
+compensation, AI-gateway, or developer-platform vendors. This may become a strong channel
+because those vendors already own buyer relationships but generally meter invention
+milestones rather than runtime AI-asset use.
+
+#### 5. Benchmark analytics, later
+
+With explicit customer consent and strong aggregation thresholds, offer benchmarks for
+Skill adoption, reward policy, creator concentration, maintenance, and reuse. This should
+be an opt-in add-on only after enough customers make the data meaningful.
+
+#### 6. External marketplace fee, deferred
+
+If the product later supplies discovery, demand, collections, refunds, quality control,
+and trust, test a 5–10% fee on external revenue. Do not charge that fee merely for wrapping
+an endpoint in x402, and do not build tradeable claims without specialist legal advice.
+
+### Pricing hypotheses to test
+
+These are starting offers for design conversations, not validated prices:
+
+| Offer | Hypothesis |
+|---|---:|
+| Founding design-partner pilot, 8–12 weeks | $10,000–$20,000 |
+| Single-program annual license | $15,000–$30,000 |
+| Multi-business-unit annual license | $40,000–$75,000 |
+| Enterprise/private deployment | $75,000–$150,000+ |
+| Implementation | $5,000–$15,000 |
+| Managed program support | $2,000–$5,000/month |
+
+Useful adjacent anchors as of the review date:
+
+- AppColl lists Invention Manager at $350/month for 100 users, including award
+ management, SSO, HR integration, workflows, and analytics
+ ([official pricing](https://www.appcoll.com/corporation-product-pricing/)).
+- Bonusly lists employee-recognition software at $30–$50 per user annually and explicitly
+ separates the software subscription from rewards redeemed at face value
+ ([official pricing](https://bonusly.com/pricing)).
+- LangSmith combines a team subscription with metered usage and reserves hybrid,
+ self-hosted, SSO, RBAC, and SLA capabilities for enterprise
+ ([official pricing](https://www.langchain.com/pricing)).
+- Stripe Billing lists 0.7% of billing volume or annual subscription tiers, an additional
+ signal that mature metering infrastructure does not justify a 2.5% fee by itself
+ ([official pricing](https://stripe.com/billing/pricing)).
+
+These products are not exact competitors. They bound how buyers already purchase adjacent
+innovation, recognition, observability, and billing workflows.
+
+### What not to monetize first
+
+- Do not charge Creators to register or see their own evidence.
+- Do not take a percentage of an employer's internal reward pool.
+- Do not make token sales or tradeable royalty claims the funding plan.
+- Do not make the Education model a paid offer until its free re-authoring bypass has a
+ measured counter.
+- Do not rely on inference resale margin; the repository already recognizes it as
+ commoditizing.
+
+## Validation plan
+
+### Customer discovery
+
+Run 12–15 interviews across:
+
+- AI Platform / Developer Productivity.
+- Engineering or technology executives.
+- Total Rewards / People Operations.
+- IP Operations, Legal, or Finance.
+
+Prioritize organizations that already operate an inventor, innovation, or recognition
+program and already have a centralized AI gateway or internal Skill inventory.
+
+Questions should test existing behavior, not solicit compliments:
+
+- How are reusable AI workflows found, approved, and maintained today?
+- Who gets credit when another team reuses one?
+- Has lack of credit caused hoarding, duplicated work, or attrition risk?
+- What budget funds inventor awards, spot bonuses, or innovation programs?
+- Which evidence would make an award defensible?
+- Who can approve policy and payment?
+- What security or employment-law condition would stop a pilot?
+- Would the company fund a pool even if no external customer ever invokes a Skill?
+
+### Paid concierge pilot
+
+Do not wait for a full platform:
+
+1. Import a real Skill inventory.
+2. Ingest signed or reconciled events from one existing runtime.
+3. Produce creator and admin views, even if some operations are manual.
+4. Run one policy preview and two monthly closes.
+5. Export a payroll-ready or award-ready file.
+6. Measure cross-team adoption, disputes, admin time, and Creator response.
+
+### Decision gates
+
+| Hypothesis | Pass signal | If it fails |
+|---|---|---|
+| Employers will pay for the rail. | Three pilots at $10,000 or more. | Stop protocol expansion; narrow or abandon the B2B thesis. |
+| Internal compensation does not require marketplace revenue. | At least one pilot funds a real Creator pool. | Reposition as governance/analytics or target only commercialized Skills. |
+| Usage evidence can approximate value. | Admins agree that the highest-scored Skills overlap materially with their independently selected high-value set. | Change signals and policy; do not automate payouts. |
+| The buying group can form. | Each pilot has an AI-platform champion and a Total Rewards/IP owner. | Narrow to one buyer's problem and remove cross-functional scope. |
+| Context-bound Skills can be instrumented usefully. | A meaningful share of one customer's real inventory produces reliable versioned events without losing its useful context. | Change the asset class or execution model. |
+| The program creates a habit. | Two monthly closes complete and W4 verified use persists. | Diagnose workflow value before adding more integrations. |
+| Annual value supports enterprise pricing. | Two pilots convert at $25,000+ ARR. | Reduce scope/cost or test an OEM model. |
+
+These are product decision gates, not forecasts.
+
+## Prioritized roadmap
+
+### Now: 0–30 days
+
+1. Write an ADR resolving the intra-org funding source and scoping “the Wielder is a
+ wallet” to external payment flows.
+2. Run the customer interviews and recruit paid design partners.
+3. Rewrite the primary landing page around the employer outcome.
+4. Add a no-wallet seeded sandbox and a clear pilot CTA.
+5. Replace or properly tool-enable the current demo Skill.
+6. Fix charged-failure receipt visibility and define retry-credit/refund semantics.
+7. Add a root offline verification path and replace the site starter README.
+8. Publish a public product overview, architecture, roadmap, and contribution path.
+
+### Pilot: 31–90 days
+
+1. Define the organization, Skill/version, event, policy, close, and dispute schemas.
+2. Import Skills from one source and events from one real runtime.
+3. Build a persistent signed ledger.
+4. Deliver minimal Creator and admin views.
+5. Run fixed-budget policy previews and CSV/payroll export.
+6. Instrument activation, verified use, trust, and close metrics.
+7. Complete the first paid pilot close.
+
+### Productize: 91–180 days
+
+1. Add multi-tenant workspaces, SSO, RBAC, and identity mapping.
+2. Add the internal catalog, versioning, feedback, and maintainer workflows.
+3. Add configurable policies, approvals, departures, and disputes.
+4. Add reliability controls, idempotency, credits/refunds, and reconciliation.
+5. Add weekly Creator and monthly admin return triggers.
+6. Offer customer-hosted or VPC execution for context-sensitive Skills.
+7. Convert pilots to annual contracts.
+
+### Only after the gates pass
+
+- Background or opt-in Story registration.
+- Additional runtime adapters.
+- OEM/API distribution.
+- Opt-in benchmark analytics.
+- External x402 monetization.
+- Marketplace discovery or tradeable claims, subject to legal review.
+
+### Explicitly defer
+
+- Securities and transfer infrastructure.
+- Open marketplace build-out.
+- Education-mode commercialization.
+- TEE investment for an unvalidated open market.
+- More inference-reseller work that does not improve the attributed ledger.
+
+## Bottom line
+
+The premise is monetizable, but not primarily as a per-call royalty marketplace.
+
+The commercially coherent product is the system an employer uses to answer:
+
+- What reusable AI Skills do we have?
+- Who created and maintains them?
+- Which teams use them successfully?
+- What value evidence can we defend?
+- What policy determines recognition or compensation?
+- What changed, who approved it, and what was paid?
+
+If the project can make that monthly operating loop trustworthy and easy, the existing
+wallet, provenance, and settlement work becomes valuable optional infrastructure. If it
+cannot find three employers willing to pay for that loop, more protocol depth will not
+solve the core problem.
diff --git a/site/.env.example b/site/.env.example
new file mode 100644
index 0000000..8e623a9
--- /dev/null
+++ b/site/.env.example
@@ -0,0 +1,6 @@
+# Optional: destination for the Wallet Kernel design-partner CTA.
+# Defaults to a prefilled GitHub issue when unset.
+NEXT_PUBLIC_PILOT_CONTACT_URL=
+
+# The archived /proof page is static. This site does not accept wallet keys,
+# payment configuration, facilitator credentials, or model-provider secrets.
diff --git a/site/.gitignore b/site/.gitignore
index 5ef6a52..870462f 100644
--- a/site/.gitignore
+++ b/site/.gitignore
@@ -12,6 +12,8 @@
# testing
/coverage
+/output/playwright/
+/.playwright-cli/
# next.js
/.next/
@@ -32,6 +34,7 @@ yarn-error.log*
# env files (can opt-in for committing if needed)
.env*
+!.env.example
# vercel
.vercel
diff --git a/site/README.md b/site/README.md
index e215bc4..98421a5 100644
--- a/site/README.md
+++ b/site/README.md
@@ -1,36 +1,88 @@
-This is a [Next.js](https://nextjs.org) project bootstrapped with [`create-next-app`](https://nextjs.org/docs/app/api-reference/cli/create-next-app).
+# Skill Asset Protocol site
-## Getting Started
+**Release status:** pre-release candidate. The approved design's implementation
+and fresh-evidence gate is not cleared; do not deploy this candidate as the
+public homepage yet.
-First, run the development server:
+The site has two deliberately separate paths:
+
+- `/` is the wallet-native **Agent Spend Control Plane** preview and
+ deterministic **Wallet Kernel** sandbox. It needs no account, wallet, API
+ key, network call, payment, or saved data.
+- `/proof` preserves the original manifesto, one bounded historical Base
+ Sepolia receipt, and the retired x402 invocation experiment as a static
+ archive. The site exposes no wallet connection or paid endpoint.
+
+The approved v1 product is a customer-hosted Wallet Kernel for spending policy,
+exact human approval, signed receipts, and reconciliation. The employer Skill
+attribution and reward experience remains in the repository as deferred
+expansion research; it is not linked from the current homepage and does not set
+the v1 interface. See the
+[approved design](../docs/superpowers/specs/2026-07-31-agent-spend-control-plane-design.md).
+
+## Local product preview
+
+Use Node 22. The production dependency graph and image optimizer are verified
+against that major.
```bash
+npm ci
npm run dev
-# or
-yarn dev
-# or
-pnpm dev
-# or
-bun dev
```
-Open [http://localhost:3000](http://localhost:3000) with your browser to see the result.
+Open . The full seeded sandbox works with no environment
+file and never calls the payment or model API.
-You can start editing the page by modifying `app/page.tsx`. The page auto-updates as you edit the file.
+The sample Agent, customer-owned wallet, policy, Spend Intents, decisions,
+approval, and receipt projection are fictional. The sandbox never creates a
+wallet payment signature or broadcasts a transaction. Refreshing or choosing
+**Restart sandbox** returns to the same deterministic fixture.
-This project uses [`next/font`](https://nextjs.org/docs/app/building-your-application/optimizing/fonts) to automatically optimize and load [Geist](https://vercel.com/font), a new font family for Vercel.
+## Optional configuration
-## Learn More
+Copy the template only when you need to change the Wallet Kernel pilot CTA:
-To learn more about Next.js, take a look at the following resources:
+```bash
+cp .env.example .env.local
+```
-- [Next.js Documentation](https://nextjs.org/docs) - learn about Next.js features and API.
-- [Learn Next.js](https://nextjs.org/learn) - an interactive Next.js tutorial.
+| Variable | Required | Purpose |
+|---|---:|---|
+| `NEXT_PUBLIC_PILOT_CONTACT_URL` | No | Override the design-partner CTA destination |
-You can check out [the Next.js GitHub repository](https://github.com/vercel/next.js) - your feedback and contributions are welcome!
+Never put a wallet key, facilitator credential, or model-provider secret in the
+site environment. The customer-hosted Wallet Kernel—not the website—owns any
+future payment integration.
+
+The historical receipt is evidence only that one test-USDC transfer settled on
+Base Sepolia. It does not prove that the endpoint is currently live, that model
+execution succeeded, that a declared split occurred, that customer demand
+exists, or that the Wallet Kernel is production-ready. The offline homepage
+sandbox is illustrative, not live settlement evidence.
+
+## Verification
+
+```bash
+npm test
+npm run lint
+npm run build
+npm audit --omit=dev
+```
-## Deploy on Vercel
+`npm test` covers the spend-control sandbox and public-claim quarantine with
+Node's built-in test runner. The build must pass
+without secrets because both routes are static product/research surfaces. The
+final-head production audit must report zero vulnerabilities before merge. See the
+[dependency security audit](../docs/dependency-security-audit.md) for the prior
+audit record, the remaining dev-only advisory, and the intentionally pinned
+transitive fixes.
-The easiest way to deploy your Next.js app is to use the [Vercel Platform](https://vercel.com/new?utm_medium=default-template&filter=next.js&utm_source=create-next-app&utm_campaign=create-next-app-readme) from the creators of Next.js.
+## Relevant files
-Check out our [Next.js deployment documentation](https://nextjs.org/docs/app/building-your-application/deploying) for more details.
+| Path | Role |
+|---|---|
+| `app/page.tsx` | Wallet-native Agent Spend Control landing page |
+| `app/landing.module.css` | Industrial product-page design system |
+| `app/components/landing/SpendControlSandbox.tsx` | Current client-only Wallet Kernel sandbox |
+| `app/components/landing/spend-control-model.ts` | Deterministic spend-policy fixture and reducer |
+| `app/proof/page.tsx` | Static archive with one bounded historical receipt |
diff --git a/site/app/api/invoke/[skillId]/route.ts b/site/app/api/invoke/[skillId]/route.ts
deleted file mode 100644
index 9efa7bf..0000000
--- a/site/app/api/invoke/[skillId]/route.ts
+++ /dev/null
@@ -1,260 +0,0 @@
-// THE COLLAR — serverless x402 seller gating a hosted skill.
-//
-// Port of the working seller reference at spikes/pi-wielder/src/x402-seller.mjs
-// into a Next.js Node-runtime route handler. The flow, per the x402 v1 spec:
-//
-// 1. POST without X-PAYMENT → 402 { x402Version: 1, accepts: [PaymentRequirements] }.
-// 2. POST with X-PAYMENT → facilitator /verify, then /settle. The settled
-// txHash is the single-use execution credential ("NO CREDENTIAL, NO RUN").
-// 3. Only then does the skill run: the skill content (see ./skill-content.ts,
-// generated from ./skill.md) becomes the SYSTEM prompt of one Anthropic
-// Messages API call. The caller receives OUTPUT ONLY — never the skill text.
-//
-// NOTE we settle BEFORE executing the skill (same deliberate ordering as the
-// reference seller): the txHash *is* the execution credential — pay → mint →
-// consume → execute.
-//
-// REPLAY PROTECTION: the EIP-3009 nonce inside the signed TransferWithAuthorization
-// is single-use ON-CHAIN. A replayed X-PAYMENT re-submits the same nonce, so the
-// facilitator's /settle fails — settle-failure IS the replay rejection. The
-// in-memory consumed-set below is belt-and-braces for a single warm serverless
-// instance (instances don't share memory; the chain is the real guarantee).
-
-import { NextResponse } from 'next/server';
-import { SKILL_CONTENT } from './skill-content';
-
-export const runtime = 'nodejs';
-
-// --- x402 v1 / Base Sepolia constants (mirror x402-seller.mjs) ---------------
-const X402_VERSION = 1;
-const NETWORK = 'base-sepolia';
-const USDC_ADDRESS = '0x036CbD53842c5426634e7929541eC2318f3dCF7e';
-const USDC_EIP712 = { name: 'USDC', version: '2' };
-const USDC_DECIMALS = 6;
-
-const PRICE_ATOMIC = '250000'; // $0.25 USDC (6 decimals)
-const SPLIT = { creator: 0.24375, treasury: 0.00625 }; // 97.5 / 2.5 of $0.25
-
-const KNOWN_SKILL_ID = 'optimizing-claude-code-prompts';
-const DEFAULT_FACILITATOR = 'https://x402.org/facilitator';
-
-const jsonToB64 = (o: unknown) => Buffer.from(JSON.stringify(o)).toString('base64');
-const b64ToJson = (s: string): T => JSON.parse(Buffer.from(s, 'base64').toString('utf8')) as T;
-
-// Per-instance consumed credentials (see REPLAY PROTECTION note above).
-const consumed = new Set();
-
-interface PaymentRequirements {
- scheme: string;
- network: string;
- maxAmountRequired: string;
- resource: string;
- description: string;
- mimeType: string;
- payTo: string;
- maxTimeoutSeconds: number;
- asset: string;
- extra: { name: string; version: string };
-}
-
-async function postJson(url: string, body: unknown): Promise {
- const res = await fetch(url, {
- method: 'POST',
- headers: { 'content-type': 'application/json' },
- body: JSON.stringify(body),
- });
- return res.json().catch(() => null);
-}
-
-export async function POST(
- req: Request,
- ctx: { params: Promise<{ skillId: string }> },
-) {
- const { skillId } = await ctx.params;
- if (skillId !== KNOWN_SKILL_ID) {
- return NextResponse.json({ error: `unknown skill: ${skillId}` }, { status: 404 });
- }
-
- // -- config: fail honestly BEFORE taking anyone's money -----------------------
- const payTo = process.env.PAY_TO_ADDRESS;
- if (!payTo) {
- return NextResponse.json(
- { error: 'seller misconfigured: PAY_TO_ADDRESS is not set' },
- { status: 500 },
- );
- }
- const anthropicKey = process.env.ANTHROPIC_API_KEY;
- if (!anthropicKey) {
- return NextResponse.json(
- { error: 'seller misconfigured: ANTHROPIC_API_KEY is not set' },
- { status: 502 },
- );
- }
- const facilitatorUrl = process.env.FACILITATOR_URL || DEFAULT_FACILITATOR;
-
- // -- input: validate before challenging (don't charge for an unrunnable call) --
- let input = '';
- try {
- const body = (await req.json()) as { input?: unknown };
- if (typeof body.input === 'string') input = body.input.trim();
- } catch {
- /* fall through to the 400 below */
- }
- if (!input) {
- return NextResponse.json(
- { error: 'request body must be JSON: { "input": "" }' },
- { status: 400 },
- );
- }
-
- const requirements: PaymentRequirements = {
- scheme: 'exact',
- network: NETWORK,
- maxAmountRequired: PRICE_ATOMIC, // atomic USDC (6 decimals) — $0.25
- resource: req.url,
- description: `Run the hosted skill "${KNOWN_SKILL_ID}" — output only, never the skill.`,
- mimeType: 'application/json',
- payTo,
- maxTimeoutSeconds: 60,
- asset: USDC_ADDRESS,
- // The buyer needs these to build the EIP-712 domain it signs against.
- extra: { name: USDC_EIP712.name, version: USDC_EIP712.version },
- };
-
- // -- step 1: no payment attached → challenge with 402 --------------------------
- const paymentHeader = req.headers.get('X-PAYMENT');
- if (!paymentHeader) {
- return NextResponse.json(
- { x402Version: X402_VERSION, error: 'X-PAYMENT header is required', accepts: [requirements] },
- { status: 402 },
- );
- }
-
- // -- step 2: decode + verify + settle through the facilitator -------------------
- let paymentPayload: unknown;
- try {
- paymentPayload = b64ToJson(paymentHeader);
- } catch {
- return NextResponse.json(
- { x402Version: X402_VERSION, error: 'malformed X-PAYMENT header', accepts: [requirements] },
- { status: 402 },
- );
- }
-
- const facilitatorBody = { x402Version: X402_VERSION, paymentPayload, paymentRequirements: requirements };
-
- let verify: { isValid?: boolean; invalidReason?: string } | null;
- let settle: { success?: boolean; errorReason?: string; transaction?: string; payer?: string } | null;
- try {
- verify = (await postJson(`${facilitatorUrl}/verify`, facilitatorBody)) as typeof verify;
- if (!verify?.isValid) {
- return NextResponse.json(
- {
- x402Version: X402_VERSION,
- error: `payment verification failed: ${verify?.invalidReason ?? 'unknown'}`,
- accepts: [requirements],
- },
- { status: 402 },
- );
- }
-
- settle = (await postJson(`${facilitatorUrl}/settle`, facilitatorBody)) as typeof settle;
- } catch {
- // Honest failure: the facilitator was unreachable — nothing was charged.
- return NextResponse.json(
- { error: `facilitator unreachable at ${facilitatorUrl} — payment not settled, nothing charged` },
- { status: 502 },
- );
- }
-
- if (!settle?.success || !settle.transaction) {
- // EIP-3009 nonces are single-use on-chain, so a replayed payment lands here:
- // settle-failure = replay rejected (or insufficient funds / expired authorization).
- return NextResponse.json(
- {
- x402Version: X402_VERSION,
- error: `payment settlement failed: ${settle?.errorReason ?? 'unknown'} (replayed or invalid authorization — EIP-3009 nonces spend exactly once)`,
- accepts: [requirements],
- },
- { status: 402 },
- );
- }
-
- // -- step 3: the settled txHash is a single-use credential ----------------------
- if (consumed.has(settle.transaction)) {
- return NextResponse.json(
- { error: 'replayed payment: credential already consumed', txHash: settle.transaction },
- { status: 409 },
- );
- }
- consumed.add(settle.transaction);
-
- // -- step 4: run the skill — output only, NEVER the skill text -------------------
- let output: string;
- try {
- const anthropicRes = await fetch('https://api.anthropic.com/v1/messages', {
- method: 'POST',
- headers: {
- 'x-api-key': anthropicKey,
- 'anthropic-version': '2023-06-01',
- 'content-type': 'application/json',
- },
- body: JSON.stringify({
- model: 'claude-sonnet-4-6',
- max_tokens: 1500,
- system: SKILL_CONTENT, // the protected asset stays server-side
- messages: [{ role: 'user', content: input }],
- }),
- });
-
- if (!anthropicRes.ok) {
- const detail = await anthropicRes.text().catch(() => '');
- // Honest failure: payment settled but the skill run failed. The txHash is
- // included so the buyer holds the receipt for the failed run.
- return NextResponse.json(
- {
- error: `skill execution failed: anthropic returned ${anthropicRes.status}`,
- detail: detail.slice(0, 500),
- paid: { amountUSDC: Number(PRICE_ATOMIC) / 10 ** USDC_DECIMALS, txHash: settle.transaction },
- },
- { status: 502 },
- );
- }
-
- const message = (await anthropicRes.json()) as {
- content?: Array<{ type: string; text?: string }>;
- };
- output = (message.content ?? [])
- .filter((b) => b.type === 'text' && typeof b.text === 'string')
- .map((b) => b.text)
- .join('\n');
- } catch {
- return NextResponse.json(
- {
- error: 'skill execution failed: anthropic unreachable',
- paid: { amountUSDC: Number(PRICE_ATOMIC) / 10 ** USDC_DECIMALS, txHash: settle.transaction },
- },
- { status: 502 },
- );
- }
-
- // -- success: output + receipt + declared split ----------------------------------
- return NextResponse.json(
- {
- output,
- paid: { amountUSDC: Number(PRICE_ATOMIC) / 10 ** USDC_DECIMALS, txHash: settle.transaction },
- split: SPLIT,
- },
- {
- headers: {
- // Standard buyer-visible settlement receipt (mirrors the reference seller).
- 'X-PAYMENT-RESPONSE': jsonToB64({
- success: true,
- transaction: settle.transaction,
- network: NETWORK,
- payer: settle.payer,
- }),
- },
- },
- );
-}
diff --git a/site/app/api/invoke/[skillId]/skill-content.ts b/site/app/api/invoke/[skillId]/skill-content.ts
deleted file mode 100644
index f8520d0..0000000
--- a/site/app/api/invoke/[skillId]/skill-content.ts
+++ /dev/null
@@ -1,7 +0,0 @@
-// GENERATED at scaffold time from ../../../../skill.md (source: .claude/skills/optimizing-claude-code-prompts/SKILL.md).
-// Inlined as a TS constant so the skill content is bundled into the serverless function
-// (survives Vercel — no outputFileTracingIncludes needed). Regenerate by re-running the
-// scaffold step; do not hand-edit.
-// The skill text is the PROTECTED ASSET: it is used server-side as the system prompt and
-// must never be returned to the caller.
-export const SKILL_CONTENT: string = "---\nname: optimizing-claude-code-prompts\ndescription: Turn a rough or vague request to Claude Code into a precise, repo-grounded, high-performing prompt. Use when the user wants help phrasing, drafting, improving, optimizing, tightening, or \"making better\" a prompt/request/instruction for Claude Code; when the user pastes a draft and asks how to word it; when a prompt already ran and Claude did the wrong thing (diagnose and fix it); or when Claude Code keeps missing the mark — doing too much, ignoring constraints, solving the wrong problem, over-engineering, or needing many back-and-forth rounds. Triggers include \"optimize this prompt\", \"help me ask Claude to…\", \"rewrite my request\", \"why did Claude do that\", \"how should I word this\", \"make this prompt clearer\".\n---\n\n# Optimizing Claude Code Prompts\n\n## Overview\n\nRewrite a user's rough request into a prompt that Claude Code can execute correctly on the\nfirst pass. The current models (Opus 4.8) follow instructions **literally** and run\n**autonomously**, so the highest-leverage move is to front-load intent, constraints, and a\nrunnable check in the first message. Vague asks spread across many turns waste tokens and\nbuild the wrong thing.\n\n**Core principle:** A strong Claude Code prompt names the **goal**, the **context**, the\n**constraints**, the **files/patterns to follow**, and **a check Claude can run to know it's\ndone**. Optimizing means supplying whichever of these the user left out — and resolving each\nto a *real artifact in this repo*, not a placeholder the user must fill in later.\n\n## The one rule that makes this skill worth invoking: ground in the repo\n\nA prompt full of `@[your-file-here]` and \"run the test suite\" is just a template — it hands the\nhard part back to the user. Before writing the optimized prompt, **resolve every reference to a\nreal thing** using the tools you have:\n\n| Reference | How to resolve it | Don't emit |\n|---|---|---|\n| The target file(s) | `Glob`/`Grep` for the actual path | `@[src/whatever]` |\n| \"Done when…\" check | Read `package.json` scripts / `Makefile` / `pyproject.toml` / CI config for the real test/build/lint command | \"run the tests\" |\n| \"Follow the pattern in…\" | `Grep` for a sibling that already does the thing; name that file | \"the existing pattern\" |\n| The symptom's likely location | `Grep` the error string / feature name to the directory | \"somewhere in the code\" |\n\n**Resolve, don't guess.** If a genuine look can't resolve something, ask **one** surgical\nquestion — never paper over it with a bracketed guess.\n\n**Red flags that you skipped grounding** (STOP and go look): the output prompt contains `[...]`,\n\"the relevant file\", \"your test command\", \"the appropriate\", or any path you didn't verify exists.\n\n## Pick the mode\n\n| The user… | Mode | What you do |\n|---|---|---|\n| Pasted a draft prompt | **Optimize** | Ground it, fill missing ingredients, return the rewrite |\n| Gave a bare goal (\"add auth\") | **Generate** | Ground it, build the prompt from scratch |\n| Says a prompt already failed (\"Claude did X not Y\") | **Diagnose** | Map the failure to the missing ingredient, fix it, add the session-hygiene step |\n| Wants a large/multi-file feature | **Spec** | Don't hand-write a mega-prompt — route to the interview→SPEC.md pattern (see reference) |\n\n## Workflow\n\n1. **Capture** the raw request verbatim. Pick the mode.\n2. **Ground** in the repo — resolve real paths, the real verification command, the real pattern\n file (table above). Do this with parallel `Glob`/`Grep`/`Read` calls; it's fast and it's the\n whole point.\n3. **Diagnose + score** the request against the seven ingredients. Show the scorecard.\n4. **Resolve gaps:** correctness-blocking gaps that grounding couldn't settle → up to **3**\n `AskUserQuestion` questions. If the user wants speed (\"just optimize it\"), proceed and label\n any remaining assumption explicitly.\n5. **Write** the optimized prompt as a copy-paste block, with real values throughout.\n6. **Hand back + offer to run it.** Note the one assumption most worth confirming, if any.\n\nDon't pad the prompt with obvious instructions (\"write clean code\"). Opus 4.8 is literal and\nsmart — filler dilutes the real constraints.\n\n## The seven ingredients\n\n| Ingredient | Answers | Weak → Strong |\n|---|---|---|\n| **Goal** | What outcome, concretely? | \"improve the dashboard\" → \"add date-range filtering to the dashboard\" |\n| **Context** | Why / where does this live? | — → \"endpoint is `@src/api/orders.ts`; read-heavy, data changes hourly\" |\n| **Constraints** | What must NOT change / limits? | — → \"keep the JSON shape backward-compatible; no new deps\" |\n| **References** | What pattern to follow? | — → \"mirror `@src/api/users.ts`\" |\n| **Acceptance / check** | How do we know it's done? | \"make it work\" → \"`npm test src/api/orders.test.ts` passes; show output\" |\n| **Approach / mode** | How should Claude work? | — → \"plan first\" / \"use TDD\" / \"just do it\" |\n| **Output** | What should Claude return? | — → \"show the diff and the test results\" |\n\nThe **acceptance check** is the highest-value ingredient — it's the difference between a session\nthe user babysits and one Claude closes on its own. Always try to supply a real one.\n\n## Scorecard (show this — it teaches the pattern)\n\n```text\nGoal ✓ Context ✗ → added Constraints ✗ → added\nReferences ✗→added Check ✗ → added Approach ~ → set Output ✓\nBefore: 2/7 After: 7/7\n```\n\n## Output template\n\n```text\n\n\nContext: \nConstraints: \nFollow: \nDone when: \nApproach: \n```\n\nDrop any line that genuinely doesn't apply. Prefer natural prose for tiny tasks; use the labeled\nlines when there are real constraints.\n\n## Example (grounded — note: no brackets)\n\n**Raw:** `make the checkout page faster`\n\n**Grounding moves:**\n- `Glob **/checkout*` → `src/checkout/CheckoutPage.tsx`\n- `package.json` scripts → `\"test\": \"vitest run\"`, `\"build\": \"vite build\"`\n- `Grep \"useMemo\\|React.memo\" src` → `src/cart/CartPage.tsx` already memoizes its list\n\n**Scorecard:** Before 1/7 → After 7/7\n\n**Optimized:**\n\n```text\nSpeed up the checkout page in @src/checkout/CheckoutPage.tsx — its product list re-renders on\nevery keystroke in the promo-code field.\n\nContext: the list isn't memoized, so typing recomputes and re-renders all rows.\nConstraints: don't change checkout behavior or the order-submit payload; no new dependencies.\nFollow: the memoization pattern already in @src/cart/CartPage.tsx (React.memo on rows + useMemo\non the derived list).\nDone when: `npx vitest run src/checkout` passes, `npm run build` succeeds, and typing in the\npromo field no longer re-renders product rows (verify with a render count or React DevTools).\nShow me the diff and the test output.\nApproach: plan first, then implement.\n```\n\n## Mode specifics\n\n- **Diagnose** a failed prompt: name the failure → the missing ingredient it maps to → the fix.\n \"Claude refactored the whole file\" = missing **Constraints** (add \"only change X; no refactors\").\n \"Claude solved the wrong thing\" = missing **Goal/Context** (name the file + symptom). Also tell\n the user the session fix: after two bad corrections, `/clear` and resend the optimized prompt;\n use `/rewind` to undo Claude's changes.\n- **Generate** from a bare goal: ground first, then if scope is still ambiguous ask the 3\n questions before writing — don't generate a confident prompt on top of unknowns.\n- **Spec** a big feature: see the interview→SPEC.md→fresh-session pattern in the reference.\n\n## Common mistakes\n\n| Mistake | Fix |\n|---|---|\n| Emitting `[bracketed placeholders]` | Ground in the repo; resolve to real paths/commands, or ask one question |\n| Stacking unrelated tasks in one prompt | One task per prompt; `/clear` between them |\n| \"Make it better\" with no check | Name a real verification: a test command, a build, a screenshot to compare |\n| Describing the fix instead of the symptom | Give symptom + likely location; let Claude find the cause |\n| Over-specifying the obvious | Cut filler; keep only constraints Claude can't infer |\n| Dribbling context over many turns | Front-load intent + constraints in the first message — Opus 4.8 rewards this |\n\n## Deeper guidance\n\nFor the full strategy tables, model-specific behavior (literalism, autonomy, over-eagerness),\nthe verification-gating ladder, rich-context input (`@files`, images, URLs, piping), plan-mode\ndecisions, mid-task course-correction phrasing, the interview→spec pattern, and reusable prompt\nsnippets, read [references/claude-code-prompting-guide.md](references/claude-code-prompting-guide.md).\n\nSource material: Anthropic's publicly documented Claude Code prompting guidance\n(https://code.claude.com/docs), summarized in this skill's own words.\n";
diff --git a/site/app/api/invoke/[skillId]/skill.md b/site/app/api/invoke/[skillId]/skill.md
deleted file mode 100644
index b1c1114..0000000
--- a/site/app/api/invoke/[skillId]/skill.md
+++ /dev/null
@@ -1,160 +0,0 @@
----
-name: optimizing-claude-code-prompts
-description: Turn a rough or vague request to Claude Code into a precise, repo-grounded, high-performing prompt. Use when the user wants help phrasing, drafting, improving, optimizing, tightening, or "making better" a prompt/request/instruction for Claude Code; when the user pastes a draft and asks how to word it; when a prompt already ran and Claude did the wrong thing (diagnose and fix it); or when Claude Code keeps missing the mark — doing too much, ignoring constraints, solving the wrong problem, over-engineering, or needing many back-and-forth rounds. Triggers include "optimize this prompt", "help me ask Claude to…", "rewrite my request", "why did Claude do that", "how should I word this", "make this prompt clearer".
----
-
-# Optimizing Claude Code Prompts
-
-## Overview
-
-Rewrite a user's rough request into a prompt that Claude Code can execute correctly on the
-first pass. The current models (Opus 4.8) follow instructions **literally** and run
-**autonomously**, so the highest-leverage move is to front-load intent, constraints, and a
-runnable check in the first message. Vague asks spread across many turns waste tokens and
-build the wrong thing.
-
-**Core principle:** A strong Claude Code prompt names the **goal**, the **context**, the
-**constraints**, the **files/patterns to follow**, and **a check Claude can run to know it's
-done**. Optimizing means supplying whichever of these the user left out — and resolving each
-to a *real artifact in this repo*, not a placeholder the user must fill in later.
-
-## The one rule that makes this skill worth invoking: ground in the repo
-
-A prompt full of `@[your-file-here]` and "run the test suite" is just a template — it hands the
-hard part back to the user. Before writing the optimized prompt, **resolve every reference to a
-real thing** using the tools you have:
-
-| Reference | How to resolve it | Don't emit |
-|---|---|---|
-| The target file(s) | `Glob`/`Grep` for the actual path | `@[src/whatever]` |
-| "Done when…" check | Read `package.json` scripts / `Makefile` / `pyproject.toml` / CI config for the real test/build/lint command | "run the tests" |
-| "Follow the pattern in…" | `Grep` for a sibling that already does the thing; name that file | "the existing pattern" |
-| The symptom's likely location | `Grep` the error string / feature name to the directory | "somewhere in the code" |
-
-**Resolve, don't guess.** If a genuine look can't resolve something, ask **one** surgical
-question — never paper over it with a bracketed guess.
-
-**Red flags that you skipped grounding** (STOP and go look): the output prompt contains `[...]`,
-"the relevant file", "your test command", "the appropriate", or any path you didn't verify exists.
-
-## Pick the mode
-
-| The user… | Mode | What you do |
-|---|---|---|
-| Pasted a draft prompt | **Optimize** | Ground it, fill missing ingredients, return the rewrite |
-| Gave a bare goal ("add auth") | **Generate** | Ground it, build the prompt from scratch |
-| Says a prompt already failed ("Claude did X not Y") | **Diagnose** | Map the failure to the missing ingredient, fix it, add the session-hygiene step |
-| Wants a large/multi-file feature | **Spec** | Don't hand-write a mega-prompt — route to the interview→SPEC.md pattern (see reference) |
-
-## Workflow
-
-1. **Capture** the raw request verbatim. Pick the mode.
-2. **Ground** in the repo — resolve real paths, the real verification command, the real pattern
- file (table above). Do this with parallel `Glob`/`Grep`/`Read` calls; it's fast and it's the
- whole point.
-3. **Diagnose + score** the request against the seven ingredients. Show the scorecard.
-4. **Resolve gaps:** correctness-blocking gaps that grounding couldn't settle → up to **3**
- `AskUserQuestion` questions. If the user wants speed ("just optimize it"), proceed and label
- any remaining assumption explicitly.
-5. **Write** the optimized prompt as a copy-paste block, with real values throughout.
-6. **Hand back + offer to run it.** Note the one assumption most worth confirming, if any.
-
-Don't pad the prompt with obvious instructions ("write clean code"). Opus 4.8 is literal and
-smart — filler dilutes the real constraints.
-
-## The seven ingredients
-
-| Ingredient | Answers | Weak → Strong |
-|---|---|---|
-| **Goal** | What outcome, concretely? | "improve the dashboard" → "add date-range filtering to the dashboard" |
-| **Context** | Why / where does this live? | — → "endpoint is `@src/api/orders.ts`; read-heavy, data changes hourly" |
-| **Constraints** | What must NOT change / limits? | — → "keep the JSON shape backward-compatible; no new deps" |
-| **References** | What pattern to follow? | — → "mirror `@src/api/users.ts`" |
-| **Acceptance / check** | How do we know it's done? | "make it work" → "`npm test src/api/orders.test.ts` passes; show output" |
-| **Approach / mode** | How should Claude work? | — → "plan first" / "use TDD" / "just do it" |
-| **Output** | What should Claude return? | — → "show the diff and the test results" |
-
-The **acceptance check** is the highest-value ingredient — it's the difference between a session
-the user babysits and one Claude closes on its own. Always try to supply a real one.
-
-## Scorecard (show this — it teaches the pattern)
-
-```text
-Goal ✓ Context ✗ → added Constraints ✗ → added
-References ✗→added Check ✗ → added Approach ~ → set Output ✓
-Before: 2/7 After: 7/7
-```
-
-## Output template
-
-```text
-
-
-Context:
-Constraints:
-Follow:
-Done when:
-Approach:
-```
-
-Drop any line that genuinely doesn't apply. Prefer natural prose for tiny tasks; use the labeled
-lines when there are real constraints.
-
-## Example (grounded — note: no brackets)
-
-**Raw:** `make the checkout page faster`
-
-**Grounding moves:**
-- `Glob **/checkout*` → `src/checkout/CheckoutPage.tsx`
-- `package.json` scripts → `"test": "vitest run"`, `"build": "vite build"`
-- `Grep "useMemo\|React.memo" src` → `src/cart/CartPage.tsx` already memoizes its list
-
-**Scorecard:** Before 1/7 → After 7/7
-
-**Optimized:**
-
-```text
-Speed up the checkout page in @src/checkout/CheckoutPage.tsx — its product list re-renders on
-every keystroke in the promo-code field.
-
-Context: the list isn't memoized, so typing recomputes and re-renders all rows.
-Constraints: don't change checkout behavior or the order-submit payload; no new dependencies.
-Follow: the memoization pattern already in @src/cart/CartPage.tsx (React.memo on rows + useMemo
-on the derived list).
-Done when: `npx vitest run src/checkout` passes, `npm run build` succeeds, and typing in the
-promo field no longer re-renders product rows (verify with a render count or React DevTools).
-Show me the diff and the test output.
-Approach: plan first, then implement.
-```
-
-## Mode specifics
-
-- **Diagnose** a failed prompt: name the failure → the missing ingredient it maps to → the fix.
- "Claude refactored the whole file" = missing **Constraints** (add "only change X; no refactors").
- "Claude solved the wrong thing" = missing **Goal/Context** (name the file + symptom). Also tell
- the user the session fix: after two bad corrections, `/clear` and resend the optimized prompt;
- use `/rewind` to undo Claude's changes.
-- **Generate** from a bare goal: ground first, then if scope is still ambiguous ask the 3
- questions before writing — don't generate a confident prompt on top of unknowns.
-- **Spec** a big feature: see the interview→SPEC.md→fresh-session pattern in the reference.
-
-## Common mistakes
-
-| Mistake | Fix |
-|---|---|
-| Emitting `[bracketed placeholders]` | Ground in the repo; resolve to real paths/commands, or ask one question |
-| Stacking unrelated tasks in one prompt | One task per prompt; `/clear` between them |
-| "Make it better" with no check | Name a real verification: a test command, a build, a screenshot to compare |
-| Describing the fix instead of the symptom | Give symptom + likely location; let Claude find the cause |
-| Over-specifying the obvious | Cut filler; keep only constraints Claude can't infer |
-| Dribbling context over many turns | Front-load intent + constraints in the first message — Opus 4.8 rewards this |
-
-## Deeper guidance
-
-For the full strategy tables, model-specific behavior (literalism, autonomy, over-eagerness),
-the verification-gating ladder, rich-context input (`@files`, images, URLs, piping), plan-mode
-decisions, mid-task course-correction phrasing, the interview→spec pattern, and reusable prompt
-snippets, read [references/claude-code-prompting-guide.md](references/claude-code-prompting-guide.md).
-
-Source material: Anthropic's publicly documented Claude Code prompting guidance
-(https://code.claude.com/docs), summarized in this skill's own words.
diff --git a/site/app/components/landing/Hero.tsx b/site/app/components/landing/Hero.tsx
new file mode 100644
index 0000000..6942979
--- /dev/null
+++ b/site/app/components/landing/Hero.tsx
@@ -0,0 +1,117 @@
+import Link from 'next/link';
+
+import styles from '../../landing.module.css';
+
+export function Hero({ pilotUrl }: { pilotUrl: string }) {
+ return (
+
+
+
+ );
+}
diff --git a/site/app/components/landing/ProofLoop.tsx b/site/app/components/landing/ProofLoop.tsx
new file mode 100644
index 0000000..a5b63ee
--- /dev/null
+++ b/site/app/components/landing/ProofLoop.tsx
@@ -0,0 +1,40 @@
+import { productProof } from '../../landing-content';
+import styles from '../../landing.module.css';
+
+export function ProofLoop() {
+ return (
+
+
+
The control loop
+
From Agent request to accountable spend.
+
+ The customer-hosted Wallet Kernel stays wallet-first: it decides what
+ may be signed and records what happened. Planned on-chain settlement
+ stays behind the release gate.
+
+ ))}
+
+
+ );
+}
diff --git a/site/app/components/landing/SpendControlSandbox.tsx b/site/app/components/landing/SpendControlSandbox.tsx
new file mode 100644
index 0000000..c850c98
--- /dev/null
+++ b/site/app/components/landing/SpendControlSandbox.tsx
@@ -0,0 +1,494 @@
+'use client';
+
+import { useEffect, useReducer, useRef } from 'react';
+
+import styles from '../../landing.module.css';
+import {
+ demoSessionProjection,
+ demoWallet,
+ INITIAL_SPEND_SANDBOX_STATE,
+ nextSpendSandboxAction,
+ spendPolicy,
+ spendSandboxReducer,
+ spendSandboxView,
+ spendStageIndex,
+ type DemoSpendAttempt,
+ type SpendSandboxStage,
+} from './spend-control-model';
+
+const steps: readonly {
+ label: string;
+ detail: string;
+ stage: SpendSandboxStage;
+}[] = [
+ { label: 'Policy', detail: 'Default deny', stage: 'ready' },
+ { label: 'Auto-pay', detail: 'Below ceiling', stage: 'policy_loaded' },
+ { label: 'Deny', detail: 'Unknown seller', stage: 'auto_allowed' },
+ { label: 'Escalate', detail: 'Exact mismatch', stage: 'denied' },
+ { label: 'Approve', detail: 'Still no signature', stage: 'approval_pending' },
+ { label: 'Retry', detail: 'Wielder repeats', stage: 'approved_waiting_retry' },
+];
+
+const announcements: Record = {
+ ready: 'Sandbox ready. Load the fictional customer policy to begin.',
+ policy_loaded:
+ 'Default-deny policy loaded for one customer-owned Base Sepolia wallet.',
+ auto_allowed:
+ 'The 0.08 test-USDC request matched policy and advanced in simulation.',
+ denied:
+ 'The unknown seller was denied before the fictional wallet or signer path.',
+ approval_pending:
+ 'The 0.60 request is queued for exact approval. No signature exists.',
+ approved_waiting_retry:
+ 'Approval is recorded and the flow has stopped. The Wielder must repeat the exact request.',
+ approval_invalidated:
+ 'The retry was rejected and its prior approval was invalidated. Start a new request.',
+ finalized:
+ 'The exact request was deliberately repeated and an unsigned session projection is ready.',
+};
+
+const isStepComplete = (
+ stepStage: SpendSandboxStage,
+ currentStage: SpendSandboxStage,
+): boolean => spendStageIndex(currentStage) > spendStageIndex(stepStage);
+
+const formatAtomic = (atomic: number): string =>
+ `${(atomic / 1_000_000).toFixed(2)} test USDC`;
+
+const decisionLabel = (attempt: DemoSpendAttempt): string => {
+ if (attempt.decision === 'allow') return '✓ Policy matched';
+ if (attempt.decision === 'deny') return '× Default denied';
+ return '◇ Exact approval path';
+};
+
+const signatureLabel = (attempt: DemoSpendAttempt): string => {
+ if (attempt.hasProjectedSigningBoundary) {
+ return 'Unsigned flow projection · no key used';
+ }
+ if (attempt.decision === 'deny') return 'Signer never reached';
+ return 'No signature created';
+};
+
+function SpendProjectionPreview({
+ pilotUrl,
+ chargedAtomic,
+ remainingAtomic,
+}: {
+ pilotUrl: string;
+ chargedAtomic: number;
+ remainingAtomic: number;
+}) {
+ return (
+ <>
+
+
+
+
Exact authority
+
The approval cannot become a blank check.
+
+ It is bound to one Spend Intent, seller, resource, wallet, exact
+ approved amount, policy version, and expiry. A changed request
+ must start again.
+
+
+
+
+
Default action
+
+ Unknown seller or shape
+ Deny
+
+
+
+
Automatic ceiling
+
+ Every policy field matches
+ {spendPolicy.automaticAllowLabel}
+
- DO NOT HAND OVER · MACHINE WASH ON-CHAIN · 100% AUTHORED WORK
+ ARCHIVED MANIFESTO · STATIC RECEIPT · NO LIVE ENDPOINT
diff --git a/site/app/page.tsx b/site/app/page.tsx
index f0899c9..7b48ad2 100644
--- a/site/app/page.tsx
+++ b/site/app/page.tsx
@@ -1,11 +1,151 @@
-import { manifesto } from './content';
-import Manifesto from './manifesto';
+import Link from 'next/link';
-// Design decision 2026-07-12: three prototype variants were built and flipped
-// live ("THE TEN" / "RECEIPT" / "GALLERY PLACARD"); "THE TEN" won. The
-// "RECEIPT" variant is preserved in ../design-archive — its thermal-printer
-// ledger aesthetic is a candidate for future invocation-receipt views.
+import { Hero } from './components/landing/Hero';
+import { PilotCta } from './components/landing/PilotCta';
+import { ProofLoop } from './components/landing/ProofLoop';
+import { SpendControlSandbox } from './components/landing/SpendControlSandbox';
+import {
+ defaultPilotUrl,
+ evidenceReceipts,
+ repositoryUrl,
+ rolePaths,
+ spendControlDesignUrl,
+} from './landing-content';
+import styles from './landing.module.css';
export default function Page() {
- return ;
+ const pilotUrl =
+ process.env.NEXT_PUBLIC_PILOT_CONTACT_URL?.trim() || defaultPilotUrl;
+
+ return (
+
+
+ Skip to main content
+
+
+
+
+
+
+
+ Pre-release candidate · publication gate not cleared
+
+ Customer demand, funded-wallet deployment, and live Wallet Kernel
+ settlement remain unvalidated
+
+
+
+
+
+
+
+
+
+
+
One kernel · three control surfaces
+
Bounded autonomy the buying group can inspect.
+
+
+ The Agent requests. The operator governs. The customer-owned wallet
+ signs only what the Wallet Kernel has already authorized.
+
+
+
+ {rolePaths.map((role) => (
+
+
{role.label}
+
{role.title}
+
{role.body}
+
+ ))}
+
+
+
+
+
+
+
+
+
+
Evidence stays bounded
+
+ Offline Wallet Kernel proof—not a production claim.
+
+
+
+ The repository verifies policy, budget, approval, replay, refund,
+ and recovery behavior offline. This browser produces only an
+ unsigned projection that is not broadcast. Live CDP payment and
+ live testnet settlement evidence remain not run. The pinned Linux
+ deployment is also not run.
+
+ Base Sepolia fixture · no mainnet · no real funds
+
+
+
+
+
+
+
+
+
+ );
}
diff --git a/site/app/proof/page.tsx b/site/app/proof/page.tsx
new file mode 100644
index 0000000..7e859db
--- /dev/null
+++ b/site/app/proof/page.tsx
@@ -0,0 +1,21 @@
+import type { Metadata } from 'next';
+
+import { manifesto } from '../content';
+import Manifesto from '../manifesto';
+
+export const metadata: Metadata = {
+ title: 'Archived protocol proof',
+ description:
+ 'An archived manifesto and one bounded historical Base Sepolia test-USDC receipt. No live payment endpoint.',
+ alternates: { canonical: '/proof' },
+ openGraph: {
+ title: '“THE PROOF” — a manifesto for the sovereignty of authored work',
+ description:
+ 'Ten historical principles and one bounded Base Sepolia test-USDC receipt in a static archive.',
+ url: '/proof',
+ },
+};
+
+export default function ProofPage() {
+ return ;
+}
diff --git a/site/design-archive/NOTES.md b/site/design-archive/NOTES.md
index 4a5e92b..fdb0361 100644
--- a/site/design-archive/NOTES.md
+++ b/site/design-archive/NOTES.md
@@ -5,13 +5,15 @@ Three structurally different variants were built and flipped live via
`?variant=`; the decision:
- **Winner — "THE TEN"** (industrial wall text): promoted to `app/manifesto.tsx`.
-- **Archived — "RECEIPT"** (`VariantB.tsx` + `VariantB.module.css` here):
- the whole manifesto as a thermal-printer point-of-sale receipt — black,
- phosphor monospace, principles as line items, txHashes as texture, terminal
- invoke prompt. Kept because the owner likes its elements; it is the natural
- design language for **future invocation-receipt and session-ledger views**.
+- **Archived — "RECEIPT"** (`VariantB.module.css` here): the visual direction
+ used a thermal-printer point-of-sale receipt — black, phosphor monospace,
+ line-item texture, and a CSS barcode. The interactive `VariantB.tsx` prototype
+ was retired with the browser-wallet payment path because it depended on the
+ deleted invocation hook and preserved obsolete signing copy. The remaining CSS
+ is a visual reference for **future receipt and session-ledger views**; it is not
+ a runnable payment interface.
- **Scrapped — "GALLERY PLACARD"**: museum-placard editorial layout. Verdict:
too quiet for the material.
-These files are design artifacts, not live code — excluded from the TypeScript
-build; their imports reference `app/` paths that may drift.
+This stylesheet is a design artifact, not live code, and `design-archive/`
+remains excluded from the TypeScript build.
diff --git a/site/design-archive/VariantB.tsx b/site/design-archive/VariantB.tsx
deleted file mode 100644
index d837bf1..0000000
--- a/site/design-archive/VariantB.tsx
+++ /dev/null
@@ -1,356 +0,0 @@
-'use client';
-
-// VARIANT B — "RECEIPT". The manifesto as a point-of-sale receipt / protocol
-// log. Pure black, phosphor-white ui-monospace, one narrow ~46ch thermal-paper
-// column. Principles are LINE ITEMS. The proof section is a settlement
-// receipt. The invoke panel is a terminal prompt whose states stream as log
-// lines. Zero large type. Density maximal.
-
-import { useEffect, useRef, useState, type FormEvent } from 'react';
-import type { Manifesto } from '../content';
-import { useInvoke, type InvokeState } from '../components/useInvoke';
-import styles from './VariantB.module.css';
-
-const DIM = 'text-[#7f997f]';
-const RULE = 'border-[#334133]';
-
-const PHASE_LINES: Partial> = {
- connecting: '[connecting] wallet handshake → base-sepolia (84532)',
- paying: '[paying] HTTP 402 → signing EIP-3009 — sign, don’t send',
- running: '[running] authorization settled — skill executing',
- done: '[done] exit 0 — output received. never the skill.',
- error: '[error] process exited non-zero',
-};
-
-const DEFAULT_INPUT = 'Optimize this prompt: “summarize my meeting notes”';
-
-// --- receipt primitives -------------------------------------------------------
-
-function Rule({ dashed = true }: { dashed?: boolean }) {
- return (
-
- );
-}
-
-function Tear() {
- return (
-