AgentSkillsCN

contract-sync

在后端与接口仓库之间同步 API 合约与黄金测试用例。适用于用户提出同步合约、更新测试用例、检查合约兼容性、修复 Schema 偏移,或在各仓库间对 API Schema 进行统一协调时使用。

SKILL.md
--- frontmatter
name: contract-sync
description: Synchronize API contracts and golden fixtures between Backend and Interface repos. Use when user asks to sync contracts, update fixtures, check contract compatibility, fix schema drift, or align API schemas between repos.

Contract Sync — Phoenix Agentic Engine Interface

Context

The Interface repo carries published fixture mirrors of the Backend's canonical schemas. The chain is:

code
Backend (owns schemas in api/schemas/) → Interface (mirrors as golden fixtures + typed SDK) → Engine (consumes)

Interface fixture locations

All golden fixtures live in contracts/v1/:

Fixture fileMaps to backend endpoint
session_start.request.jsonPOST /api/v1/session/start request
session_start.response.jsonPOST /api/v1/session/start response
delta_update.request.jsonPOST /api/v1/session/delta request
delta_update.response.jsonPOST /api/v1/session/delta response
task_request.request.jsonPOST /api/v1/task/request request
task_request.response.jsonPOST /api/v1/task/request response
approval_decision.request.jsonPOST /api/v1/task/{plan_id}/approval request
approval_decision.response.jsonPOST /api/v1/task/{plan_id}/approval response
auth_handshake.response.jsonPOST /api/v1/auth/handshake response
tools_list.response.jsonGET /api/v1/tools/list response
tools_invoke.request.jsonPOST /api/v1/tools/invoke request
tools_invoke.response.jsonPOST /api/v1/tools/invoke response

Sync workflow: Receiving Backend updates

Step 1: Get updated fixtures from Backend

Check Backend repo's api/schemas/ for the canonical Pydantic models. Generate sample JSON from the models and compare with current fixtures.

Step 2: Update fixture JSON files

Update the relevant contracts/v1/*.json files to match the new schema.

Step 3: Update TypeScript types

Update sdk/client/types.ts to match the new fixture shapes.

Step 4: Update Zod validators

Update validators in sdk/validators/ to match new schema fields.

Step 5: Run tests

bash
npm run typecheck   # Verify types compile
npm test            # Run contract + compatibility tests

Contract evolution rules

  1. Never mutate v1 — existing fields cannot change type or be removed
  2. Additive only for v1 — new optional fields can be added
  3. Breaking changes → v2 — create new contracts/v2/ directory
  4. Fixture-first — update fixtures before SDK types
  5. Backend is canonical — backend golden tests are the source of truth
  6. Fixture drift = breaking change — must be caught in CI