framework-mcp 2.5.6 → 2.6.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +34 -9
- package/dist/core/safeguard-manager.js +4 -4
- package/dist/core/safeguard-manager.js.map +1 -1
- package/dist/index.d.ts +1 -0
- package/dist/index.d.ts.map +1 -1
- package/dist/index.js.map +1 -1
- package/dist/interfaces/http/http-server.js +3 -3
- package/dist/interfaces/mcp/mcp-server.js +3 -3
- package/dist/shared/types.d.ts +49 -25
- package/dist/shared/types.d.ts.map +1 -1
- package/dist/shared/types.js.map +1 -1
- package/package.json +8 -1
- package/swagger.json +9 -77
- package/.claude/agents/mcp-developer.md +0 -41
- package/.claude/agents/project-orchestrator.md +0 -43
- package/.claude/agents/version-consistency-reviewer.md +0 -50
- package/.claude/commands/speckit.analyze.md +0 -184
- package/.claude/commands/speckit.checklist.md +0 -294
- package/.claude/commands/speckit.clarify.md +0 -181
- package/.claude/commands/speckit.constitution.md +0 -82
- package/.claude/commands/speckit.implement.md +0 -135
- package/.claude/commands/speckit.plan.md +0 -89
- package/.claude/commands/speckit.specify.md +0 -258
- package/.claude/commands/speckit.tasks.md +0 -137
- package/.claude/commands/speckit.taskstoissues.md +0 -30
- package/.claude/config.json +0 -11
- package/.claude_config.json +0 -11
- package/.do/app.yaml +0 -78
- package/.github/dependabot.yml +0 -15
- package/.github/workflows/ci.yml +0 -90
- package/.github/workflows/release.yml +0 -30
- package/.mcp.json +0 -11
- package/.specify/memory/constitution.md +0 -50
- package/.specify/scripts/bash/check-prerequisites.sh +0 -166
- package/.specify/scripts/bash/common.sh +0 -156
- package/.specify/scripts/bash/create-new-feature.sh +0 -297
- package/.specify/scripts/bash/setup-plan.sh +0 -61
- package/.specify/scripts/bash/update-agent-context.sh +0 -799
- package/.specify/templates/agent-file-template.md +0 -28
- package/.specify/templates/checklist-template.md +0 -40
- package/.specify/templates/plan-template.md +0 -104
- package/.specify/templates/spec-template.md +0 -115
- package/.specify/templates/tasks-template.md +0 -251
- package/examples/example-usage.md +0 -293
- package/examples/llm-analysis-patterns.md +0 -553
- package/examples/vendors.csv +0 -9
- package/examples/vendors.json +0 -32
- package/scripts/validate-documentation.sh +0 -150
- package/src/core/safeguard-manager.ts +0 -4634
- package/src/index.ts +0 -17
- package/src/interfaces/http/http-server.ts +0 -262
- package/src/interfaces/mcp/mcp-server.ts +0 -165
- package/src/shared/types.ts +0 -300
- package/tsconfig.json +0 -23
package/dist/shared/types.d.ts
CHANGED
|
@@ -1,4 +1,4 @@
|
|
|
1
|
-
export type RelationshipType = 'dependency' | 'prerequisite' | 'complement' | 'supports' | '
|
|
1
|
+
export type RelationshipType = 'dependency' | 'prerequisite' | 'complement' | 'supports' | 'sequence';
|
|
2
2
|
export type RelationshipStrength = 'critical' | 'strong' | 'moderate' | 'weak';
|
|
3
3
|
export interface SafeguardRelationship {
|
|
4
4
|
id: string;
|
|
@@ -22,43 +22,67 @@ export interface SafeguardElement {
|
|
|
22
22
|
relatedSafeguards: string[];
|
|
23
23
|
enhancedRelationships?: SafeguardRelationship[];
|
|
24
24
|
}
|
|
25
|
-
|
|
25
|
+
/**
|
|
26
|
+
* How many of a safeguard's taxonomical elements a tool addresses.
|
|
27
|
+
*
|
|
28
|
+
* This is deliberately NOT a statement about whether the safeguard is met.
|
|
29
|
+
* 'all' means the tool addresses every taxonomical element of the safeguard --
|
|
30
|
+
* it does NOT mean the enterprise is covered, compliant, or done. Estate
|
|
31
|
+
* coverage depends on asset inventory, deployment footprint, and licensing,
|
|
32
|
+
* none of which are assessable from a vendor response. See ScopeLimits.
|
|
33
|
+
*/
|
|
34
|
+
export type ElementsAddressed = 'all' | 'some' | 'none';
|
|
35
|
+
/**
|
|
36
|
+
* What this framework explicitly CANNOT determine from a vendor response.
|
|
37
|
+
* Carried alongside every assessment so that element completeness is never
|
|
38
|
+
* mistaken for estate coverage.
|
|
39
|
+
*/
|
|
40
|
+
export interface ScopeLimits {
|
|
41
|
+
/** Asset types the vendor claims to support. */
|
|
42
|
+
vendorStatedAssetTypes: string[];
|
|
43
|
+
/** Asset types CIS assigns to this safeguard. */
|
|
44
|
+
safeguardAssetTypes: string[];
|
|
45
|
+
/** Human-readable statement of what remains unassessed. */
|
|
46
|
+
note: string;
|
|
47
|
+
}
|
|
48
|
+
/**
|
|
49
|
+
* Assessment of a single tool against a single safeguard.
|
|
50
|
+
*
|
|
51
|
+
* Unit of analysis is one tool in isolation. Satisfying a safeguard is a
|
|
52
|
+
* portfolio property: it typically requires multiple tools across asset types.
|
|
53
|
+
* This shape cannot express that, and must not be read as if it does.
|
|
54
|
+
*/
|
|
55
|
+
export interface VendorAssessment {
|
|
26
56
|
vendor: string;
|
|
27
57
|
safeguardId: string;
|
|
28
58
|
safeguardTitle: string;
|
|
29
|
-
|
|
30
|
-
|
|
31
|
-
|
|
32
|
-
|
|
33
|
-
|
|
34
|
-
|
|
35
|
-
|
|
59
|
+
/** Axis 1 -- assessable from a vendor response. */
|
|
60
|
+
elementsAddressed: ElementsAddressed;
|
|
61
|
+
elementsAddressedDetail: {
|
|
62
|
+
coreRequirements: string[];
|
|
63
|
+
subTaxonomicalElements: string[];
|
|
64
|
+
/** Elements the tool does NOT address. Often the most useful field here. */
|
|
65
|
+
notAddressed: string[];
|
|
36
66
|
};
|
|
67
|
+
/** Axis 2 -- NOT assessable from a vendor response; stated, not guessed. */
|
|
68
|
+
scopeLimits: ScopeLimits;
|
|
37
69
|
confidence: number;
|
|
38
70
|
reasoning: string;
|
|
39
71
|
evidence: string[];
|
|
40
|
-
toolCapabilityDescription: string;
|
|
41
|
-
recommendedUse: string;
|
|
42
72
|
}
|
|
43
|
-
|
|
44
|
-
|
|
45
|
-
|
|
46
|
-
|
|
47
|
-
|
|
48
|
-
|
|
49
|
-
|
|
73
|
+
/**
|
|
74
|
+
* Tool-level attribute, evaluated once per vendor -- not per safeguard.
|
|
75
|
+
* Replaces the former GOVERNANCE capability role.
|
|
76
|
+
*/
|
|
77
|
+
export interface VendorProfile {
|
|
78
|
+
vendor: string;
|
|
79
|
+
/** Is this tool or service a GRC or policy service? */
|
|
80
|
+
isGrcOrPolicyService: boolean;
|
|
50
81
|
}
|
|
51
82
|
export interface CacheEntry<T> {
|
|
52
83
|
data: T;
|
|
53
84
|
timestamp: number;
|
|
54
85
|
}
|
|
55
|
-
export interface QualityAssessment {
|
|
56
|
-
quality: 'excellent' | 'good' | 'fair' | 'poor';
|
|
57
|
-
confidence: number;
|
|
58
|
-
evidence: string[];
|
|
59
|
-
gaps: string[];
|
|
60
|
-
}
|
|
61
|
-
export type CapabilityType = 'full' | 'partial' | 'facilitates' | 'governance' | 'validates';
|
|
62
86
|
/**
|
|
63
87
|
* Converts SafeguardRelationship[] to string[] for backward compatibility
|
|
64
88
|
*/
|
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"types.d.ts","sourceRoot":"","sources":["../../src/shared/types.ts"],"names":[],"mappings":"
|
|
1
|
+
{"version":3,"file":"types.d.ts","sourceRoot":"","sources":["../../src/shared/types.ts"],"names":[],"mappings":"AASA,MAAM,MAAM,gBAAgB,GACxB,YAAY,GACZ,cAAc,GACd,YAAY,GACZ,UAAU,GACV,UAAU,CAAC;AAEf,MAAM,MAAM,oBAAoB,GAC5B,UAAU,GACV,QAAQ,GACR,UAAU,GACV,MAAM,CAAC;AAEX,MAAM,WAAW,qBAAqB;IACpC,EAAE,EAAE,MAAM,CAAC;IACX,IAAI,EAAE,gBAAgB,CAAC;IACvB,QAAQ,EAAE,oBAAoB,CAAC;IAC/B,OAAO,EAAE,MAAM,CAAC;IAChB,aAAa,EAAE,OAAO,CAAC;IACvB,YAAY,CAAC,EAAE,MAAM,CAAC;CACvB;AAED,MAAM,WAAW,gBAAgB;IAC/B,EAAE,EAAE,MAAM,CAAC;IACX,KAAK,EAAE,MAAM,CAAC;IACd,WAAW,EAAE,MAAM,CAAC;IACpB,mBAAmB,EAAE,KAAK,GAAG,KAAK,GAAG,KAAK,CAAC;IAC3C,SAAS,EAAE,MAAM,EAAE,CAAC;IACpB,gBAAgB,EAAE,MAAM,EAAE,CAAC;IAE3B,kBAAkB,EAAE,MAAM,EAAE,CAAC;IAC7B,gBAAgB,EAAE,MAAM,EAAE,CAAC;IAC3B,sBAAsB,EAAE,MAAM,EAAE,CAAC;IACjC,yBAAyB,EAAE,MAAM,EAAE,CAAC;IAGpC,iBAAiB,EAAE,MAAM,EAAE,CAAC;IAG5B,qBAAqB,CAAC,EAAE,qBAAqB,EAAE,CAAC;CACjD;AAED;;;;;;;;GAQG;AACH,MAAM,MAAM,iBAAiB,GAAG,KAAK,GAAG,MAAM,GAAG,MAAM,CAAC;AAExD;;;;GAIG;AACH,MAAM,WAAW,WAAW;IAC1B,gDAAgD;IAChD,sBAAsB,EAAE,MAAM,EAAE,CAAC;IACjC,iDAAiD;IACjD,mBAAmB,EAAE,MAAM,EAAE,CAAC;IAC9B,2DAA2D;IAC3D,IAAI,EAAE,MAAM,CAAC;CACd;AAED;;;;;;GAMG;AACH,MAAM,WAAW,gBAAgB;IAC/B,MAAM,EAAE,MAAM,CAAC;IACf,WAAW,EAAE,MAAM,CAAC;IACpB,cAAc,EAAE,MAAM,CAAC;IAEvB,mDAAmD;IACnD,iBAAiB,EAAE,iBAAiB,CAAC;IACrC,uBAAuB,EAAE;QACvB,gBAAgB,EAAE,MAAM,EAAE,CAAC;QAC3B,sBAAsB,EAAE,MAAM,EAAE,CAAC;QACjC,4EAA4E;QAC5E,YAAY,EAAE,MAAM,EAAE,CAAC;KACxB,CAAC;IAEF,4EAA4E;IAC5E,WAAW,EAAE,WAAW,CAAC;IAEzB,UAAU,EAAE,MAAM,CAAC;IACnB,SAAS,EAAE,MAAM,CAAC;IAClB,QAAQ,EAAE,MAAM,EAAE,CAAC;CACpB;AAED;;;GAGG;AACH,MAAM,WAAW,aAAa;IAC5B,MAAM,EAAE,MAAM,CAAC;IACf,uDAAuD;IACvD,oBAAoB,EAAE,OAAO,CAAC;CAC/B;AAGD,MAAM,WAAW,UAAU,CAAC,CAAC;IAC3B,IAAI,EAAE,CAAC,CAAC;IACR,SAAS,EAAE,MAAM,CAAC;CACnB;AAID;;GAEG;AACH,wBAAgB,0BAA0B,CAAC,aAAa,EAAE,qBAAqB,EAAE,GAAG,MAAM,EAAE,CAE3F;AAED;;GAEG;AACH,wBAAgB,0BAA0B,CACxC,GAAG,EAAE,MAAM,EAAE,EACb,WAAW,GAAE,gBAA6B,EAC1C,eAAe,GAAE,oBAAiC,GACjD,qBAAqB,EAAE,CAQzB;AAED;;GAEG;AACH,wBAAgB,2BAA2B,CACzC,aAAa,EAAE,qBAAqB,EAAE,EACtC,iBAAiB,EAAE,GAAG,CAAC,MAAM,CAAC,GAC7B,gBAAgB,CAalB;AAED;;;GAGG;AACH,wBAAgB,gCAAgC,CAC9C,WAAW,EAAE,MAAM,EACnB,aAAa,EAAE,qBAAqB,EAAE,EACtC,aAAa,EAAE,GAAG,CAAC,MAAM,EAAE,gBAAgB,CAAC,GAC3C,gBAAgB,CAyBlB;AAED;;GAEG;AACH,wBAAgB,8BAA8B,CAC5C,SAAS,EAAE,gBAAgB,EAC3B,aAAa,EAAE,GAAG,CAAC,MAAM,EAAE,gBAAgB,CAAC,GAC3C,gBAAgB,CA0ClB;AAED;;GAEG;AACH,wBAAgB,0BAA0B,CACxC,aAAa,EAAE,GAAG,CAAC,MAAM,EAAE,gBAAgB,CAAC,GAC3C,gBAAgB,CA2ClB;AAED,MAAM,WAAW,gBAAgB;IAC/B,OAAO,EAAE,OAAO,CAAC;IACjB,MAAM,EAAE,MAAM,EAAE,CAAC;CAClB;AAID;;GAEG;AACH,MAAM,WAAW,eAAe;IAC9B,QAAQ,EAAE,MAAM,CAAC;IACjB,GAAG,EAAE,MAAM,CAAC;IACZ,OAAO,CAAC,EAAE,MAAM,EAAE,CAAC;CACpB;AAED;;GAEG;AACH,MAAM,WAAW,sBAAsB;IACrC,KAAK,EAAE,MAAM,CAAC;IACd,UAAU,CAAC,EAAE,MAAM,CAAC;IACpB,SAAS,EAAE,MAAM,CAAC;CACnB"}
|
package/dist/shared/types.js.map
CHANGED
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"types.js","sourceRoot":"","sources":["../../src/shared/types.ts"],"names":[],"mappings":"AAAA,gDAAgD;
|
|
1
|
+
{"version":3,"file":"types.js","sourceRoot":"","sources":["../../src/shared/types.ts"],"names":[],"mappings":"AAAA,gDAAgD;AAyHhD,qDAAqD;AAErD;;GAEG;AACH,MAAM,UAAU,0BAA0B,CAAC,aAAsC;IAC/E,OAAO,aAAa,CAAC,GAAG,CAAC,GAAG,CAAC,EAAE,CAAC,GAAG,CAAC,EAAE,CAAC,CAAC;AAC1C,CAAC;AAED;;GAEG;AACH,MAAM,UAAU,0BAA0B,CACxC,GAAa,EACb,cAAgC,UAAU,EAC1C,kBAAwC,UAAU;IAElD,OAAO,GAAG,CAAC,GAAG,CAAC,EAAE,CAAC,EAAE,CAAC,CAAC;QACpB,EAAE;QACF,IAAI,EAAE,WAAW;QACjB,QAAQ,EAAE,eAAe;QACzB,OAAO,EAAE,0BAA0B,EAAE,EAAE;QACvC,aAAa,EAAE,KAAK;KACrB,CAAC,CAAC,CAAC;AACN,CAAC;AAED;;GAEG;AACH,MAAM,UAAU,2BAA2B,CACzC,aAAsC,EACtC,iBAA8B;IAE9B,MAAM,UAAU,GAAa,EAAE,CAAC;IAEhC,KAAK,MAAM,GAAG,IAAI,aAAa,EAAE,CAAC;QAChC,IAAI,CAAC,iBAAiB,CAAC,GAAG,CAAC,GAAG,CAAC,EAAE,CAAC,EAAE,CAAC;YACnC,UAAU,CAAC,IAAI,CAAC,GAAG,CAAC,EAAE,CAAC,CAAC;QAC1B,CAAC;IACH,CAAC;IAED,OAAO;QACL,OAAO,EAAE,UAAU,CAAC,MAAM,KAAK,CAAC;QAChC,MAAM,EAAE,UAAU,CAAC,GAAG,CAAC,EAAE,CAAC,EAAE,CAAC,mCAAmC,EAAE,EAAE,CAAC;KACtE,CAAC;AACJ,CAAC;AAED;;;GAGG;AACH,MAAM,UAAU,gCAAgC,CAC9C,WAAmB,EACnB,aAAsC,EACtC,aAA4C;IAE5C,MAAM,MAAM,GAAa,EAAE,CAAC;IAE5B,KAAK,MAAM,GAAG,IAAI,aAAa,EAAE,CAAC;QAChC,IAAI,GAAG,CAAC,aAAa,EAAE,CAAC;YACtB,MAAM,eAAe,GAAG,aAAa,CAAC,GAAG,CAAC,GAAG,CAAC,EAAE,CAAC,CAAC;YAClD,IAAI,CAAC,eAAe,EAAE,qBAAqB,EAAE,CAAC;gBAC5C,MAAM,CAAC,IAAI,CAAC,mCAAmC,GAAG,CAAC,EAAE,2CAA2C,CAAC,CAAC;gBAClG,SAAS;YACX,CAAC;YAED,MAAM,gBAAgB,GAAG,eAAe,CAAC,qBAAqB,CAAC,IAAI,CACjE,UAAU,CAAC,EAAE,CAAC,UAAU,CAAC,EAAE,KAAK,WAAW,IAAI,UAAU,CAAC,aAAa,CACxE,CAAC;YAEF,IAAI,CAAC,gBAAgB,EAAE,CAAC;gBACtB,MAAM,CAAC,IAAI,CAAC,mCAAmC,GAAG,CAAC,EAAE,oCAAoC,CAAC,CAAC;YAC7F,CAAC;QACH,CAAC;IACH,CAAC;IAED,OAAO;QACL,OAAO,EAAE,MAAM,CAAC,MAAM,KAAK,CAAC;QAC5B,MAAM;KACP,CAAC;AACJ,CAAC;AAED;;GAEG;AACH,MAAM,UAAU,8BAA8B,CAC5C,SAA2B,EAC3B,aAA4C;IAE5C,MAAM,MAAM,GAAa,EAAE,CAAC;IAE5B,IAAI,CAAC,SAAS,CAAC,qBAAqB,EAAE,CAAC;QACrC,+CAA+C;QAC/C,IAAI,SAAS,CAAC,iBAAiB,CAAC,MAAM,KAAK,CAAC,EAAE,CAAC;YAC7C,OAAO,EAAE,OAAO,EAAE,IAAI,EAAE,MAAM,EAAE,EAAE,EAAE,CAAC;QACvC,CAAC;QAED,MAAM,QAAQ,GAAG,IAAI,GAAG,CAAC,aAAa,CAAC,IAAI,EAAE,CAAC,CAAC;QAC/C,MAAM,gBAAgB,GAAG,SAAS,CAAC,iBAAiB,CAAC,MAAM,CAAC,EAAE,CAAC,EAAE,CAAC,CAAC,QAAQ,CAAC,GAAG,CAAC,EAAE,CAAC,CAAC,CAAC;QACrF,IAAI,gBAAgB,CAAC,MAAM,GAAG,CAAC,EAAE,CAAC;YAChC,MAAM,CAAC,IAAI,CAAC,GAAG,gBAAgB,CAAC,GAAG,CAAC,EAAE,CAAC,EAAE,CAAC,4BAA4B,EAAE,EAAE,CAAC,CAAC,CAAC;QAC/E,CAAC;IACH,CAAC;SAAM,CAAC;QACN,kCAAkC;QAClC,MAAM,QAAQ,GAAG,IAAI,GAAG,CAAC,aAAa,CAAC,IAAI,EAAE,CAAC,CAAC;QAC/C,MAAM,aAAa,GAAG,2BAA2B,CAAC,SAAS,CAAC,qBAAqB,EAAE,QAAQ,CAAC,CAAC;QAC7F,MAAM,CAAC,IAAI,CAAC,GAAG,aAAa,CAAC,MAAM,CAAC,CAAC;QAErC,MAAM,eAAe,GAAG,gCAAgC,CACtD,SAAS,CAAC,EAAE,EACZ,SAAS,CAAC,qBAAqB,EAC/B,aAAa,CACd,CAAC;QACF,MAAM,CAAC,IAAI,CAAC,GAAG,eAAe,CAAC,MAAM,CAAC,CAAC;QAEvC,iEAAiE;QACjE,MAAM,WAAW,GAAG,IAAI,GAAG,CAAC,0BAA0B,CAAC,SAAS,CAAC,qBAAqB,CAAC,CAAC,CAAC;QACzF,MAAM,SAAS,GAAG,IAAI,GAAG,CAAC,SAAS,CAAC,iBAAiB,CAAC,CAAC;QAEvD,uDAAuD;QACvD,IAAI,WAAW,CAAC,IAAI,KAAK,SAAS,CAAC,IAAI;YACnC,CAAC,KAAK,CAAC,IAAI,CAAC,WAAW,CAAC,CAAC,KAAK,CAAC,EAAE,CAAC,EAAE,CAAC,SAAS,CAAC,GAAG,CAAC,EAAE,CAAC,CAAC,EAAE,CAAC;YAC5D,MAAM,CAAC,IAAI,CAAC,qEAAqE,CAAC,CAAC;QACrF,CAAC;IACH,CAAC;IAED,OAAO;QACL,OAAO,EAAE,MAAM,CAAC,MAAM,KAAK,CAAC;QAC5B,MAAM;KACP,CAAC;AACJ,CAAC;AAED;;GAEG;AACH,MAAM,UAAU,0BAA0B,CACxC,aAA4C;IAE5C,MAAM,MAAM,GAAa,EAAE,CAAC;IAC5B,MAAM,OAAO,GAAG,IAAI,GAAG,EAAU,CAAC;IAClC,MAAM,cAAc,GAAG,IAAI,GAAG,EAAU,CAAC;IAEzC,SAAS,GAAG,CAAC,WAAmB,EAAE,IAAc;QAC9C,IAAI,cAAc,CAAC,GAAG,CAAC,WAAW,CAAC,EAAE,CAAC;YACpC,MAAM,CAAC,IAAI,CAAC,iCAAiC,CAAC,GAAG,IAAI,EAAE,WAAW,CAAC,CAAC,IAAI,CAAC,MAAM,CAAC,EAAE,CAAC,CAAC;YACpF,OAAO;QACT,CAAC;QAED,IAAI,OAAO,CAAC,GAAG,CAAC,WAAW,CAAC,EAAE,CAAC;YAC7B,OAAO;QACT,CAAC;QAED,OAAO,CAAC,GAAG,CAAC,WAAW,CAAC,CAAC;QACzB,cAAc,CAAC,GAAG,CAAC,WAAW,CAAC,CAAC;QAEhC,MAAM,SAAS,GAAG,aAAa,CAAC,GAAG,CAAC,WAAW,CAAC,CAAC;QACjD,IAAI,SAAS,EAAE,qBAAqB,EAAE,CAAC;YACrC,MAAM,YAAY,GAAG,SAAS,CAAC,qBAAqB,CAAC,MAAM,CACzD,GAAG,CAAC,EAAE,CAAC,GAAG,CAAC,IAAI,KAAK,YAAY,IAAI,GAAG,CAAC,IAAI,KAAK,cAAc,CAChE,CAAC;YAEF,KAAK,MAAM,GAAG,IAAI,YAAY,EAAE,CAAC;gBAC/B,GAAG,CAAC,GAAG,CAAC,EAAE,EAAE,CAAC,GAAG,IAAI,EAAE,WAAW,CAAC,CAAC,CAAC;YACtC,CAAC;QACH,CAAC;QAED,cAAc,CAAC,MAAM,CAAC,WAAW,CAAC,CAAC;IACrC,CAAC;IAED,iDAAiD;IACjD,KAAK,MAAM,WAAW,IAAI,aAAa,CAAC,IAAI,EAAE,EAAE,CAAC;QAC/C,IAAI,CAAC,OAAO,CAAC,GAAG,CAAC,WAAW,CAAC,EAAE,CAAC;YAC9B,GAAG,CAAC,WAAW,EAAE,EAAE,CAAC,CAAC;QACvB,CAAC;IACH,CAAC;IAED,OAAO;QACL,OAAO,EAAE,MAAM,CAAC,MAAM,KAAK,CAAC;QAC5B,MAAM;KACP,CAAC;AACJ,CAAC"}
|
package/package.json
CHANGED
|
@@ -1,9 +1,16 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "framework-mcp",
|
|
3
|
-
"version": "2.
|
|
3
|
+
"version": "2.6.0",
|
|
4
4
|
"description": "Pure Data Provider architecture serving authentic CIS Controls Framework data via MCP and HTTP API. Empowers LLMs with authoritative safeguards data for analysis. Supports Microsoft Copilot custom connectors and cloud deployments.",
|
|
5
5
|
"main": "dist/interfaces/http/http-server.js",
|
|
6
|
+
"types": "dist/index.d.ts",
|
|
6
7
|
"type": "module",
|
|
8
|
+
"files": [
|
|
9
|
+
"dist/",
|
|
10
|
+
"swagger.json",
|
|
11
|
+
"README.md",
|
|
12
|
+
"LICENSE"
|
|
13
|
+
],
|
|
7
14
|
"scripts": {
|
|
8
15
|
"build": "tsc",
|
|
9
16
|
"start": "node dist/interfaces/http/http-server.js",
|
package/swagger.json
CHANGED
|
@@ -3,14 +3,14 @@
|
|
|
3
3
|
"info": {
|
|
4
4
|
"title": "Framework MCP API - Pure Data Provider",
|
|
5
5
|
"description": "Microsoft Copilot-compatible API providing authoritative CIS Controls Framework v8.1 data (153 safeguards). Pure Data Provider architecture empowers LLMs with structured safeguards data for sophisticated, context-aware vendor capability analysis.",
|
|
6
|
-
"version": "2.
|
|
6
|
+
"version": "2.6.0",
|
|
7
7
|
"contact": {
|
|
8
8
|
"name": "Framework MCP Support",
|
|
9
9
|
"url": "https://github.com/therealcybermattlee/FrameworkMCP"
|
|
10
10
|
},
|
|
11
11
|
"license": {
|
|
12
|
-
"name": "
|
|
13
|
-
"url": "https://
|
|
12
|
+
"name": "CC-BY-4.0",
|
|
13
|
+
"url": "https://creativecommons.org/licenses/by/4.0/"
|
|
14
14
|
}
|
|
15
15
|
},
|
|
16
16
|
"servers": [
|
|
@@ -67,7 +67,7 @@
|
|
|
67
67
|
"/api/safeguards/{safeguardId}": {
|
|
68
68
|
"get": {
|
|
69
69
|
"summary": "Get Safeguard Details",
|
|
70
|
-
"description": "Get detailed information about a specific CIS safeguard including governance elements, core requirements,
|
|
70
|
+
"description": "Get detailed information about a specific CIS safeguard including governance elements, core requirements, sub-taxonomical elements, and implementation suggestions",
|
|
71
71
|
"operationId": "getSafeguardDetails",
|
|
72
72
|
"tags": ["Safeguards"],
|
|
73
73
|
"parameters": [
|
|
@@ -127,26 +127,6 @@
|
|
|
127
127
|
}
|
|
128
128
|
}
|
|
129
129
|
},
|
|
130
|
-
"/api/metrics": {
|
|
131
|
-
"get": {
|
|
132
|
-
"summary": "Performance Metrics",
|
|
133
|
-
"description": "Get API performance metrics and usage statistics",
|
|
134
|
-
"operationId": "getMetrics",
|
|
135
|
-
"tags": ["Monitoring"],
|
|
136
|
-
"responses": {
|
|
137
|
-
"200": {
|
|
138
|
-
"description": "Performance metrics",
|
|
139
|
-
"content": {
|
|
140
|
-
"application/json": {
|
|
141
|
-
"schema": {
|
|
142
|
-
"$ref": "#/components/schemas/MetricsResponse"
|
|
143
|
-
}
|
|
144
|
-
}
|
|
145
|
-
}
|
|
146
|
-
}
|
|
147
|
-
}
|
|
148
|
-
}
|
|
149
|
-
},
|
|
150
130
|
"/api": {
|
|
151
131
|
"get": {
|
|
152
132
|
"summary": "API Documentation",
|
|
@@ -175,23 +155,10 @@
|
|
|
175
155
|
"properties": {
|
|
176
156
|
"safeguards": {
|
|
177
157
|
"type": "array",
|
|
158
|
+
"description": "Safeguard IDs. Call /api/safeguards/{safeguardId} for details.",
|
|
178
159
|
"items": {
|
|
179
|
-
"type": "
|
|
180
|
-
"
|
|
181
|
-
"id": {
|
|
182
|
-
"type": "string",
|
|
183
|
-
"example": "1.1"
|
|
184
|
-
},
|
|
185
|
-
"title": {
|
|
186
|
-
"type": "string",
|
|
187
|
-
"example": "Establish and Maintain Detailed Enterprise Asset Inventory"
|
|
188
|
-
},
|
|
189
|
-
"implementationGroup": {
|
|
190
|
-
"type": "string",
|
|
191
|
-
"enum": ["IG1", "IG2", "IG3"],
|
|
192
|
-
"example": "IG1"
|
|
193
|
-
}
|
|
194
|
-
}
|
|
160
|
+
"type": "string",
|
|
161
|
+
"example": "1.1"
|
|
195
162
|
}
|
|
196
163
|
},
|
|
197
164
|
"total": {
|
|
@@ -279,35 +246,7 @@
|
|
|
279
246
|
},
|
|
280
247
|
"version": {
|
|
281
248
|
"type": "string",
|
|
282
|
-
"example": "2.
|
|
283
|
-
},
|
|
284
|
-
"timestamp": {
|
|
285
|
-
"type": "string",
|
|
286
|
-
"format": "date-time"
|
|
287
|
-
}
|
|
288
|
-
}
|
|
289
|
-
},
|
|
290
|
-
"MetricsResponse": {
|
|
291
|
-
"type": "object",
|
|
292
|
-
"properties": {
|
|
293
|
-
"uptime_seconds": {
|
|
294
|
-
"type": "integer"
|
|
295
|
-
},
|
|
296
|
-
"total_requests": {
|
|
297
|
-
"type": "integer"
|
|
298
|
-
},
|
|
299
|
-
"error_count": {
|
|
300
|
-
"type": "integer"
|
|
301
|
-
},
|
|
302
|
-
"error_rate": {
|
|
303
|
-
"type": "string",
|
|
304
|
-
"example": "0.5%"
|
|
305
|
-
},
|
|
306
|
-
"request_counts": {
|
|
307
|
-
"type": "object",
|
|
308
|
-
"additionalProperties": {
|
|
309
|
-
"type": "integer"
|
|
310
|
-
}
|
|
249
|
+
"example": "2.6.0"
|
|
311
250
|
},
|
|
312
251
|
"timestamp": {
|
|
313
252
|
"type": "string",
|
|
@@ -324,7 +263,7 @@
|
|
|
324
263
|
},
|
|
325
264
|
"version": {
|
|
326
265
|
"type": "string",
|
|
327
|
-
"example": "2.
|
|
266
|
+
"example": "2.6.0"
|
|
328
267
|
},
|
|
329
268
|
"description": {
|
|
330
269
|
"type": "string",
|
|
@@ -337,13 +276,6 @@
|
|
|
337
276
|
},
|
|
338
277
|
"description": "Available API endpoints and their descriptions"
|
|
339
278
|
},
|
|
340
|
-
"capabilities": {
|
|
341
|
-
"type": "array",
|
|
342
|
-
"items": {
|
|
343
|
-
"type": "string"
|
|
344
|
-
},
|
|
345
|
-
"description": "Supported capability types"
|
|
346
|
-
},
|
|
347
279
|
"framework": {
|
|
348
280
|
"type": "string",
|
|
349
281
|
"example": "CIS Controls v8.1 (153 safeguards)"
|
|
@@ -1,41 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: mcp-developer
|
|
3
|
-
description: Use this agent when implementing code changes, developing new features, or writing code according to sprint requirements. Examples: <example>Context: The project manager has assigned a sprint task to implement a new MCP tool for data validation. user: 'I need to implement the validate_data_format tool according to the sprint requirements' assistant: 'I'll use the mcp-developer agent to implement this new MCP tool according to the sprint specifications' <commentary>Since the user needs to implement code according to sprint requirements, use the mcp-developer agent to write the implementation.</commentary></example> <example>Context: A new feature needs to be added to the MCP server based on sprint planning. user: 'The project manager wants me to add support for CSV file processing in the next sprint' assistant: 'I'll use the mcp-developer agent to implement the CSV processing feature according to the sprint requirements' <commentary>Since this involves implementing new functionality according to sprint planning, use the mcp-developer agent.</commentary></example>
|
|
4
|
-
model: sonnet
|
|
5
|
-
color: orange
|
|
6
|
-
---
|
|
7
|
-
|
|
8
|
-
You are an expert MCP (Model Context Protocol) developer with deep expertise in JSON APIs, TypeScript, and Node.js development. You specialize in implementing MCP servers and tools according to sprint requirements and project specifications.
|
|
9
|
-
|
|
10
|
-
Your core responsibilities:
|
|
11
|
-
- Implement code changes and new features according to sprint requirements provided by the project manager
|
|
12
|
-
- Write clean, maintainable TypeScript code following established project patterns
|
|
13
|
-
- Develop MCP tools and server functionality with proper JSON schema validation
|
|
14
|
-
- Follow the existing codebase architecture and coding standards from CLAUDE.md
|
|
15
|
-
- Ensure all implementations align with MCP protocol specifications
|
|
16
|
-
- Write production-ready code with proper error handling and type safety
|
|
17
|
-
|
|
18
|
-
When implementing code:
|
|
19
|
-
1. **Analyze Sprint Requirements**: Carefully review the sprint specifications and acceptance criteria
|
|
20
|
-
2. **Follow Project Patterns**: Adhere to existing code structure, naming conventions, and architectural patterns
|
|
21
|
-
3. **Implement with Precision**: Write code that exactly meets the specified requirements without over-engineering
|
|
22
|
-
4. **Ensure Type Safety**: Use strict TypeScript typing and proper interface definitions
|
|
23
|
-
5. **Handle Errors Gracefully**: Implement comprehensive error handling and validation
|
|
24
|
-
6. **Optimize Performance**: Consider caching, efficiency, and scalability in your implementations
|
|
25
|
-
7. **Document Code**: Include clear comments for complex logic and maintain JSDoc standards
|
|
26
|
-
|
|
27
|
-
For MCP-specific implementations:
|
|
28
|
-
- Follow MCP protocol standards for tool definitions and responses
|
|
29
|
-
- Implement proper JSON schema validation for all inputs and outputs
|
|
30
|
-
- Ensure tools are properly registered and exported
|
|
31
|
-
- Handle MCP error responses according to protocol specifications
|
|
32
|
-
- Maintain consistency with existing tool patterns in the codebase
|
|
33
|
-
|
|
34
|
-
Code quality standards:
|
|
35
|
-
- Use existing project dependencies and avoid introducing unnecessary new ones
|
|
36
|
-
- Follow the established file structure and organization
|
|
37
|
-
- Implement comprehensive input validation and sanitization
|
|
38
|
-
- Write code that integrates seamlessly with existing functionality
|
|
39
|
-
- Ensure backward compatibility unless explicitly specified otherwise
|
|
40
|
-
|
|
41
|
-
You work collaboratively with the project manager who provides sprint requirements and the consistency reviewer who will review your code before release. Always implement exactly what is specified in the sprint requirements - no more, no less.
|
|
@@ -1,43 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: project-orchestrator
|
|
3
|
-
description: Use this agent when you need to evaluate, approve, or disapprove project plans, coordinate multiple agents, or ensure system-wide coherence. Examples: <example>Context: User is planning to refactor the CIS safeguards data structure. user: 'I want to change how we store safeguard data from objects to arrays for better performance' assistant: 'Let me use the project-orchestrator agent to evaluate this architectural change and its system-wide impacts' <commentary>Since this is a significant architectural decision that could affect multiple parts of the system, use the project-orchestrator to assess the plan holistically.</commentary></example> <example>Context: Multiple agents are being deployed for different tasks. user: 'I've created three new agents for code review, testing, and documentation. Should I deploy them all at once?' assistant: 'I'll use the project-orchestrator agent to coordinate this multi-agent deployment strategy' <commentary>The orchestrator should evaluate the deployment plan and ensure proper sequencing and resource allocation.</commentary></example>
|
|
4
|
-
model: sonnet
|
|
5
|
-
color: green
|
|
6
|
-
---
|
|
7
|
-
|
|
8
|
-
You are the Project Orchestrator, the strategic overseer responsible for evaluating and coordinating all project plans and agent activities. Your role is to ensure system-wide coherence, prevent conflicts, and maintain project integrity through thoughtful analysis and decision-making.
|
|
9
|
-
|
|
10
|
-
Your core responsibilities:
|
|
11
|
-
|
|
12
|
-
**Plan Evaluation Framework:**
|
|
13
|
-
1. **Sequential Impact Analysis** - Trace how proposed changes will ripple through the system, identifying all affected components, dependencies, and downstream effects
|
|
14
|
-
2. **Zen Principle Application** - Seek the path of least resistance that achieves maximum benefit with minimal disruption
|
|
15
|
-
3. **Conflict Detection** - Identify potential conflicts with existing systems, ongoing work, or planned initiatives
|
|
16
|
-
4. **Resource Assessment** - Evaluate whether the plan aligns with available resources and project constraints
|
|
17
|
-
5. **Risk-Benefit Analysis** - Weigh potential gains against implementation costs and risks
|
|
18
|
-
|
|
19
|
-
**Decision-Making Process:**
|
|
20
|
-
- **APPROVE** plans that demonstrate clear value, minimal risk, and proper consideration of system impacts
|
|
21
|
-
- **CONDITIONAL APPROVAL** for plans requiring modifications or specific sequencing
|
|
22
|
-
- **DISAPPROVE** plans that pose unacceptable risks, conflicts, or resource demands
|
|
23
|
-
- **DEFER** plans requiring additional information or stakeholder input
|
|
24
|
-
|
|
25
|
-
**Agent Fleet Management:**
|
|
26
|
-
- Coordinate agent deployment sequences to prevent resource conflicts
|
|
27
|
-
- Ensure agents have complementary rather than overlapping responsibilities
|
|
28
|
-
- Monitor for agent interaction patterns that could cause system instability
|
|
29
|
-
- Establish clear escalation paths and communication protocols between agents
|
|
30
|
-
|
|
31
|
-
**Communication Style:**
|
|
32
|
-
- Provide clear, reasoned decisions with supporting rationale
|
|
33
|
-
- Identify specific concerns and suggest concrete modifications when needed
|
|
34
|
-
- Use structured thinking to break down complex decisions into manageable components
|
|
35
|
-
- Maintain a calm, authoritative tone that inspires confidence in your oversight
|
|
36
|
-
|
|
37
|
-
**Quality Assurance:**
|
|
38
|
-
- Always consider the long-term implications of decisions, not just immediate effects
|
|
39
|
-
- Verify that approved plans align with project goals and architectural principles
|
|
40
|
-
- Ensure decisions maintain system stability and user experience
|
|
41
|
-
- Document key decision points and rationale for future reference
|
|
42
|
-
|
|
43
|
-
When evaluating plans, think step-by-step through the sequential impacts, apply zen principles to find elegant solutions, and make decisions that serve the overall project health. Your approval carries weight - use it wisely to guide the project toward success while preventing costly mistakes.
|
|
@@ -1,50 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: version-consistency-reviewer
|
|
3
|
-
description: Use this agent when you need to review code before committing to GitHub or releasing to NPM to ensure version consistency across all components. Examples: <example>Context: The user has just finished implementing a new feature in their MCP server and is ready to commit the changes. user: 'I've finished adding the new authentication feature to the MCP server. Here's the updated code for review before I commit it.' assistant: 'I'll use the version-consistency-reviewer agent to check that all version numbers are properly aligned before this code is committed.' <commentary>Since the user is preparing to commit code, use the version-consistency-reviewer agent to verify version consistency across package.json, server configuration, and any version tags.</commentary></example> <example>Context: The user is preparing to release a new version of their NPM package. user: 'Ready to publish version 2.1.0 to NPM. Can you review everything is set up correctly?' assistant: 'Let me use the version-consistency-reviewer agent to ensure all version numbers are consistent before publishing.' <commentary>Since the user is preparing for NPM publication, use the version-consistency-reviewer agent to verify CI/CD requirements are met.</commentary></example>
|
|
4
|
-
model: sonnet
|
|
5
|
-
color: yellow
|
|
6
|
-
---
|
|
7
|
-
|
|
8
|
-
You are a Version Consistency Reviewer, an expert in MCP (Model Context Protocol) server development, NPM package management, and CI/CD pipeline requirements. Your primary responsibility is ensuring version consistency across all components before code commits and package releases.
|
|
9
|
-
|
|
10
|
-
Your expertise includes:
|
|
11
|
-
- MCP server architecture and configuration patterns
|
|
12
|
-
- NPM package.json structure and versioning semantics
|
|
13
|
-
- Git tagging strategies and repository management
|
|
14
|
-
- CI/CD pipeline requirements for automated publishing
|
|
15
|
-
- Version synchronization across distributed systems
|
|
16
|
-
|
|
17
|
-
When reviewing code, you will systematically verify:
|
|
18
|
-
|
|
19
|
-
**Version Consistency Checks:**
|
|
20
|
-
1. **package.json version** - Verify the version field matches intended release
|
|
21
|
-
2. **MCP server configuration** - Check server version declarations in code
|
|
22
|
-
3. **Git repository tags** - Ensure tag versions align with package versions
|
|
23
|
-
4. **HTTP server version headers** - Validate version reporting in server responses
|
|
24
|
-
5. **Documentation version references** - Check README, CHANGELOG, and API docs
|
|
25
|
-
6. **Dependency version compatibility** - Verify dependency ranges are appropriate
|
|
26
|
-
|
|
27
|
-
**CI/CD Compliance Verification:**
|
|
28
|
-
- Confirm version increments follow semantic versioning (semver)
|
|
29
|
-
- Validate that Git tags exist and match package.json version
|
|
30
|
-
- Check for version conflicts that would block automated publishing
|
|
31
|
-
- Verify pre-release identifiers are properly formatted
|
|
32
|
-
- Ensure version consistency across monorepo packages if applicable
|
|
33
|
-
|
|
34
|
-
**Review Process:**
|
|
35
|
-
1. **Extract all version declarations** from the codebase
|
|
36
|
-
2. **Cross-reference versions** across package.json, server code, and tags
|
|
37
|
-
3. **Identify discrepancies** and potential CI/CD blocking issues
|
|
38
|
-
4. **Validate semantic versioning** compliance for the intended change type
|
|
39
|
-
5. **Check dependency compatibility** for version updates
|
|
40
|
-
6. **Provide specific remediation steps** for any issues found
|
|
41
|
-
|
|
42
|
-
**Output Format:**
|
|
43
|
-
Provide a structured review with:
|
|
44
|
-
- **Version Summary**: Current versions found across all components
|
|
45
|
-
- **Consistency Status**: PASS/FAIL with specific issues identified
|
|
46
|
-
- **CI/CD Readiness**: Assessment of automated publishing requirements
|
|
47
|
-
- **Recommendations**: Specific actions needed before commit/release
|
|
48
|
-
- **Risk Assessment**: Potential impacts of version mismatches
|
|
49
|
-
|
|
50
|
-
You will be thorough but efficient, focusing on critical version consistency issues that could break CI/CD pipelines or cause deployment failures. Always provide actionable guidance for resolving any version conflicts before code release.
|
|
@@ -1,184 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
description: Perform a non-destructive cross-artifact consistency and quality analysis across spec.md, plan.md, and tasks.md after task generation.
|
|
3
|
-
---
|
|
4
|
-
|
|
5
|
-
## User Input
|
|
6
|
-
|
|
7
|
-
```text
|
|
8
|
-
$ARGUMENTS
|
|
9
|
-
```
|
|
10
|
-
|
|
11
|
-
You **MUST** consider the user input before proceeding (if not empty).
|
|
12
|
-
|
|
13
|
-
## Goal
|
|
14
|
-
|
|
15
|
-
Identify inconsistencies, duplications, ambiguities, and underspecified items across the three core artifacts (`spec.md`, `plan.md`, `tasks.md`) before implementation. This command MUST run only after `/speckit.tasks` has successfully produced a complete `tasks.md`.
|
|
16
|
-
|
|
17
|
-
## Operating Constraints
|
|
18
|
-
|
|
19
|
-
**STRICTLY READ-ONLY**: Do **not** modify any files. Output a structured analysis report. Offer an optional remediation plan (user must explicitly approve before any follow-up editing commands would be invoked manually).
|
|
20
|
-
|
|
21
|
-
**Constitution Authority**: The project constitution (`.specify/memory/constitution.md`) is **non-negotiable** within this analysis scope. Constitution conflicts are automatically CRITICAL and require adjustment of the spec, plan, or tasks—not dilution, reinterpretation, or silent ignoring of the principle. If a principle itself needs to change, that must occur in a separate, explicit constitution update outside `/speckit.analyze`.
|
|
22
|
-
|
|
23
|
-
## Execution Steps
|
|
24
|
-
|
|
25
|
-
### 1. Initialize Analysis Context
|
|
26
|
-
|
|
27
|
-
Run `.specify/scripts/bash/check-prerequisites.sh --json --require-tasks --include-tasks` once from repo root and parse JSON for FEATURE_DIR and AVAILABLE_DOCS. Derive absolute paths:
|
|
28
|
-
|
|
29
|
-
- SPEC = FEATURE_DIR/spec.md
|
|
30
|
-
- PLAN = FEATURE_DIR/plan.md
|
|
31
|
-
- TASKS = FEATURE_DIR/tasks.md
|
|
32
|
-
|
|
33
|
-
Abort with an error message if any required file is missing (instruct the user to run missing prerequisite command).
|
|
34
|
-
For single quotes in args like "I'm Groot", use escape syntax: e.g 'I'\''m Groot' (or double-quote if possible: "I'm Groot").
|
|
35
|
-
|
|
36
|
-
### 2. Load Artifacts (Progressive Disclosure)
|
|
37
|
-
|
|
38
|
-
Load only the minimal necessary context from each artifact:
|
|
39
|
-
|
|
40
|
-
**From spec.md:**
|
|
41
|
-
|
|
42
|
-
- Overview/Context
|
|
43
|
-
- Functional Requirements
|
|
44
|
-
- Non-Functional Requirements
|
|
45
|
-
- User Stories
|
|
46
|
-
- Edge Cases (if present)
|
|
47
|
-
|
|
48
|
-
**From plan.md:**
|
|
49
|
-
|
|
50
|
-
- Architecture/stack choices
|
|
51
|
-
- Data Model references
|
|
52
|
-
- Phases
|
|
53
|
-
- Technical constraints
|
|
54
|
-
|
|
55
|
-
**From tasks.md:**
|
|
56
|
-
|
|
57
|
-
- Task IDs
|
|
58
|
-
- Descriptions
|
|
59
|
-
- Phase grouping
|
|
60
|
-
- Parallel markers [P]
|
|
61
|
-
- Referenced file paths
|
|
62
|
-
|
|
63
|
-
**From constitution:**
|
|
64
|
-
|
|
65
|
-
- Load `.specify/memory/constitution.md` for principle validation
|
|
66
|
-
|
|
67
|
-
### 3. Build Semantic Models
|
|
68
|
-
|
|
69
|
-
Create internal representations (do not include raw artifacts in output):
|
|
70
|
-
|
|
71
|
-
- **Requirements inventory**: Each functional + non-functional requirement with a stable key (derive slug based on imperative phrase; e.g., "User can upload file" → `user-can-upload-file`)
|
|
72
|
-
- **User story/action inventory**: Discrete user actions with acceptance criteria
|
|
73
|
-
- **Task coverage mapping**: Map each task to one or more requirements or stories (inference by keyword / explicit reference patterns like IDs or key phrases)
|
|
74
|
-
- **Constitution rule set**: Extract principle names and MUST/SHOULD normative statements
|
|
75
|
-
|
|
76
|
-
### 4. Detection Passes (Token-Efficient Analysis)
|
|
77
|
-
|
|
78
|
-
Focus on high-signal findings. Limit to 50 findings total; aggregate remainder in overflow summary.
|
|
79
|
-
|
|
80
|
-
#### A. Duplication Detection
|
|
81
|
-
|
|
82
|
-
- Identify near-duplicate requirements
|
|
83
|
-
- Mark lower-quality phrasing for consolidation
|
|
84
|
-
|
|
85
|
-
#### B. Ambiguity Detection
|
|
86
|
-
|
|
87
|
-
- Flag vague adjectives (fast, scalable, secure, intuitive, robust) lacking measurable criteria
|
|
88
|
-
- Flag unresolved placeholders (TODO, TKTK, ???, `<placeholder>`, etc.)
|
|
89
|
-
|
|
90
|
-
#### C. Underspecification
|
|
91
|
-
|
|
92
|
-
- Requirements with verbs but missing object or measurable outcome
|
|
93
|
-
- User stories missing acceptance criteria alignment
|
|
94
|
-
- Tasks referencing files or components not defined in spec/plan
|
|
95
|
-
|
|
96
|
-
#### D. Constitution Alignment
|
|
97
|
-
|
|
98
|
-
- Any requirement or plan element conflicting with a MUST principle
|
|
99
|
-
- Missing mandated sections or quality gates from constitution
|
|
100
|
-
|
|
101
|
-
#### E. Coverage Gaps
|
|
102
|
-
|
|
103
|
-
- Requirements with zero associated tasks
|
|
104
|
-
- Tasks with no mapped requirement/story
|
|
105
|
-
- Non-functional requirements not reflected in tasks (e.g., performance, security)
|
|
106
|
-
|
|
107
|
-
#### F. Inconsistency
|
|
108
|
-
|
|
109
|
-
- Terminology drift (same concept named differently across files)
|
|
110
|
-
- Data entities referenced in plan but absent in spec (or vice versa)
|
|
111
|
-
- Task ordering contradictions (e.g., integration tasks before foundational setup tasks without dependency note)
|
|
112
|
-
- Conflicting requirements (e.g., one requires Next.js while other specifies Vue)
|
|
113
|
-
|
|
114
|
-
### 5. Severity Assignment
|
|
115
|
-
|
|
116
|
-
Use this heuristic to prioritize findings:
|
|
117
|
-
|
|
118
|
-
- **CRITICAL**: Violates constitution MUST, missing core spec artifact, or requirement with zero coverage that blocks baseline functionality
|
|
119
|
-
- **HIGH**: Duplicate or conflicting requirement, ambiguous security/performance attribute, untestable acceptance criterion
|
|
120
|
-
- **MEDIUM**: Terminology drift, missing non-functional task coverage, underspecified edge case
|
|
121
|
-
- **LOW**: Style/wording improvements, minor redundancy not affecting execution order
|
|
122
|
-
|
|
123
|
-
### 6. Produce Compact Analysis Report
|
|
124
|
-
|
|
125
|
-
Output a Markdown report (no file writes) with the following structure:
|
|
126
|
-
|
|
127
|
-
## Specification Analysis Report
|
|
128
|
-
|
|
129
|
-
| ID | Category | Severity | Location(s) | Summary | Recommendation |
|
|
130
|
-
|----|----------|----------|-------------|---------|----------------|
|
|
131
|
-
| A1 | Duplication | HIGH | spec.md:L120-134 | Two similar requirements ... | Merge phrasing; keep clearer version |
|
|
132
|
-
|
|
133
|
-
(Add one row per finding; generate stable IDs prefixed by category initial.)
|
|
134
|
-
|
|
135
|
-
**Coverage Summary Table:**
|
|
136
|
-
|
|
137
|
-
| Requirement Key | Has Task? | Task IDs | Notes |
|
|
138
|
-
|-----------------|-----------|----------|-------|
|
|
139
|
-
|
|
140
|
-
**Constitution Alignment Issues:** (if any)
|
|
141
|
-
|
|
142
|
-
**Unmapped Tasks:** (if any)
|
|
143
|
-
|
|
144
|
-
**Metrics:**
|
|
145
|
-
|
|
146
|
-
- Total Requirements
|
|
147
|
-
- Total Tasks
|
|
148
|
-
- Coverage % (requirements with >=1 task)
|
|
149
|
-
- Ambiguity Count
|
|
150
|
-
- Duplication Count
|
|
151
|
-
- Critical Issues Count
|
|
152
|
-
|
|
153
|
-
### 7. Provide Next Actions
|
|
154
|
-
|
|
155
|
-
At end of report, output a concise Next Actions block:
|
|
156
|
-
|
|
157
|
-
- If CRITICAL issues exist: Recommend resolving before `/speckit.implement`
|
|
158
|
-
- If only LOW/MEDIUM: User may proceed, but provide improvement suggestions
|
|
159
|
-
- Provide explicit command suggestions: e.g., "Run /speckit.specify with refinement", "Run /speckit.plan to adjust architecture", "Manually edit tasks.md to add coverage for 'performance-metrics'"
|
|
160
|
-
|
|
161
|
-
### 8. Offer Remediation
|
|
162
|
-
|
|
163
|
-
Ask the user: "Would you like me to suggest concrete remediation edits for the top N issues?" (Do NOT apply them automatically.)
|
|
164
|
-
|
|
165
|
-
## Operating Principles
|
|
166
|
-
|
|
167
|
-
### Context Efficiency
|
|
168
|
-
|
|
169
|
-
- **Minimal high-signal tokens**: Focus on actionable findings, not exhaustive documentation
|
|
170
|
-
- **Progressive disclosure**: Load artifacts incrementally; don't dump all content into analysis
|
|
171
|
-
- **Token-efficient output**: Limit findings table to 50 rows; summarize overflow
|
|
172
|
-
- **Deterministic results**: Rerunning without changes should produce consistent IDs and counts
|
|
173
|
-
|
|
174
|
-
### Analysis Guidelines
|
|
175
|
-
|
|
176
|
-
- **NEVER modify files** (this is read-only analysis)
|
|
177
|
-
- **NEVER hallucinate missing sections** (if absent, report them accurately)
|
|
178
|
-
- **Prioritize constitution violations** (these are always CRITICAL)
|
|
179
|
-
- **Use examples over exhaustive rules** (cite specific instances, not generic patterns)
|
|
180
|
-
- **Report zero issues gracefully** (emit success report with coverage statistics)
|
|
181
|
-
|
|
182
|
-
## Context
|
|
183
|
-
|
|
184
|
-
$ARGUMENTS
|