Declaration Contract Design
Design or refactor declaration contracts using a Name plus Shape view so meaning stays explicit and the shape remains stable at use sites.
Response Contract
- Deliverable: apply the requested changes to the target artifact.
- Chat output: no additional output beyond the deliverable.
Skill Model
Definitions used to reason about declaration shape decisions.
Grouping
Grouping is how a declaration organizes elements into conceptual blocks. A shape reflects the grouping decisions that were made.
Addressing Modes
A declaration’s shape is addressed in one of two modes.
Standards
Each standard is defined once here and referenced elsewhere by its ID.
name.meaning — Name states meaning
Choose names that communicate domain meaning rather than implementation detail.
contract.core.explicit — Core meaning is explicit
Keep meaning-defining elements explicit in the declaration shape. Do not hide them inside unmodeled containers or convenience wrappers.
Grouping
grouping.modeled_only — Grouping is a modeled concept
Introduce a group only when the group itself is a nameable concept with a stable semantic boundary.
grouping.no_catch_all — No catch-all groups
Do not use groups whose purpose is only to absorb leftovers or unrelated concerns.
Positional shape
positional.role.anchor — Anchor role
Identifies the primary subject, such as a target, id, path, key.
positional.role.core — Core role
Required information that defines the primary semantic variation.
positional.role.policy — Policy role
Optional strategy and tuning that changes behavior without changing the subject.
positional.role.observability — Observability role
Diagnostics and tracing concerns.
positional.order.gradient — Order follows stability gradient
In positional shape, order elements by role: Anchor, Core, Policy, Observability.
positional.prefix.stable — Stable prefix discipline
Treat Anchor and Core as a stable prefix. After publication, do not reorder the stable prefix. Only append new positional elements at the tail.
Callable declarations
callable.split — Split by role
When a callable uses both modes and the language supports named arguments, keep Anchor and Core in the positional segment and express Policy and Observability through named mechanisms.
callable.options.modeled — Options are modeled
If a callable introduces an options or config argument, it must be a modeled concept under grouping.modeled_only and must not become a catch-all under grouping.no_catch_all.
Parameterized declarations
- generics.semantic_order — Order by semantic progression
Order generic or type parameters by semantic progression: meaning-defining parameters first, constrained parameters later, and defaulted parameters at the end.
Workflow
Identify the declaration kind and the meaning the contract must communicate. Apply name.meaning and contract.core.explicit.
Decide grouping boundaries if any. Apply grouping.modeled_only and grouping.no_catch_all.
Choose addressing mode for the shape or for shape segments.
If any segment is positional, assign roles and order by the stability gradient. Apply positional.role.*, positional.order.gradient, positional.prefix.stable.
Apply kind-specific standards.
- Data-shape: no additional family beyond the base standards already applied.
- Callable: apply
callable.*.
- Parameterized: apply
generics.*.
Run acceptance checks.
Acceptance Criteria
A revision is complete only if all checks pass.
1---2name: declaration-contract-design-33description: Use when declaration contracts need design or refactoring decisions across signatures, type shapes, schemas, or generic parameters. Goal: declaration contracts are explicit, coherent, and stable at use sites.4---56# Declaration Contract Design78Design or refactor declaration contracts using a Name plus Shape view so meaning stays explicit and the shape remains stable at use sites.910## Response Contract1112- Deliverable: apply the requested changes to the target artifact.13- Chat output: no additional output beyond the deliverable.1415## Skill Model1617Definitions used to reason about declaration shape decisions.1819### Grouping2021Grouping is how a declaration organizes elements into conceptual blocks. A shape reflects the grouping decisions that were made.2223### Addressing Modes2425A declaration’s shape is addressed in one of two modes.2627- **Named shape**28 Elements are addressed by name.2930- **Positional shape**31 Elements are addressed by position.3233## Standards3435Each standard is defined once here and referenced elsewhere by its ID.3637- **name.meaning — Name states meaning**38 Choose names that communicate domain meaning rather than implementation detail.3940- **contract.core.explicit — Core meaning is explicit**41 Keep meaning-defining elements explicit in the declaration shape. Do not hide them inside unmodeled containers or convenience wrappers.4243### Grouping4445- **grouping.modeled_only — Grouping is a modeled concept**46 Introduce a group only when the group itself is a nameable concept with a stable semantic boundary.4748- **grouping.no_catch_all — No catch-all groups**49 Do not use groups whose purpose is only to absorb leftovers or unrelated concerns.5051### Positional shape5253- **positional.role.anchor — Anchor role**54 Identifies the primary subject, such as a target, id, path, key.5556- **positional.role.core — Core role**57 Required information that defines the primary semantic variation.5859- **positional.role.policy — Policy role**60 Optional strategy and tuning that changes behavior without changing the subject.6162- **positional.role.observability — Observability role**63 Diagnostics and tracing concerns.6465- **positional.order.gradient — Order follows stability gradient**66 In positional shape, order elements by role: Anchor, Core, Policy, Observability.6768- **positional.prefix.stable — Stable prefix discipline**69 Treat Anchor and Core as a stable prefix. After publication, do not reorder the stable prefix. Only append new positional elements at the tail.7071### Callable declarations7273- **callable.split — Split by role**74 When a callable uses both modes and the language supports named arguments, keep Anchor and Core in the positional segment and express Policy and Observability through named mechanisms.7576- **callable.options.modeled — Options are modeled**77 If a callable introduces an options or config argument, it must be a modeled concept under `grouping.modeled_only` and must not become a catch-all under `grouping.no_catch_all`.7879### Parameterized declarations8081- **generics.semantic_order — Order by semantic progression**82 Order generic or type parameters by semantic progression: meaning-defining parameters first, constrained parameters later, and defaulted parameters at the end.8384## Workflow85861. Identify the declaration kind and the meaning the contract must communicate. Apply `name.meaning` and `contract.core.explicit`.872. Decide grouping boundaries if any. Apply `grouping.modeled_only` and `grouping.no_catch_all`.883. Choose addressing mode for the shape or for shape segments.894. If any segment is positional, assign roles and order by the stability gradient. Apply `positional.role.*`, `positional.order.gradient`, `positional.prefix.stable`.905. Apply kind-specific standards.9192 - Data-shape: no additional family beyond the base standards already applied.93 - Callable: apply `callable.*`.94 - Parameterized: apply `generics.*`.956. Run acceptance checks.9697## Acceptance Criteria9899A revision is complete only if all checks pass.100101- **Response**: Output satisfies the Response Contract.102- **Standards satisfied**:103104 - Data-shape: `name.meaning`, `contract.core.explicit`, plus `grouping.*` when grouping is introduced, and `positional.*` when positional shape is used.105 - Callable: `name.meaning`, `contract.core.explicit`, `callable.*`, plus `grouping.*` when grouping is introduced, and `positional.*` when positional shape is used.106 - Parameterized: `contract.core.explicit`, `generics.*`, plus `positional.*` when positional shape is used.