astragentic 1.0.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 +52 -0
- package/assets/_astraler/engine.md +307 -0
- package/assets/_astraler/workflows/brownfield.md +582 -0
- package/assets/_astraler/workflows/change.md +210 -0
- package/assets/_astraler/workflows/greenfield.md +415 -0
- package/assets/claude-code/CLAUDE-TEMPLATE.md +185 -0
- package/assets/claude-code/commands/astra/arch.md +311 -0
- package/assets/claude-code/commands/astra/build.md +109 -0
- package/assets/claude-code/commands/astra/change.md +175 -0
- package/assets/claude-code/commands/astra/help.md +240 -0
- package/assets/claude-code/commands/astra/plan.md +171 -0
- package/assets/claude-code/commands/astra/spec.md +200 -0
- package/assets/claude-code/commands/astra/start.md +86 -0
- package/assets/claude-code/commands/astra/status.md +135 -0
- package/assets/claude-code/commands/astra/verify.md +139 -0
- package/bin/cli.js +82 -0
- package/package.json +14 -0
|
@@ -0,0 +1,185 @@
|
|
|
1
|
+
# CLAUDE.md
|
|
2
|
+
|
|
3
|
+
This file provides guidance to Claude Code when working with this repository.
|
|
4
|
+
|
|
5
|
+
## Project Overview
|
|
6
|
+
|
|
7
|
+
**Project Name:** [CUSTOMIZE: Your project name]
|
|
8
|
+
|
|
9
|
+
**Description:** [CUSTOMIZE: Brief project description]
|
|
10
|
+
|
|
11
|
+
---
|
|
12
|
+
|
|
13
|
+
## Framework Architecture
|
|
14
|
+
|
|
15
|
+
Astragentic operates through three interconnected roots:
|
|
16
|
+
|
|
17
|
+
| Root | Location | Purpose |
|
|
18
|
+
|------|----------|---------|
|
|
19
|
+
| **Artifacts** | `.astraler-docs/` | Source of truth for all design documents |
|
|
20
|
+
| **Commands** | `.claude/commands/astra/` | AI command definitions (slash commands) |
|
|
21
|
+
| **Engine** | `_astraler/` | Execution rules, workflows, and governance |
|
|
22
|
+
|
|
23
|
+
```
|
|
24
|
+
your-project/
|
|
25
|
+
├── .astraler-docs/ # What we're building (artifacts)
|
|
26
|
+
│ ├── 01-context/ # Vision, constraints, glossary
|
|
27
|
+
│ ├── 02-spec/ # Business requirements by domain
|
|
28
|
+
│ ├── 03-arch/ # Technical architecture by domain
|
|
29
|
+
│ ├── 04-tasks/ # Implementation breakdown
|
|
30
|
+
│ ├── 05-changes/ # Change records (CHG)
|
|
31
|
+
│ └── ai/ # Rules, guardrails, quality gates
|
|
32
|
+
│
|
|
33
|
+
├── .claude/ # AI operating system
|
|
34
|
+
│ └── commands/astra/ # Slash command definitions
|
|
35
|
+
│
|
|
36
|
+
└── _astraler/ # Framework engine
|
|
37
|
+
├── engine.md # Core execution rules
|
|
38
|
+
└── workflows/ # greenfield, brownfield, change
|
|
39
|
+
```
|
|
40
|
+
|
|
41
|
+
---
|
|
42
|
+
|
|
43
|
+
## Project Documentation
|
|
44
|
+
|
|
45
|
+
All project documentation lives in `.astraler-docs/`. Read these before making changes:
|
|
46
|
+
|
|
47
|
+
### Context & Vision
|
|
48
|
+
- [Product Vision](.astraler-docs/01-context/product.md) - North star, priorities, anti-goals
|
|
49
|
+
- [Constraints](.astraler-docs/01-context/constraints.md) - Technical & business boundaries
|
|
50
|
+
- [Assumptions](.astraler-docs/01-context/assumptions.md) - Validatable assumptions
|
|
51
|
+
- [Glossary](.astraler-docs/01-context/glossary.md) - Domain terminology
|
|
52
|
+
|
|
53
|
+
### Technical Reference
|
|
54
|
+
- [Tech Stack](.astraler-docs/03-arch/overview.md) - Technology choices, infrastructure
|
|
55
|
+
- [Data Schema](.astraler-docs/03-arch/data-schema.md) - Database structure, relationships
|
|
56
|
+
- [Engineering Standards](.astraler-docs/03-arch/standards.md) - DoD, code standards, testing
|
|
57
|
+
- [Architecture Decisions](.astraler-docs/03-arch/decisions.md) - ADRs
|
|
58
|
+
|
|
59
|
+
### Business Requirements
|
|
60
|
+
- [System Overview](.astraler-docs/02-spec/core/overview.md) - Actors, scope, boundaries
|
|
61
|
+
- [Business Flows](.astraler-docs/02-spec/core/flows.md) - Cross-domain processes
|
|
62
|
+
- [Business Rules](.astraler-docs/02-spec/core/rules.md) - Global constraints
|
|
63
|
+
|
|
64
|
+
### Implementation
|
|
65
|
+
- [Milestones](.astraler-docs/04-tasks/milestones.md) - Epic-level goals
|
|
66
|
+
- [Changelog](.astraler-docs/05-changes/changelog.md) - Change history
|
|
67
|
+
|
|
68
|
+
### AI Governance
|
|
69
|
+
- [Guardrails](.astraler-docs/ai/guardrails.md) - AI agent constraints
|
|
70
|
+
- [Rules](.astraler-docs/ai/rules.md) - Development rules
|
|
71
|
+
- [Quality Gates](.astraler-docs/ai/quality_gates.md) - Test taxonomy, gates
|
|
72
|
+
|
|
73
|
+
---
|
|
74
|
+
|
|
75
|
+
## Astra Commands
|
|
76
|
+
|
|
77
|
+
### Discovery & Status
|
|
78
|
+
|
|
79
|
+
| Command | Purpose |
|
|
80
|
+
|---------|---------|
|
|
81
|
+
| `/astra:start` | Bootstrap project or scan existing codebase |
|
|
82
|
+
| `/astra:status` | Show current project state and suggest next action |
|
|
83
|
+
| `/astra:help` | List available commands and workflow guidance |
|
|
84
|
+
|
|
85
|
+
### Design Phase
|
|
86
|
+
|
|
87
|
+
| Command | Purpose |
|
|
88
|
+
|---------|---------|
|
|
89
|
+
| `/astra:spec <domain>` | Create/update domain specification |
|
|
90
|
+
| `/astra:arch <domain>` | Create/update domain architecture |
|
|
91
|
+
| `/astra:plan <domain>` | Generate implementation tasks |
|
|
92
|
+
|
|
93
|
+
### Build Phase
|
|
94
|
+
|
|
95
|
+
| Command | Purpose |
|
|
96
|
+
|---------|---------|
|
|
97
|
+
| `/astra:build <task> [--auto]` | Implement tasks with code + tests |
|
|
98
|
+
| `/astra:verify` | Check documentation consistency |
|
|
99
|
+
|
|
100
|
+
### Governance
|
|
101
|
+
|
|
102
|
+
| Command | Purpose |
|
|
103
|
+
|---------|---------|
|
|
104
|
+
| `/astra:change <title>` | Manage changes to approved docs |
|
|
105
|
+
|
|
106
|
+
---
|
|
107
|
+
|
|
108
|
+
## Development Rules
|
|
109
|
+
|
|
110
|
+
### Before Coding
|
|
111
|
+
1. Read the relevant [domain spec](.astraler-docs/02-spec/domains/) for business requirements
|
|
112
|
+
2. Read the relevant [domain arch](.astraler-docs/03-arch/domains/) for technical design
|
|
113
|
+
3. Check [engineering standards](.astraler-docs/03-arch/standards.md) for DoD
|
|
114
|
+
|
|
115
|
+
### Code Standards
|
|
116
|
+
[CUSTOMIZE: Add your coding conventions]
|
|
117
|
+
|
|
118
|
+
- Follow naming conventions in [standards](.astraler-docs/03-arch/standards.md)
|
|
119
|
+
- Match existing patterns in the codebase
|
|
120
|
+
- [CUSTOMIZE: Additional rules]
|
|
121
|
+
|
|
122
|
+
### Testing Requirements
|
|
123
|
+
[CUSTOMIZE: Add your testing rules]
|
|
124
|
+
|
|
125
|
+
- See [quality gates](.astraler-docs/ai/quality_gates.md) for test taxonomy
|
|
126
|
+
- [CUSTOMIZE: Coverage requirements]
|
|
127
|
+
- [CUSTOMIZE: Test naming conventions]
|
|
128
|
+
|
|
129
|
+
### Forbidden Patterns
|
|
130
|
+
[CUSTOMIZE: Add patterns to avoid]
|
|
131
|
+
|
|
132
|
+
- Never edit `Approved` docs without a CHG record
|
|
133
|
+
- [CUSTOMIZE: Security anti-patterns]
|
|
134
|
+
- [CUSTOMIZE: Architecture violations]
|
|
135
|
+
|
|
136
|
+
---
|
|
137
|
+
|
|
138
|
+
## Common Commands
|
|
139
|
+
|
|
140
|
+
[CUSTOMIZE: Add your build/test/run commands]
|
|
141
|
+
|
|
142
|
+
```bash
|
|
143
|
+
# Install dependencies
|
|
144
|
+
[CUSTOMIZE]
|
|
145
|
+
|
|
146
|
+
# Run tests
|
|
147
|
+
[CUSTOMIZE]
|
|
148
|
+
|
|
149
|
+
# Build
|
|
150
|
+
[CUSTOMIZE]
|
|
151
|
+
|
|
152
|
+
# Start development server
|
|
153
|
+
[CUSTOMIZE]
|
|
154
|
+
```
|
|
155
|
+
|
|
156
|
+
---
|
|
157
|
+
|
|
158
|
+
## Change Management
|
|
159
|
+
|
|
160
|
+
When requirements change:
|
|
161
|
+
1. Run `/astra:change "<title>"` to create a change record
|
|
162
|
+
2. Wait for impact analysis and human approval
|
|
163
|
+
3. Changes are applied to docs and tasks automatically
|
|
164
|
+
4. Run `/astra:verify` to confirm consistency
|
|
165
|
+
|
|
166
|
+
See [changelog](.astraler-docs/05-changes/changelog.md) for recent changes.
|
|
167
|
+
|
|
168
|
+
---
|
|
169
|
+
|
|
170
|
+
## Domain Quick Links
|
|
171
|
+
|
|
172
|
+
[CUSTOMIZE: Add your domains after running /astra:spec]
|
|
173
|
+
|
|
174
|
+
| Domain | Spec | Arch | Tasks |
|
|
175
|
+
|--------|------|------|-------|
|
|
176
|
+
| [DOMAIN] | [spec](.astraler-docs/02-spec/domains/[DOMAIN].md) | [arch](.astraler-docs/03-arch/domains/[DOMAIN].arch.md) | [tasks](.astraler-docs/04-tasks/domains/[DOMAIN].tasks.md) |
|
|
177
|
+
|
|
178
|
+
---
|
|
179
|
+
|
|
180
|
+
## Navigation
|
|
181
|
+
|
|
182
|
+
- **New to project?** Start with [Product Vision](.astraler-docs/01-context/product.md)
|
|
183
|
+
- **Understanding the system?** See [System Overview](.astraler-docs/02-spec/core/overview.md)
|
|
184
|
+
- **Technical questions?** Check [Tech Stack](.astraler-docs/03-arch/overview.md) and [Data Schema](.astraler-docs/03-arch/data-schema.md)
|
|
185
|
+
- **Need to implement?** See [Milestones](.astraler-docs/04-tasks/milestones.md)
|
|
@@ -0,0 +1,311 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: "Create or update domain architecture"
|
|
3
|
+
argument-hint: "<domain>"
|
|
4
|
+
allowed-tools: ["Read", "Write", "Edit", "Glob"]
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
Creates or updates technical architecture for a domain.
|
|
8
|
+
|
|
9
|
+
## Activation
|
|
10
|
+
|
|
11
|
+
1. LOAD engine rules from `@_astraler/engine.md`
|
|
12
|
+
2. Parse domain name from arguments
|
|
13
|
+
3. Check prerequisites
|
|
14
|
+
4. Create or update arch
|
|
15
|
+
|
|
16
|
+
## Prerequisites
|
|
17
|
+
|
|
18
|
+
- `.astraler-docs/02-spec/domains/{domain}.md` exists (Draft or Approved)
|
|
19
|
+
- Spec has defined flows and rules
|
|
20
|
+
|
|
21
|
+
## Reads
|
|
22
|
+
|
|
23
|
+
- `.astraler-docs/02-spec/domains/{domain}.md` (requirements to implement)
|
|
24
|
+
- `.astraler-docs/03-arch/domains/{domain}.arch.md` (if updating)
|
|
25
|
+
- `.astraler-docs/03-arch/overview.md` (system architecture, tech stack)
|
|
26
|
+
- `.astraler-docs/03-arch/data-schema.md` (global database schema)
|
|
27
|
+
- `.astraler-docs/03-arch/decisions.md` (existing ADRs)
|
|
28
|
+
- `.astraler-docs/03-arch/standards.md` (engineering standards)
|
|
29
|
+
|
|
30
|
+
## Writes
|
|
31
|
+
|
|
32
|
+
- `.astraler-docs/03-arch/domains/{domain}.arch.md`
|
|
33
|
+
- `.astraler-docs/03-arch/data-schema.md` (if new entities added)
|
|
34
|
+
- `.astraler-docs/03-arch/decisions.md` (if ADR needed)
|
|
35
|
+
|
|
36
|
+
## Mermaid Diagram Requirements
|
|
37
|
+
|
|
38
|
+
Every arch doc MUST include these diagrams:
|
|
39
|
+
|
|
40
|
+
| Diagram Type | Section | Purpose |
|
|
41
|
+
|--------------|---------|---------|
|
|
42
|
+
| `flowchart` | Overview | Show component relationships |
|
|
43
|
+
| `classDiagram` | Components | Show class/service structure |
|
|
44
|
+
| `sequenceDiagram` | Contracts | Show API request/response flows |
|
|
45
|
+
| `erDiagram` | Data Models | Show database schema |
|
|
46
|
+
| `stateDiagram-v2` | State Machine | Show entity lifecycle (if applicable) |
|
|
47
|
+
|
|
48
|
+
**Optional but recommended:**
|
|
49
|
+
- `flowchart` for dependency graphs
|
|
50
|
+
- `sequenceDiagram` for integration flows
|
|
51
|
+
|
|
52
|
+
## Arch Structure
|
|
53
|
+
|
|
54
|
+
```markdown
|
|
55
|
+
---
|
|
56
|
+
doc: {domain}-arch
|
|
57
|
+
domain: {domain}
|
|
58
|
+
status: Draft
|
|
59
|
+
owner: astra-arch
|
|
60
|
+
version: v1.0
|
|
61
|
+
change-id: CHG-INIT
|
|
62
|
+
last-updated: {YYYY-MM-DD}
|
|
63
|
+
spec-ref: 02-spec/domains/{domain}.md
|
|
64
|
+
---
|
|
65
|
+
|
|
66
|
+
# {Domain} Architecture
|
|
67
|
+
|
|
68
|
+
## Overview
|
|
69
|
+
|
|
70
|
+
```mermaid
|
|
71
|
+
flowchart TB
|
|
72
|
+
subgraph Domain
|
|
73
|
+
CTRL[Controller]
|
|
74
|
+
SVC[Service]
|
|
75
|
+
REPO[Repository]
|
|
76
|
+
end
|
|
77
|
+
|
|
78
|
+
subgraph External
|
|
79
|
+
DB[(Database)]
|
|
80
|
+
EXT[External Service]
|
|
81
|
+
end
|
|
82
|
+
|
|
83
|
+
CTRL --> SVC --> REPO --> DB
|
|
84
|
+
SVC --> EXT
|
|
85
|
+
```
|
|
86
|
+
|
|
87
|
+
{High-level technical approach description}
|
|
88
|
+
|
|
89
|
+
## Components
|
|
90
|
+
|
|
91
|
+
```mermaid
|
|
92
|
+
classDiagram
|
|
93
|
+
class Service {
|
|
94
|
+
-repository: Repository
|
|
95
|
+
+method(dto): Result
|
|
96
|
+
}
|
|
97
|
+
class Repository {
|
|
98
|
+
+create(entity): Entity
|
|
99
|
+
+findById(id): Entity
|
|
100
|
+
}
|
|
101
|
+
Service --> Repository
|
|
102
|
+
```
|
|
103
|
+
|
|
104
|
+
### {Component Name}
|
|
105
|
+
|
|
106
|
+
| Attribute | Value |
|
|
107
|
+
|-----------|-------|
|
|
108
|
+
| **Purpose** | {what it does} |
|
|
109
|
+
| **Technology** | {stack/framework} |
|
|
110
|
+
| **Location** | `src/{domain}/{component}.ts` |
|
|
111
|
+
|
|
112
|
+
**Responsibilities:**
|
|
113
|
+
- Responsibility 1
|
|
114
|
+
- Responsibility 2
|
|
115
|
+
|
|
116
|
+
**Dependencies:**
|
|
117
|
+
- {dependency} ({type})
|
|
118
|
+
|
|
119
|
+
## Contracts
|
|
120
|
+
|
|
121
|
+
### {Endpoint}: {METHOD} /api/v1/{path}
|
|
122
|
+
|
|
123
|
+
```mermaid
|
|
124
|
+
sequenceDiagram
|
|
125
|
+
Client->>API: {METHOD} /api/v1/{path}
|
|
126
|
+
API->>Service: method(dto)
|
|
127
|
+
Service->>DB: query
|
|
128
|
+
DB-->>Service: result
|
|
129
|
+
Service-->>API: response
|
|
130
|
+
API-->>Client: {status} {body}
|
|
131
|
+
```
|
|
132
|
+
|
|
133
|
+
**Request:**
|
|
134
|
+
```typescript
|
|
135
|
+
interface RequestDto {
|
|
136
|
+
field: type;
|
|
137
|
+
}
|
|
138
|
+
```
|
|
139
|
+
|
|
140
|
+
**Response ({status}):**
|
|
141
|
+
```typescript
|
|
142
|
+
interface ResponseDto {
|
|
143
|
+
field: type;
|
|
144
|
+
}
|
|
145
|
+
```
|
|
146
|
+
|
|
147
|
+
**Errors:**
|
|
148
|
+
| Code | Condition |
|
|
149
|
+
|------|-----------|
|
|
150
|
+
| 400 | {condition} |
|
|
151
|
+
| 404 | {condition} |
|
|
152
|
+
|
|
153
|
+
## Data Models
|
|
154
|
+
|
|
155
|
+
```mermaid
|
|
156
|
+
erDiagram
|
|
157
|
+
ENTITY_NAME ||--o{ RELATED_ENTITY : contains
|
|
158
|
+
ENTITY_NAME {
|
|
159
|
+
uuid id PK
|
|
160
|
+
string field
|
|
161
|
+
timestamp created_at
|
|
162
|
+
}
|
|
163
|
+
RELATED_ENTITY {
|
|
164
|
+
uuid id PK
|
|
165
|
+
uuid entity_id FK
|
|
166
|
+
string data
|
|
167
|
+
}
|
|
168
|
+
```
|
|
169
|
+
|
|
170
|
+
> Replace `ENTITY_NAME`, `RELATED_ENTITY` with actual table names.
|
|
171
|
+
|
|
172
|
+
### Indexes
|
|
173
|
+
```sql
|
|
174
|
+
CREATE INDEX idx_{table}_{field} ON {table}({field});
|
|
175
|
+
```
|
|
176
|
+
|
|
177
|
+
## State Machine
|
|
178
|
+
|
|
179
|
+
```mermaid
|
|
180
|
+
stateDiagram-v2
|
|
181
|
+
[*] --> STATE1: create
|
|
182
|
+
STATE1 --> STATE2: action
|
|
183
|
+
STATE2 --> [*]: complete
|
|
184
|
+
```
|
|
185
|
+
|
|
186
|
+
| From | To | Trigger | Guard |
|
|
187
|
+
|------|-----|---------|-------|
|
|
188
|
+
| STATE1 | STATE2 | {trigger} | {condition} |
|
|
189
|
+
|
|
190
|
+
## Dependencies
|
|
191
|
+
|
|
192
|
+
### Internal
|
|
193
|
+
| Domain | Type | Purpose |
|
|
194
|
+
|--------|------|---------|
|
|
195
|
+
| {domain} | sync/async | {purpose} |
|
|
196
|
+
|
|
197
|
+
### External
|
|
198
|
+
| Service | Purpose | Fallback |
|
|
199
|
+
|---------|---------|----------|
|
|
200
|
+
| {service} | {purpose} | {fallback} |
|
|
201
|
+
|
|
202
|
+
## Decisions
|
|
203
|
+
- [ADR-{date}-{topic}](../decisions.md#{anchor}): {summary}
|
|
204
|
+
```
|
|
205
|
+
|
|
206
|
+
## ADR Trigger
|
|
207
|
+
|
|
208
|
+
If making a significant technical choice:
|
|
209
|
+
1. Document in `03-arch/decisions.md`
|
|
210
|
+
2. Reference from domain arch
|
|
211
|
+
|
|
212
|
+
ADR format in decisions.md:
|
|
213
|
+
```markdown
|
|
214
|
+
## ADR-{YYYY-MM-DD}-{topic}
|
|
215
|
+
|
|
216
|
+
**Status:** Accepted
|
|
217
|
+
**Domain:** {domain}
|
|
218
|
+
**Date:** {YYYY-MM-DD}
|
|
219
|
+
|
|
220
|
+
### Context
|
|
221
|
+
Why decision was needed
|
|
222
|
+
|
|
223
|
+
### Decision
|
|
224
|
+
What we chose
|
|
225
|
+
|
|
226
|
+
```mermaid
|
|
227
|
+
flowchart TD
|
|
228
|
+
A[Option A] --> B{Decision}
|
|
229
|
+
C[Option B] --> B
|
|
230
|
+
B --> D[Chosen: Option A]
|
|
231
|
+
```
|
|
232
|
+
|
|
233
|
+
### Consequences
|
|
234
|
+
**Positive:** Benefits
|
|
235
|
+
**Negative:** Trade-offs
|
|
236
|
+
|
|
237
|
+
### Alternatives Considered
|
|
238
|
+
| Alternative | Why Rejected |
|
|
239
|
+
|-------------|--------------|
|
|
240
|
+
| Option B | {reason} |
|
|
241
|
+
```
|
|
242
|
+
|
|
243
|
+
## Execution Pattern (Checkpoints)
|
|
244
|
+
|
|
245
|
+
Generate architecture in sections with save-after-each pattern:
|
|
246
|
+
|
|
247
|
+
```
|
|
248
|
+
1. Generate Overview (with flowchart)
|
|
249
|
+
→ Save to file
|
|
250
|
+
→ Present diagram for review
|
|
251
|
+
→ Confirm: [c] Continue | [e] Edit | [q] Quit
|
|
252
|
+
|
|
253
|
+
2. Generate Components (with classDiagram)
|
|
254
|
+
→ Save to file
|
|
255
|
+
→ Present diagram for review
|
|
256
|
+
→ Confirm: [c] Continue | [e] Edit
|
|
257
|
+
|
|
258
|
+
3. Generate Contracts (with sequenceDiagram per endpoint)
|
|
259
|
+
→ Save to file
|
|
260
|
+
→ Present each diagram for review
|
|
261
|
+
→ Confirm: [c] Continue | [e] Edit
|
|
262
|
+
|
|
263
|
+
4. Generate Data Models (with erDiagram)
|
|
264
|
+
→ Save to file
|
|
265
|
+
→ Present diagram for review
|
|
266
|
+
→ Update global data-schema.md if new entities
|
|
267
|
+
→ Confirm: [c] Continue | [e] Edit
|
|
268
|
+
|
|
269
|
+
5. Generate State Machine (with stateDiagram-v2)
|
|
270
|
+
→ Save to file
|
|
271
|
+
→ Present diagram for review
|
|
272
|
+
→ Confirm: [c] Continue | [e] Edit
|
|
273
|
+
|
|
274
|
+
6. Generate Dependencies + ADR refs
|
|
275
|
+
→ Save to file
|
|
276
|
+
→ Present complete arch for final review
|
|
277
|
+
```
|
|
278
|
+
|
|
279
|
+
This prevents losing work and enables iterative refinement.
|
|
280
|
+
|
|
281
|
+
## Interactive Diagram Review
|
|
282
|
+
|
|
283
|
+
After generating each required Mermaid diagram, present for validation:
|
|
284
|
+
|
|
285
|
+
```markdown
|
|
286
|
+
## Component Diagram: {Domain} Architecture
|
|
287
|
+
|
|
288
|
+
```mermaid
|
|
289
|
+
flowchart TB
|
|
290
|
+
subgraph Domain
|
|
291
|
+
CTRL[Controller]
|
|
292
|
+
SVC[Service]
|
|
293
|
+
REPO[Repository]
|
|
294
|
+
end
|
|
295
|
+
CTRL --> SVC --> REPO
|
|
296
|
+
```
|
|
297
|
+
|
|
298
|
+
**Does this accurately represent the architecture?**
|
|
299
|
+
[y] Yes, continue | [e] Edit this diagram | [s] Skip (will flag in verify)
|
|
300
|
+
```
|
|
301
|
+
|
|
302
|
+
Repeat for each diagram type:
|
|
303
|
+
- `flowchart` for component overview
|
|
304
|
+
- `classDiagram` for service structure
|
|
305
|
+
- `sequenceDiagram` for API contracts
|
|
306
|
+
- `erDiagram` for data models
|
|
307
|
+
- `stateDiagram-v2` for entity lifecycle
|
|
308
|
+
|
|
309
|
+
## Output
|
|
310
|
+
|
|
311
|
+
Confirm arch created/updated with component summary and diagrams included.
|
|
@@ -0,0 +1,109 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: "Implement tasks: code, test, verify"
|
|
3
|
+
argument-hint: "<TSK-ID|domain|--all> [--auto]"
|
|
4
|
+
allowed-tools: ["Read", "Write", "Edit", "Glob", "Grep", "Bash"]
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
Implements one or more tasks with code and tests.
|
|
8
|
+
|
|
9
|
+
## Activation
|
|
10
|
+
|
|
11
|
+
1. LOAD engine rules from `@_astraler/engine.md`
|
|
12
|
+
2. Parse input (task ID, domain, or --all)
|
|
13
|
+
3. Check for `--auto` flag
|
|
14
|
+
4. Select and validate tasks
|
|
15
|
+
5. Implement each task
|
|
16
|
+
|
|
17
|
+
## Input Modes
|
|
18
|
+
|
|
19
|
+
| Input | Behavior |
|
|
20
|
+
|-------|----------|
|
|
21
|
+
| `TSK-order-001` | Single task |
|
|
22
|
+
| `order` | All TODO tasks in domain |
|
|
23
|
+
| `--all` | All TODO tasks across domains |
|
|
24
|
+
| `--auto` | Skip human confirmation gates |
|
|
25
|
+
|
|
26
|
+
## Execution Modes
|
|
27
|
+
|
|
28
|
+
### Interactive Mode (default)
|
|
29
|
+
|
|
30
|
+
- Confirm task selection before starting
|
|
31
|
+
- Show progress after each task
|
|
32
|
+
- Pause on failures for human decision
|
|
33
|
+
|
|
34
|
+
### Auto Mode (`--auto`)
|
|
35
|
+
|
|
36
|
+
- Skip confirmation gates
|
|
37
|
+
- Continue on failures (log and proceed)
|
|
38
|
+
- Show summary at end
|
|
39
|
+
- Useful for CI/batch processing
|
|
40
|
+
|
|
41
|
+
**Warning:** Auto mode will not stop for:
|
|
42
|
+
- Task selection confirmation
|
|
43
|
+
- Mid-implementation reviews
|
|
44
|
+
- Non-critical failures
|
|
45
|
+
|
|
46
|
+
It WILL stop for:
|
|
47
|
+
- Missing prerequisites (spec, arch)
|
|
48
|
+
- Level-B/C refactors (require CHG)
|
|
49
|
+
|
|
50
|
+
## Per-Task Flow
|
|
51
|
+
|
|
52
|
+
```
|
|
53
|
+
1. Load task definition
|
|
54
|
+
2. Validate: has spec ref, arch ref, AC
|
|
55
|
+
3. Set status: TODO → DOING
|
|
56
|
+
4. Read spec + arch sections
|
|
57
|
+
5. Implement code
|
|
58
|
+
6. Write tests
|
|
59
|
+
7. Run tests
|
|
60
|
+
8. If pass: Set status → DONE
|
|
61
|
+
9. If fail: Keep DOING, report issue
|
|
62
|
+
```
|
|
63
|
+
|
|
64
|
+
## Implementation Rules
|
|
65
|
+
|
|
66
|
+
- Follow arch contracts exactly
|
|
67
|
+
- Stay within task scope
|
|
68
|
+
- Level-A refactors allowed inline
|
|
69
|
+
- Level-B/C refactors: STOP, recommend `/astra:change`
|
|
70
|
+
|
|
71
|
+
## Test Requirements
|
|
72
|
+
|
|
73
|
+
Based on change type:
|
|
74
|
+
- **API:** Contract test + integration test
|
|
75
|
+
- **Data:** Migration test + rollback test
|
|
76
|
+
- **Logic:** Unit tests covering AC
|
|
77
|
+
|
|
78
|
+
## Human Gate
|
|
79
|
+
|
|
80
|
+
Before starting batch (if multiple tasks):
|
|
81
|
+
```
|
|
82
|
+
Selected {n} tasks for implementation:
|
|
83
|
+
- TSK-xxx-001: {title}
|
|
84
|
+
- TSK-xxx-002: {title}
|
|
85
|
+
|
|
86
|
+
[c] Continue | [s] Select specific | [q] Quit
|
|
87
|
+
```
|
|
88
|
+
|
|
89
|
+
## Output
|
|
90
|
+
|
|
91
|
+
Per task:
|
|
92
|
+
```markdown
|
|
93
|
+
## TSK-{domain}-{###}: {status}
|
|
94
|
+
|
|
95
|
+
**Files changed:**
|
|
96
|
+
- {file1} (created)
|
|
97
|
+
- {file2} (modified)
|
|
98
|
+
|
|
99
|
+
**Tests:**
|
|
100
|
+
- {test_file}: {pass/fail}
|
|
101
|
+
|
|
102
|
+
**Notes:**
|
|
103
|
+
- {any refactors or issues}
|
|
104
|
+
```
|
|
105
|
+
|
|
106
|
+
Summary:
|
|
107
|
+
- Tasks completed: X
|
|
108
|
+
- Tasks failed: Y
|
|
109
|
+
- Files changed: Z
|