UNPKG

paqad-ai

Version:

Spec-driven development framework — AI agents that think before they type

github.com/Eliyce/paqad-ai

Eliyce/paqad-ai

37 lines (23 loc) • 2.15 kB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
# Cross-Module Impact Classification verified: 2026-11-02 When a proposed change touches a module's public surface, classify the impact on every consuming module along these dimensions. ## Surface types - **API contract**: HTTP endpoint, RPC method, message schema, library export - **Event**: published or consumed bus events, webhooks - **Schema**: database table, column, constraint, index - **Configuration**: environment variable, feature flag, runtime setting - **Shared utility**: function or class re-used across modules ## Impact severity - **`breaking`**: consumers will fail at compile, deploy, or run time without coordinated change. Examples: removing a required request field, changing a response field type, deleting a published event. - **`additive`**: consumers continue to work unchanged; new behavior is opt-in. Examples: adding an optional request field, adding a new event type, adding a non-required env var with a sensible default. - **`silent-shift`**: consumers continue to compile and deploy but the runtime contract has shifted in a way they may not notice. Examples: changing a default value, narrowing an accepted range, reordering pagination, changing rate limits. - **`internal-only`**: the change does not affect any other module. The scanner records this for completeness but does not warn. ## Decision rules When in doubt between `breaking` and `silent-shift`, prefer `breaking`. Silent shifts are the most dangerous because consumers do not get a fail-fast signal at deploy time. When the change is `additive` but ships with no documentation update, downgrade to `silent-shift` until the docs are updated: a behavior consumers cannot discover is effectively a silent shift. ## Coordination requirement For each `breaking` or `silent-shift` impact, the report must list: 1. The consuming module(s) affected. 2. The minimum coordinated change required in each consumer. 3. Whether a deprecation window is feasible (i.e. ship the additive form first, retire the old form later). When a deprecation window is not feasible, the change requires a Decision Packet under the Decision Pause Contract before merging.