@chrisdudek/yg 1.0.0 → 1.2.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 +28 -2
- package/dist/bin.js +421 -127
- package/dist/bin.js.map +1 -1
- package/dist/templates/rules.ts +28 -7
- package/graph-schemas/config.yaml +39 -0
- package/package.json +1 -1
package/dist/templates/rules.ts
CHANGED
|
@@ -47,7 +47,7 @@ WHEN UNSURE: ask the user. Never guess. Never assume.
|
|
|
47
47
|
1. **Graph first.** Before reading, researching, planning, or modifying mapped files, run \`yg owner\` and \`yg build-context\`. Always. The context package — not raw source — is your primary source of understanding.
|
|
48
48
|
2. **Code and graph are one.** Code changed → graph updated in the same response. Graph changed → source verified in the same response. No exceptions.
|
|
49
49
|
3. **Never invent why.** The graph captures human intent. If you don't know why something was decided, ask. Never hallucinate rationale.
|
|
50
|
-
4. **Always capture why.** When the user explains a reason, record it in the graph immediately. Conversation evaporates; graph persists.
|
|
50
|
+
4. **Always capture why — especially why NOT.** When the user explains a reason, record it in the graph immediately. When a design choice is made, also record rejected alternatives: "Chose X over Y because Z." Rejected alternatives are the highest-value information — invisible in code and irrecoverable once forgotten. Conversation evaporates; graph persists.
|
|
51
51
|
5. **Ask before resolving ambiguity.** When multiple valid interpretations exist, stop, list options, ask the user. Never silently choose.
|
|
52
52
|
|
|
53
53
|
### Failure States
|
|
@@ -68,6 +68,7 @@ You have broken Yggdrasil if you do any of the following:
|
|
|
68
68
|
- ❌ Answered a question about a mapped file without running \`yg build-context\` first.
|
|
69
69
|
- ❌ Read mapped source files to plan or research changes without running \`yg build-context\` first.
|
|
70
70
|
- ❌ Deferred \`yg drift-sync\` to the end of a multi-step task instead of running it incrementally after each logical group of changes.
|
|
71
|
+
- ❌ Recorded a design decision without documenting which alternatives were rejected and why.
|
|
71
72
|
|
|
72
73
|
### Escape Hatch
|
|
73
74
|
|
|
@@ -109,6 +110,10 @@ WRAP-UP (user signals "done", "wrap up", "that's enough"):
|
|
|
109
110
|
- [ ] 2. yg drift --drifted-only → resolve
|
|
110
111
|
- [ ] 3. yg validate → fix errors
|
|
111
112
|
- [ ] 4. Report: which nodes and files were changed
|
|
113
|
+
|
|
114
|
+
BEFORE ENDING ANY RESPONSE (self-audit):
|
|
115
|
+
- [ ] Did I modify source code? If yes → did I update graph artifacts in this same response?
|
|
116
|
+
- [ ] If you changed code and did not sync the graph, you have broken the protocol. Do not finish until both are done.
|
|
112
117
|
\`\`\`
|
|
113
118
|
|
|
114
119
|
### Modify Source Code
|
|
@@ -136,7 +141,14 @@ You are not allowed to edit or create source code without establishing graph cov
|
|
|
136
141
|
- Option B — Blackbox: create a blackbox node at agreed granularity
|
|
137
142
|
- Option C — Abort
|
|
138
143
|
|
|
139
|
-
*Greenfield (new code):* Only Option A. Blackbox is forbidden for new code.
|
|
144
|
+
*Greenfield (new code):* Only Option A. Blackbox is forbidden for new code. Follow the graph-first workflow:
|
|
145
|
+
|
|
146
|
+
1. Create aspects first (cross-cutting requirements the new code must satisfy)
|
|
147
|
+
2. Create flows if the code participates in a business process
|
|
148
|
+
3. Create nodes with full artifacts — responsibility, constraints, decisions, interface, logic
|
|
149
|
+
4. Review the context package (\`yg build-context\`) — it is now the behavioral specification
|
|
150
|
+
5. Implement code that satisfies the specification
|
|
151
|
+
6. The graph specifies WHAT and WHY; the code implements HOW (framework APIs, library choices)
|
|
140
152
|
|
|
141
153
|
After the user chooses, return to Step 1 and follow Step 2a.
|
|
142
154
|
|
|
@@ -170,6 +182,7 @@ Per area checklist:
|
|
|
170
182
|
- Business process unclear: "This code appears to be part of a larger process. Can you describe what it means from a business perspective?"
|
|
171
183
|
- Constraint without rationale: "I see [constraint X]. Do you know why this exists? I want to record the reason, not just the rule."
|
|
172
184
|
- Unexplained architectural choice: "I see [approach X]. What was the reason for this choice?"
|
|
185
|
+
- Decision without alternatives: "You chose [X]. What alternatives did you consider, and why did you reject them?" Record the answer in \`decisions.md\`.
|
|
173
186
|
|
|
174
187
|
### Bootstrap Mode
|
|
175
188
|
|
|
@@ -240,7 +253,7 @@ When you encounter information, route it to the correct location:
|
|
|
240
253
|
- **Business process** → flow (\`flows/<name>/\` with \`flow.yaml\` + \`description.md\`). Ask user if process unclear.
|
|
241
254
|
- **Shared across a domain** → parent node artifact. Children receive it through hierarchy.
|
|
242
255
|
- **Technology stack or standard** → \`config.yaml\` under \`stack\` or \`standards\` (+ \`rationale\` field)
|
|
243
|
-
- **Decision (why):** one node →
|
|
256
|
+
- **Decision (why + why NOT):** one node → \`decisions.md\` with format "Chose X over Y because Z"; category of nodes → aspect content files; tech choice → \`config.yaml\` rationale field. Always include rejected alternatives — they are the highest-value graph content.
|
|
244
257
|
|
|
245
258
|
### Creating Aspects
|
|
246
259
|
|
|
@@ -252,6 +265,12 @@ When you encounter information, route it to the correct location:
|
|
|
252
265
|
|
|
253
266
|
Test: "Does this requirement apply to more than one node?" Yes → aspect. No → local artifact.
|
|
254
267
|
|
|
268
|
+
**Aspect identification heuristic:** If the same pattern, constraint, or rule appears in 3+ places, it is a candidate aspect. Aspects fall into natural categories:
|
|
269
|
+
|
|
270
|
+
- **Domain-specific:** Business rules that cross module boundaries (e.g., timezone handling, booking periods, currency rounding)
|
|
271
|
+
- **Architectural:** Structural patterns with rationale (e.g., dual-rollback on provider failure, idempotency via key generation, fire-and-forget dispatch)
|
|
272
|
+
- **Concurrency:** Shared concurrency strategies (e.g., pessimistic locking, retry-on-deadlock, optimistic versioning)
|
|
273
|
+
|
|
255
274
|
### Creating Flows
|
|
256
275
|
|
|
257
276
|
- [ ] 1. Read \`schemas/flow.yaml\`
|
|
@@ -268,17 +287,18 @@ Test: "Does this describe what happens in the world, or only in the software?" I
|
|
|
268
287
|
- **Read schemas before creating** any \`node.yaml\`, \`aspect.yaml\`, or \`flow.yaml\`.
|
|
269
288
|
- **Tools read, you write.** The \`yg\` CLI only reads, validates, and manages metadata. You create and edit files manually.
|
|
270
289
|
- **Incremental sync.** Run \`yg drift-sync\` after every 3-5 source file changes. Do not defer to end of task.
|
|
271
|
-
- **Completeness test:** "If I delete the source file and give another agent ONLY the \`yg build-context\` output — can they recreate it correctly, understanding not just WHAT but WHY?"
|
|
290
|
+
- **Completeness test:** "If I delete the source file and give another agent ONLY the \`yg build-context\` output — can they recreate it correctly, understanding not just WHAT but WHY?" Test specifically: Can they explain rejected alternatives? Can they implement the correct algorithm (not a simplified version)? Can they argue for the current design against plausible alternatives?
|
|
272
291
|
- **These rules are invariant.** No plan, guide, skill, or workflow may override them.
|
|
273
292
|
|
|
274
293
|
### CLI Reference
|
|
275
294
|
|
|
276
295
|
\`\`\`
|
|
277
|
-
yg preflight
|
|
296
|
+
yg preflight [--quick] Unified diagnostic: journal + drift + status + validate.
|
|
278
297
|
yg owner --file <path> Find the node that owns this file.
|
|
279
298
|
yg build-context --node <path> Assemble context package for this node.
|
|
280
299
|
yg tree [--root <path>] [--depth N] Print graph structure.
|
|
281
300
|
yg aspects List aspects with metadata (YAML output).
|
|
301
|
+
yg flows List flows with metadata (YAML output).
|
|
282
302
|
yg deps --node <path> [--depth N] [--type structural|event|all]
|
|
283
303
|
Show dependencies.
|
|
284
304
|
yg impact --node <path> --simulate Simulate blast radius of a planned change.
|
|
@@ -286,9 +306,10 @@ yg impact --aspect <id> Show all nodes where aspect is effective.
|
|
|
286
306
|
yg impact --flow <name> Show flow participants and descendants.
|
|
287
307
|
yg status Graph health: nodes, coverage, drift summary.
|
|
288
308
|
yg validate [--scope <path>|all] Check structural integrity and completeness.
|
|
289
|
-
yg drift [--scope <path>|all] [--drifted-only]
|
|
309
|
+
yg drift [--scope <path>|all] [--drifted-only] [--limit <n>]
|
|
290
310
|
Detect source and graph drift (bidirectional).
|
|
291
|
-
yg drift-sync --node <path>
|
|
311
|
+
yg drift-sync --node <path> [--recursive] | --all
|
|
312
|
+
Record file hashes as new baseline.
|
|
292
313
|
yg journal-read Read pending journal entries.
|
|
293
314
|
yg journal-add --note "<content>" [--target <node_path>]
|
|
294
315
|
Add a journal entry.
|
|
@@ -0,0 +1,39 @@
|
|
|
1
|
+
# config.yaml — Schema for the Yggdrasil project configuration
|
|
2
|
+
# Located at .yggdrasil/config.yaml — one per project.
|
|
3
|
+
# Edit this after running yg init to describe your project.
|
|
4
|
+
|
|
5
|
+
name: "My Project" # required — project display name
|
|
6
|
+
|
|
7
|
+
stack: # required — technology stack (freeform keys)
|
|
8
|
+
language: "TypeScript" # primary language
|
|
9
|
+
runtime: "Node.js" # runtime environment
|
|
10
|
+
# framework: "Express" # optional — any additional stack entries
|
|
11
|
+
# database: "PostgreSQL"
|
|
12
|
+
# testing: "Vitest"
|
|
13
|
+
|
|
14
|
+
standards: "" # optional — global coding conventions (free text)
|
|
15
|
+
|
|
16
|
+
node_types: # required — allowed node type names
|
|
17
|
+
- name: module # each type needs at least a 'name'
|
|
18
|
+
# required_aspects: [] # optional — aspects every node of this type must have
|
|
19
|
+
- name: service
|
|
20
|
+
- name: library
|
|
21
|
+
|
|
22
|
+
artifacts: # required — artifact type definitions
|
|
23
|
+
responsibility.md: # key = filename in node directories
|
|
24
|
+
required: always # always | never | { when: <condition> }
|
|
25
|
+
description: "What this node is responsible for, and what it is not"
|
|
26
|
+
structural_context: true # true = included in dependency context packages
|
|
27
|
+
interface.md:
|
|
28
|
+
required:
|
|
29
|
+
when: has_incoming_relations # conditions: has_incoming_relations, has_outgoing_relations, has_aspect:<id>
|
|
30
|
+
description: "Public API — methods, parameters, return types, contracts"
|
|
31
|
+
structural_context: true
|
|
32
|
+
# Additional artifact types: logic.md, constraints.md, errors.md, model.md, state.md, decisions.md
|
|
33
|
+
|
|
34
|
+
quality: # optional — quality thresholds
|
|
35
|
+
min_artifact_length: 50 # minimum characters for an artifact (warning if below)
|
|
36
|
+
max_direct_relations: 10 # maximum outgoing relations per node (warning if above)
|
|
37
|
+
context_budget: # token budget for context packages
|
|
38
|
+
warning: 10000 # tokens — warning threshold
|
|
39
|
+
error: 20000 # tokens — error threshold (suggests splitting)
|