@receiz/ai-skills 102.0.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +45 -0
- package/package.json +31 -0
- package/receiz-builder-skill/SKILL.md +92 -0
- package/receiz-builder-skill/examples/create-marketplace.md +10 -0
- package/receiz-builder-skill/examples/create-pack-app.md +12 -0
- package/receiz-builder-skill/examples/create-profile-vault.md +5 -0
- package/receiz-builder-skill/examples/create-proof-page.md +5 -0
- package/receiz-builder-skill/examples/create-storefront.md +5 -0
- package/receiz-builder-skill/resources/app-patterns.md +29 -0
- package/receiz-builder-skill/resources/deployment-checklist.md +13 -0
- package/receiz-builder-skill/resources/generated-code-rules.md +27 -0
- package/receiz-builder-skill/resources/no-db-pattern.md +34 -0
- package/receiz-builder-skill/resources/proof-native-ui-patterns.md +29 -0
- package/receiz-builder-skill/resources/sdk-quickstart.md +68 -0
- package/receiz-commerce-skill/SKILL.md +95 -0
- package/receiz-commerce-skill/examples/create-no-db-store.md +15 -0
- package/receiz-commerce-skill/examples/create-product-page.md +25 -0
- package/receiz-commerce-skill/examples/explain-receiz-commerce.md +14 -0
- package/receiz-commerce-skill/examples/verify-product-ownership.md +20 -0
- package/receiz-commerce-skill/resources/commerce-object-model.md +44 -0
- package/receiz-commerce-skill/resources/conversion-copy-patterns.md +23 -0
- package/receiz-commerce-skill/resources/order-and-receipt-boundaries.md +29 -0
- package/receiz-commerce-skill/resources/product-proof-flow.md +26 -0
- package/receiz-commerce-skill/resources/seller-buyer-language.md +26 -0
- package/receiz-commerce-skill/resources/storefront-patterns.md +33 -0
- package/receiz-distribution-skill/SKILL.md +94 -0
- package/receiz-distribution-skill/examples/create-bar-flyer-copy.md +18 -0
- package/receiz-distribution-skill/examples/create-restaurant-activation.md +20 -0
- package/receiz-distribution-skill/examples/create-venue-one-pager.md +15 -0
- package/receiz-distribution-skill/examples/explain-pack-derby.md +9 -0
- package/receiz-distribution-skill/resources/affiliate-boundaries.md +23 -0
- package/receiz-distribution-skill/resources/conversion-language.md +20 -0
- package/receiz-distribution-skill/resources/pack-derby-model.md +19 -0
- package/receiz-distribution-skill/resources/qr-activation-flow.md +24 -0
- package/receiz-distribution-skill/resources/staff-training-script.md +17 -0
- package/receiz-distribution-skill/resources/venue-playbook.md +25 -0
- package/receiz-mcp-agent-skill/SKILL.md +89 -0
- package/receiz-mcp-agent-skill/examples/agent-append-proof.md +11 -0
- package/receiz-mcp-agent-skill/examples/agent-build-app.md +10 -0
- package/receiz-mcp-agent-skill/examples/agent-inspect-vault.md +8 -0
- package/receiz-mcp-agent-skill/examples/agent-verify-object.md +3 -0
- package/receiz-mcp-agent-skill/resources/action-confirmation-rules.md +22 -0
- package/receiz-mcp-agent-skill/resources/agent-operating-rules.md +28 -0
- package/receiz-mcp-agent-skill/resources/auth-boundaries.md +21 -0
- package/receiz-mcp-agent-skill/resources/mcp-tool-map.md +61 -0
- package/receiz-mcp-agent-skill/resources/response-templates.md +38 -0
- package/receiz-mcp-agent-skill/resources/safe-tool-calling.md +45 -0
- package/receiz-offline-verifier-skill/SKILL.md +91 -0
- package/receiz-offline-verifier-skill/examples/debug-verification-failure.md +17 -0
- package/receiz-offline-verifier-skill/examples/explain-offline-proof.md +9 -0
- package/receiz-offline-verifier-skill/examples/verify-offline-asset.md +19 -0
- package/receiz-offline-verifier-skill/resources/airplane-mode-principle.md +15 -0
- package/receiz-offline-verifier-skill/resources/artifact-over-server.md +22 -0
- package/receiz-offline-verifier-skill/resources/offline-verification-law.md +17 -0
- package/receiz-offline-verifier-skill/resources/security-boundaries.md +20 -0
- package/receiz-offline-verifier-skill/resources/verifier-flow.md +25 -0
- package/receiz-proof-skill/SKILL.md +98 -0
- package/receiz-proof-skill/examples/verify-card.md +21 -0
- package/receiz-proof-skill/examples/verify-pack.md +14 -0
- package/receiz-proof-skill/examples/verify-post.md +7 -0
- package/receiz-proof-skill/examples/verify-product.md +7 -0
- package/receiz-proof-skill/examples/verify-vault.md +7 -0
- package/receiz-proof-skill/resources/failure-modes.md +31 -0
- package/receiz-proof-skill/resources/mcp-tool-map.md +49 -0
- package/receiz-proof-skill/resources/output-templates.md +56 -0
- package/receiz-proof-skill/resources/proof-object-model.md +30 -0
- package/receiz-proof-skill/resources/receiz-laws.md +41 -0
- package/receiz-proof-skill/resources/sdk-reference.md +80 -0
- package/receiz-proof-skill/resources/verification-flow.md +38 -0
- package/receiz-skill-bundle/SKILL.md +87 -0
- package/receiz-skill-bundle/resources/canonical-receiz-language.md +46 -0
- package/receiz-skill-bundle/resources/combined-agent-behavior.md +35 -0
- package/receiz-skill-bundle/resources/skill-routing.md +15 -0
- package/receiz-skill-bundle/resources/when-to-use-each-skill.md +29 -0
- package/receiz-sports-card-skill/SKILL.md +97 -0
- package/receiz-sports-card-skill/examples/explain-card-market.md +18 -0
- package/receiz-sports-card-skill/examples/explain-geo-appeal.md +9 -0
- package/receiz-sports-card-skill/examples/explain-live-event-card.md +18 -0
- package/receiz-sports-card-skill/examples/explain-pack-opening.md +10 -0
- package/receiz-sports-card-skill/examples/explain-player-card.md +19 -0
- package/receiz-sports-card-skill/resources/card-memory-law.md +23 -0
- package/receiz-sports-card-skill/resources/game-surface-patterns.md +26 -0
- package/receiz-sports-card-skill/resources/live-event-append-flow.md +19 -0
- package/receiz-sports-card-skill/resources/mlb-proof-language.md +24 -0
- package/receiz-sports-card-skill/resources/rarity-and-event-language.md +25 -0
- package/receiz-sports-card-skill/resources/sports-card-object-model.md +22 -0
package/README.md
ADDED
|
@@ -0,0 +1,45 @@
|
|
|
1
|
+
# Receiz AI Skills
|
|
2
|
+
|
|
3
|
+
This package teaches AI agents how to understand, verify, build with, and operate Receiz from the existing repository surfaces.
|
|
4
|
+
|
|
5
|
+
It is published as `@receiz/ai-skills` and is an exact-version dependency of both `@receiz/sdk` and `@receiz/mcp-server`. Installing either package places these eight skill directories under `node_modules/@receiz/ai-skills` for explicit loading by an agent host.
|
|
6
|
+
|
|
7
|
+
Receiz is a proof-native artifact system. A Receiz object is not a database row. It is a proof-carrying artifact. The artifact's witnessed history is the truth boundary. Server state, database state, UI state, marketplace state, and model memory are projections only. Old witnessed truth is not stale. If a projection is wrong, rebuild it from object history. If truth is missing, append new truth. Never mutate witnessed truth.
|
|
8
|
+
|
|
9
|
+
## SDK, MCP, And Skills
|
|
10
|
+
|
|
11
|
+
- SDK: `@receiz/sdk` is for building apps. It exposes validators, projections, proof memory, identity artifact helpers, public app-state, public store, commerce, wallet, sports, world, offline queues, webhooks, and sandbox helpers.
|
|
12
|
+
- MCP: `@receiz/mcp-server` is for agent tool access. It exposes SDK-backed tools for diagnostics, public reads, offline shape inspection, app-state/public-store actions, deterministic previews, and delegated writes. Artifact verification remains SDK `verification.verifyArtifact(file)` and requires continuity.
|
|
13
|
+
- Skills: this package is operating doctrine. It tells an AI which Receiz primitive is active, which source of truth wins, which SDK or MCP rail to use, and what must never be assumed.
|
|
14
|
+
|
|
15
|
+
Agents may acquire scoped delegated access through the official Receiz Connect/OIDC Authorization Code + PKCE flow or through the MCP delegated-agent setup path exposed by `receiz_mcp_login`. That acquired access is permission to call scoped SDK/MCP rails after user consent. It is not proof authority and must never outrank artifact truth.
|
|
16
|
+
|
|
17
|
+
## How Agents Should Use This Package
|
|
18
|
+
|
|
19
|
+
Start with `receiz-skill-bundle` when the request spans multiple Receiz domains. Use `receiz-proof-skill` for any verification, proof object, vault, profile, pack, card, post, product, listing, receipt, marketplace, or offline artifact question. Use narrower skills only after the primitive is named.
|
|
20
|
+
|
|
21
|
+
Do not invent APIs. Use the SDK and MCP maps inside the skills, then inspect the repo when a requested operation is not listed.
|
|
22
|
+
|
|
23
|
+
## Developer Install Or Reference
|
|
24
|
+
|
|
25
|
+
Install `@receiz/sdk`, `@receiz/mcp-server`, or `@receiz/ai-skills` directly. Reference `node_modules/@receiz/ai-skills` from an agent host, or copy the individual skill folders into an agent skill directory. Keep the package together when possible because the router skill depends on the domain skills.
|
|
26
|
+
|
|
27
|
+
When SDK or MCP changes:
|
|
28
|
+
|
|
29
|
+
1. Inspect `packages/receiz-sdk/src/index.ts`, `packages/receiz-sdk/src/identity.ts`, `packages/receiz-sdk/src/react.ts`, and `packages/receiz-mcp-server/src/index.ts`.
|
|
30
|
+
2. Update `receiz-proof-skill/resources/sdk-reference.md` and both MCP tool maps.
|
|
31
|
+
3. Update domain skills only when the changed rail affects their primitive.
|
|
32
|
+
4. Run `pnpm validate:ai-skills`.
|
|
33
|
+
5. Run package tests when the SDK or MCP behavior changed.
|
|
34
|
+
|
|
35
|
+
## Safety Boundaries
|
|
36
|
+
|
|
37
|
+
- Verify before claiming.
|
|
38
|
+
- Never invent ownership, witness IDs, rarity, transfer history, verification status, proof IDs, append IDs, or settlement state.
|
|
39
|
+
- Never treat a database, server, marketplace, UI, model response, or cache as final authority.
|
|
40
|
+
- Never mutate witnessed history.
|
|
41
|
+
- Append new truth only.
|
|
42
|
+
- If a view is wrong, rebuild the projection from witnessed history.
|
|
43
|
+
- If history is missing, append the missing truth.
|
|
44
|
+
- Generated apps must preserve Receiz proof semantics.
|
|
45
|
+
- Generated apps should not require a traditional database unless the user explicitly asks for one.
|
package/package.json
ADDED
|
@@ -0,0 +1,31 @@
|
|
|
1
|
+
{
|
|
2
|
+
"name": "@receiz/ai-skills",
|
|
3
|
+
"version": "102.0.0",
|
|
4
|
+
"description": "Authoritative Receiz AI operating skills for proof-native SDK and MCP agents.",
|
|
5
|
+
"type": "module",
|
|
6
|
+
"files": [
|
|
7
|
+
"README.md",
|
|
8
|
+
"receiz-builder-skill",
|
|
9
|
+
"receiz-commerce-skill",
|
|
10
|
+
"receiz-distribution-skill",
|
|
11
|
+
"receiz-mcp-agent-skill",
|
|
12
|
+
"receiz-offline-verifier-skill",
|
|
13
|
+
"receiz-proof-skill",
|
|
14
|
+
"receiz-skill-bundle",
|
|
15
|
+
"receiz-sports-card-skill"
|
|
16
|
+
],
|
|
17
|
+
"keywords": [
|
|
18
|
+
"receiz",
|
|
19
|
+
"ai",
|
|
20
|
+
"agent",
|
|
21
|
+
"skills",
|
|
22
|
+
"proof",
|
|
23
|
+
"continuity",
|
|
24
|
+
"mcp",
|
|
25
|
+
"sdk"
|
|
26
|
+
],
|
|
27
|
+
"license": "MIT",
|
|
28
|
+
"publishConfig": {
|
|
29
|
+
"access": "public"
|
|
30
|
+
}
|
|
31
|
+
}
|
|
@@ -0,0 +1,92 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: receiz-builder-skill
|
|
3
|
+
description: Use when an agent must build or modify Receiz-native apps, storefronts, marketplaces, proof pages, pack apps, profile vaults, claim flows, QR entry flows, templates, or custom domain apps with the Receiz SDK.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# receiz-builder-skill
|
|
7
|
+
|
|
8
|
+
Build Receiz apps from proof objects, durable public projections, proof memory, identity primitives, and append-only sync. Do not downgrade Receiz into a CRUD app.
|
|
9
|
+
|
|
10
|
+
## When To Use This Skill
|
|
11
|
+
|
|
12
|
+
- Use for no-db storefronts, product pages, marketplaces, pack opening apps, profile vaults, proof pages, claim flows, QR entry flows, custom domains, subdomains, and template apps.
|
|
13
|
+
- Use when generating app code that imports `@receiz/sdk` or `@receiz/sdk/react`.
|
|
14
|
+
- Use when an AI must choose SDK rails for public store, app state, checkout, media, identity, wallet, sports, or offline queues.
|
|
15
|
+
|
|
16
|
+
## When Not To Use This Skill
|
|
17
|
+
|
|
18
|
+
- Do not use as the only verifier for an existing object. Use `receiz-proof-skill` first.
|
|
19
|
+
- Do not use to call MCP tools directly. Use `receiz-mcp-agent-skill`.
|
|
20
|
+
- Do not use to invent app backend tables when Receiz public store, app-state projection, proof memory, or signed publish already satisfies the behavior.
|
|
21
|
+
|
|
22
|
+
## Core Receiz Laws
|
|
23
|
+
|
|
24
|
+
- A generated Receiz app must not downgrade Receiz into a normal CRUD app.
|
|
25
|
+
- The app may use projections, caches, and UI state, but the proof object remains the authority.
|
|
26
|
+
- Generated apps should not require a traditional database unless the user explicitly asks for one.
|
|
27
|
+
- Never treat a database, server, marketplace, UI, model response, or cache as final authority.
|
|
28
|
+
- SDK is for building. MCP is for agent tool access. Skills are operating doctrine.
|
|
29
|
+
- If known verified truth exists, first-paint it and ask only for verified additions after the known head.
|
|
30
|
+
|
|
31
|
+
## Required Behavior
|
|
32
|
+
|
|
33
|
+
1. Identify the primitive the app carries: proof, identity, ownership, settlement, public proof, store, pack, profile, or offline verification.
|
|
34
|
+
2. Select SDK rails from [resources/sdk-quickstart.md](resources/sdk-quickstart.md).
|
|
35
|
+
3. First-paint public store/app-state/proof memory before background sync.
|
|
36
|
+
4. Use `publicStore.resolve` for cold storefront recovery.
|
|
37
|
+
5. Use `publicStore.publishWithIdentityProof` when merchant proof owns the publish boundary.
|
|
38
|
+
6. Use delegated writes only for agent/server tasks that need delegated permission.
|
|
39
|
+
7. Keep generated code rules from [resources/generated-code-rules.md](resources/generated-code-rules.md).
|
|
40
|
+
|
|
41
|
+
## Forbidden Behavior
|
|
42
|
+
|
|
43
|
+
- Do not make DB rows the canonical product, order, proof, receipt, card, profile, or ownership truth.
|
|
44
|
+
- Do not add a new verifier, issuer, token, signature, or registry before reusing implemented Receiz primitives.
|
|
45
|
+
- Do not block deterministic first paint on session lookup, DB refresh, global sync, or marketplace reconstruction when public proof truth is available.
|
|
46
|
+
- Do not call durable proof memory a cache.
|
|
47
|
+
- Do not hide verify links, source links, owner/custody state, or proof rows.
|
|
48
|
+
|
|
49
|
+
## MCP Usage Rules
|
|
50
|
+
|
|
51
|
+
MCP is optional for app building. Use it to inspect capabilities, required scopes, runtime blueprints, public store state, and templates when a live MCP host is available. Never hallucinate unavailable MCP tools. See `receiz-mcp-agent-skill` for tool execution and confirmation rules.
|
|
52
|
+
|
|
53
|
+
## SDK Usage Rules
|
|
54
|
+
|
|
55
|
+
Use `createReceizClient`, `publicStore.resolve`, `publicStore.publish`, `publicStore.publishWithIdentityProof`, `appState.resolve`, `appState.publish`, `proofMemory`, `identity.ensureTenantSession`, `commerce.oneClickCheckout`, `media.upload`, `wallet.publicLedger`, `sports.resolveCardMemory`, `offline.createQueue`, and React helpers from `@receiz/sdk/react` as needed. See [resources/sdk-quickstart.md](resources/sdk-quickstart.md).
|
|
56
|
+
|
|
57
|
+
## Output Format
|
|
58
|
+
|
|
59
|
+
For generated apps, end with:
|
|
60
|
+
|
|
61
|
+
```md
|
|
62
|
+
Primitive carried:
|
|
63
|
+
Source of truth:
|
|
64
|
+
SDK rails used:
|
|
65
|
+
MCP rails used:
|
|
66
|
+
First-paint plan:
|
|
67
|
+
Append/enrichment plan:
|
|
68
|
+
No-db boundary:
|
|
69
|
+
User confirmation needed:
|
|
70
|
+
Checks to run:
|
|
71
|
+
```
|
|
72
|
+
|
|
73
|
+
## Safety And Security Boundaries
|
|
74
|
+
|
|
75
|
+
Do not print tokens, passphrases, private keys, or private identity artifact contents. Do not execute settlement, transfer, publish, or public-state write actions without explicit user confirmation. Keep access tokens as delegated permissions beneath identity proof, not proof authority.
|
|
76
|
+
|
|
77
|
+
## Examples
|
|
78
|
+
|
|
79
|
+
- [Create storefront](examples/create-storefront.md)
|
|
80
|
+
- [Create marketplace](examples/create-marketplace.md)
|
|
81
|
+
- [Create proof page](examples/create-proof-page.md)
|
|
82
|
+
- [Create pack app](examples/create-pack-app.md)
|
|
83
|
+
- [Create profile vault](examples/create-profile-vault.md)
|
|
84
|
+
|
|
85
|
+
Resources:
|
|
86
|
+
|
|
87
|
+
- [SDK quickstart](resources/sdk-quickstart.md)
|
|
88
|
+
- [App patterns](resources/app-patterns.md)
|
|
89
|
+
- [No-db pattern](resources/no-db-pattern.md)
|
|
90
|
+
- [Proof-native UI patterns](resources/proof-native-ui-patterns.md)
|
|
91
|
+
- [Deployment checklist](resources/deployment-checklist.md)
|
|
92
|
+
- [Generated code rules](resources/generated-code-rules.md)
|
|
@@ -0,0 +1,10 @@
|
|
|
1
|
+
# Create Marketplace
|
|
2
|
+
|
|
3
|
+
Use marketplace as a public projection over proof objects, ownership state, settlement state, and store/product records.
|
|
4
|
+
|
|
5
|
+
Minimum flow:
|
|
6
|
+
|
|
7
|
+
1. Resolve public app-state or public-store listings.
|
|
8
|
+
2. Render item identity, media, owner/custody, value/settlement, verify link.
|
|
9
|
+
3. Use proof query or public proof reads for enrichment.
|
|
10
|
+
4. Require confirmation before transfer, purchase, settlement, or listing writes.
|
|
@@ -0,0 +1,12 @@
|
|
|
1
|
+
# Create Pack App
|
|
2
|
+
|
|
3
|
+
Pack preview is not pack truth. Build separate states:
|
|
4
|
+
|
|
5
|
+
- preview
|
|
6
|
+
- issued pack
|
|
7
|
+
- opened pack
|
|
8
|
+
- claimed card outputs
|
|
9
|
+
- verified receipt
|
|
10
|
+
- failed or missing proof
|
|
11
|
+
|
|
12
|
+
Use deterministic preview for UX. Append or admit proof only after receipt verification or existing Sports pack rails confirm the issued state.
|
|
@@ -0,0 +1,5 @@
|
|
|
1
|
+
# Create Profile Vault
|
|
2
|
+
|
|
3
|
+
Render profile vault objects from proof memory, public proof rails, or canonical profile proof state. Each object remains a proof object with identity, ownership/custody, provenance, media, and verification.
|
|
4
|
+
|
|
5
|
+
Do not flatten the vault into generic cards. Add filters, search, and sorting beneath proof truth.
|
|
@@ -0,0 +1,5 @@
|
|
|
1
|
+
# Create Proof Page
|
|
2
|
+
|
|
3
|
+
A proof page first-paints a proof object, not a marketing hero. It should include object identity, proof status, verify link, provenance, media, owner/custody if known, witness history, transfer state, and safe actions.
|
|
4
|
+
|
|
5
|
+
Use `projectReceizAssetManifest` or `projectReceizSportsCardManifest` after validation. Use `publicProof.byUrl` or `publicProof.byId` for public proof enrichment.
|
|
@@ -0,0 +1,5 @@
|
|
|
1
|
+
# Create Storefront
|
|
2
|
+
|
|
3
|
+
Use `publicStore.resolve({ host })` for cold first paint. Render `storeStateRecord` as the public storefront. For edits, publish through `publicStore.publishWithIdentityProof` when a merchant identity artifact is available, otherwise use delegated `publicStore.publish` only after confirmation.
|
|
4
|
+
|
|
5
|
+
Do not add a database unless requested. If requested, make it an index beneath public store proof truth.
|
|
@@ -0,0 +1,29 @@
|
|
|
1
|
+
# App Patterns
|
|
2
|
+
|
|
3
|
+
## No-Db Storefront
|
|
4
|
+
|
|
5
|
+
1. Resolve public store by host.
|
|
6
|
+
2. Render the returned `storeStateRecord` immediately.
|
|
7
|
+
3. Show proof, product, media, seller, and claim affordances from the record.
|
|
8
|
+
4. Let admin save publish a new public-store append.
|
|
9
|
+
5. Store the known append head when returned.
|
|
10
|
+
|
|
11
|
+
## Product Page
|
|
12
|
+
|
|
13
|
+
Use a product proof object or public-store product record as the first paint. Link to verify/source material. Do not prove ownership or stock from the visual product tile alone.
|
|
14
|
+
|
|
15
|
+
## Marketplace
|
|
16
|
+
|
|
17
|
+
A marketplace is a projection over proof objects, ownership state, settlement state, and public store state. Use public reads and proof query for discovery, but keep object verification available per item.
|
|
18
|
+
|
|
19
|
+
## Pack Opening App
|
|
20
|
+
|
|
21
|
+
Preview may be deterministic. Issuance requires verified pack receipt, pack ID, reward lane, card claims, and append state. Do not issue cards from preview alone.
|
|
22
|
+
|
|
23
|
+
## Profile Vault
|
|
24
|
+
|
|
25
|
+
Render owned proof objects as proof objects. Preserve custody, transfer, certify, inspect, sell, verify, share, and source affordances. Do not call the vault a content grid.
|
|
26
|
+
|
|
27
|
+
## QR Entry Flow
|
|
28
|
+
|
|
29
|
+
QR routes should carry claim or proof entry. They can open the app, resolve a proof object or pack route, and ask the user to confirm claim/open actions before appending truth.
|
|
@@ -0,0 +1,13 @@
|
|
|
1
|
+
# Deployment Checklist
|
|
2
|
+
|
|
3
|
+
Use this before claiming a Receiz app is ready.
|
|
4
|
+
|
|
5
|
+
- Run the generated app build and lint checks.
|
|
6
|
+
- Run Receiz SDK local conformance when SDK proof handling changed.
|
|
7
|
+
- Run `receiz doctor` or the SDK `doctor()` rail for tenant wiring when app setup is in scope.
|
|
8
|
+
- Confirm public store/app-state first paint resolves without a private session when the surface is public.
|
|
9
|
+
- Confirm delegated actions require explicit user confirmation where they append, publish, transfer, or settle.
|
|
10
|
+
- Confirm no generated database table is treated as final authority.
|
|
11
|
+
- Confirm verify links, source links, ownership/custody state, and proof rows remain visible.
|
|
12
|
+
- Confirm offline or local proof routes project known truth before sync.
|
|
13
|
+
- Confirm failure states say what is missing and never claim proof that did not verify.
|
|
@@ -0,0 +1,27 @@
|
|
|
1
|
+
# Generated Code Rules
|
|
2
|
+
|
|
3
|
+
## Must Do
|
|
4
|
+
|
|
5
|
+
- Import from public SDK exports only.
|
|
6
|
+
- Keep SDK responses typed as projections unless the underlying proof object or append is verified.
|
|
7
|
+
- Use idempotency keys for retryable writes.
|
|
8
|
+
- Ask for explicit confirmation before writes, transfers, settlement actions, public publishes, or proof appends.
|
|
9
|
+
- Preserve verify/source links and proof object identity in UI.
|
|
10
|
+
- Keep durable proof memory scoped by owner, app, route, or tenant.
|
|
11
|
+
- Use public store/app-state rails for no-db storefronts.
|
|
12
|
+
|
|
13
|
+
## Must Not Do
|
|
14
|
+
|
|
15
|
+
- Do not call private SDK helpers or raw internal API routes when a client method exists.
|
|
16
|
+
- Do not invent schemas, tool names, issuers, rarity levels, ownership states, or receipt IDs.
|
|
17
|
+
- Do not create a parallel auth model that downgrades Receiz ID, PBI, Receiz Key, Identity Record, or Identity Seal.
|
|
18
|
+
- Do not make UI cache, React state, database rows, or model memory final authority.
|
|
19
|
+
- Do not hide verification behind a preview or share page.
|
|
20
|
+
|
|
21
|
+
## Generated Output Must Say
|
|
22
|
+
|
|
23
|
+
- which primitive is carried
|
|
24
|
+
- which SDK rails are used
|
|
25
|
+
- what remains unverified
|
|
26
|
+
- what requires a live bearer token or user confirmation
|
|
27
|
+
- which checks were run
|
|
@@ -0,0 +1,34 @@
|
|
|
1
|
+
# No-Db Pattern
|
|
2
|
+
|
|
3
|
+
Receiz apps can use public proof rails and durable app-state projections without a traditional app database.
|
|
4
|
+
|
|
5
|
+
## Correct Shape
|
|
6
|
+
|
|
7
|
+
```txt
|
|
8
|
+
public store/app-state projection -> first paint
|
|
9
|
+
proof object or identity proof -> authority
|
|
10
|
+
SDK publish rail -> append new projection
|
|
11
|
+
known head -> ask only for verified additions
|
|
12
|
+
```
|
|
13
|
+
|
|
14
|
+
## When A Database Is Allowed
|
|
15
|
+
|
|
16
|
+
A database may index, search, cache, or decorate proof truth when the user explicitly asks for one or the app needs lower-authority operational data. It must not become final authority over proof, ownership, settlement, profile, product, receipt, card, pack, or verification truth.
|
|
17
|
+
|
|
18
|
+
## Write Path
|
|
19
|
+
|
|
20
|
+
If a user edits a storefront or product:
|
|
21
|
+
|
|
22
|
+
1. Build the new store state.
|
|
23
|
+
2. Sign with merchant identity proof when available, or use delegated publish for agent/server operation.
|
|
24
|
+
3. Publish through Receiz public-store/app-state rails.
|
|
25
|
+
4. Save returned append coordinates or known head.
|
|
26
|
+
5. Re-render from the returned projection or next resolved public state.
|
|
27
|
+
|
|
28
|
+
## Forbidden Shape
|
|
29
|
+
|
|
30
|
+
```txt
|
|
31
|
+
form submit -> DB row -> UI says product exists -> proof added later
|
|
32
|
+
```
|
|
33
|
+
|
|
34
|
+
The Receiz shape appends proof-native truth or public projection first, then weaker indexes mirror it.
|
|
@@ -0,0 +1,29 @@
|
|
|
1
|
+
# Proof-Native UI Patterns
|
|
2
|
+
|
|
3
|
+
## First Paint
|
|
4
|
+
|
|
5
|
+
Paint the strongest known proof or public projection immediately. Do not show loading theater for truth already carried by local proof memory, artifact bytes, public store state, or deterministic fixtures.
|
|
6
|
+
|
|
7
|
+
## Object Surface
|
|
8
|
+
|
|
9
|
+
Every proof object display should expose:
|
|
10
|
+
|
|
11
|
+
- object identity
|
|
12
|
+
- proof or verify affordance
|
|
13
|
+
- owner/custody when known
|
|
14
|
+
- provenance or source
|
|
15
|
+
- media or payload
|
|
16
|
+
- append or history summary
|
|
17
|
+
- safe actions
|
|
18
|
+
|
|
19
|
+
## Storefront Surface
|
|
20
|
+
|
|
21
|
+
Storefronts should show products as proof-carrying objects or product projections with verification path. Checkout may use wallet-first funding, card fallback, and receipt proof, but the proof object remains the authority.
|
|
22
|
+
|
|
23
|
+
## Profile Vault Surface
|
|
24
|
+
|
|
25
|
+
Vault items are artifact objects. Use direct labels: proof object, ownership, custody, provenance, settlement, transfer, certificate, verification.
|
|
26
|
+
|
|
27
|
+
## Background Work
|
|
28
|
+
|
|
29
|
+
Background sync may append additions, warm routes, upload media, publish records, or refresh projections. It must not replace the settled shell or demote proof truth to UI state.
|
|
@@ -0,0 +1,68 @@
|
|
|
1
|
+
# SDK Quickstart
|
|
2
|
+
|
|
3
|
+
Use the SDK through public exported APIs.
|
|
4
|
+
|
|
5
|
+
## Build Client
|
|
6
|
+
|
|
7
|
+
Use `createReceizClient({ baseUrl, accessToken, fetchImpl })` when you need a typed client. Public reads can run without delegated access when the rail is public. Delegated actions require a Receiz-issued bearer token from Connect/OIDC.
|
|
8
|
+
|
|
9
|
+
## Public Store
|
|
10
|
+
|
|
11
|
+
- Publish delegated store state: `receiz.publicStore.publish({ tenantHost, merchantReceizId, state, title })`
|
|
12
|
+
- Publish merchant proof-owned state: `receiz.publicStore.publishWithIdentityProof({ keyFile, tenantHost, merchantReceizId, storeStateRecord })`
|
|
13
|
+
- Recover latest public storefront: `receiz.publicStore.resolve({ host })`
|
|
14
|
+
- Check signed publish contract: `receiz.publicStore.assertSignedPublishContract(...)`
|
|
15
|
+
|
|
16
|
+
## App State
|
|
17
|
+
|
|
18
|
+
- `receiz.appState.publish(...)`
|
|
19
|
+
- `receiz.appState.publishRecord(...)`
|
|
20
|
+
- `receiz.appState.resolve(...)`
|
|
21
|
+
- `receiz.appState.byUrl(...)`
|
|
22
|
+
- `receiz.appState.byCreator(...)`
|
|
23
|
+
- `receiz.appState.byNamespace(...)`
|
|
24
|
+
- `receiz.appState.byId(...)`
|
|
25
|
+
- `receiz.appState.restoreByHost(...)`
|
|
26
|
+
|
|
27
|
+
## Proof Memory
|
|
28
|
+
|
|
29
|
+
- `createReceizProofMemory`
|
|
30
|
+
- `createReceizLocalStorageProofMemoryStorage`
|
|
31
|
+
- `createReceizInMemoryProofMemoryStorage`
|
|
32
|
+
- `receiz.proofMemory.syncAdditions`
|
|
33
|
+
- `receiz.runtime.localFirst`
|
|
34
|
+
|
|
35
|
+
## Identity
|
|
36
|
+
|
|
37
|
+
- `createReceizIdIdentity`
|
|
38
|
+
- `readReceizIdentityArtifact`
|
|
39
|
+
- `projectReceizIdentityAccount`
|
|
40
|
+
- `signReceizIdentityLoginProof`
|
|
41
|
+
- `verifyReceizIdentityLoginProof`
|
|
42
|
+
- `identity.ensureTenantSession`
|
|
43
|
+
- `identity.authorizeUrl`
|
|
44
|
+
|
|
45
|
+
## Commerce And Media
|
|
46
|
+
|
|
47
|
+
- `commerce.oneClickCheckout`
|
|
48
|
+
- `media.upload`
|
|
49
|
+
- `media.transform`
|
|
50
|
+
- `wallet.publicLedger`
|
|
51
|
+
- `wallet.resolveLedger`
|
|
52
|
+
- `events.subscribe`
|
|
53
|
+
- `proof.query`
|
|
54
|
+
|
|
55
|
+
## React Subpath
|
|
56
|
+
|
|
57
|
+
Use `@receiz/sdk/react` for UI convenience:
|
|
58
|
+
|
|
59
|
+
- `useReceizIdentity`
|
|
60
|
+
- `useReceizCheckout`
|
|
61
|
+
- `useReceizAppState`
|
|
62
|
+
- `useReceizMedia`
|
|
63
|
+
- `ReceizIdentityButton`
|
|
64
|
+
- `ReceizCheckoutButton`
|
|
65
|
+
- `ReceizWalletBalance`
|
|
66
|
+
- `ReceizMediaUploader`
|
|
67
|
+
- `ReceizDomainConnector`
|
|
68
|
+
- `ReceizTwinWriter`
|
|
@@ -0,0 +1,95 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: receiz-commerce-skill
|
|
3
|
+
description: Use when an agent must create, explain, inspect, or verify Receiz commerce surfaces, product proof objects, storefronts, no-database stores, checkout boundaries, buyer/seller language, product ownership, or receipt proof.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# receiz-commerce-skill
|
|
7
|
+
|
|
8
|
+
Receiz commerce is proof-native commerce. A product page, storefront, order view, receipt, certificate, note, or resale route must preserve product proof, ownership state, settlement state, and public proof surfaces.
|
|
9
|
+
|
|
10
|
+
## When To Use This Skill
|
|
11
|
+
|
|
12
|
+
- Use for product proof pages, storefronts, marketplace listings, checkout explanations, buyer/seller copy, no-database stores, receipt proof, and ownership verification.
|
|
13
|
+
- Use when an agent is asked to build a commerce app with the Receiz SDK or MCP tools.
|
|
14
|
+
- Use before writing purchase, transfer, certificate, note, receipt, or seller-facing language.
|
|
15
|
+
|
|
16
|
+
## When Not To Use This Skill
|
|
17
|
+
|
|
18
|
+
- Do not use this as the only verifier for a raw artifact. Use `receiz-proof-skill` first when the object itself has not been verified.
|
|
19
|
+
- Do not use this for sports card memory rules. Use `receiz-sports-card-skill` for live-event card logic.
|
|
20
|
+
- Do not use this to execute checkout, transfer, or settlement actions without `receiz-mcp-agent-skill` confirmation rules.
|
|
21
|
+
|
|
22
|
+
## Core Receiz Laws
|
|
23
|
+
|
|
24
|
+
- Commerce objects are proof objects with product, ownership, provenance, media, and settlement boundaries.
|
|
25
|
+
- A storefront projection is weaker than the product proof object it presents.
|
|
26
|
+
- A buyer receives a proof-bearing object or receipt boundary, not a generic order row.
|
|
27
|
+
- A seller presents ownership, custody, and transfer conditions directly.
|
|
28
|
+
- Never treat a database, server, marketplace, UI, model response, or cache as final authority.
|
|
29
|
+
- Settlement language must distinguish purchase route, funded event, certificate value, note value, reserve state, and display price.
|
|
30
|
+
- Read [resources/commerce-object-model.md](resources/commerce-object-model.md) before generating commerce behavior.
|
|
31
|
+
|
|
32
|
+
## Required Behavior
|
|
33
|
+
|
|
34
|
+
1. Name the product primitive: proof object, ownership surface, settlement primitive, public proof surface, certificate, note, receipt, or storefront projection.
|
|
35
|
+
2. Verify the product object or public proof URL before making ownership or provenance claims.
|
|
36
|
+
3. Separate product proof from checkout mechanics and receipt projection.
|
|
37
|
+
4. Use no-database patterns only when artifact truth and SDK/MCP rails remain the source of truth.
|
|
38
|
+
5. Use buyer and seller language from [resources/seller-buyer-language.md](resources/seller-buyer-language.md).
|
|
39
|
+
6. Preserve explicit confirmation before checkout, transfer, certificate, note, or receipt append actions.
|
|
40
|
+
|
|
41
|
+
## Forbidden Behavior
|
|
42
|
+
|
|
43
|
+
- Do not call a product proof object merely a listing, card, catalog item, SKU, or content record.
|
|
44
|
+
- Do not treat checkout completion as stronger than sealed artifact truth or verified receipt proof.
|
|
45
|
+
- Do not invent ownership, price, seller authority, buyer custody, or transfer status.
|
|
46
|
+
- Do not build a storefront that requires a database before showing known verified product truth.
|
|
47
|
+
- Do not imply that marketplace visibility proves ownership.
|
|
48
|
+
|
|
49
|
+
## MCP Usage Rules
|
|
50
|
+
|
|
51
|
+
Use MCP read tools to resolve and inspect product proof first: `receiz_asset_by_url`, `receiz_asset_by_id`, `receiz_inspect_proof_object`, and `receiz_public_store_resolve`. Resolution and inspection are not verification. Use SDK `verification.verifyArtifact(file)` for the integrity-and-continuity verdict. Use `receiz_public_store_publish`, `receiz_sandbox_seed_store`, or `receiz_sandbox_checkout` only when the user explicitly asks for a write or sandbox action and confirms the exact inputs. See [resources/product-proof-flow.md](resources/product-proof-flow.md).
|
|
52
|
+
|
|
53
|
+
## SDK Usage Rules
|
|
54
|
+
|
|
55
|
+
Use `createReceizClient` and the commerce, public store, verification, app state, payments, and connect rails. Prefer `receiz.publicStore.resolve`, `receiz.publicStore.publish`, `receiz.verification.verifyArtifact`, `receiz.connect.checkout`, `receiz.connect.checkoutSession`, `receiz.commerce`, `receiz.payments`, `assertReceizAssetManifest`, and `projectReceizAssetManifest` as documented in [resources/storefront-patterns.md](resources/storefront-patterns.md).
|
|
56
|
+
|
|
57
|
+
## Output Format
|
|
58
|
+
|
|
59
|
+
Use this structure for commerce answers:
|
|
60
|
+
|
|
61
|
+
```md
|
|
62
|
+
## Commerce Proof Surface
|
|
63
|
+
Object:
|
|
64
|
+
Commerce primitive:
|
|
65
|
+
Source of truth:
|
|
66
|
+
Product proof:
|
|
67
|
+
Ownership / custody:
|
|
68
|
+
Seller claim:
|
|
69
|
+
Buyer action:
|
|
70
|
+
Settlement boundary:
|
|
71
|
+
Receipt or certificate boundary:
|
|
72
|
+
What is proven:
|
|
73
|
+
What is not proven:
|
|
74
|
+
Safe next action:
|
|
75
|
+
```
|
|
76
|
+
|
|
77
|
+
## Safety And Security Boundaries
|
|
78
|
+
|
|
79
|
+
Checkout, transfer, certificate issue, note issue, receipt append, seller onboarding, payment, and refund actions are value-affecting. They require explicit confirmation, scoped delegated access, and the existing Receiz rail. Never print bearer tokens, payment credentials, private keys, private identity files, or hidden recovery material.
|
|
80
|
+
|
|
81
|
+
## Examples
|
|
82
|
+
|
|
83
|
+
- [Create product page](examples/create-product-page.md)
|
|
84
|
+
- [Create no-database store](examples/create-no-db-store.md)
|
|
85
|
+
- [Verify product ownership](examples/verify-product-ownership.md)
|
|
86
|
+
- [Explain Receiz commerce](examples/explain-receiz-commerce.md)
|
|
87
|
+
|
|
88
|
+
Load resources as needed:
|
|
89
|
+
|
|
90
|
+
- [Commerce object model](resources/commerce-object-model.md)
|
|
91
|
+
- [Product proof flow](resources/product-proof-flow.md)
|
|
92
|
+
- [Storefront patterns](resources/storefront-patterns.md)
|
|
93
|
+
- [Order and receipt boundaries](resources/order-and-receipt-boundaries.md)
|
|
94
|
+
- [Seller buyer language](resources/seller-buyer-language.md)
|
|
95
|
+
- [Conversion copy patterns](resources/conversion-copy-patterns.md)
|
|
@@ -0,0 +1,15 @@
|
|
|
1
|
+
# Create No-Database Store
|
|
2
|
+
|
|
3
|
+
Use public proof and public store state as the source of rendered products.
|
|
4
|
+
|
|
5
|
+
## Agent Steps
|
|
6
|
+
|
|
7
|
+
1. Use `receiz.publicStore.resolve` or `receiz_public_store_resolve`.
|
|
8
|
+
2. Verify product proof objects referenced by the store projection.
|
|
9
|
+
3. Render deterministic product shells from verified truth.
|
|
10
|
+
4. Use background sync only to append verified additions.
|
|
11
|
+
5. Do not introduce a database as product authority.
|
|
12
|
+
|
|
13
|
+
## Required Statement
|
|
14
|
+
|
|
15
|
+
State that the store is no-database because product truth lives in Receiz proof objects and public store append rails.
|
|
@@ -0,0 +1,25 @@
|
|
|
1
|
+
# Create Product Page
|
|
2
|
+
|
|
3
|
+
Use `receiz-commerce-skill` with `receiz-proof-skill`.
|
|
4
|
+
|
|
5
|
+
## Agent Steps
|
|
6
|
+
|
|
7
|
+
1. Resolve the product proof object with `receiz_asset_by_url` or SDK verification.
|
|
8
|
+
2. Name the commerce primitive and source of truth.
|
|
9
|
+
3. Build the page around proof identity, product media, provenance, ownership, price display, and purchase action.
|
|
10
|
+
4. Put checkout behind explicit confirmation.
|
|
11
|
+
5. Show receipt proof status after a purchase rail returns proof.
|
|
12
|
+
|
|
13
|
+
## Output Shape
|
|
14
|
+
|
|
15
|
+
```md
|
|
16
|
+
## Product Page Plan
|
|
17
|
+
Proof identity:
|
|
18
|
+
Product media:
|
|
19
|
+
Ownership:
|
|
20
|
+
Provenance:
|
|
21
|
+
Settlement boundary:
|
|
22
|
+
Receipt boundary:
|
|
23
|
+
SDK rails:
|
|
24
|
+
MCP rails:
|
|
25
|
+
```
|
|
@@ -0,0 +1,14 @@
|
|
|
1
|
+
# Explain Receiz Commerce
|
|
2
|
+
|
|
3
|
+
Receiz commerce sells proof-bearing objects. The product object, ownership state, provenance, receipt proof, and settlement route remain legible outside a single storefront.
|
|
4
|
+
|
|
5
|
+
## Explanation Pattern
|
|
6
|
+
|
|
7
|
+
```md
|
|
8
|
+
Receiz commerce is proof-native commerce:
|
|
9
|
+
- Products are proof objects.
|
|
10
|
+
- Storefronts project verified product truth.
|
|
11
|
+
- Buyers inspect proof before value moves.
|
|
12
|
+
- Receipts, certificates, and notes carry their own proof boundaries.
|
|
13
|
+
- Servers and marketplaces help route actions, but they do not outrank artifact truth.
|
|
14
|
+
```
|
|
@@ -0,0 +1,20 @@
|
|
|
1
|
+
# Verify Product Ownership
|
|
2
|
+
|
|
3
|
+
## Agent Steps
|
|
4
|
+
|
|
5
|
+
1. Identify the product proof identity.
|
|
6
|
+
2. Inspect artifact proof and ownership surface.
|
|
7
|
+
3. Compare seller claim to current custody or owner state.
|
|
8
|
+
4. Report proven and unproven ownership separately.
|
|
9
|
+
5. Refuse to confirm sale authority when ownership is absent.
|
|
10
|
+
|
|
11
|
+
## Output
|
|
12
|
+
|
|
13
|
+
```md
|
|
14
|
+
Product:
|
|
15
|
+
Proof identity:
|
|
16
|
+
Current owner / custody:
|
|
17
|
+
Seller claim:
|
|
18
|
+
Ownership status:
|
|
19
|
+
Safe buyer action:
|
|
20
|
+
```
|
|
@@ -0,0 +1,44 @@
|
|
|
1
|
+
# Commerce Object Model
|
|
2
|
+
|
|
3
|
+
Receiz commerce objects are proof-native artifacts projected into commerce surfaces.
|
|
4
|
+
|
|
5
|
+
## Required Fields To Name
|
|
6
|
+
|
|
7
|
+
- Object identity: deterministic proof identity, public proof URL, artifact ID, or manifest identity.
|
|
8
|
+
- Product identity: product name, media, description, and included proof payload.
|
|
9
|
+
- Ownership or custody: current owner, seller, custody state, or absent proof.
|
|
10
|
+
- Provenance: origin, creator, chain, public witness, register append, or artifact history.
|
|
11
|
+
- Settlement boundary: purchase route, funded state, certificate value, note issue value, reserve state, or display price.
|
|
12
|
+
- Receipt boundary: proof of purchase, certificate, note, or receipt artifact.
|
|
13
|
+
|
|
14
|
+
## Truth Order
|
|
15
|
+
|
|
16
|
+
1. Sealed artifact truth or embedded proof.
|
|
17
|
+
2. Deterministic proof object state.
|
|
18
|
+
3. Verified local truth or durable local projection.
|
|
19
|
+
4. Verified register append.
|
|
20
|
+
5. Authenticated snapshot.
|
|
21
|
+
6. Server append and public store state.
|
|
22
|
+
7. Database, session, UI, or market projection.
|
|
23
|
+
|
|
24
|
+
When conflict appears, report the stronger proof first and mark the weaker projection as inconsistent.
|
|
25
|
+
|
|
26
|
+
## Language
|
|
27
|
+
|
|
28
|
+
Use direct language:
|
|
29
|
+
|
|
30
|
+
- Product proof object
|
|
31
|
+
- Ownership surface
|
|
32
|
+
- Receipt proof
|
|
33
|
+
- Public proof surface
|
|
34
|
+
- Settlement route
|
|
35
|
+
- Certificate value
|
|
36
|
+
- Note issue route
|
|
37
|
+
- Verified product projection
|
|
38
|
+
|
|
39
|
+
Avoid generic language as product truth:
|
|
40
|
+
|
|
41
|
+
- Generic listing
|
|
42
|
+
- Plain SKU
|
|
43
|
+
- Cart item as final authority
|
|
44
|
+
- Backend order as final authority
|