--- name: mock-data-contract namespace: process description: 'Use WHEN a prototype, frontend handoff, or backend integration needs realistic mock data TO create schema-tied mock contracts and scenario fixtures before frontend implementation. Triggers: ''mock data contract'', ''prepare mocks'', ''data-fed prototype'', ''frontend before backend''.' allowed-tools: - Read - Grep - Glob - Bash - Write - Edit phase: handoff prerequisites: - prototype-or-spec-exists emits-artifact: mock-data-contract confidence-rubric: confidence-rubrics/agent-delivery.yaml gate-on-exit: true version: 1 last-verified: 2026-05-07T00:00:00.000Z --- # Mock Data Contract ## Overview Mock Data Contract owns the mock-data-contract workflow for the handoff phase. It reads the triggering request, source artifacts, local runtime state, and required command or receipt proof, then emits `mock-data-contract` with a concrete decision and handoff. Use it to turn mock-data-contract input into a bounded action; return BLOCKED when the source artifact, owner approval, validator output, or runtime receipt is missing. A mock is a contract, not filler data. The historical mock-data-designer responsibility now resolves through `supervibe:mock-data-contract`: produce `mock-contract.json`, `mock-scenarios.json`, `api-fixtures/`, PII policy, backend drift notes, and a `Confidence: .
/10` line only after fixture, schema, and handoff evidence are recorded. ## When to Use - The prototype interaction depth is `data-fed`. - A screen spec includes loading, empty, error, permission, validation, partial, pagination, or large-list data states. - Frontend work must start before backend endpoints are available. - `/supervibe-design` reaches prototype or handoff with fake API responses. - A stack developer receives a prototype handoff and needs to know how mocks map to the eventual backend. Do not invoke for purely visual prototypes, static marketing pages with no API state, or production seed data. ## When to invoke Invoke this skill before data-fed prototype fetch logic, before approved prototype handoff, and whenever mock data must become a durable contract instead of informal fixture JSON. ## Expert Operating Standard Follow `/docs/references/skill-expert-operating-standard.md`: start from source of truth, preserve context evidence, apply scope safety, use real producers with runtime receipts for durable delegated outputs, verify before completion claims, and keep confidence below gate when evidence is partial. ## Swarm-First Durable Work Gate Follow `/docs/references/swarm-first-skill-contract.md`. Named durable worker, reviewer, producer, validator, verifier, or specialist work requires real specialist dispatch through the host/runtime path with selected skill ids, resolved `SKILL.md` paths, runtime receipts or receipt-ready host invocation evidence, and scoped verification evidence. Inline or controller-authored work is diagnostic or trivial-only; it cannot satisfy durable proof, reviewer proof, producer proof, validator proof, verification proof, task closure, or graph task closure. ## Swarm-First Durable Design Gate Durable mock contracts that affect prototype or handoff evidence require specialist producers and receipt-backed proof. Before writing, approving, or copying mock contracts, scenarios, fixtures, or backend integration notes: - Bind the data-fed UI to the selected art-direction or brand-direction owner before mock-driven prototype variants are produced. Variants without selected direction evidence are diagnostic only. - Route durable mock contract creation through the owning specialist producer and record runtime-issued producer receipts. Controller-authored or inline fixture drafts may inform the contract but must not become durable design implementation or handoff proof. - Run a screenshot critique loop for every data-fed visual state that claims approval or handoff readiness. Record critique receipts with viewport list, scenario ids, artifact hash, required fixes, approval or blocker state, and reviewer owner. - Serialize final polish under one named owner after divergent data states, directions, or variants converge. Parallel critique may produce findings, but the final polish owner alone records the accepted changes and receipt linkage. - Enforce the no-inline rule: do not inline durable design implementation or proof. If producer, screenshot critique, approval, or polish receipts are missing, mark the output diagnostic-only or `BLOCKED` and name the missing receipt path. ## Anti-AI-Slop Contract Before producing mock data for a design-facing prototype or handoff, consult `/docs/references/anti-ai-slop-contract.md`. Produce or require `antiSlopReport.schema` for the affected data-fed UI artifact, using exact `gateTaxonomy` ids such as `data-ui.state-matrix`, `data-ui.mock-data-contract-missing`, `component-state.error-empty-loading-missing`, and `domain-trust.claims-substantiated`. Fail closed when evidence is missing, a gate id is unknown, any critical gate failed, or any major gate remains unresolved without an approved waiver. Include the compact `Anti-AI-Slop:` stamp in design review/handoff output when mock data affects a design artifact. ## Step 0 - Read source of truth Before writing fixtures, read the relevant available files: - `.supervibe/artifacts/prototypes//config.json` - `.supervibe/artifacts/prototypes//spec.md` - `.supervibe/artifacts/prototypes//content/copy.md` - `.supervibe/artifacts/prototypes//mocks/` if it already exists - `.supervibe/artifacts/prototypes//.approval.json` when handoff is requested - API specs such as `openapi.yaml`, `openapi.json`, `schema.graphql`, `*.proto`, or `asyncapi.yaml` - Data model artifacts such as migrations, ORM models, Prisma schema, SQL schema, or data-modeler output - API designer output, PRD decision sections, and project memory entries for contracts, error envelopes, pagination, auth, and PII rules If no API/schema/data-model source exists, create a **provisional** contract with explicit backend questions. Do not mark it schema-backed. ## Decision tree ``` Is interaction data-fed? no -> stop; no mock-data contract needed. yes -> continue. Does an API/schema contract exist? yes -> derive mock-contract.json schemaRefs from it. no -> check data model / spec / API designer notes. Only product/spec shape exists? -> create contractStatus="provisional" and list backendQuestions. Does the spec name states? yes -> cover every named state in mock-scenarios.json. no -> require baseline states: success, loading, slow, empty, error, permission, validation, partial, large-list where relevant. Does any fixture include real PII, secrets, or production export data? yes -> replace with synthetic values before handoff. no -> continue. Is handoff being produced? yes -> copy mocks into handoff/mocks/ and add backend-integration.md. no -> keep mocks under prototype root and record readiness state. ``` ## Practice matrix | Source state | Contract status | Required scenarios | Blocker | | --- | --- | --- | --- | | OpenAPI/GraphQL/proto available | `api-backed` or `schema-backed` | success plus schema-defined errors and pagination | schema refs missing from `mock-contract.json` | | Data model only | `data-model-backed` | entity states, validation, empty, permission, large-list | API shape or error envelope treated as final | | Product/spec only | `provisional` | success, loading, slow, empty, error, permission, validation, partial | backend questions absent or hidden | | Approved handoff | current status plus handoff copy | every scenario id has a fixture file | `handoff/backend-integration.md` missing | ## Procedure 1. Resolve `` and target prototype root. 2. Classify `contractStatus`: `api-backed`, `schema-backed`, `data-model-backed`, or `provisional`. 3. Create `.supervibe/artifacts/prototypes//mocks/` if absent. 4. Write `.supervibe/artifacts/prototypes//mocks/mock-contract.json` from `/templates/mock-data/mock-contract.json.tpl`. 5. Write `.supervibe/artifacts/prototypes//mocks/mock-scenarios.json` from `/templates/mock-data/mock-scenarios.json.tpl`. 6. Write one JSON fixture per scenario under `.supervibe/artifacts/prototypes//mocks/api-fixtures/`. 7. Write `.supervibe/artifacts/prototypes//mocks/README.md` with data ownership, PII policy, backend questions, and replacement steps. 8. When producing handoff, copy the same mock bundle into `.supervibe/artifacts/prototypes//handoff/mocks/` and write `handoff/backend-integration.md` from `/templates/mock-data/backend-integration.md.tpl`. 9. Verify scenario coverage, schema refs, PII safety, and backend drift notes. 10. Score with `supervibe:confidence-scoring`. ## Anti-patterns - Ignoring the boundary: Do not use this skill to bypass the command or workflow that owns durable artifacts. - Accepting the rationalization: "This is small, so no source check is needed" - reject when the skill changes code, config, or durable artifacts. - Proceeding despite this red flag: A durable artifact changes without a command, receipt, or verification path. - Letting the known failure mode happen: Inline emulation replaces a required producer or reviewer. ## When not to use - Do not use this skill to bypass the command or workflow that owns durable artifacts. - Do not use it when source evidence, CodeGraph, or required verification is missing. - Do not use it to replace a specialist producer, worker, or reviewer that must issue runtime evidence. ## Common rationalizations - "Mock Data Contract can proceed from a vague trigger" fails because the mock-data-contract packet must name the triggering request, source artifact, owner, and expected `mock-data-contract` before durable work starts. - "Skipping mock-data-contract command proof is fine" fails when the output affects graph, release, design, security, memory, or user-visible workflow state; collect the named command, receipt, or artifact first. - "Mock Data Contract can finish with a general summary" fails because the handoff must include status, evidence, confidence, blockers, and nextAction tied to the mock-data-contract decision. ## Red flags - Mock Data Contract receives a trigger but no source artifact, owner, approval, validator output, or receipt; return BLOCKED and request the missing proof. - Mock Data Contract changes or approves `mock-data-contract` while status, evidence, confidence, or nextAction is absent; rerun the skill and repair the output contract. - Mock Data Contract crosses graph, release, design, security, provider, or memory boundaries without the owning command or reviewer receipt; stop and hand off to that owner. ## Checklist - Source of truth read. - Scope and owner confirmed. - CodeGraph/memory requirement decided. - Evidence artifact or command recorded. - Stop condition and next handoff clear. ## Failure modes - Inline emulation replaces a required producer or reviewer. - Broad use of the skill slows delivery without improving evidence. - Missing verification lets stale assumptions pass as production-ready. ## Examples - Valid data-fed prototype example: `orders-dashboard` has `contractStatus=schema-backed`, references `schema.graphql#Order`, includes success/loading/empty/error/permission/partial/large-list scenario ids, and has one synthetic fixture per scenario. - Valid provisional example: `billing-export-wizard` has no API spec yet, so `mock-contract.json` records backend questions for pagination, error envelope, and PII fields; handoff says provisional instead of backend-ready. - Anti-example: copying a production customer export into `api-fixtures/success.json`; replace with synthetic values, record the PII policy, and rerun fixture inspection before handoff. ## Output contract Returns: ```markdown === Mock Data Contract === Slug: Contract: .supervibe/artifacts/prototypes//mocks/mock-contract.json Scenarios: .supervibe/artifacts/prototypes//mocks/mock-scenarios.json Fixtures: .supervibe/artifacts/prototypes//mocks/api-fixtures/ Handoff copy: /handoff/mocks/> Backend notes: /handoff/backend-integration.md> Status: Evidence: Blockers: Next action: Confidence: .
/10 Override: Rubric: agent-delivery ``` ## Guard rails - DO NOT write happy-path-only mock data for data-fed prototypes. - DO NOT use real PII, access tokens, secrets, production exports, or customer-identifying strings in fixtures. - DO NOT call provisional mocks backend-ready; list the missing owner decision and backend questions. - DO NOT let mock shape diverge from API/schema/data model without a drift note. - DO NOT hand off data-fed prototypes without `mock-contract.json`, `mock-scenarios.json`, `api-fixtures/`, and backend integration notes. - ALWAYS preserve the distinction between UI state, API response shape, and backend persistence shape. ## Verification This skill's output is verified by: - `mock-contract.json` includes `contractStatus`, `owner`, `schemaRefs`, `endpoints`, `entities`, `piiPolicy`, and `driftRule` - `mock-scenarios.json` includes scenario ids for success and every applicable non-happy-path state - `api-fixtures/` includes one fixture file per scenario id - Fixture values are synthetic and contain no secrets, tokens, or production export markers - `backend-integration.md` exists in handoff for approved data-fed prototypes - Downstream prototype or handoff summary names the mock contract status and unresolved backend questions - After any repair, rerun fixture/schema inspection or the project mock verifier, record exit code, and keep status `provisional` or `BLOCKED` when schema refs, scenario fixtures, or PII-safety proof are missing. ## Supporting references ### Resource tree hardening - `references/practice-pack.md` - Load when mock-data-contract needs deeper load rules, local evidence anchors, gotchas, or the final checklist. - `scripts/self-check.mjs` - Run with `--check` before claiming the mock-data-contract resource tree is complete; add `--json` when machine-readable evidence is needed. - `evals/regression.json` - Use when tuning the mock-data-contract trigger boundary or checking should-trigger and should-not-trigger prompts. - `examples/workflow.md` - Load when a concrete Mock Data Contract execution example or anti-example would clarify the next action. - `templates/output-contract.md` - Use when emitting mock-data-contract so status, evidence, blockers, confidence, and nextAction stay consistent. - `/templates/mock-data/mock-contract.json.tpl` - mock contract template for status, schema refs, endpoints, entities, PII policy, and drift rule. - `/templates/mock-data/mock-scenarios.json.tpl` - scenario matrix template for happy path and non-happy-path UI states. - `/templates/mock-data/backend-integration.md.tpl` - handoff notes template for backend replacement and drift questions. - `/rules/mock-data-contract.md` - rule-level gate for frontend-before-backend workflows. - `/tests/fixtures/design-scenario-evals/a028-design-scenario-packs.json` and `/tests/skill-content-quality.test.mjs` - scenario/eval evidence for data-fed design handoffs and skill output expectations. ## Related - `supervibe:_ops:mock-data-designer` - specialist agent for producing this bundle - `supervibe:_ops:api-designer` - API contract owner - `supervibe:_ops:data-modeler` - data-model owner - `supervibe:prototype` - data-fed prototype consumer - `supervibe:prototype-handoff` - packages mock data for stack developers - `/rules/mock-data-contract.md` - rule-level gate for frontend-before-backend workflows