antigravity-ai-kit 3.3.1 → 3.4.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.
|
@@ -118,7 +118,7 @@
|
|
|
118
118
|
},
|
|
119
119
|
"workflowBindings": [
|
|
120
120
|
{ "workflow": "brainstorm", "loadAgents": [], "loadSkills": ["brainstorming"], "bindingType": "inferred" },
|
|
121
|
-
{ "workflow": "quality-gate", "loadAgents": [], "loadSkills": ["brainstorming"], "bindingType": "inferred" },
|
|
121
|
+
{ "workflow": "quality-gate", "loadAgents": [], "loadSkills": ["brainstorming"], "loadRules": ["quality-gate"], "bindingType": "inferred" },
|
|
122
122
|
{ "workflow": "plan", "loadAgents": ["planner"], "loadSkills": ["plan-writing", "brainstorming", "plan-validation"], "bindingType": "explicit" },
|
|
123
123
|
{ "workflow": "create", "loadAgents": [], "loadSkills": ["app-builder", "clean-code"], "bindingType": "inferred" },
|
|
124
124
|
{ "workflow": "enhance", "loadAgents": [], "loadSkills": ["clean-code", "testing-patterns"], "bindingType": "inferred" },
|
|
@@ -140,7 +140,7 @@
|
|
|
140
140
|
],
|
|
141
141
|
"planningMandates": {
|
|
142
142
|
"description": "Mandatory resources loaded for every /plan invocation regardless of keyword matching. Ensures cross-cutting concerns are never omitted.",
|
|
143
|
-
"alwaysLoadRules": ["security", "testing", "coding-style", "documentation"],
|
|
143
|
+
"alwaysLoadRules": ["security", "testing", "coding-style", "documentation", "architecture"],
|
|
144
144
|
"alwaysLoadSkills": ["security-practices", "testing-patterns"],
|
|
145
145
|
"crossCuttingSections": [
|
|
146
146
|
"security-considerations",
|
package/.agent/manifest.json
CHANGED
|
@@ -88,6 +88,19 @@
|
|
|
88
88
|
{ "name": "test", "file": "workflows/test.md" },
|
|
89
89
|
{ "name": "ui-ux-pro-max", "file": "workflows/ui-ux-pro-max.md" }
|
|
90
90
|
]
|
|
91
|
+
},
|
|
92
|
+
"rules": {
|
|
93
|
+
"count": 8,
|
|
94
|
+
"items": [
|
|
95
|
+
{ "name": "architecture", "file": "rules/architecture.md" },
|
|
96
|
+
{ "name": "coding-style", "file": "rules/coding-style.md" },
|
|
97
|
+
{ "name": "documentation", "file": "rules/documentation.md" },
|
|
98
|
+
{ "name": "git-workflow", "file": "rules/git-workflow.md" },
|
|
99
|
+
{ "name": "quality-gate", "file": "rules/quality-gate.md" },
|
|
100
|
+
{ "name": "security", "file": "rules/security.md" },
|
|
101
|
+
{ "name": "sprint-tracking", "file": "rules/sprint-tracking.md" },
|
|
102
|
+
{ "name": "testing", "file": "rules/testing.md" }
|
|
103
|
+
]
|
|
91
104
|
}
|
|
92
105
|
}
|
|
93
106
|
}
|
|
@@ -0,0 +1,111 @@
|
|
|
1
|
+
# Architecture Rules
|
|
2
|
+
|
|
3
|
+
> **Priority**: HIGH — Enforced in design reviews
|
|
4
|
+
> **Scope**: All workspaces — universal architectural constraints
|
|
5
|
+
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
## Architecture Principles
|
|
9
|
+
|
|
10
|
+
| Principle | Enforcement |
|
|
11
|
+
| :----------------------- | :------------------------------------------------------------ |
|
|
12
|
+
| Separation of Concerns | Each module has a single, well-defined responsibility |
|
|
13
|
+
| Dependency Direction | Dependencies ALWAYS point inward — domain never imports infra |
|
|
14
|
+
| Contract-First Design | Define API contracts before implementation begins |
|
|
15
|
+
| Explicit Over Implicit | Configuration, dependencies, and boundaries must be explicit |
|
|
16
|
+
| Composition Over Inherit | Prefer composition and dependency injection over inheritance |
|
|
17
|
+
|
|
18
|
+
---
|
|
19
|
+
|
|
20
|
+
## Boundary Enforcement
|
|
21
|
+
|
|
22
|
+
- **NEVER** import backend code from frontend or vice versa
|
|
23
|
+
- **NEVER** skip architectural layers — each layer imports only from the layer directly below
|
|
24
|
+
- **NEVER** hold direct object references across aggregate or module boundaries — use IDs
|
|
25
|
+
- Shared types and contracts are defined at the API boundary and replicated per consumer
|
|
26
|
+
- Cross-module communication uses events or explicit service interfaces, not direct coupling
|
|
27
|
+
|
|
28
|
+
---
|
|
29
|
+
|
|
30
|
+
## Project Structure
|
|
31
|
+
|
|
32
|
+
Projects should follow one of these organizational patterns:
|
|
33
|
+
|
|
34
|
+
| Pattern | When to Use |
|
|
35
|
+
| :--------------- | :------------------------------------------------------- |
|
|
36
|
+
| **Monorepo** | Multiple apps sharing code (Turborepo, Nx, Rush) |
|
|
37
|
+
| **Polyrepo** | Independent services with separate lifecycles |
|
|
38
|
+
| **Modular Mono** | Single deployable with clear bounded context separation |
|
|
39
|
+
|
|
40
|
+
> **Customization**: Project-specific structure decisions should be documented in `decisions/` as Architecture Decision Records (ADRs).
|
|
41
|
+
|
|
42
|
+
---
|
|
43
|
+
|
|
44
|
+
## Layered Architecture
|
|
45
|
+
|
|
46
|
+
```
|
|
47
|
+
Thin Routes / Controllers → Service Layer → Models / Data Access
|
|
48
|
+
↕
|
|
49
|
+
Domain Logic
|
|
50
|
+
```
|
|
51
|
+
|
|
52
|
+
| Layer | Responsibility | Rules |
|
|
53
|
+
| :--------------- | :---------------------------------------- | :------------------------------------------------- |
|
|
54
|
+
| Routes | HTTP handling, auth enforcement | MAX 10 lines per handler, delegate to services |
|
|
55
|
+
| Services | Business logic, validation, orchestration | Pure functions where possible, fully testable |
|
|
56
|
+
| Models / Data | Database schema, relationships | ORM-managed, migration-controlled |
|
|
57
|
+
| Schemas | Request/response contracts | Validated models, explicit field constraints |
|
|
58
|
+
|
|
59
|
+
---
|
|
60
|
+
|
|
61
|
+
## Database Conventions
|
|
62
|
+
|
|
63
|
+
- **Migrations** for ALL schema changes — no manual SQL in production
|
|
64
|
+
- Table names: `snake_case`, plural (`users`, `funnel_events`)
|
|
65
|
+
- Column names: `snake_case`
|
|
66
|
+
- Always include: `id` (UUID recommended), `created_at`, `updated_at`
|
|
67
|
+
- Foreign keys: `<entity>_id` naming convention
|
|
68
|
+
- Indexes: create for all foreign keys and frequent query columns
|
|
69
|
+
- Soft deletes preferred over hard deletes for audit-sensitive data
|
|
70
|
+
|
|
71
|
+
---
|
|
72
|
+
|
|
73
|
+
## API Design Principles
|
|
74
|
+
|
|
75
|
+
| Principle | Standard |
|
|
76
|
+
| :------------------- | :---------------------------------------------------------- |
|
|
77
|
+
| Versioning | URL-prefix (`/api/v1/`) or header-based — be consistent |
|
|
78
|
+
| Methods | Standard HTTP methods and status codes (RESTful) |
|
|
79
|
+
| Response Format | All endpoints return validated, structured JSON |
|
|
80
|
+
| Pagination | Offset-based (`skip`/`limit`) or cursor-based — documented |
|
|
81
|
+
| Error Format | `{ "detail": "Human-readable message" }` minimum |
|
|
82
|
+
| Rate Limiting | Documented per endpoint, enforced server-side |
|
|
83
|
+
|
|
84
|
+
---
|
|
85
|
+
|
|
86
|
+
## Architecture Decision Records
|
|
87
|
+
|
|
88
|
+
When making significant architectural decisions, document them using ADRs in the `decisions/` directory:
|
|
89
|
+
|
|
90
|
+
- Choosing between architectural approaches (monolith vs microservices)
|
|
91
|
+
- Selecting a technology (database, framework, library)
|
|
92
|
+
- Establishing a pattern (event sourcing vs CRUD)
|
|
93
|
+
- Making a trade-off (consistency vs availability)
|
|
94
|
+
|
|
95
|
+
ADR format: `decisions/adr-NNN-<decision-title>.md`
|
|
96
|
+
|
|
97
|
+
---
|
|
98
|
+
|
|
99
|
+
## Related Resources
|
|
100
|
+
|
|
101
|
+
- **Skill**: `.agent/skills/architecture/SKILL.md` — deep architectural patterns (DDD, Clean Architecture, 12-Factor, SOLID)
|
|
102
|
+
- **Agent**: `.agent/agents/architect.md` — architecture review process and checklists
|
|
103
|
+
|
|
104
|
+
---
|
|
105
|
+
|
|
106
|
+
## Version History
|
|
107
|
+
|
|
108
|
+
| Version | Date | Changes |
|
|
109
|
+
| :------ | :--------- | :----------------------------------------------------- |
|
|
110
|
+
| 1.0.0 | 2026-03-16 | Initial generic architecture enforcement rules for kit |
|
|
111
|
+
|
|
@@ -0,0 +1,117 @@
|
|
|
1
|
+
# Quality Gate Rules
|
|
2
|
+
|
|
3
|
+
> **Priority**: HIGH — Enforced before implementation of new features and refactors
|
|
4
|
+
> **Scope**: All workspaces — applies to `feat()` and `refactor()` tasks only
|
|
5
|
+
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
## Scope Filter
|
|
9
|
+
|
|
10
|
+
| Task Type | Quality Gate Required? |
|
|
11
|
+
| :-------------------------------- | :--------------------- |
|
|
12
|
+
| `feat()` — new features | ✅ Required |
|
|
13
|
+
| `refactor()` — structural changes | ✅ Required |
|
|
14
|
+
| `fix()` — bug fixes | ❌ Skip |
|
|
15
|
+
| `chore()` — maintenance | ❌ Skip |
|
|
16
|
+
| `docs()` — documentation | ❌ Skip |
|
|
17
|
+
| `test()` — test additions | ❌ Skip |
|
|
18
|
+
|
|
19
|
+
---
|
|
20
|
+
|
|
21
|
+
## Pre-Execution Research Checklist
|
|
22
|
+
|
|
23
|
+
Before implementing any in-scope task, **ALL** items must be completed. If any item is incomplete, execution is forbidden.
|
|
24
|
+
|
|
25
|
+
### ☐ 1. Market Research Completed
|
|
26
|
+
|
|
27
|
+
- Analyze **minimum 5** competitors or market leaders in the feature domain
|
|
28
|
+
- Document how each implements the same or similar feature
|
|
29
|
+
- Identify user adoption drivers: UX simplicity, accuracy, speed, transparency
|
|
30
|
+
|
|
31
|
+
### ☐ 2. Outdated Pattern Verification
|
|
32
|
+
|
|
33
|
+
- Verify the proposed approach does not use deprecated, abandoned, or criticized patterns
|
|
34
|
+
- If outdated → propose a modern, evidence-based alternative (mandatory)
|
|
35
|
+
- Document which patterns are considered harmful or legacy
|
|
36
|
+
|
|
37
|
+
### ☐ 3. Baseline Parity Validation
|
|
38
|
+
|
|
39
|
+
- Confirm the project **meets or exceeds** the current market baseline
|
|
40
|
+
- Gaps must be explicitly listed with severity assessment
|
|
41
|
+
- No gap left unaddressed without documented justification
|
|
42
|
+
|
|
43
|
+
### ☐ 4. Enhancement Definition
|
|
44
|
+
|
|
45
|
+
- Define exactly how the project **improves upon** the market baseline
|
|
46
|
+
- Improvement must be intentional and documented
|
|
47
|
+
- Consider: transparency, ethical automation, user-centricity, measurable outcomes
|
|
48
|
+
|
|
49
|
+
### ☐ 5. Ethics & Automation Risk Assessment
|
|
50
|
+
|
|
51
|
+
- Evaluate: privacy implications, AI bias risks, automation safety, user autonomy
|
|
52
|
+
- Mitigation strategies must be documented for each identified risk
|
|
53
|
+
- Data protection compliance must be considered for data-touching features
|
|
54
|
+
|
|
55
|
+
### ☐ 6. Implementation Plan Prepared
|
|
56
|
+
|
|
57
|
+
- Structured plan ready before execution begins
|
|
58
|
+
- Plan includes research summary, key insights, risks, execution steps
|
|
59
|
+
- Plan reviewed and approved before implementation may begin
|
|
60
|
+
|
|
61
|
+
---
|
|
62
|
+
|
|
63
|
+
## Enhancement Principle
|
|
64
|
+
|
|
65
|
+
| Scenario | Required Action |
|
|
66
|
+
| :------------------------------------------ | :------------------------------- |
|
|
67
|
+
| Competitors offer a standard | **Meet or exceed** it |
|
|
68
|
+
| Competitors use unethical automation | **Reject and improve** |
|
|
69
|
+
| Feature can be more transparent | **Enhance by default** |
|
|
70
|
+
| Feature can be more user-centric | **Enhance by default** |
|
|
71
|
+
| Feature can offer measurable outcomes | **Enhance by default** |
|
|
72
|
+
|
|
73
|
+
**Never replicate patterns without improvement.**
|
|
74
|
+
|
|
75
|
+
---
|
|
76
|
+
|
|
77
|
+
## Cross-Cutting Deference
|
|
78
|
+
|
|
79
|
+
Quality gate enforcement defers to specialized rules for domain-specific checks:
|
|
80
|
+
|
|
81
|
+
- **Security**: See `rules/security.md` for input validation, auth, data protection
|
|
82
|
+
- **Testing**: See `rules/testing.md` for coverage requirements, test types
|
|
83
|
+
- **Code Quality**: See `rules/coding-style.md` for naming, file limits, immutability
|
|
84
|
+
- **Documentation**: See `rules/documentation.md` for doc hierarchy, SSOT
|
|
85
|
+
|
|
86
|
+
---
|
|
87
|
+
|
|
88
|
+
## Reject & Escalate Rules
|
|
89
|
+
|
|
90
|
+
| Condition | Action |
|
|
91
|
+
| :------------------------------------------ | :------------------------------------- |
|
|
92
|
+
| No market research provided | ❌ Reject — enforce research protocol |
|
|
93
|
+
| Clearly outdated or harmful patterns | ❌ Reject — propose modern alternative |
|
|
94
|
+
| Below-market standard solutions | ❌ Reject — document gap |
|
|
95
|
+
| Ethics, privacy, or automation safety risks | ❌ Reject — document mitigation |
|
|
96
|
+
| Bypassing research ("just implement it") | ❌ Reject — enforce protocol |
|
|
97
|
+
|
|
98
|
+
### Escalation Response
|
|
99
|
+
|
|
100
|
+
> "This task cannot proceed in its current form, as it does not meet quality and market standards. Below are the identified risks and gaps. A revised, modern alternative is proposed."
|
|
101
|
+
|
|
102
|
+
---
|
|
103
|
+
|
|
104
|
+
## Related Resources
|
|
105
|
+
|
|
106
|
+
- **Workflow**: `.agent/workflows/quality-gate.md` — step-by-step research procedure
|
|
107
|
+
- **Skill**: `.agent/skills/brainstorming/SKILL.md` — Socratic questioning patterns
|
|
108
|
+
- **Next Step**: After approval, proceed to `/plan` for implementation planning
|
|
109
|
+
|
|
110
|
+
---
|
|
111
|
+
|
|
112
|
+
## Version History
|
|
113
|
+
|
|
114
|
+
| Version | Date | Changes |
|
|
115
|
+
| :------ | :--------- | :------------------------------------------------ |
|
|
116
|
+
| 1.0.0 | 2026-03-16 | Initial generic quality gate protocol for kit |
|
|
117
|
+
|
|
@@ -190,6 +190,7 @@ If any of these conditions are met, **REJECT** the task:
|
|
|
190
190
|
|
|
191
191
|
## Related Resources
|
|
192
192
|
|
|
193
|
+
- **Rule**: `.agent/rules/quality-gate.md` (enforcement principles for this workflow)
|
|
193
194
|
- **Previous**: `/brainstorm` (explore options before validation)
|
|
194
195
|
- **Next**: `/plan` (implementation planning after approval)
|
|
195
196
|
- **Related**: `/retrospective` (post-sprint audit applies similar rigor)
|
package/lib/verify.js
CHANGED
|
@@ -189,6 +189,32 @@ function runAllChecks(projectRoot) {
|
|
|
189
189
|
results.push(checkJsonFile(path.join(agentDir, ENGINE_DIR, engineFile), `engine:${engineFile}`));
|
|
190
190
|
}
|
|
191
191
|
|
|
192
|
+
// --- Check 10a: Rule files exist ---
|
|
193
|
+
const manifestRules = manifest.capabilities?.rules?.items || [];
|
|
194
|
+
for (const rule of manifestRules) {
|
|
195
|
+
const rulePath = path.join(agentDir, rule.file);
|
|
196
|
+
const exists = fs.existsSync(rulePath);
|
|
197
|
+
results.push({
|
|
198
|
+
name: `rule-file:${rule.name}`,
|
|
199
|
+
status: exists ? 'pass' : 'fail',
|
|
200
|
+
message: exists ? `Rule exists: ${rule.name}` : `Missing rule file: ${rule.file}`,
|
|
201
|
+
});
|
|
202
|
+
}
|
|
203
|
+
|
|
204
|
+
// --- Check 10b: Rule count matches ---
|
|
205
|
+
const ruleCountManifest = manifest.capabilities?.rules?.count || 0;
|
|
206
|
+
const ruleCountFS = fs.existsSync(path.join(agentDir, 'rules'))
|
|
207
|
+
? fs.readdirSync(path.join(agentDir, 'rules')).filter((f) => f.endsWith('.md') && f !== 'README.md').length
|
|
208
|
+
: 0;
|
|
209
|
+
results.push({
|
|
210
|
+
name: 'rule-count',
|
|
211
|
+
status: ruleCountManifest === ruleCountFS ? 'pass' : 'fail',
|
|
212
|
+
message:
|
|
213
|
+
ruleCountManifest === ruleCountFS
|
|
214
|
+
? `Rule count matches: ${ruleCountFS}`
|
|
215
|
+
: `Rule count mismatch: manifest=${ruleCountManifest}, filesystem=${ruleCountFS}`,
|
|
216
|
+
});
|
|
217
|
+
|
|
192
218
|
// --- Check 11: Hooks file valid ---
|
|
193
219
|
results.push(checkJsonFile(path.join(agentDir, HOOKS_DIR, 'hooks.json'), 'hooks-json'));
|
|
194
220
|
|
|
@@ -212,6 +238,19 @@ function runAllChecks(projectRoot) {
|
|
|
212
238
|
});
|
|
213
239
|
}
|
|
214
240
|
}
|
|
241
|
+
// --- Check 13: Cross-reference — alwaysLoadRules files exist ---
|
|
242
|
+
const mandatoryRules = loadingRules.planningMandates?.alwaysLoadRules || [];
|
|
243
|
+
for (const ruleName of mandatoryRules) {
|
|
244
|
+
const rulePath = path.join(agentDir, 'rules', `${ruleName}.md`);
|
|
245
|
+
const ruleExists = fs.existsSync(rulePath);
|
|
246
|
+
results.push({
|
|
247
|
+
name: `xref:mandatory-rule:${ruleName}`,
|
|
248
|
+
status: ruleExists ? 'pass' : 'fail',
|
|
249
|
+
message: ruleExists
|
|
250
|
+
? `Mandatory rule "${ruleName}" exists`
|
|
251
|
+
: `Mandatory rule "${ruleName}" referenced in alwaysLoadRules but file missing: rules/${ruleName}.md`,
|
|
252
|
+
});
|
|
253
|
+
}
|
|
215
254
|
} catch {
|
|
216
255
|
results.push({ name: 'xref:loading-rules', status: 'warn', message: 'Could not parse loading-rules.json for cross-reference check' });
|
|
217
256
|
}
|
package/package.json
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "antigravity-ai-kit",
|
|
3
|
-
"version": "3.
|
|
4
|
-
"description": "🚀 Trust-Grade AI development framework with a 29-module runtime engine — 19 Agents, 32 Skills, 31 Commands, 14 Workflows,
|
|
3
|
+
"version": "3.4.0",
|
|
4
|
+
"description": "🚀 Trust-Grade AI development framework with a 29-module runtime engine — 19 Agents, 32 Skills, 31 Commands, 14 Workflows, 8 Rules, 330 Tests. Workflow enforcement, task governance, agent reputation, self-healing, and skill marketplace.",
|
|
5
5
|
"main": "bin/ag-kit.js",
|
|
6
6
|
"bin": {
|
|
7
7
|
"ag-kit": "./bin/ag-kit.js"
|