@chrisdudek/yg 1.3.0 → 1.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.
- package/dist/bin.js +225 -21
- package/dist/bin.js.map +1 -1
- package/dist/templates/rules.ts +32 -2
- package/package.json +1 -1
package/dist/templates/rules.ts
CHANGED
|
@@ -51,11 +51,29 @@ WHEN UNSURE: ask the user. Never guess. Never assume.
|
|
|
51
51
|
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.
|
|
52
52
|
5. **Ask before resolving ambiguity.** When multiple valid interpretations exist, stop, list options, ask the user. Never silently choose.
|
|
53
53
|
|
|
54
|
+
### Recognizing Graph-Required Actions
|
|
55
|
+
|
|
56
|
+
What matters is the ACTION you are performing, not what instructed it. If the action involves understanding mapped code, the graph protocol applies — whether the instruction came from a skill, a plan, a user message, a workflow step, or your own initiative.
|
|
57
|
+
|
|
58
|
+
**Actions that require \`yg owner\` + \`yg build-context\` first:**
|
|
59
|
+
|
|
60
|
+
- Reading or exploring source files to understand a component
|
|
61
|
+
- Proposing approaches, designs, or plans for changing code
|
|
62
|
+
- Reviewing or debugging code
|
|
63
|
+
- Any form of reasoning about how mapped code works or should change
|
|
64
|
+
|
|
65
|
+
**Actions that do NOT require yg:**
|
|
66
|
+
|
|
67
|
+
- Git operations (log, diff, status, blame)
|
|
68
|
+
- Reading documentation, READMEs, or config files outside \`.yggdrasil/\`
|
|
69
|
+
- Running tests, builds, or linters
|
|
70
|
+
- Working with files that \`yg owner\` reports as unmapped
|
|
71
|
+
|
|
54
72
|
### Failure States
|
|
55
73
|
|
|
56
74
|
You have broken Yggdrasil if you do any of the following:
|
|
57
75
|
|
|
58
|
-
- ❌ Worked on a mapped file without running \`yg owner\` + \`yg build-context\` first —
|
|
76
|
+
- ❌ Worked on a mapped file without running \`yg owner\` + \`yg build-context\` first — regardless of what instructed the action (skill, plan, user request, workflow step).
|
|
59
77
|
- ❌ Modified source code without updating graph artifacts in the same response, or vice versa.
|
|
60
78
|
- ❌ Resolved a code-graph inconsistency or ambiguity without asking the user first.
|
|
61
79
|
- ❌ Created or edited a graph element without reading its schema in \`schemas/\` first.
|
|
@@ -167,6 +185,7 @@ Per area checklist:
|
|
|
167
185
|
- [ ] 4. Analyze source — for each artifact type in \`config.artifacts\`: extract content, do not invent
|
|
168
186
|
- [ ] 5. Identify relations — add to \`node.yaml\`
|
|
169
187
|
- [ ] 6. Identify cross-cutting requirements — add matching aspects, create if needed
|
|
188
|
+
- [ ] 6b. For each aspect on the node: identify 2-5 code anchors (function names, constants) that evidence the pattern → add to \`node.yaml\` \`anchors\` field
|
|
170
189
|
- [ ] 7. Identify business process participation — add to flow, ask user if process unclear
|
|
171
190
|
- [ ] 8. \`yg validate\` — fix errors
|
|
172
191
|
- [ ] 9. \`yg drift-sync --node <path>\`
|
|
@@ -271,6 +290,8 @@ Three artifacts capture node knowledge at three levels:
|
|
|
271
290
|
- **interface.md** (required when node has consumers) — HOW TO USE: public methods, parameters, return types, contracts, failure modes, exposed data structures. Everything another node needs to interact with this one.
|
|
272
291
|
- **internals.md** (optional, highest value for cross-module nodes) — HOW IT WORKS + WHY: algorithms, control flow, business rules, invariants, state machines, lifecycle, and design decisions with rejected alternatives. Use sections within the file: ## Logic, ## Constraints, ## State, ## Decisions (with "Chose X over Y because Z" format).
|
|
273
292
|
|
|
293
|
+
**Enrichment priority (when adding incrementally):** \`interface.md\` first (highest cross-module ROI — contracts enable other nodes to reason about interactions), then \`responsibility.md\` (identity and boundaries), then \`internals.md\` (depth for complex nodes). A node with only \`interface.md\` provides more cross-module value than one with only \`internals.md\`.
|
|
294
|
+
|
|
274
295
|
### Context Assembly
|
|
275
296
|
|
|
276
297
|
Run \`yg build-context --node <path>\` to get the deterministic context package for a node. The package assembles global config, hierarchy, own artifacts, aspects, and relational context. It is your architectural map. For implementation-level claims (exact call patterns, error handling, await vs fire-and-forget) — verify against source code. If the package is insufficient, enrich the graph.
|
|
@@ -306,6 +327,14 @@ When a node follows an aspect's pattern with exceptions, record exceptions in \`
|
|
|
306
327
|
|
|
307
328
|
**Aspect lifecycle warning.** Aspects decay CATASTROPHICALLY — a pattern either exists or it doesn't. When a pattern changes, ALL aspect claims become wrong at once. This differs from other artifacts: \`interface.md\` and \`responsibility.md\` are most stable (~9-year half-life); \`internals.md\` has moderate stability (~2.5-year half-life); aspects are least stable (~2.4-year half-life, binary decay). After any significant feature addition, review ALL aspects touching the affected area. Don't wait for drift — aspects can be 100% wrong without any mapped file changing.
|
|
308
329
|
|
|
330
|
+
**Aspect stability tiers.** If an aspect has a \`stability\` field in \`aspect.yaml\`, use it to calibrate review urgency:
|
|
331
|
+
|
|
332
|
+
- \`schema\` — enforced by data model; review only when data model changes (most stable)
|
|
333
|
+
- \`protocol\` — contractual pattern; review when contracts or interfaces change
|
|
334
|
+
- \`implementation\` — specific mechanism; review after ANY significant code change (least stable)
|
|
335
|
+
|
|
336
|
+
When code anchors (\`anchors\` field in \`node.yaml\`) are present for an aspect, they list code patterns (function names, constants, SQL fragments) evidencing the aspect's implementation in this node. \`yg validate\` checks that each anchor exists in the node's mapped source files — a missing anchor (W014) signals the aspect may be stale for this node.
|
|
337
|
+
|
|
309
338
|
### Creating Flows
|
|
310
339
|
|
|
311
340
|
- [ ] 1. Read \`schemas/flow.yaml\`
|
|
@@ -342,6 +371,7 @@ yg flows List flows with metadata (YAML output).
|
|
|
342
371
|
yg deps --node <path> [--depth N] [--type structural|event|all]
|
|
343
372
|
Show dependencies.
|
|
344
373
|
yg impact --node <path> --simulate Simulate blast radius of a planned change.
|
|
374
|
+
yg impact --node <path> --method <name> Filter impact to dependents consuming a specific method.
|
|
345
375
|
yg impact --aspect <id> Show all nodes where aspect is effective.
|
|
346
376
|
yg impact --flow <name> Show flow participants and descendants.
|
|
347
377
|
yg status Graph health: nodes, coverage, drift summary.
|
|
@@ -369,4 +399,4 @@ yg journal-archive Archive consolidated journal entries.
|
|
|
369
399
|
| Technology stack | \`config.yaml stack\` (+ \`rationale\` field) |
|
|
370
400
|
| Global coding standards | \`config.yaml standards\` |`;
|
|
371
401
|
|
|
372
|
-
export const AGENT_RULES_CONTENT = [CORE_PROTOCOL, OPERATIONS, KNOWLEDGE_BASE].join('\n\n---\n\n');
|
|
402
|
+
export const AGENT_RULES_CONTENT = [CORE_PROTOCOL, OPERATIONS, KNOWLEDGE_BASE].join('\n\n---\n\n') + '\n';
|