[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6N82D2G2F4NABBC2B6GTWRF":3,"skill-same:01M6N82D2G2F4NABBC2B6GTWRF":81},{"skillNo":4,"name":5,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":33,"publishedAt":41,"linkOnly":42,"markdownContent":43,"markdownBody":44,"frontMatter":45,"refName":46,"commitSha":47,"skillDirectory":48,"forksCount":49,"repositoryHtmlUrl":50,"repositoryHomepageUrl":6,"ownerHtmlUrl":51,"ownerBlogUrl":52,"ownerDescription":53,"updatedAt":54,"install":55,"resources":68},"01M6N82D2G2F4NABBC2B6GTWRF","mh-cto-sdlc-contract-test-design",null,"Imad-Oute\u002FMicroHard","Imad-Oute","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F139675528?v=4","01M6N68WHDQ53HQJQ5Y84AGMWX","imad outemgount","01M6N68WP1YPV15H5RTGQHM02G",2,"MIT","https:\u002F\u002Fgithub.com\u002FImad-Oute\u002FMicroHard\u002Fblob\u002Fmain\u002Fsrc\u002Fdepartments\u002Fcto\u002Fsdlc\u002Fphase-5-testing-strategy\u002Fmh-cto-sdlc-contract-test-design\u002FSKILL.md",[17,22,25,30],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":23,"categoryName":24,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":26,"categoryName":27,"taxonomyType":28,"taxonomyTypeDesc":29},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",{"categoryNo":31,"categoryName":32,"taxonomyType":28,"taxonomyTypeDesc":29},"01JBSEEDCAT000000000000037","律师与法务",[34,35,36,37,38,39,40],"design","test","sdlc","test design","contract","cto","mh cto sdlc contract test design","2026-11-10 10:12:30",false,"---\nname: mh-cto-sdlc-contract-test-design\ndescription: Contract Test Design — designs consumer-driven contract tests for every external integration boundary. Specifies consumer, provider, contract shape, failure scenarios, and idempotency verification. Run after test-prioritization. Trigger phrases: \"contract tests\", \"contract test design\", \"consumer-driven contracts\", \"pact tests\", \"integration contracts testing\", \"api contracts\".\nmetadata:\n  author: MicroHard\n  version: 1.0.0\n  phase: 5-testing-strategy\n  module: cto-sdlc\n---\n\n# Contract Test Design\n\n**Mode: synthesize-first (D34).** Read the integration contracts and system diagram. Derive consumer\u002Fprovider relationships. Ask only where the contract boundary or failure behavior is ambiguous.\n\n**Elite character:** Contract tests protect the assumption that \"if my service sends this, the other service handles it correctly.\" Without contract tests, integration failures appear in staging or production — not in CI. The cost of a late integration failure is 100× the cost of a contract test. Every external boundary is a contract. Every contract is a potential break point.\n\n## Step 1 — Load Artifacts\n\nConfirm present:\n\n- Integration contracts (`integration-contracts.md`) ✓ \u002F ✗ — REQUIRED\n- System diagram (`system-diagram.md`) ✓ \u002F ✗ — REQUIRED\n- Test strategy (`test-strategy.md`) ✓ \u002F ✗\n\nMissing integration contracts: \"Cannot design contract tests without integration-contracts.md. Run `\u002Fmh-cto-sdlc-integration-design` first.\"\n\n## Step 2 — Map Consumer\u002FProvider Relationships\n\nFor each integration identified in `integration-contracts.md`, establish the contract relationship:\n\n**For each integration:**\n\n- **Consumer:** [service or client that initiates or depends on the integration]\n- **Provider:** [service that fulfills the request or produces the event]\n- **Boundary type:** REST API | gRPC | Message\u002FEvent | Webhook | SDK call\n- **Owned by:** [internal — we control both sides] \u002F [external — we control only the consumer]\n\n**Consumer-driven contract principle:** The consumer defines what it _needs_ from the provider — not what the provider _offers_. This is the inverse of schema-first API design. If the provider changes a field the consumer depends on, the contract test fails.\n\nFor external providers (third-party APIs, SaaS), note: we cannot run provider-side contract tests. We design consumer-side pact tests with recorded responses and provider replay.\n\n## Step 3 — Design Contract Per Integration\n\nFor each integration, produce the contract specification:\n\n**Contract: {Consumer} → {Provider}**\n\n```\nConsumer: {service name}\nProvider: {service name or external service}\nBoundary: {REST \u002F gRPC \u002F Event \u002F Webhook}\n\nInteractions:\n  1. {Interaction name}\n     Given: {provider state required for this interaction}\n     When: {what the consumer sends — request or event shape}\n     Then: {what the consumer expects in return — response or side effect}\n     On failure: {circuit breaker \u002F retry \u002F fallback behavior — from integration-contracts.md}\n\n  2. {Interaction name — happy path}\n     ...\n\n  3. {Error interaction}\n     Given: {provider is degraded or returns error status}\n     When: {consumer request}\n     Then: {expected graceful degradation behavior}\n```\n\n**Idempotency verification:** For async integrations, include:\n\n- Interaction sending duplicate events (same idempotency key)\n- Expected: provider deduplicates, consumer does not double-process\n\n**Dead letter scenario:** For queue-backed integrations, include:\n\n- Interaction where provider rejects the message\n- Expected: message goes to dead letter queue, alert is triggered\n\n## Step 4 — Identify Missing Contracts\n\nScan the system diagram for integration boundaries not covered in integration-contracts.md. Flag them:\n\n\"The system diagram shows {service A} calling {service B} via {mechanism}, but no integration contract exists. Either add the contract in integration-contracts.md or document why this integration does not need a contract test.\"\n\n## Step 5 — Define Contract Test Infrastructure\n\nSpecify what infrastructure is needed to run these contract tests:\n\n**Provider mocks:** For each external provider — what mock\u002Fstub approach?\n\n- Record-replay (Pact, WireMock): suitable for stable external APIs\n- Hand-crafted mocks: suitable for simple, infrequently-changing contracts\n- Real sandbox: when the provider offers a test environment\n\n**Contract verification:**\n\n- For internal services (we control both): bi-directional pact verification in CI\n- For external services: consumer-side only, with periodic replay against real sandbox\n\n**Test isolation:** Contract tests must run without real network calls. All provider interactions are intercepted.\n\n## Step 6 — Write Output\n\nSave to `_mh-output\u002Fcto\u002Fsdlc\u002Fcontract-test-design\u002F{YYYY-MM-DD}_{r###}_contract-test-spec.md`:\n\n```markdown\n# Contract Test Specification\n\n**Product:** {name}\n**Date:** {date}\n\n---\n\n## Consumer\u002FProvider Map\n\n| Consumer  | Provider       | Boundary | Control  | Contract Count |\n| --------- | -------------- | -------- | -------- | -------------- |\n| {service} | {service}      | REST     | Internal | {N}            |\n| {service} | {external API} | REST     | External | {N}            |\n\n## Contracts\n\n### {Consumer} → {Provider}\n\n{Full contract spec from Step 3}\n\n---\n\n## Missing Contract Flags\n\n{Any uncontracted boundaries from Step 4}\n\n## Test Infrastructure\n\n| Provider   | Mock Strategy      | Verification Mode    |\n| ---------- | ------------------ | -------------------- |\n| {service}  | Pact record-replay | Bi-directional in CI |\n| {external} | WireMock stub      | Consumer-side only   |\n\n## Contract Test Counts\n\nTotal contracts: {N}\nInteractions per contract (avg): {N}\nExternal provider contracts: {N}\n```\n\n## Step 7 — Present Summary\n\n**Contract Test Design complete.**\n\n**Integrations covered:** {N} integrations, {N} contracts, {N} total interactions.\n\n**External provider contracts:** {N} — consumer-side only (no provider verification).\n\n**Infrastructure required:** {mock\u002Fstub approach summary}.\n\n**Gaps flagged:** {N} uncontracted boundaries (if any).\n\n**Next step:** Run `\u002Fmh-cto-sdlc-test-data-arch` to design the test data strategy.\n","# Contract Test Design\n\n**Mode: synthesize-first (D34).** Read the integration contracts and system diagram. Derive consumer\u002Fprovider relationships. Ask only where the contract boundary or failure behavior is ambiguous.\n\n**Elite character:** Contract tests protect the assumption that \"if my service sends this, the other service handles it correctly.\" Without contract tests, integration failures appear in staging or production — not in CI. The cost of a late integration failure is 100× the cost of a contract test. Every external boundary is a contract. Every contract is a potential break point.\n\n## Step 1 — Load Artifacts\n\nConfirm present:\n\n- Integration contracts (`integration-contracts.md`) ✓ \u002F ✗ — REQUIRED\n- System diagram (`system-diagram.md`) ✓ \u002F ✗ — REQUIRED\n- Test strategy (`test-strategy.md`) ✓ \u002F ✗\n\nMissing integration contracts: \"Cannot design contract tests without integration-contracts.md. Run `\u002Fmh-cto-sdlc-integration-design` first.\"\n\n## Step 2 — Map Consumer\u002FProvider Relationships\n\nFor each integration identified in `integration-contracts.md`, establish the contract relationship:\n\n**For each integration:**\n\n- **Consumer:** [service or client that initiates or depends on the integration]\n- **Provider:** [service that fulfills the request or produces the event]\n- **Boundary type:** REST API | gRPC | Message\u002FEvent | Webhook | SDK call\n- **Owned by:** [internal — we control both sides] \u002F [external — we control only the consumer]\n\n**Consumer-driven contract principle:** The consumer defines what it _needs_ from the provider — not what the provider _offers_. This is the inverse of schema-first API design. If the provider changes a field the consumer depends on, the contract test fails.\n\nFor external providers (third-party APIs, SaaS), note: we cannot run provider-side contract tests. We design consumer-side pact tests with recorded responses and provider replay.\n\n## Step 3 — Design Contract Per Integration\n\nFor each integration, produce the contract specification:\n\n**Contract: {Consumer} → {Provider}**\n\n```\nConsumer: {service name}\nProvider: {service name or external service}\nBoundary: {REST \u002F gRPC \u002F Event \u002F Webhook}\n\nInteractions:\n  1. {Interaction name}\n     Given: {provider state required for this interaction}\n     When: {what the consumer sends — request or event shape}\n     Then: {what the consumer expects in return — response or side effect}\n     On failure: {circuit breaker \u002F retry \u002F fallback behavior — from integration-contracts.md}\n\n  2. {Interaction name — happy path}\n     ...\n\n  3. {Error interaction}\n     Given: {provider is degraded or returns error status}\n     When: {consumer request}\n     Then: {expected graceful degradation behavior}\n```\n\n**Idempotency verification:** For async integrations, include:\n\n- Interaction sending duplicate events (same idempotency key)\n- Expected: provider deduplicates, consumer does not double-process\n\n**Dead letter scenario:** For queue-backed integrations, include:\n\n- Interaction where provider rejects the message\n- Expected: message goes to dead letter queue, alert is triggered\n\n## Step 4 — Identify Missing Contracts\n\nScan the system diagram for integration boundaries not covered in integration-contracts.md. Flag them:\n\n\"The system diagram shows {service A} calling {service B} via {mechanism}, but no integration contract exists. Either add the contract in integration-contracts.md or document why this integration does not need a contract test.\"\n\n## Step 5 — Define Contract Test Infrastructure\n\nSpecify what infrastructure is needed to run these contract tests:\n\n**Provider mocks:** For each external provider — what mock\u002Fstub approach?\n\n- Record-replay (Pact, WireMock): suitable for stable external APIs\n- Hand-crafted mocks: suitable for simple, infrequently-changing contracts\n- Real sandbox: when the provider offers a test environment\n\n**Contract verification:**\n\n- For internal services (we control both): bi-directional pact verification in CI\n- For external services: consumer-side only, with periodic replay against real sandbox\n\n**Test isolation:** Contract tests must run without real network calls. All provider interactions are intercepted.\n\n## Step 6 — Write Output\n\nSave to `_mh-output\u002Fcto\u002Fsdlc\u002Fcontract-test-design\u002F{YYYY-MM-DD}_{r###}_contract-test-spec.md`:\n\n```markdown\n# Contract Test Specification\n\n**Product:** {name}\n**Date:** {date}\n\n---\n\n## Consumer\u002FProvider Map\n\n| Consumer  | Provider       | Boundary | Control  | Contract Count |\n| --------- | -------------- | -------- | -------- | -------------- |\n| {service} | {service}      | REST     | Internal | {N}            |\n| {service} | {external API} | REST     | External | {N}            |\n\n## Contracts\n\n### {Consumer} → {Provider}\n\n{Full contract spec from Step 3}\n\n---\n\n## Missing Contract Flags\n\n{Any uncontracted boundaries from Step 4}\n\n## Test Infrastructure\n\n| Provider   | Mock Strategy      | Verification Mode    |\n| ---------- | ------------------ | -------------------- |\n| {service}  | Pact record-replay | Bi-directional in CI |\n| {external} | WireMock stub      | Consumer-side only   |\n\n## Contract Test Counts\n\nTotal contracts: {N}\nInteractions per contract (avg): {N}\nExternal provider contracts: {N}\n```\n\n## Step 7 — Present Summary\n\n**Contract Test Design complete.**\n\n**Integrations covered:** {N} integrations, {N} contracts, {N} total interactions.\n\n**External provider contracts:** {N} — consumer-side only (no provider verification).\n\n**Infrastructure required:** {mock\u002Fstub approach summary}.\n\n**Gaps flagged:** {N} uncontracted boundaries (if any).\n\n**Next step:** Run `\u002Fmh-cto-sdlc-test-data-arch` to design the test data strategy.\n",{},"main","2ec3bbf5ba353f3fdd2c6d842b791fd75d08a635","src\u002Fdepartments\u002Fcto\u002Fsdlc\u002Fphase-5-testing-strategy\u002Fmh-cto-sdlc-contract-test-design",0,"https:\u002F\u002Fgithub.com\u002FImad-Oute\u002FMicroHard","https:\u002F\u002Fgithub.com\u002FImad-Oute","https:\u002F\u002Fimad369.vercel.app\u002F","I'm just starting my Journey.","2026-05-13 03:02:22",{"source":7,"skillName":5,"commands":56,"prompt":66,"zipAvailable":67},[57,60,63],{"tool":58,"command":59},"npx","npx skills add Imad-Oute\u002FMicroHard --skill mh-cto-sdlc-contract-test-design",{"tool":61,"command":62},"bunx","bunx skills add Imad-Oute\u002FMicroHard --skill mh-cto-sdlc-contract-test-design",{"tool":64,"command":65},"pnpm","pnpm dlx skills add Imad-Oute\u002FMicroHard --skill mh-cto-sdlc-contract-test-design","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FImad-Oute\u002FMicroHard\u002Fblob\u002Fmain\u002Fsrc\u002Fdepartments\u002Fcto\u002Fsdlc\u002Fphase-5-testing-strategy\u002Fmh-cto-sdlc-contract-test-design\u002FSKILL.md",true,[69,75],{"path":70,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":73,"sourceHtmlUrl":74},"customize.toml","OTHER","其他",421,"https:\u002F\u002Fgithub.com\u002FImad-Oute\u002FMicroHard\u002Fblob\u002Fmain\u002Fsrc\u002Fdepartments\u002Fcto\u002Fsdlc\u002Fphase-5-testing-strategy\u002Fmh-cto-sdlc-contract-test-design\u002Fcustomize.toml",{"path":76,"resourceType":77,"resourceTypeDesc":78,"sizeBytes":79,"sourceHtmlUrl":80},"mh-skill-manifest.yaml","REFERENCE","参考文档",491,"https:\u002F\u002Fgithub.com\u002FImad-Oute\u002FMicroHard\u002Fblob\u002Fmain\u002Fsrc\u002Fdepartments\u002Fcto\u002Fsdlc\u002Fphase-5-testing-strategy\u002Fmh-cto-sdlc-contract-test-design\u002Fmh-skill-manifest.yaml",[82,109,126,140,157,174],{"skillNo":83,"name":84,"nameZh":6,"description":85,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":86,"categories":87,"keywords":88,"publishedAt":41},"01M6N8JYRPSHVW4Y76X5SAGRDX","mh-vo-vault-brief","Weekly vault intelligence report — health score, pipeline status, OS alignment, and top issues. Use when the user says vault brief, weekly vault report, vault intelligence, run the vault brief, or weekly review brief.","https:\u002F\u002Fgithub.com\u002FImad-Oute\u002FMicroHard\u002Fblob\u002Fmain\u002Fsrc\u002Fmodules\u002Fvo\u002F5-report\u002Fmh-vo-vault-brief\u002FSKILL.md",[],[89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108],"mh vo vault brief","brief","vault","intelligence report","top","weekly","os","pipeline","health","issues","report","run","status","review","weekly review","user","use","pipeline status","alignment","intelligence",{"skillNo":110,"name":111,"nameZh":6,"description":112,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":113,"categories":114,"keywords":115,"publishedAt":41},"01M6N8JCK7E7Y19940RBB51R96","mh-vo-output-bridge","Scan _mh-output\u002F for new artifacts and create or update corresponding vault entries. Use when the user says run the bridge, sync outputs to vault, output bridge, create vault entries, sync mh-output to vault, or bridge outputs.","https:\u002F\u002Fgithub.com\u002FImad-Oute\u002FMicroHard\u002Fblob\u002Fmain\u002Fsrc\u002Fmodules\u002Fvo\u002F4-bridge\u002Fmh-vo-output-bridge\u002FSKILL.md",[],[116,117,118,91,119,120,100,121,122,123,104,124,125,105],"bridge","output","mh vo output bridge","artifacts","update","create","sync","for","entries","scan",{"skillNo":127,"name":128,"nameZh":6,"description":129,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":130,"categories":131,"keywords":132,"publishedAt":41},"01M6N8HXW3ENQ939C93R59W371","mh-vo-moc-builder","Create or update Maps of Content for vault sections and ensure every note is reachable from a MOC. Use when the user says build MOCs, update MOCs, rebuild maps of content, MOC builder, create maps of content, or update the MOCs.","https:\u002F\u002Fgithub.com\u002FImad-Oute\u002FMicroHard\u002Fblob\u002Fmain\u002Fsrc\u002Fmodules\u002Fvo\u002F3-connect\u002Fmh-vo-moc-builder\u002FSKILL.md",[],[133,134,123,135,136,137,138,121,105,91,139,120,104],"builder","mh vo moc builder","note","build","rebuild","maps","content",{"skillNo":141,"name":142,"nameZh":6,"description":143,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":144,"categories":145,"keywords":146,"publishedAt":41},"01M6N8HHZ30706B2ZS33X3MR42","mh-vo-link-architect","Identify missing vault connections and generate precise link recommendations. Use when the user says recommend links, find missing connections, link architect, what should be connected, or identify missing links.","https:\u002F\u002Fgithub.com\u002FImad-Oute\u002FMicroHard\u002Fblob\u002Fmain\u002Fsrc\u002Fmodules\u002Fvo\u002F3-connect\u002Fmh-vo-link-architect\u002FSKILL.md",[],[147,148,149,104,150,151,152,153,154,105,155,91,156],"mh vo link architect","link","architect","recommend","links","missing","recommendations","connections","find","generate",{"skillNo":158,"name":159,"nameZh":6,"description":160,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":161,"categories":162,"keywords":163,"publishedAt":41},"01M6N8H6FKWGTNFWS5PTPPTEN0","mh-vo-base-builder","Generate Obsidian Bases (.base files) for live database views of vault data. Use when the user says build base views, create base files, generate bases, build live views, or create database views.","https:\u002F\u002Fgithub.com\u002FImad-Oute\u002FMicroHard\u002Fblob\u002Fmain\u002Fsrc\u002Fmodules\u002Fvo\u002F3-connect\u002Fmh-vo-base-builder\u002FSKILL.md",[],[164,165,166,133,91,167,168,169,156,121,170,104,123,171,136,172,173,105],"mh vo base builder","base builder","base","obsidian bases","data","database","obsidian","live","files","bases",{"skillNo":175,"name":176,"nameZh":6,"description":177,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":178,"categories":179,"keywords":180,"publishedAt":41},"01M6N8GSRETQW3B9C843F1S1CP","mh-vo-taxonomy-enforcer","Audit vault tags and frontmatter, find drift, and apply corrections. Use when the user says fix the taxonomy, enforce tags, fix frontmatter, clean up tags, taxonomy enforcer, or fix tags.","https:\u002F\u002Fgithub.com\u002FImad-Oute\u002FMicroHard\u002Fblob\u002Fmain\u002Fsrc\u002Fmodules\u002Fvo\u002F2-route\u002Fmh-vo-taxonomy-enforcer\u002FSKILL.md",[],[181,182,183,184,185,186,187,188,189,190,105,191,104,155,91,192],"mh vo taxonomy enforcer","taxonomy","enforce","apply","frontmatter","tags","drift","clean","vault tags","up","fix","audit"]