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
package/README.md
ADDED
|
@@ -0,0 +1,52 @@
|
|
|
1
|
+
# Astragentic Installer
|
|
2
|
+
|
|
3
|
+
This is the installer for the Astragentic DevKit. It sets up the necessary configuration and resources for the Astraler framework.
|
|
4
|
+
|
|
5
|
+
## Installation
|
|
6
|
+
|
|
7
|
+
Run the following command in your project root:
|
|
8
|
+
|
|
9
|
+
```bash
|
|
10
|
+
npx astragentic install
|
|
11
|
+
```
|
|
12
|
+
|
|
13
|
+
This command will:
|
|
14
|
+
1. Install `.claude` configuration to your project root.
|
|
15
|
+
2. Install `_astraler` resources to your project root.
|
|
16
|
+
|
|
17
|
+
## Development & Deployment
|
|
18
|
+
|
|
19
|
+
### Manual Publishing (Locally)
|
|
20
|
+
|
|
21
|
+
When publishing manually from your local machine, **you do not need to manually configure a token file**. Authenticity is handled by your local npm session.
|
|
22
|
+
|
|
23
|
+
1. **Login to npm**:
|
|
24
|
+
Open your terminal and run:
|
|
25
|
+
```bash
|
|
26
|
+
npm login
|
|
27
|
+
```
|
|
28
|
+
Follow the browser prompts to authenticate. Once done, your machine is authorized.
|
|
29
|
+
|
|
30
|
+
2. **Ship It**:
|
|
31
|
+
We provide a `ship.sh` script in the root of the repository to automate the bundling and publishing process.
|
|
32
|
+
|
|
33
|
+
```bash
|
|
34
|
+
# From the repository root
|
|
35
|
+
./scripts/ship.sh <version>
|
|
36
|
+
|
|
37
|
+
# Example:
|
|
38
|
+
./scripts/ship.sh 0.0.1
|
|
39
|
+
```
|
|
40
|
+
|
|
41
|
+
The script will:
|
|
42
|
+
- Update the version in `package.json`.
|
|
43
|
+
- Bundle the latest `devkit/claude-code` and `_astraler` content.
|
|
44
|
+
- Ask for confirmation before running `npm publish`.
|
|
45
|
+
|
|
46
|
+
### Automated Publishing (CI/CD)
|
|
47
|
+
|
|
48
|
+
For CI/CD (like GitHub Actions), we use an automation token.
|
|
49
|
+
- Variable: `NPM_TOKEN`
|
|
50
|
+
- Location: set in GitHub Repository Secrets.
|
|
51
|
+
|
|
52
|
+
This is NOT required for manual local deployment.
|
|
@@ -0,0 +1,307 @@
|
|
|
1
|
+
# Astra Engine
|
|
2
|
+
|
|
3
|
+
> Single source of truth for Astra execution rules.
|
|
4
|
+
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
## Core Principles
|
|
8
|
+
|
|
9
|
+
1. **Artifact-first**: All work reads/writes `.astraler-docs/`
|
|
10
|
+
2. **Human-gated**: AI drafts, human approves status changes
|
|
11
|
+
3. **Change-tracked**: Approved docs need CHG record before edit
|
|
12
|
+
4. **Scope-bound**: Never expand beyond current domain/task
|
|
13
|
+
5. **Cognitive sync**: Validate understanding before proceeding
|
|
14
|
+
|
|
15
|
+
---
|
|
16
|
+
|
|
17
|
+
## Command Reference
|
|
18
|
+
|
|
19
|
+
### Discovery & Status
|
|
20
|
+
|
|
21
|
+
| Command | Purpose | Read-Only |
|
|
22
|
+
|---------|---------|-----------|
|
|
23
|
+
| `/astra:start` | Bootstrap or scan project | No |
|
|
24
|
+
| `/astra:status` | Show project state | Yes |
|
|
25
|
+
| `/astra:help` | List commands, workflow | Yes |
|
|
26
|
+
|
|
27
|
+
### Design Phase
|
|
28
|
+
|
|
29
|
+
| Command | Purpose | Checkpoints |
|
|
30
|
+
|---------|---------|-------------|
|
|
31
|
+
| `/astra:spec <domain>` | Create domain specification | Yes (per section) |
|
|
32
|
+
| `/astra:arch <domain>` | Create domain architecture | Yes (per section) |
|
|
33
|
+
| `/astra:plan <domain>` | Generate tasks | No |
|
|
34
|
+
|
|
35
|
+
### Build Phase
|
|
36
|
+
|
|
37
|
+
| Command | Purpose | Flags |
|
|
38
|
+
|---------|---------|-------|
|
|
39
|
+
| `/astra:build <target>` | Implement tasks | `--auto` for batch |
|
|
40
|
+
| `/astra:verify` | Validate consistency | `--all` for all domains |
|
|
41
|
+
|
|
42
|
+
### Governance
|
|
43
|
+
|
|
44
|
+
| Command | Purpose | Creates |
|
|
45
|
+
|---------|---------|---------|
|
|
46
|
+
| `/astra:change <title>` | Modify approved docs | CHG record |
|
|
47
|
+
|
|
48
|
+
---
|
|
49
|
+
|
|
50
|
+
## Document Lifecycle
|
|
51
|
+
|
|
52
|
+
```
|
|
53
|
+
Draft → Approved → Deprecated
|
|
54
|
+
│ │
|
|
55
|
+
│ └── Requires CHG to edit
|
|
56
|
+
└── AI may edit freely
|
|
57
|
+
```
|
|
58
|
+
|
|
59
|
+
**Status rules:**
|
|
60
|
+
- `Draft`: Work in progress, editable
|
|
61
|
+
- `Approved`: Human-reviewed, locked without CHG
|
|
62
|
+
- `Deprecated`: Archived, read-only
|
|
63
|
+
|
|
64
|
+
---
|
|
65
|
+
|
|
66
|
+
## Human Gates
|
|
67
|
+
|
|
68
|
+
**STOP and WAIT for human input:**
|
|
69
|
+
- Before status transition (Draft → Approved)
|
|
70
|
+
- Before deployment/commit
|
|
71
|
+
- Before cross-domain changes
|
|
72
|
+
- When CHG is required
|
|
73
|
+
|
|
74
|
+
**Auto-proceed with reporting:**
|
|
75
|
+
- Consistency checks
|
|
76
|
+
- Test coverage metrics
|
|
77
|
+
- Lint/format results
|
|
78
|
+
|
|
79
|
+
---
|
|
80
|
+
|
|
81
|
+
## ID Conventions
|
|
82
|
+
|
|
83
|
+
| Type | Format | Example |
|
|
84
|
+
|------|--------|---------|
|
|
85
|
+
| Task | `TSK-{domain}-{###}` | `TSK-order-001` |
|
|
86
|
+
| Change | `CHG-{YYYY-MM-DD}-{slug}` | `CHG-2026-01-04-add-refund` |
|
|
87
|
+
| ADR | `ADR-{YYYY-MM-DD}-{topic}` | `ADR-2026-01-04-use-redis` |
|
|
88
|
+
|
|
89
|
+
---
|
|
90
|
+
|
|
91
|
+
## Workflow Selection
|
|
92
|
+
|
|
93
|
+
| Signal | Workflow | Entry |
|
|
94
|
+
|--------|----------|-------|
|
|
95
|
+
| No `.astraler-docs/` | Greenfield | `/astra:start` |
|
|
96
|
+
| Has `.astraler-docs/`, no spec | Greenfield | `/astra:start` |
|
|
97
|
+
| Has codebase, no docs | Brownfield | `/astra:start --scan` |
|
|
98
|
+
| New requirement on existing | Change | `/astra:change` |
|
|
99
|
+
|
|
100
|
+
---
|
|
101
|
+
|
|
102
|
+
## Output Structure (FINAL)
|
|
103
|
+
|
|
104
|
+
```
|
|
105
|
+
.astraler-docs/
|
|
106
|
+
├── _index.md
|
|
107
|
+
├── 01-context/
|
|
108
|
+
│ ├── _index.md
|
|
109
|
+
│ ├── product.md # Vision, priorities, anti-goals
|
|
110
|
+
│ ├── constraints.md # Technical & business constraints
|
|
111
|
+
│ ├── assumptions.md # Validatable assumptions
|
|
112
|
+
│ └── glossary.md # Domain terminology
|
|
113
|
+
│
|
|
114
|
+
├── 02-spec/
|
|
115
|
+
│ ├── _index.md
|
|
116
|
+
│ ├── core/
|
|
117
|
+
│ │ ├── overview.md # System scope, actors
|
|
118
|
+
│ │ ├── flows.md # Cross-domain flows
|
|
119
|
+
│ │ └── rules.md # Global business rules
|
|
120
|
+
│ └── domains/
|
|
121
|
+
│ └── {domain}.md # Per-domain specification
|
|
122
|
+
│
|
|
123
|
+
├── 03-arch/
|
|
124
|
+
│ ├── _index.md # Navigation only
|
|
125
|
+
│ ├── overview.md # System architecture, tech stack
|
|
126
|
+
│ ├── data-schema.md # Global database schema
|
|
127
|
+
│ ├── decisions.md # ADR collection
|
|
128
|
+
│ ├── standards.md # Engineering standards, DoD
|
|
129
|
+
│ └── domains/
|
|
130
|
+
│ └── {domain}.arch.md # Per-domain architecture
|
|
131
|
+
│
|
|
132
|
+
├── 04-tasks/
|
|
133
|
+
│ ├── _index.md
|
|
134
|
+
│ ├── milestones.md # Epic-level goals
|
|
135
|
+
│ ├── domains/
|
|
136
|
+
│ │ └── {domain}.tasks.md # Per-domain task breakdown
|
|
137
|
+
│ └── sprints/ # Optional time-box view
|
|
138
|
+
│ └── {sprint}.md
|
|
139
|
+
│
|
|
140
|
+
├── 05-changes/
|
|
141
|
+
│ ├── _index.md
|
|
142
|
+
│ ├── changelog.md # Change history summary
|
|
143
|
+
│ └── impact/
|
|
144
|
+
│ └── CHG-YYYY-MM-DD-*.md # Individual change records
|
|
145
|
+
│
|
|
146
|
+
└── ai/
|
|
147
|
+
├── guardrails.md # AI agent constraints
|
|
148
|
+
└── quality_gates.md # Test taxonomy & gates
|
|
149
|
+
```
|
|
150
|
+
|
|
151
|
+
---
|
|
152
|
+
|
|
153
|
+
## Mermaid Diagram Requirements
|
|
154
|
+
|
|
155
|
+
All generated documentation MUST include visual diagrams:
|
|
156
|
+
|
|
157
|
+
| Document Type | Required Diagrams |
|
|
158
|
+
|---------------|-------------------|
|
|
159
|
+
| **Spec** (`02-spec/domains/*.md`) | `sequenceDiagram`, `stateDiagram-v2`, `erDiagram` |
|
|
160
|
+
| **Arch** (`03-arch/domains/*.arch.md`) | `flowchart`, `classDiagram`, `sequenceDiagram`, `erDiagram`, `stateDiagram-v2` |
|
|
161
|
+
| **Tasks** (`04-tasks/domains/*.tasks.md`) | `pie` (status distribution), `flowchart` (dependency graph) |
|
|
162
|
+
| **CHG** (`05-changes/impact/CHG-*.md`) | `flowchart` (impact analysis) |
|
|
163
|
+
|
|
164
|
+
**Diagram Update Rules:**
|
|
165
|
+
- When task status changes → update `pie` counts and `flowchart` node styles
|
|
166
|
+
- When adding CHG → include impact flowchart with affected artifacts
|
|
167
|
+
- Verify passes only when all required diagrams are present
|
|
168
|
+
|
|
169
|
+
---
|
|
170
|
+
|
|
171
|
+
## Quality Checks
|
|
172
|
+
|
|
173
|
+
Before writing spec:
|
|
174
|
+
- `01-context/product.md` exists
|
|
175
|
+
|
|
176
|
+
Before writing arch:
|
|
177
|
+
- `02-spec/domains/{domain}.md` exists (Draft+)
|
|
178
|
+
|
|
179
|
+
Before writing tasks:
|
|
180
|
+
- Spec + arch exist for domain
|
|
181
|
+
|
|
182
|
+
Before implementing:
|
|
183
|
+
- Task has spec ref, arch ref, testable AC
|
|
184
|
+
|
|
185
|
+
Before approving:
|
|
186
|
+
- Human has reviewed
|
|
187
|
+
- `/astra:verify` passes
|
|
188
|
+
- All required Mermaid diagrams present
|
|
189
|
+
|
|
190
|
+
---
|
|
191
|
+
|
|
192
|
+
## Quality Gates by Change Type
|
|
193
|
+
|
|
194
|
+
| Change Type | Required |
|
|
195
|
+
|-------------|----------|
|
|
196
|
+
| API change | Contract test + integration test |
|
|
197
|
+
| Data change | Migration + rollback + test |
|
|
198
|
+
| Payment/refund | Idempotency + negative cases + audit |
|
|
199
|
+
| Auth | Security baseline + rate limiting |
|
|
200
|
+
|
|
201
|
+
---
|
|
202
|
+
|
|
203
|
+
## Versioning
|
|
204
|
+
|
|
205
|
+
| Change Type | Version Bump |
|
|
206
|
+
|-------------|--------------|
|
|
207
|
+
| Wording only | Patch (v1.0 → v1.1) |
|
|
208
|
+
| New flow/rule | Minor (v1.1 → v2.0) |
|
|
209
|
+
| Contract/boundary | Major (v2.0 → v3.0) |
|
|
210
|
+
|
|
211
|
+
---
|
|
212
|
+
|
|
213
|
+
## Refactor Rules
|
|
214
|
+
|
|
215
|
+
| Level | Scope | Allowed |
|
|
216
|
+
|-------|-------|---------|
|
|
217
|
+
| A | Internal only | Yes, inline |
|
|
218
|
+
| B | Contract/boundary | Requires CHG |
|
|
219
|
+
| C | Cross-domain | Requires CHG + ADR |
|
|
220
|
+
|
|
221
|
+
---
|
|
222
|
+
|
|
223
|
+
## Checkpoint Pattern
|
|
224
|
+
|
|
225
|
+
Commands with checkpoint pattern save progress after each section:
|
|
226
|
+
|
|
227
|
+
```
|
|
228
|
+
Generate Section → Save to File → Present for Review → [c/e/q] → Next Section
|
|
229
|
+
```
|
|
230
|
+
|
|
231
|
+
**Checkpoint controls:**
|
|
232
|
+
- `[c]` Continue to next section
|
|
233
|
+
- `[e]` Edit current section
|
|
234
|
+
- `[q]` Quit (progress saved)
|
|
235
|
+
|
|
236
|
+
Commands using checkpoints:
|
|
237
|
+
- `/astra:spec` — saves after Purpose, Flows, Rules, Data, Criteria
|
|
238
|
+
- `/astra:arch` — saves after Overview, Components, Contracts, Data, State
|
|
239
|
+
|
|
240
|
+
This prevents work loss and enables iterative refinement.
|
|
241
|
+
|
|
242
|
+
---
|
|
243
|
+
|
|
244
|
+
## Interactive Diagram Review
|
|
245
|
+
|
|
246
|
+
For required Mermaid diagrams, present each for validation:
|
|
247
|
+
|
|
248
|
+
```markdown
|
|
249
|
+
## {Diagram Type}: {Subject}
|
|
250
|
+
|
|
251
|
+
```mermaid
|
|
252
|
+
{diagram content}
|
|
253
|
+
```
|
|
254
|
+
|
|
255
|
+
**Does this accurately represent {the flow/architecture/data}?**
|
|
256
|
+
[y] Yes, continue | [e] Edit | [s] Skip (flags in verify)
|
|
257
|
+
```
|
|
258
|
+
|
|
259
|
+
Diagrams skipped during creation are flagged as warnings by `/astra:verify`.
|
|
260
|
+
|
|
261
|
+
---
|
|
262
|
+
|
|
263
|
+
## Cognitive Sync Checkpoint
|
|
264
|
+
|
|
265
|
+
Before major phase transitions, present understanding for explicit validation:
|
|
266
|
+
|
|
267
|
+
**Used in:**
|
|
268
|
+
- Greenfield Phase 2 → Phase 3 (Brainstorm → Distill)
|
|
269
|
+
|
|
270
|
+
**Format:**
|
|
271
|
+
```markdown
|
|
272
|
+
## My Understanding
|
|
273
|
+
|
|
274
|
+
### What We're Building
|
|
275
|
+
{summary}
|
|
276
|
+
|
|
277
|
+
### Key Actors
|
|
278
|
+
{list}
|
|
279
|
+
|
|
280
|
+
### Core Flows
|
|
281
|
+
{list}
|
|
282
|
+
|
|
283
|
+
### Anti-goals
|
|
284
|
+
{list}
|
|
285
|
+
|
|
286
|
+
### Assumptions
|
|
287
|
+
{table with risk levels}
|
|
288
|
+
|
|
289
|
+
---
|
|
290
|
+
**Is this correct?** [y] Yes | [n] No | [p] Partially
|
|
291
|
+
```
|
|
292
|
+
|
|
293
|
+
This ensures human and AI are aligned before committing to documentation.
|
|
294
|
+
|
|
295
|
+
---
|
|
296
|
+
|
|
297
|
+
## Execution Modes
|
|
298
|
+
|
|
299
|
+
| Mode | Flag | Behavior |
|
|
300
|
+
|------|------|----------|
|
|
301
|
+
| Interactive | (default) | Confirm gates, pause on errors |
|
|
302
|
+
| Auto | `--auto` | Skip confirmations, continue on non-critical errors |
|
|
303
|
+
|
|
304
|
+
**Auto mode will NOT skip:**
|
|
305
|
+
- Missing prerequisites (spec, arch)
|
|
306
|
+
- Level-B/C refactors (require CHG)
|
|
307
|
+
- Critical validation failures
|