This template is used only when enable_contract_map is explicitly enabled.
It should not be produced by default.
Use this page to document request and response contracts in more detail than the default interface map.
Typical goals:
- clarify required vs optional fields
- clarify enum sources
- clarify unresolved fields
- reduce frontend-backend contract ambiguity
Use this page only when one of these is true:
- the user explicitly enabled
enable_contract_map - the integration flow is parameter-heavy
- contract misunderstandings are a real cost in the current project
Recommended sections:
- contract scope
- request contract table
- response contract table
- enum and dictionary notes
- unresolved contract items
Recommended table:
| field | required | type | source | meaning | enum/source note | evidence level | code locations |
| --- | --- | --- | --- | --- | --- | --- | --- |Possible source values:
- page form
- app view model
- api wrapper
- DTO
- bridge params
- callback payload
Recommended table:
| field | type | consumer side | meaning | enum/source note | evidence level | code locations |
| --- | --- | --- | --- | --- | --- | --- |If enums or dictionary values are visible, record:
- enum name
- visible values
- source file or config
- unresolved gaps
Do not invent business meaning for a field if the code does not support it.
If a field name is visible but semantics are unclear:
- record the field
- mark the meaning as unresolved
- keep the evidence level aligned with what is visible
Use phrases like:
Required by caller-side validationOptional in DTOEnum source visible in codeField meaning unresolved in current scopeConsumer-side usage visible