# Receiz SDK

Current package: `@receiz/sdk@129.0.0`. Prepared release coordinate: `v129.0.0`. Constitutional ruleset: `127.0.0`.

Install:

```bash
npm install @receiz/sdk
```

The matching `@receiz/ai-skills` package is installed as a dependency. Agent hosts can load all 43 skills, 37 manifests, and 34 OpenAI agent prompts from `node_modules/@receiz/ai-skills`; the SDK still enforces continuity even when a host does not load them, and no AI instruction becomes proof authority.

## Registered native application setup

For registered native APIs, use the **exact registered OIDC client ID** as `RECEIZ_APPLICATION_ID` and SDK `applicationId`, preserving its case and `rc_` prefix throughout audience, grant, session, source, replay, and requests. It is separate from the subject's Receiz ID, username, and client secret. Keep client secrets server-side; never normalize or substitute aliases. A valid-format unknown client remains unauthorized.

Follow [registered native runtime](https://unpkg.com/@receiz/sdk@129.0.0/docs/registered-native-runtime.md) for device-held consent, minimum-scope proof grant, current complete subject-source publication, authority-session opening, actual operation qualification, and deployed integration evidence. Funding, payment, complete bearer delivery, claim, custody, seller proceeds, and asset use require separate evidence; card checkout success alone establishes no asset purchase or ownership transfer. Compatible SDK/MCP/skills, server, and forward database migration must ship together without rewriting old sealed coordinates or history.

## V129 — Reality-Grade Infrastructure

V129 preserves exact registered application IDs across the established SDK, compiler, full MCP and AI packages, with complete source custody, first-seal ownership, deterministic coordinates and verified append continuity. The public function catalog covers 704 callable exports across the main, compiler, testing, React, offline sealing, local subject host, offline KaiSigil and pure valuation entry points. MCP capability reporting includes this catalog and the complete 425-method client inventory; 356 explicit tools retain their SDK authority boundaries. Twenty-one new full-library adapters compose seven financial operations and eleven public-proof, World, sports, verification, and record operations plus three read-only offline valuation adapters without replacing proof or custody.

The [SDK/MCP execution coverage guide](https://unpkg.com/@receiz/sdk@129.0.0/docs/capability-execution-coverage.md) distinguishes direct bounded MCP tools from SDK operations composed by a trusted host or device. Discovery describes all 425 client methods and 704 callable exports; execution follows the actual adapter, credentials, grants, confirmation, and custody requirements. Identity-signed public-store publication, offline Note/Reserve WebAuthn custody, and private account-Twin binary export/import require SDK host or device composition; subject-Twin has its own source-family adapters. Exact bytes, device keys, callbacks, and SDK-issued authority objects remain in their existing host or device runtime. The full library includes financial execution; the separate ChatGPT profile retains 195 restricted tools.

The current `receiz_connect_record` adapter requires `receiz:record`, exact single-use record/save/visibility consent, and the complete PNG from `connect.record`. Set `body.save` explicitly: the route defaults it to true. `vis: "public"` selects showcase, `"private"` selects private visibility, and `"hidden"` or an omitted `vis` hides the record from showcase. It verifies the enclosing canonical proof before private exact-byte output. Save, visibility, and showcase response headers describe server effects beneath that proof. A remote save may precede a failed delivery or verification; resolve the unknown outcome before retry and never infer zero remote writes.

V127 ships [offline file sealing and local KaiSigil proving](https://unpkg.com/@receiz/sdk@129.0.0/docs/offline-sealing.md) and a [durable local subject runtime](https://unpkg.com/@receiz/sdk@129.0.0/docs/local-subject-runtime.md). After explicit device enrollment, file sealing runs without network access; KaiSigil proving requires no enrollment or network. The Node subject host admits sealed sources under the genuine identity and consumes full, causally bound KaiSigil proofs for temporal execution. Portable exports preserve the exact historical V120 snapshot and complete temporal evidence; seal the envelope before transport. Historical HTTP methods fail before requests unless their explicit compatibility configuration is selected; see [historical HTTP compatibility](https://unpkg.com/@receiz/sdk@129.0.0/docs/historical-http.md).

### Preserved V125 economy contracts

**Sealed Reality Becomes Spendable Value. Economic authority follows proof, not institution.** V125 activates the complete institution-independent Glyph economy without rewriting any earlier artifact, identity, custody, Settlement, Reserve, execution, or source-carried proof. Settlement is spendable proof-native Phi. Reserve is the legacy funding rail. Wallet Account Value presents both, while proof objects and deterministic value heads remain authority above UI, server, and database projections.

A registered lawful-action law and each completed action are carried by separate enclosing sealed proof objects. Receiz verifies the enclosing proof first, then reverifies the embedded portable execution-authority transition and derives the actor, subject head, causal parents, input/output commitments, completion witness, and Kai coordinates from that verified runtime. It admits one stable spendable membership to the current owner and derives current value in micro-Phi as `(completionKai - startKai + 1) * (valuationKai - completionKai + 1)`. The caller cannot submit a completion verdict, amount, multiplier, bonus, backfill, or institutional exemption. A custody transfer moves the same membership and preserves provenance; it never duplicates value.

Any architecture can use the framework-neutral production client:

```ts
import { createReceizV125LawfulActionClient } from "@receiz/sdk";

const lawfulActions = createReceizV125LawfulActionClient({
  baseUrl: "https://receiz.com",
  getAccessToken: () => delegatedAccessToken,
});

const law = await lawfulActions.registerLaw({
  proofObject: { exactBytes: sealedLawBytes, filename: "law.receiz", mimeType: "application/vnd.receiz" },
  idempotencyKey: "law:delivery-complete:v1",
});
const admission = await lawfulActions.admit({
  lawDigest: law.lawDigest,
  proofObject: { exactBytes: sealedActionBytes, filename: "action.receiz", mimeType: "application/vnd.receiz" },
  expectedPriorAdmissionDigest: null,
  idempotencyKey: "action:delivery:42",
});
await lawfulActions.deriveValueHead({
  membershipId: admission.membershipId,
  expectedPriorValueHeadDigest: null,
});
```

Grant only the required scopes: `receiz:lawful-actions.laws.write`, `receiz:lawful-actions.write`, and `receiz:lawful-actions.value.write`. Settlement movement and idempotency recovery continue through the existing Settlement execution rail. Notes and wires remain Reserve-only.

### Complete edge Settlement and Reserve lifecycle

`client.value.edge` exposes the same deterministic planning, inspection, transition verification, local commit preparation, recovery packaging, and independent send/receive verification for both rails. The sender and receiver each verify the carried recovery locally. A server or database may synchronize the resulting proof globally; it does not create, approve, price, or redefine the transaction.

```ts
const plan = await receiz.value.edge.planSettlement(input);
await receiz.value.edge.inspect(plan, { participantId: plan.sourceParticipantId, expectedRail: "settlement" });
await receiz.value.edge.inspect(plan, { participantId: plan.destinationParticipantId, expectedRail: "settlement" });

const verified = await receiz.value.edge.verifyTransitionSet(portableTransitionSet, { audience: input.applicationId });
const prepared = await receiz.value.edge.prepareCommitSet(verified);
const recovery = await receiz.value.edge.createRecovery({
  applicationId: input.applicationId,
  transitionSet: portableTransitionSet,
  committedTransitions,
});

await receiz.value.edge.confirmSettlementSend(recovery, {
  applicationId: input.applicationId,
  participantId: plan.sourceParticipantId,
});
await receiz.value.edge.receiveSettlement(recovery, {
  applicationId: input.applicationId,
  participantId: plan.destinationParticipantId,
});
```

Reserve uses `planReserve`, `confirmReserveSend`, and `receiveReserve` over the same carried-proof lifecycle. `execution.exportCommittedRecovery` converts a canonically committed execution outcome into the portable recovery consumed at both edges.

Import `RECEIZ_V125_CAPABILITY_INVENTORY` for the exact v125 SDK/MCP/AI binding. `describeReceizSdkClientCapabilityInventory()` enumerates all 425 callable public client methods. The inventory includes retained historical methods; downstream AI manifests classify them explicitly instead of deleting them or presenting them as current defaults.

## Historical V124 — Reality Becomes Infrastructure

**The Production Runtime for Verified Civilization.** The sealed proof object remains storage and continuity authority. V124 composes canonical live Kai time, request-bound authenticated runtime evidence, exact-head verification, durable staged plans, exactly-once execution and recovery, closed replay/checkpoint validation, access-filtered private additions, atomic multi-domain writes, privacy-safe recipient resolution, and operational capability evidence. Servers, databases, sessions, and SDK representations remain subordinate coordination, sync, and recovery layers. V123 whole-pulse fields retain their meaning; explicit micro-pulse precision uses newly versioned fields.

V124 is a universal primitive release. It does not create a consumer-specific application identity, admission path, issuer, or authority layer. Stable V123 protocol identifiers remain unchanged for compatibility.

### V124.1 complete callable capability map

Import `RECEIZ_V124_1_CAPABILITY_INVENTORY` for the exact SDK export, SDK client-method, MCP tool, AI Skill, outcome, and authority binding of every V124.1 capability. The implementation guide is shipped at [`docs/v124.1-source-carried-capabilities.md`](https://unpkg.com/@receiz/sdk@129.0.0/docs/v124.1-source-carried-capabilities.md).

### Portable playable proof URLs and sealed Kai creation

Content-bearing proof URLs can render on `receiz.com` or any developer-owned domain without uploading the sealed artifact to a media server or database. The URL fragment carries the exact sealed artifact; the SDK verifies that enclosing proof object before exposing its native payload.

```ts
import {
  admitReceizKksV1ProofCoordinate,
  createReceizKksV1LiveProofCoordinate,
  createReceizPlayableMaterialObjectUrl,
  openVerifiedReceizMaterialUrl,
  projectReceizKksV1SealedProofCoordinate,
} from "@receiz/sdk";

const verified = await openVerifiedReceizMaterialUrl(window.location.href);
const playable = createReceizPlayableMaterialObjectUrl(verified);
mediaElement.src = playable.url;
canonicalProofLink.href = verified.canonicalReceizUrl;

const liveCoordinate = await createReceizKksV1LiveProofCoordinate({
  prove: kaiSigilProver,
  previousKaiSigilProofHead: priorHead,
});
const admittedCoordinate = await admitReceizKksV1ProofCoordinate(liveCoordinate, {
  expectedPreviousKaiSigilProofHead: priorHead,
  minimumExclusiveKaiUpulse: priorUpulse,
  maximumInclusiveKaiUpulse: admittedCurrentUpulse,
});
const identityMoment = await projectReceizKksV1SealedProofCoordinate(
  verifiedIdentityProof.kksCoordinate,
);
```

`openVerifiedReceizMaterialUrl` returns exact verified payload bytes, MIME type, filename, playable kind, and the canonical Receiz proof URL. Fully inline `rma2` carries the exact capsule in the URL. Composite `rmc1` and streaming `rmc2` use bounded public heads and reconstruct complete committed source families before verification. `rmc2/rma3/raw` projects the raw artifact and never enters the compressed RMA2 decoder. A head bound never truncates or limits the sealed artifact. An external host is a presentation wrapper beneath the sealed proof object.

KKSv1.0 is the single temporal authority. A local KKS sample is only a coordinate candidate until `createReceizKksV1LiveProofCoordinate({ prove })` binds it through the existing, unchanged KaiSigil BLAKE3 -> Poseidon -> Groth16 circuit. `projectReceizKksV1SealedProofCoordinate()` accepts only the complete proof-bearing coordinate carried by a verified sealed proof object. `admitReceizKksV1ProofCoordinate()` rejects bare pulse strings, extra `createdAt` fields, inconsistent pulse/micro-pulse pairs, invalid KaiSigil proofs, broken previous-head bindings, and noncausal append bounds. KaiSigil proves the exact KKS coordinate binding; Receiz ID/PBI authorship and the enclosing proof object separately bind the actor and event. Device time, browser time, timezone, process uptime, session state, SDK state, device-enrollment time, network services, server rows, and database state cannot alter a sealed coordinate. Chronos may be projected from Kai for display only; it never reconstructs proof authority. Run `runReceizV125TemporalAuthorityConformance()` or `pnpm test:temporal-authority-conformance` to verify the published boundary.

The v125 authority compiler is also closed and forward-only: `source -> evidence -> relationship -> permissible inference -> representation`. Use `RECEIZ_V125_AUTHORITY_FLOW` as the machine-readable contract and `assertReceizV125AuthorityFlowStep()` at derivation boundaries. The actual sealed proof object is terminal authority; a representation cannot reconstruct its source and no external authority exists above the actual thing. For an append, the successor is the same proof object's next authorized history head, not a competing object or parallel authority.

## Historical continuity retained from v121

V121 promotes the coordinated package, registry, and application-operation matrix while preserving every historical proof object and the established v120 HTTP routes. Sealed proof-object truth remains authoritative; server and database projections accelerate global distribution, restore lawful additions, and persist hydrated heads without entering the admission boundary or delaying deterministic first paint.

The v122 publication contract is immediate local proof admission followed by idempotent global append. A settled profile, live player, identity, or Settlement surface never reloads or remounts to wait for representation. Caption-only records retain a real SHA-256 commitment, media posts preserve exact source bytes across Safari-compatible transports, and stronger verified fields survive reconciliation with partial server projections.

## V120 living proof subjects

V120 adds first-class proof-native subjects, complete Kai/Merkle/Fibonacci proof brains, subject-scoped Twins, event-derived memory, bounded autonomous mandates, durable runtime job contracts, deterministic world commands, atomic multi-subject transactions, relationships, inventory/trades, portable minds, and one-time bearer ownership transitions.

The proof-brain retrieval law is exact: canonical head to complete content-addressed history to indexes to relevant references to exact primary proof-object bytes to cited answer. The 96-object reasoning window is bounded context, never a history limit. Model speech and performance are non-authoritative; only deterministic command or transaction admission can append an event.

The V120 HTTP methods on `client.subjects`, `client.world`, and `client.bearer` require explicitly selected historical transport; they are not default production routes. Configure the [local subject runtime](https://unpkg.com/@receiz/sdk@129.0.0/docs/local-subject-runtime.md) for supported source-bound local operations. Use `createReceizLivingSubjectRuntime` and `runReceizLivingSubjectConformanceV120` for deterministic reference and emulator evidence. Every failed decision reports zero writes, and unknown subject namespace bytes survive every transition.

### Subject identity, state, and complete proof history

```ts
const subject = await receiz.subjects.resolve(subjectId);
const verified = await receiz.subjects.verify(subject);
const state = await receiz.subjects.state(subjectId);
const history = await receiz.subjects.history(subjectId, {
  afterHead: priorHead,
  limit: 128,
});
```

`receiz.subject.v1` keeps `subjectId`, `proofObjectId`, `subjectType`, `ownerReceizId`, `identityDigest`, `genesisDigest`, and `createdAtKai` immutable. Ownership, application, device, and Twin-provider changes append successors without rewriting identity or earlier history. All named and unknown namespaces remain exact bytes through append, reconciliation, export, import, and transfer.

### Complete streamed proof brain and subject Twin

```ts
const head = await receiz.subjects.brain.head(subjectId);
const references = await receiz.subjects.brain.search(subjectId, {
  query: "What happened during the first expedition?",
  atHead: head.subjectHead,
  limit: 24,
});
const proofContext = await receiz.subjects.brain.resolve(subjectId, {
  atHead: head.subjectHead,
  references,
});

const response = await receiz.subjects.twin.message(subjectId, {
  message: "Tell me what you remember about the expedition.",
  ownerReceizId,
  contextHead: head.subjectHead,
  expectedSubjectDigest: head.subjectDigest,
  responseMode: "text",
  clientMessageId,
});
```

`brain.search` returns compact references. `brain.resolve` independently resolves and verifies the exact primary proof objects—including full long-form text—before reasoning. `brain.stream` emits `proof_head`, candidate references, primary objects, passages, and the complete context receipt as they become available. `twin.stream` and `twin.streamPerformance` add reply, audio, viseme, gaze, blink, breath, emotion, gesture, intention, and completion events without turning performance into canonical fact.

The Twin result separates spoken response, proposed intentions, observed facts, proof-derived memories, and non-authoritative performance. It carries an empty `worldEventIds` list because model output never admits a world event.

Portable subject-mind operations are `twin.profile`, `twin.exportMind`, `twin.importMind`, and `twin.memorySummary`. A mind artifact binds exact subject identity and prior subject, history, memory, and brain heads; it preserves public/private memory policy, unknown namespaces, and conflicts as forks.

### Typed world admission and atomic transactions

```ts
const plan = await receiz.world.planCommand(commandInput);
const validation = await receiz.world.validateCommand(plan);
if (!validation.ok) throw new Error(validation.code);

const result = await receiz.world.executeCommand(plan, authority);
if (!result.ok) {
  if (result.writes !== 0) throw new Error("zero-write law violated");
  throw new Error(result.code);
}

const transaction = await receiz.world.planTransaction({
  participants,
  expectedHeads,
  commands,
});
const transactionResult = await receiz.world.executeTransaction(
  transaction,
  participantAuthorities,
);
```

Commands follow intent proposal → typed command → exact-head validation → capability or mandate verification → deterministic reduction → atomic event append → receipt → projection. Transactions stage all participant effects and advance every affected subject and world head together, or advance none. `world.receipt`, `world.replay`, `world.additions`, and `world.subscribe` expose independently verifiable receipts, deterministic checkpoints, cursor replay, and live additions without a latest-snapshot-wins policy.

### Memory, relationships, inventory, and trade

- `subjects.memory.query`, `project`, `citations`, and `compact` preserve factual event citations and rebuildable derived summaries.
- `subjects.relationships.list`, `propose`, `respond`, and `history` use mutual consent and atomic participant histories.
- `subjects.inventory.list` and `use` mutate inventory only through admitted commands.
- `subjects.trades.preview` and `execute` bind both ownership heads, mandate/value limits, owner approval, idempotency, and one atomic swap.

### Autonomous mandates and durable subject runtime

```ts
const mandatePlan = await receiz.subjects.mandates.plan(subjectId, policy);
const mandate = await receiz.subjects.mandates.activate(
  mandatePlan,
  ownerCapability,
);

const job = await receiz.subjects.runtime.enqueueTick({
  subjectId,
  mandateDigest: mandate.mandateDigest,
  expectedHead: state.head,
  worldHead,
  runAfter,
  idempotencyKey,
});
```

Mandates bind actions, regions, subjects and owners, privacy, battle, item/value exposure, approval thresholds, rate limits, memory visibility, expiry, provider, safety, application, and tenant. Runtime execution re-verifies the exact mandate and current heads after lease acquisition. Pause, revocation, expiry, owner change, stale head, timeout, or malformed model intent produces no event. `runtime.status`, `runtime.pause`, and bounded `runtime.catchUp` expose deterministic recovery.

### Bearer ownership transfer

```ts
const plan = await receiz.bearer.previewTransfer({ subjectId, policy });
const instrument = await receiz.bearer.issueTransferInstrument({
  plan,
  ownerCapability,
});
const inspection = await receiz.bearer.inspectInstrument(instrument);
if (!inspection.offlineVerified) throw new Error("instrument verification failed");
const claim = await receiz.bearer.claimInstrument(
  instrument,
  recipientCapability,
);
```

Transfer supports known recipients and open bearer handoff, exact ownership-head binding, pending custody, recipient acceptance, expiry, cancellation, one-time claim, replay protection, explicit inventory disposition, explicit prior-owner conversation policy, and a newly sealed successor artifact. Claim preserves the same subject identity and history while atomically revoking the former owner’s mandates, private Twin access, queued jobs, and delegated capabilities. The new owner must authorize autonomy again. `cancelTransfer` and `transferStatus` complete the lifecycle; every rejected claim writes zero state.

### Testing and conformance

`@receiz/sdk/testing` includes multiple owners and subjects, a deterministic model stub, Kai/world-clock advancement, durable leases and crash recovery, autonomous ticks, exact retries, atomic transactions, partitions, delayed and duplicate delivery, stale heads, mandate expiry and revocation, malformed/timeout model output, artifact portability, tampering/substitution vectors, and checkpoint/replay equivalence.

`runReceizLivingSubjectConformanceV120()` executes the release’s 19 deterministic laws, including the ten living-subject invariants and nine bearer-transfer invariants. Emulator evidence is deterministic sandbox evidence; it does not claim package publication, deployment, or production state.

## Offline Note custody evidence retained in v120

The SDK exports the portable evidence and conformance layer for transferable
Offline Notes:

```ts
import {
  verifyReceizOfflineNoteCustodyQualification,
  verifyReceizOfflineNoteReceivingCustodyCommitment,
  verifyReceizOfflineNoteWebAuthnConsumptionReceipt,
  verifyReceizOfflineNoteWebAuthnActivationReceipt,
  runReceizOfflineNoteCustodyConformance,
} from "@receiz/sdk";
```

The required order is enclosing proof first, subordinate custody evidence
second:

```txt
canonical-verify receiz.account.state.v3 Receiz Key/Identity proof
-> verify receiz.offline-reserve.funding-binding.v1 at the exact account head and preselected qualified Reserve custody
-> locally compose one Reserve-debit account successor
-> locally compose one equal whole-value held-bound Note genesis
-> canonical-verify both successors
-> activate that exact Note genesis in qualified custody
then for every Send:
canonical-verify exact Note artifact
-> verify exact current proof-history head
-> verify qualified anonymous receiving-custody commitment
-> verify irreversible one-use consumption receipt
-> verify whole-value canonical successor
-> verify exact receiver activation receipt
```

These APIs validate schemas, canonical digests, P-256/WebAuthn evidence, exact
state transitions, receiver binding, whole value, Kai position, and fixed
conformance results. They do not infer that a browser, authenticator, device,
application, account, or profile is qualified from caller-provided data. A
platform adapter qualifies only against an exact registered conformance profile
backed by the complete rollback, backup, crash, clone, and once-only vector
corpus.

The SDK does not consume hardware state by itself and does not expose an
Offline Send command. The qualified PWA/native/device adapter owns irreversible
state; the canonical Note transition owns value, predecessor, history,
Settlement, and successor truth. Identity is optional one-handoff policy.
The verified `receiz.account.state.v3` Receiz Key/Identity proof is the Reserve
source for genesis. Eligible Reserve also carries a verified
`receiz.offline-reserve.funding-binding.v1` sealed at funding against that exact
account head and qualified custody; legacy or unbound Reserve is rejected. No
server response or database row can substitute for either proof.
Supabase/server publication remains optional distribution beneath the locally
verified account/Note successors and already-complete local Settlement.

## V120 coordinated SDK

Sealed proof/object truth is strongest. The current SDK adapts accepted identity proof plus the admitted same-UID binding through Receiz.com reference behavior before SDK, MCP, and AI developer rails. Obsolete versioned developer entry points are not shipped; a registry row alone never proves portable state.

V120 carries the current SDK baseline forward without rewriting historical proof. It preserves two proof-object append
transports beneath the canonically verified enclosing artifact:

- `receiz.native_capture.v1` binds exact bytes produced by Receiz's dedicated
  camera ceremony. It attests that ceremony only; it does not claim
  physical-sensor certification, and an ordinary upload cannot acquire this
  provenance.
- `receiz.pbi.proof-object-authorship.v1` appends PBI authorship only after the
  predecessor artifact verifies. Each append binds the exact predecessor
  artifact digest and proof head, Receiz ID, credential, position, proof
  coordinates, and Kai/Chronos event.

PBI authorship is ordered, append-only, and independently verifiable. It never
changes ownership, media bytes, capture provenance, or earlier proof history.
The verified successor settles locally before optional global publication; a
durable outbox retries that weaker propagation without delaying offline
completion.

A verified proof object is not limited to the platform that created it. Any lawful platform may append authenticated ownership and history only while preserving the same immutable object identity, payload, provenance root, prior history, and unknown namespaces, then returning a complete verified proof object. The SDK verifies and adapts this continuity; it does not create an origin-platform authority or parallel chain.

```ts
async function updateProfileFor(admittedAccountUid: string) {
  const receiz = createReceizClient({ accessToken });
  const updated = await receiz.profile.update({
    username: "new-name",
    displayName: "New Name",
  });

  if (updated.accountUid !== admittedAccountUid) {
    throw new Error("profile_identity_mismatch");
  }
  return updated;
}
```

`receiz.identity.updateProfile(intent)` is a compatibility alias for that same neutral operation. Neither current method accepts an identity key, expected head, receipt, SQL function, or RPC name. Username uniqueness is coordinated by Receiz.com while the admitted account UID remains the actor.

For ownership, pass the complete SDK-issued sealed artifact to `receiz.ownership.claimBearerAsset({ artifact })`. The SDK verifies the enclosing artifact before Receiz.com appends authenticated ownership and returns a new complete sealed artifact.

`receiz.verification.verifyArtifact(file)` and `receiz.artifacts.verifyAndOpen(file)` verify complete artifact bytes locally. They make zero network calls and require no session, database, access token, or Receiz.com process. Issuance through `assets.createProofObject` remains the authenticated native Record -> Seal rail.

Unified admission and recovery remain first-class in v120, with exact-byte-derived authority:

```ts
const { admission, recoveryPlan } = await receiz.artifacts.admitAndRecover(file);
if (admission.verdict === "invalid") return admission.error;

console.log(admission.permittedActions);
console.log(recoveryPlan?.proofHistory, recoveryPlan?.nextHeadDigest);
```

`admitAndRecover` verifies exact bytes, classifies authority, restores verified history/state, and performs zero writes and zero network calls. Mutation is separate: `artifacts.commitRecovery(plan, verifiedCapability, idempotencyKey, localStore)` accepts only runtime-branded SDK objects and commits one atomic unit of work. Bearer recovery cannot grant signing, canonical identity, publishing, or settlement authority. Plans and explanations remain non-authoritative projections beneath the proof object.

## V120 Package Architecture

Use `@receiz/sdk` for the universal runtime, `@receiz/sdk/react` for React bindings, `@receiz/sdk/compiler` for Node-only contract compilation and repository work, and `@receiz/sdk/testing` for browser-safe deterministic fixtures, emulator, and conformance support.

## Application Contract Compiler

<!-- receiz-canonical-compiler-quickstart:start -->
```ts
import {
  defineReceizApp,
  compileReceizAppContract,
  RECEIZ_CURRENT_APPLICATION_OPERATION_MATRIX,
} from "@receiz/sdk/compiler";

const contract = defineReceizApp({
  schema: "receiz.app.contract.v1",
  name: "My Receiz App",
  framework: "nextjs-app-router",
  features: ["identity", "proof", "proofMemory"],
  authority: { mode: "artifact-first", allowDatabaseAuthority: false },
  deployment: { target: "vercel" },
  operations: RECEIZ_CURRENT_APPLICATION_OPERATION_MATRIX,
});

const plan = compileReceizAppContract(contract, { targetSdkVersion: "129.0.0" });
```
<!-- receiz-canonical-compiler-quickstart:end -->

## V120 Local And Global Coordination Rails

The active executable registry ships inside the package. It is the exact recursively frozen registry whose canonical digest equals `RECEIZ_CURRENT_REGISTRY_DIGEST`; callers do not read repository release files at runtime.

```ts
import {
  RECEIZ_CURRENT_CONSTITUTION_REGISTRY,
  createReceizAdmissionEngine,
  createReceizBrowserAdmissionStore,
  loadReceizCurrentRegistry,
  signReceizCapability,
} from "@receiz/sdk";

const registry = loadReceizCurrentRegistry();
const store = createReceizBrowserAdmissionStore({
  databaseName: "my-receiz-admission",
  namespace: "tenant:example",
});
const engine = createReceizAdmissionEngine({
  registry,
  store,
  capabilityVerifier,
  consequenceProjector,
});

const signed = await signReceizCapability({ keyFile, passphrase, payload });
```

The equivalent client conveniences are `client.identity.signCapability(...)`, `client.admission.browserStore(...)`, and `client.admission.createEngine(...)`. `RECEIZ_CURRENT_CONSTITUTION_REGISTRY` is the frozen package constant; `loadReceizCurrentRegistry()` returns a detached recursively frozen copy.

Durable local admission truth is not cache. The IndexedDB ledger atomically coordinates aggregate heads, events, receipts, effects, idempotency, and outbox entries, but it never stores proof objects or sealed artifact bytes. Known sealed artifact truth paints first; opening the browser ledger is lazy and cannot block that first paint.

V120 preserves the provider-neutral `client.coordination.remoteDomain({ namespace, commitDomain })` rail, the bounded profile/economy composite proof-object operations, Native Capture, and verified offline PBI authorship. The returned domain exposes `resolveAcceptedHead`, `planOfflineReconciliation`, `stageOfflineReconciliation`, `commitOfflineReconciliation`, `reconcileOffline`, `resolveReconciliationAttempt`, and `resolveEffectStatus` with the exact reviewed request/result types. Supply the player's returned Connect token directly to `createReceizClient`; never read or fall back to a player token from environment variables. “Global” means acceptance by the explicitly named commit domain, never authority above the sealed artifact.

Resolution and planning are read-only. Staging writes only private immutable candidate bytes and advances no head. Commitment independently resolves and reverifies the exact staged version before one atomic expected-head acceptance. An `accepted` result does not mean effects were delivered; an `indeterminate` result does not mean failure. Structural divergence never auto-merges, rebases, or chooses a timestamp winner.

The compiler API also exports `validateReceizAppContract`,
`inspectReceizProject`, `planReceizIntegration`, `checkReceizIntegration`,
`planReceizUpgrade`, and `explainReceizIntegrationFinding`. The CLI exposes the
same core through `receiz app init|inspect|plan|apply|check|upgrade|explain`.

Planning is read-only. Apply returns the complete preview first, requires its
exact digest as confirmation, preserves unrelated code, and is idempotent.
See `docs/app-contract-compiler.md`, `docs/framework-adapters.md`, and
`docs/generated-files-and-upgrades.md`.

Use one typed client for Receiz proof objects, public proof rendering, Sports Arena card/event proof integration, wallet ledger reads, Twin and World surfaces, Connect transfers, webhook endpoint management, and webhook delivery verification.

```ts
import { createReceizClient } from "@receiz/sdk";

const receiz = createReceizClient({
  baseUrl: "https://receiz.com",
  accessToken,
});
```

Local proof tooling ships with the same package:

```bash
npx @receiz/sdk conformance
npx @receiz/sdk inspect ./receiz-asset-manifest.json
npx @receiz/sdk init ./receiz-integration
```

These commands use packaged SDK validators and projections. `conformance` and `inspect` do not call Receiz production, Supabase, or any database. Historical manifests remain inspectable, but inspection never admits them as verified asset truth.

## Primitive Boundary

The SDK is convenience, not authority. It reads public API projections, sends delegated actions, validates developer manifests, and verifies webhook delivery signatures. Sealed artifacts, proof bundles, verified appends, ownership appends, and settlement ledger records remain the stronger source of truth.

A manifest is inspection-only. The SDK accepts only a **complete sealed proof object**: canonical payload, ownership/custody, provenance/appends, and settlement state must travel inside the artifact; the artifact must pass the existing Receiz verifier; the SDK must reconstruct the same object from the returned bytes; and server admission independently repeats verification.

Kai Klok is the proof object state machine. `kaiPulseEternal` is the pulse unit carried by that state machine. A complete Receiz proof object carries Kai; without its Kai coordinate it is not complete Receiz proof truth.

Receiz ID is the default account-continuity rail for everyday login. It does not replace PBI/passkey, email magic-link recovery, Receiz Key, Identity Record, Identity Seal, or OIDC/Connect. Those rails all preserve the same account when bound: PBI/passkey can create or recover a Receiz account, email can recover the account, Receiz identity artifacts can restore it locally, and OIDC/Connect can delegate API access after identity proof.

Receiz Key, Identity Record, and Identity Seal are Receiz identity primitives exposed through the SDK for developer apps. Their current account-state envelope is `receiz.account.state.v3`; it carries admitted account proof memory across profile, action ledger, calendar, wallet settlement, Sports vault/cards/appends/event proofs, and related entries. The SDK mirrors the same law for developer apps through local proof registers: admit verified truth once, persist it, and ask Receiz only for verified additions after the known head. Connect is delegated API access; it is not the identity proof root.

Default integration order:

1. Verify first, then project.
2. Render the proof object or manifest as the user-facing truth.
3. Append public proof, wallet, sports, or Connect additions after the known truth.
4. Order proof objects by Kai/Klok state; render Chronos only as display.
5. Never treat an SDK response as stronger than the sealed artifact, verified append, ownership append, or settlement primitive it projects.

## Five-Minute Proof Object App

This is the highest-leverage SDK path for most apps:

```ts
import { createReceizClient } from "@receiz/sdk";

const receiz = createReceizClient({ accessToken: process.env.RECEIZ_ACCESS_TOKEN });
async function custodyWorkflow(sourceFile: File, file: File) {
  const input = {
    assetType: "proof_object",
    payload: { mimeType: sourceFile.type, bytes: new Uint8Array(await sourceFile.arrayBuffer()) },
  } as const;
  const options = { idempotencyKey: crypto.randomUUID(), filename: sourceFile.name };

  const sealed = await receiz.assets.createProofObject(input, options);
  await receiz.artifacts.download(sealed);
  const opened = await receiz.artifacts.verifyAndOpen(file);
  consume(opened.verifiedPayload.bytes);
}
```

`sourceFile` carries payload bytes into native Record -> Seal. `file` is a complete sealed artifact selected for opening; it is never the source payload. `sealed` is an SDK-issued runtime-custody handle for the exact native Record -> Seal bytes. An ordinary `Blob`, a cast value, or a copied property bag cannot be downloaded as that artifact. The payload is available only as `opened.verifiedPayload` after the enclosing artifact verifies; it is never a download substitute.

The register is not a cache. It is the app's admitted verified prefix. Use it immediately on next open, then ask Receiz only for verified additions after the known head.

Full quickstart: `docs/proof-memory-and-projections.md`.

For complete copy-paste integrations, use `docs/copy-paste-integrations.md`. It includes a React proof memory hook, browser admission helper, Next append-sync route, webhook receiver, Sports card renderer, and local CLI proof commands.

## CLI And Local Conformance

```bash
npx @receiz/sdk conformance
```

Runs the packaged asset manifest, Sports card manifest, and webhook event fixtures through SDK inspection and validation. Inspection-only manifests do not enter verified proof memory.

```bash
npx @receiz/sdk inspect ./receiz-asset-manifest.json
```

Validates one payload and projects display-ready rows. Asset and Sports manifests report `admitted: false` because shape validation is inspection, not proof-object admission.

```bash
npx @receiz/sdk init ./receiz-integration
```

Writes a local-first proof memory starter. The starter keeps manifest projection explicitly inspection-only and admits only independently verified events/register entries.

Full quickstart: `docs/cli-and-conformance.md`.

## Schemas, Projections, And Proof Memory

```ts
import {
  RECEIZ_SCHEMAS,
  createReceizInMemoryProofMemoryStorage,
  createReceizProofMemory,
  createReceizProofRegister,
  projectReceizSportsCardManifest,
} from "@receiz/sdk";

const schema = RECEIZ_SCHEMAS.sportsCardManifest;
const projection = projectReceizSportsCardManifest(cardManifest);

const memory = createReceizProofRegister();
memory.admitWebhookEvent(webhookEvent);

const snapshot = memory.snapshot();

const durableMemory = await createReceizProofMemory({
  storage: createReceizInMemoryProofMemoryStorage(snapshot),
});
const additionsAfter = durableMemory.knownHead(50);
```

Use schemas for developer validation, projections for display-ready proof rows, and proof memory for first-admission-then-append-forever UX.

## Receiz ID Account Creation And Recovery

Developers can let users create a fresh Receiz ID account, recover from a Receiz Key, or login with an Identity Record / Identity Seal image without inventing a parallel login model. Receiz ID is the default login path, but it does not replace the existing rails: PBI/passkey stays available for account creation, account recovery, and account signing; email magic-link stays available for recovery; OIDC/Connect stays available for delegated API access. The result is one account, not separate accounts for each rail.

```ts
import {
  buildReceizIdContinueRequest,
  createReceizIdIdentity,
  projectReceizIdentityAccount,
  readReceizIdentityArtifact,
  signReceizIdentityLoginProof,
} from "@receiz/sdk";

const identity = await createReceizIdIdentity({
  username: "builder",
  displayName: "Builder",
});

const keyFile = await readReceizIdentityArtifact(fileOrImageBytes);
const account = await projectReceizIdentityAccount(keyFile);
if (!account.completeAtSealedHead || account.authority !== "verified-identity-portable-state") {
  throw new Error("identity_portable_state_not_verified");
}
renderAccountImmediately(account.verifiedState);

// Size thresholds recursively create signed segment proof objects beneath the
// sealed account composite; they never truncate verifiedState.

if (!account.portableStateVerified) throw new Error("identity proof failed");

const proof = await signReceizIdentityLoginProof({
  keyFile,
  challengeText: "your-app-login-challenge",
});

const receizPublication = await buildReceizIdContinueRequest(identity, {
  next: "/profile",
});
```

`account.continuity` is an exact public contract: the admitted account projects its complete sealed head immediately, local truth is permanent and append-only, and synchronization may admit only verified descendants bound after that head. Global acknowledgement changes delivery status only and never deletes local proof custody. A network, server, database, index, session, or projection receipt cannot block local use by the verified owner. Only invalid proof, an unauthorized delta, an exact predecessor-head conflict, or an operation outside the admitted capability may fail closed.

Use the local projection for first paint in your app. Send the continuation request to Receiz only when you need Receiz infrastructure to append global continuity or issue a Receiz session. Use Connect after proof login when your app needs delegated Receiz API access.

Full quickstart: `docs/identity-login-and-recovery.md`.

## Artifact Verification

```ts
import { createReceizClient } from "@receiz/sdk";

const receiz = createReceizClient();
const file = new File([artifactBytes], "received.receizbundle", {
  type: "application/vnd.receiz.bundle+json",
});
const opened = await receiz.artifacts.verifyAndOpen(file);

consume(opened.verifiedPayload.bytes);
```

`assets.createProofObject` uses the same current native creation sequence as receiz.com: the authenticated account's real Receiz ID is resolved, its Receiz Record projection is created, and the source bytes are sealed at those exact native coordinates. Developers do not submit or invent owner, namespace, or continuity objects. `artifacts.verifyAndOpen` verifies the complete enclosing proof before it returns a separate copied payload projection. Existing verified legacy artifacts are read-only compatibility objects and cannot be downloaded as current native artifacts.

Full quickstart: `docs/artifact-verification.md`.

## Public Proof Rendering

```ts
import { createReceizClient } from "@receiz/sdk";

const receiz = createReceizClient();
const proof = await receiz.publicProof.byUrl("https://example.com/work");
```

Full quickstart: `docs/public-proof-rendering.md`.

## App-State Public Projections

Receiz apps can publish durable public app-state projections without adding Supabase, Redis, Vercel KV, Shopify, or a custom database. Writes require delegated Connect/OIDC access with `receiz:app_state.write` or `receiz:public_store.write`; reads are public when the projection is public.

```ts
import {
  RECEIZ_PUBLIC_STORE_STATE_PROJECTION_SCHEMA,
  createReceizClient,
  createReceizPublicStoreStateRecord,
} from "@receiz/sdk";

const receiz = createReceizClient({ accessToken });

await receiz.appState.publishRecord(createReceizPublicStoreStateRecord({
  sourceUrl: "bjklock.receiz.app",
  externalCreatorId: "bjklock.receiz.id",
  title: "BJ Klock storefront",
  data: { storeStateRecord },
}));

const restored = await createReceizClient().appState.restoreByHost<{
  storeStateRecord: StoreStateRecord;
}>("bjklock.receiz.app", {
  schema: RECEIZ_PUBLIC_STORE_STATE_PROJECTION_SCHEMA,
  state: "published",
  requiredDataKey: "storeStateRecord",
});

if (restored.ok && restored.data) renderStorefront(restored.data.storeStateRecord);
```

For commerce storefronts, use the first-party public-store recipe so every app publishes the same `storeStateRecord` envelope:

```ts
await receiz.publicStore.publish({
  tenantHost: "bjklock.receiz.app",
  merchantReceizId: "bjklock.receiz.id",
  title: "BJ Klock storefront",
  state: storeStateRecord,
}, { idempotencyKey: `storefront:${storeStateRecord.updatedKaiUpulse}` });

const store = await createReceizClient().publicStore.resolve<StoreStateRecord>({
  host: "bjklock.receiz.app",
});

if (store.ok && store.storeStateRecord) renderStorefront(store.storeStateRecord);
```

When the merchant has a Receiz Key / Identity Seal, publish with merchant proof authority instead of a server bearer token:

```ts
const result = await createReceizClient().publicStore.publishWithIdentityProof({
  keyFile,
  tenantHost: "bjklock.receiz.app",
  merchantReceizId: "bjklock.receiz.id",
  storeStateRecord,
});

console.log(result.knownHead.afterKaiUpulse, result.appendAnchorId);
```

This signs the exact public-store feed with the merchant proof object, posts the signed envelope to the public proof rail, and returns the Kai/anchor append head. Delegated tokens remain available for agent/server operations; merchant storefront sync does not require `RECEIZ_ACCESS_TOKEN`.

`receiz.appState.publish(feed)` remains available for batch writes. `receiz.publicProof.registryFeed(feed)` remains available and aliases the same publish path for existing integrations.
Raw reads remain available through `byUrl()`, `byHost()`, `byCreator()`, `byNamespace()`, and `byId()` when an app needs the full public projection envelope instead of direct restored data.

Full quickstarts:

- `docs/app-state-public-projections.md`
- `docs/signed-public-store-publish.md`

## Receiz App Runtime Rails

`@receiz/sdk@99.0.0` adds dogfood-ready local-first recipes on top of the enterprise runtime rails for Commerce Cloud style apps. These helpers compose existing Receiz primitives; they do not replace proof objects, local proof memory, Connect, or the public app-state projection rail.

```ts
import { RECEIZ_OIDC_SCOPES_BY_RAIL, createReceizClient } from "@receiz/sdk";

const receiz = createReceizClient({ accessToken });

const doctor = await receiz.doctor({
  tenantHost: "bjklock.receiz.app",
  callbackUrl: "https://bjklock.receiz.app/api/auth/receiz/callback",
  scopes: [
    ...RECEIZ_OIDC_SCOPES_BY_RAIL.customers,
    ...RECEIZ_OIDC_SCOPES_BY_RAIL.merchants,
    ...RECEIZ_OIDC_SCOPES_BY_RAIL.publicStore,
  ],
});
if (!doctor.ok) console.table(doctor.fixes);

const caps = await receiz.capabilities({ tenantHost: "bjklock.receiz.app" });
if (caps.capabilities.commerce.available) {
  await receiz.commerce.oneClickCheckout({
    tenantHost: "bjklock.receiz.app",
    orderId: "order_123",
    amountUsd: "42.00",
    walletFirst: true,
    cardFallback: true,
    idempotencyKey: "order_123",
  });
}

await receiz.appState.publish({
  tenantHost: "bjklock.receiz.app",
  creatorReceizId: "bjklock.receiz.id",
  title: "BJ Klock storefront",
  state: { storeStateRecord },
  idempotencyKey: "storefront_state_1",
});

const restored = await createReceizClient().appState.resolve({
  host: "bjklock.receiz.app",
  requiredDataKey: "storeStateRecord",
});

const tenantSession = await receiz.customers.bootstrapSession({
  tenantHost: "bjklock.receiz.app",
  customerReceizId: "customer.receiz.id",
  scopes: ["orders", "rewards", "assets"],
}, { idempotencyKey: "customer-session:v1" });

const hostedIdentity = receiz.identity.ensureTenantSession({
  tenantHost: "bjklock.receiz.app",
  returnTo: "https://bjklock.receiz.app/account",
  fallback: "artifact_upload",
});

const profile = await receiz.profile.resolveLocalFirst({
  memory,
  local: admittedProfileTruth,
  sync: (knownHead) => fetchVerifiedProfileAdditions(knownHead),
});

const walletLedger = await receiz.wallet.resolveLedger({
  memory,
  local: admittedWalletLedger,
  sync: (knownHead) => fetchVerifiedWalletAdditions(knownHead),
});

const pitchDay = await receiz.sports.resolvePitchDayProof({
  local: admittedPitchDayProof,
});
```

Additional typed surfaces:

- `RECEIZ_OIDC_SCOPES_BY_RAIL` and `receizOidcScopesForRails()` for stable per-rail Connect/OIDC scopes
- `receiz.runtime.localFirst()`, `profile.resolveLocalFirst()`, `wallet.resolveLedger()`, `sports.resolveCardMemory()`, `sports.resolvePitchDayProof()`
- `receiz.proofMemory.syncAdditions()` for append-only sync after the known proof-memory head
- `receiz.publicStore.publish()`, `publicStore.resolve()`, `publicStore.createRecord()`
- `receiz.identity.ensureTenantSession({ tenantHost, returnTo, fallback })`
- `receiz.customers.bootstrapSession()`, `customers.session()`, `customers.portal()`, `customers.orders()`, `customers.rewards()`, `customers.assets()`
- `receiz.merchants.onboard()`, `merchants.profile()`, `merchants.capabilities()`
- `receiz.commerce.refunds`, `subscriptions`, `shipping`, `tax`, `discounts`, `giftCards`, `accessPasses`, `inventory`, `fulfillment`, `payouts`
- `receiz.media.upload(file, { tenantHost, purpose, idempotencyKey })`
- `receiz.media.transform({ mediaId, resize, optimize, blurPlaceholder, altText, metadata })`
- `receiz.domains.normalizeHost()`, `tenantUrl()`, `namespace()`, `objectId()`, `resolveTenant()`
- `receiz.events.subscribe()`, `events.replay()`, `events.list()`, `events.ack()`
- `receiz.proof.query({ namespace, tenantHost, type, customerReceizId })`
- `receiz.jobs.enqueue()`, `jobs.status()`, `jobs.cancel()`, `jobs.list()`
- `receiz.permissions.grant()`, `permissions.revoke()`, `permissions.check()`, `permissions.roles()`
- `receiz.audit.append()`, `audit.query()`, `audit.export()`
- `receiz.risk.scorePayment()`, `scoreAccountRecovery()`, `velocity()`, `proofActivity()`
- `receiz.compliance.exportOrders()`, `exportTaxes()`, `exportPayouts()`, `exportCustomers()`, `exportAudit()`
- `receiz.portability.exportStore()`, `portability.importStore()`
- `receiz.search.query()`, `products()`, `pages()`, `blog()`, `orders()`, `customers()`, `proofObjects()`
- `receiz.notifications.send()`, `notifications.subscribe()`, `notifications.templates()`
- `receiz.releases.pin()`, `releases.check()`, `releases.supported()`
- `receiz.webhookEndpoints.list()`, `create()`, `update()`, `rotateSecret()`, `sendTest()`, `delete()`
- `receiz.webhooks.parseRequest()`, `routeEvent()`, `verifySignature()`, `eventTypes`, `eventGroups`, `presets`
- `receiz.sandbox.seedStore()`, `sandbox.wallet()`, `sandbox.checkout()`
- `receiz.offline.createQueue()`, `offline.createInMemoryStorage()`, `offline.createLocalStorage()`
- CLI: `receiz doctor`, `receiz dev`, `receiz deploy-check`, `receiz seed-store`, `receiz simulate-checkout`

React apps can import optional hooks and hosted component factories from `@receiz/sdk/react`:

```ts
import {
  ReceizCheckoutButton,
  ReceizIdentityButton,
  ReceizMediaUploader,
  useReceizAppState,
  useReceizCheckout,
} from "@receiz/sdk/react";

const storefront = useReceizAppState({
  resolve: {
    host: "bjklock.receiz.app",
    requiredDataKey: "storeStateRecord",
  },
});
```

The React subpath is UI convenience. The core SDK client remains the primitive boundary, and proof objects / local proof memory remain stronger than component state.

## Agent MCP Server

Agents can use Receiz through the official MCP server:

```bash
npx -y @receiz/mcp-server
```

`@receiz/mcp-server` wraps the SDK for agent hosts. It can inspect, resolve, publish through delegated SDK calls, expose Receiz resource templates, and direct byte-bearing artifacts to SDK `verification.verifyArtifact(file)`. MCP lookup or inspection never supplies the verification verdict. It is not a proof authority above Receiz proof objects, identity primitives, settlement primitives, ownership surfaces, or public proof surfaces.

For writes, create a Receiz-issued delegated agent token from `/developers/connect` with **Create Delegated Agent Token**. Store only the one-time `access_token` in the MCP host:

```toml
[mcp_servers.receiz.env]
RECEIZ_BASE_URL = "https://receiz.com"
RECEIZ_ACCESS_TOKEN = "..."
```

Use the returned `token_id` for revocation/audit and the `agent:*` label to identify agent-published additions.

## Sports Card And Event Proof Integration

```ts
import { assertReceizSportsCardManifest, createReceizClient } from "@receiz/sdk";

const manifest = assertReceizSportsCardManifest(await response.json());
const eventProofUrl = createReceizClient().sports.eventProofUrl("event_proof_123");
```

Full quickstart: `docs/sports-card-event-proofs.md`.

## Wallet Ledger Reads

```ts
import { createReceizClient } from "@receiz/sdk";

const receiz = createReceizClient();
const ledger = await receiz.wallet.publicLedger({ limit: 40 });
```

Full quickstart: `docs/wallet-ledger-reads.md`.

## Twin And World

Public World/Twin reads are available without a token. Owner-scoped Twin actions require a Receiz Connect access token with `receiz:twin.read` or `receiz:twin.write`, issued through a registered OIDC client.

```ts
import { createReceizClient } from "@receiz/sdk";

const publicReceiz = createReceizClient();
const world = await publicReceiz.world.profile("bjklock");

const receiz = createReceizClient({ accessToken: process.env.RECEIZ_ACCESS_TOKEN });
const mandate = await receiz.twin.marketMandate();
await receiz.twin.saveMarketMandate({
  status: "active",
  executionMode: "approve",
  maxOrderUsd: "25.00",
});
const intent = await receiz.twin.createMarketIntent({
  marketItemId: "asset_123",
  side: "buy",
  amountUsd: "10.00",
});
```

Full quickstart: `docs/twin-and-world.md`.

## Connect Transfers

```ts
import { createReceizClient } from "@receiz/sdk";

const receiz = createReceizClient({ accessToken: process.env.RECEIZ_ACCESS_TOKEN });
await receiz.connect.transfer(
  { recipientUserId: "user_123", unit: "phi", amountPhi: "10" },
  { idempotencyKey: crypto.randomUUID() },
);
```

Full quickstart: `docs/connect-transfers.md`.

## Webhook Signatures

```ts
import { parseReceizWebhookRequest, routeReceizWebhookEvent } from "@receiz/sdk";

const parsed = await parseReceizWebhookRequest(request, {
  secret: process.env.RECEIZ_WEBHOOK_SECRET!,
  toleranceSeconds: 300,
});

await routeReceizWebhookEvent(parsed.event, {
  "payment.settled": async (event) => {
    // Delivery is authentic. Verify the settlement ledger event before admitting product truth.
    await verifySettlementLedgerEvent(event.data);
  },
  "proof.appended": async (event) => {
    // Delivery is authentic. Verify the proof object or append before projecting it.
    await verifyProofAppend(event.data);
  },
});
```

Full quickstart: `docs/webhook-signatures.md`.

## Webhook Endpoint Management

Humans can register endpoints at `/developers/webhooks`. Apps and agents can use the same lifecycle through the SDK with `receiz:webhooks.read` and `receiz:webhooks.write`.

```ts
import {
  RECEIZ_WEBHOOK_EVENT_PRESETS,
  createReceizClient,
} from "@receiz/sdk";

const receiz = createReceizClient({
  accessToken: process.env.RECEIZ_ACCESS_TOKEN,
});

const created = await receiz.webhookEndpoints.create({
  label: "Production payments",
  url: "https://app.example.com/api/receiz/webhooks",
  eventTypes: RECEIZ_WEBHOOK_EVENT_PRESETS.payment,
  idempotencyKey: "webhook:production-payments:v1",
});

await saveSecretOnce(created.credentials.secret);

await receiz.webhookEndpoints.sendTest(created.endpoint.endpointId, {
  eventType: "payment.settled",
});
```

Create and rotate return the plaintext `whsec_...` value once. Store it in your app secret manager. List, update, test, and delete return endpoint configuration only.

Webhook signatures prove delivery authenticity. Payment settlement, ownership appends, proof objects, and verified ledger records remain the product truth your receiver must verify before admitting the event.

## App Registration And Token Lifecycle

Use Receiz Connect OIDC for self-serve developer onboarding: register an app, redirect through Authorization Code + PKCE, exchange tokens server-side, refresh on expiry, and call delegated clients with least-privilege scopes.

Full quickstart: `docs/app-registration-token-lifecycle.md`.

## Current And Historical HTTP

Current versus historical HTTP execution is recorded in
`RECEIZ_HTTP_OPERATION_SUPPORT`. Historical Connect calls require an explicitly
configured compatibility host; they are not default server capabilities. See
[Historical HTTP compatibility](https://unpkg.com/@receiz/sdk@129.0.0/docs/historical-http.md) for configuration and
the checkout settlement boundary. Offline proof creation requires no such host.

## Highest Cash-Out Frame

**source + law + sequence + object + evidence. And the reader underneath them.**

The actual sealed proof object remains terminal authority through time. SDK
readers may inspect, verify, and project the source, law, sequence, object, and
evidence; they cannot author, reorder, replace, or outrank them. Import
`RECEIZ_V125_HIGHEST_CASH_OUT_FRAME` and `RECEIZ_V125_AUTHORITY_FLOW` when an
implementation needs the machine-readable contract.

## V129 coordinated distribution target

The [v129 release record](https://docs.receiz.com/releases/v129.0.0) describes the coordinated `129.0.0` SDK, full MCP library, and AI-skills source/package target. The admitted constitutional ruleset remains `127.0.0` with its exact canonical registry bytes and retained v124/v125 protocols. V129 preserves registered application bytes through existing proof-authority, source publication, sessions, replay, and execution without an alias or replacement authority.

**Source + law + sequence + object + evidence. And the reader underneath them.** The enclosing proof object remains terminal authority through time. SDK/MCP responses, OIDC grants, sessions, rows, public projections, configuration, and agent statements remain readers or execution mechanics beneath it. The full MCP library supports financial workflows; the ChatGPT Marketplace plugin has a separate restricted nonfinancial profile.

The generated catalogs bind the exact callable methods, actual tools, and skill manifests. Qualification must cover actual used operations and deployed dependencies. Funding, wallet credit, payment, seller proceeds, complete bearer delivery, claim, custody, and asset use remain distinct live evidence stages. Current package publication, server/database deployment, and fresh-client seller/buyer acceptance are recorded separately in the [v129 conformance source](https://github.com/kojibai/receiz/blob/main/docs/releases/v129.0.0-conformance.md); this prepared target does not claim those stages passed. V128 acceptance remains historical evidence at its original frozen coordinates.