Change a shared CLAIM-CMEV contract

Deliver a coherent contract change and its compatibility evidence. Use the available agent's normal tools; no vendor-specific commands or integrations are required.

Use proposal v2 for current scope and the workflow guide for module mapping and specification-transition limits. Read only the v2 sections relevant to this task; unmigrated v1 content does not override v2. Check newer explicitly recorded user decisions and their affected specifications before applying runtime assumptions.

Scope and sources

Read AGENTS.md, CONTEXT.md, data contracts, and affected module specifications from the index. Read the platform specification when APIs, revisions or persistence are affected.

Use v2 sections 8, 9.3 and 16 to identify changed record meanings before following the legacy contracts. In particular, v2 M6 is pen marks, M7 is reference ranges and M8 combines the old cost/evidence checks. Inspect the actual schema/code before planning a migration. At scaffold stage, a contract may exist only as documentation; do not claim a database migration or compatibility test exists unless implemented.

Trace the change

1. Identify the field/enum/record, its meaning, nullable/default semantics, and why it changes.
2. Locate producers, consumers, persisted representations, exports, fixtures and generated clients. Record whether existing historical records or model artifacts depend on the old shape.
3. Decide whether the change is additive, requires a version transition, or changes meaning even if its type stays the same. Define how old records will be read. Give changed v1 amount/taxonomy semantics a distinct version and explicit conversion or rejection policy; do not reinterpret old fixtures or bundles silently.
4. Update authoritative schemas and documentation together. Generate derived client/schema files using existing tooling when available; do not maintain conflicting copies.
5. Implement required adapters/migrations and affected call sites within the requested scope. Preserve historical meaning; a backfill must not invent evidence or approval.

Domain invariants to inspect

• Claim, input, assessment and review identities remain distinct; stale results cannot replace newer results.
• Money retains exact decimals and separate printed, human-confirmed effective/agreed and final-approved amounts. Optional OCR amount suggestions cannot overwrite confirmed values; a pending price change leaves the effective amount unresolved. Missing is not zero.
• Pen marks retain detection IDs/boxes, nullable row links and candidate rows, pending/confirmed/rejected state and confirmation-action provenance. Confirmed exclusion is a row state, not an ok finding.
• Declaration completeness distinguishes complete, partial, unreadable and explicitly empty, with human confirmation provenance. A no-row parser result cannot silently become an empty scope.
• Parts preserve original names, side and mapping uncertainty. HITL part predictions do not resolve side; human physical-identity/coverage confirmations remain separate. Summary records retain every observation without claiming a physical-damage count.
• CarDD uses six damage categories; conversion from instance annotations records overlap/background policy. A HITL-damage fallback needs its own taxonomy version, not relabelled CarDD outputs.
• Photo masks and report boxes retain source IDs, dimensions/transforms and original-coordinate navigation.
• Overall outcomes retain individual check results and reasons; skipped or failed processing is not a passed check.
• Proposed additions have no declared entry/amount until a human creates them.
• Cost generation, features and lookup share part/operation/vehicle-class/currency and the fixed single-part SGD basis; year, side and damage type are excluded from pricing dimensions. Independent base-case support differs from quote counts.
• Decision-changing confirmations/corrections create new input/assessment revisions with explicit artifact reuse; print uses the completed assessment and matching frozen review. Versioned cost ranges and model artifacts still explain historical assessments.

Inspect only invariants affected by the change; this is not a mandatory full-system audit for every field addition.

Acceptance and output

Exercise a representative producer-to-consumer round trip, relevant invalid/null/unknown input, old/new compatibility, and persistence/export behaviour when changed. For a migration, verify the documented upgrade/restore approach against a disposable test database if available; do not run it on a shared live database merely to validate a schema.

Return the semantic change, affected paths, compatibility/version decision, migration implications and actual check results. Update relevant specification TODOs and CONTEXT.md after implementation. If asked only for analysis, return the impact assessment without modifying code.