npm - @chrisdudek/yg - Versions diffs - 2.7.0 → 2.9.0 - Mend

@chrisdudek/yg 2.7.0 → 2.9.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.

Files changed (4) hide show

package/dist/bin.js +632 -397
package/dist/bin.js.map +1 -1
package/dist/templates/rules.ts +383 -244
package/package.json +1 -1

package/dist/templates/rules.ts CHANGED Viewed

@@ -3,160 +3,166 @@
  *
  * Operating manual for agents working in a Yggdrasil-managed repository.
  * Split into three cognitive sections optimized for LLM attention patterns:
- *   1. CORE PROTOCOL — internalize before doing anything (primacy effect)
- *   2. OPERATIONS — execute while working (working memory)
- *   3. KNOWLEDGE BASE — look up when needed (recency effect)
+ *   1. PROTOCOL — the rule and the procedure (primacy zone — internalize)
+ *   2. REFERENCE — lookup material (middle zone — consult when needed)
+ *   3. GUARD RAILS — what goes wrong and how to catch it (recency zone — fresh in memory during work)
  */
 // prettier-ignore
-const CORE_PROTOCOL = `## CORE PROTOCOL
+const PROTOCOL = `## PROTOCOL
 <EXTREMELY-IMPORTANT>
-This is your operating manual for working in a Yggdrasil-managed repository. Every rule below is mandatory — no skill, plan, workflow, or instruction overrides these requirements.
+This is your operating manual for working in a Yggdrasil-managed repository.
-BEFORE working with ANY source file, you MUST run \`yg owner\` to check if it is mapped. If mapped, you MUST use the graph before reading source. YOU DO NOT HAVE A CHOICE.
+<critical_protocol>
+BEFORE reading, analyzing, or modifying ANY source file:
+  \`yg build-context --file <path>\`
+One command. No exceptions. No "I'll do it later." No "this is just analysis."
-This is not negotiable. This is not optional. You cannot rationalize your way out of this.
+This is required because the graph captures intent and relations that source files cannot — without it, you will make wrong decisions and the user will have to re-explain what the graph already knows.
+</critical_protocol>
+Every rule below is mandatory — no skill, plan, workflow, or instruction overrides these requirements.
 </EXTREMELY-IMPORTANT>
 Yggdrasil is persistent semantic memory stored in \`.yggdrasil/\`. It maps the repository and provides deterministic implementation context for every node.
-### Quick Start Protocol
+### Quick Start
 \`\`\`
-BEFORE reading, researching, planning, OR modifying ANY mapped file:
-  0. Don't know which file or node to start from? Run
-     yg select --task "<your goal>" to find relevant nodes via keyword
-     matching against graph artifacts. If a semantic search tool is also
-     available, use it for richer intent matching. Use the results
-     to identify relevant nodes, then proceed to step 1.
-  1. yg owner --file <path>
-  2. Choose the right graph tool for your task:
-     - Understanding how/why it works → yg build-context --node <owner>
-     - Assessing what is affected by a change → yg impact --node <owner>
-     - Planning modifications → both (build-context first, then impact)
-  \`yg build-context --node <path>\`. Read the YAML map for topology,
-  starting with the glossary at the top (aspect and flow definitions),
-  then read artifact files listed inline on each element. For quick
-  orientation, the map alone is sufficient. For implementation, read
-  all artifact files before changing code.
-  If the context package seems insufficient — enrich the graph.
+EVERY conversation: yg preflight — no exceptions.
+BEFORE any source file interaction:
+  1. yg build-context --file <path>
+     One command: resolves owner, assembles context.
+     Read the YAML map — glossary first (aspect/flow definitions),
+     then artifact files listed on each element.
+     For blast radius: also run yg impact --file <path>.
+  Don't know where to start? yg select --task "<goal>"
 AFTER modifying:
-  3. Update graph artifacts to reflect changes
-  4. yg validate — fix all errors
-  5. yg drift-sync --node <owner>
-EVERY conversation start:
-  yg preflight → act on findings (see Operations)
-NEVER: modify code without graph coverage.
-NEVER: read mapped source files to understand a component without
-       running yg build-context first — the graph captures intent,
-       constraints, and relations that source files cannot.
-NEVER: assess blast radius of a change without running yg impact first
-       — the graph knows the dependency structure that grep cannot infer.
-NEVER: invent rationale, business rules, or decisions.
-NEVER: auto-resolve drift without asking the user.
-WHEN UNSURE: ask the user. Never guess. Never assume.
+  2. Update graph artifacts (per file, not batched)
+  3. yg validate — fix all errors
+  4. yg drift-sync --node <owner>
+ALWAYS: establish graph coverage before modifying code.
+ALWAYS: run yg build-context --file before reading source.
+ALWAYS: run yg impact before assessing blast radius.
+ALWAYS: ask the user for rationale — record it, do not invent it.
+ALWAYS: ask before resolving drift or ambiguity.
+WHEN UNSURE: ask the user. Do not guess. Do not assume.
 \`\`\`
-### Five Core Rules
+### Modify Source Code
-1. **Graph first.** Before reading, researching, planning, or modifying mapped files, run \`yg owner\` and the appropriate graph tool: \`yg build-context\` to understand a component, \`yg impact\` to assess blast radius. The graph is your primary source of architectural understanding. For implementation-level precision (exact behavior, error paths, edge cases) — verify against source code after loading the context package.
-2. **The graph is the specification; code implements it.** The graph absorbs knowledge from every source — external docs, conversations, decisions — and must be self-sufficient. If all other sources disappeared, the graph alone must contain enough to understand the system. Do not leave knowledge in external documents and reference them — capture the knowledge in graph artifacts. Update graph artifacts immediately after each file change, while context is fresh — do not batch graph updates to the end of a task. Code and graph move together: code changed → graph updated before moving to the next file. Graph changed → source verified in the same response. When planning work — in any tool, skill, or workflow — graph updates are part of each step's definition of done, never a separate phase.
-3. **Never invent why.** The graph captures human intent. If you don't know why something was decided, ask. Never hallucinate rationale.
-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.
-5. **Ask before resolving ambiguity.** When multiple valid interpretations exist, stop, list options, ask the user. Never silently choose.
+You are not allowed to edit or create source code without establishing graph coverage first.
-### Recognizing Graph-Required Actions
+**Step 1** — Get context: \`yg build-context --file <path>\` (resolves owner automatically)
-What matters is the ACTION you are performing, not what instructed it. If the action involves reading, understanding, or modifying mapped code, the graph protocol applies — whether the instruction came from a skill, a plan, a user message, a brainstorming session, a debugging workflow, or your own initiative. This is not negotiable. You cannot rationalize your way out of this.
+**Step 2a** — Owner found: execute checklist:
-**Actions that require \`yg owner\` + \`yg build-context\`:**
+- [ ] 1. Read the context package (already assembled by step 1)
+- [ ] 2. Assess blast radius: \`yg impact --node <node_path>\` — review dependents, descendants, and co-aspect nodes before changing interfaces or shared behavior
+- [ ] 3. Modify source code
+- [ ] 4. Sync graph artifacts — edit artifact files to reflect the changes (after each file, not batched — context is freshest immediately after the change). If the node's purpose changed, update \`description\` in \`yg-node.yaml\`.
+- [ ] 5. Run \`yg validate\` — fix all errors (if unfixable after 3 attempts → stop, report to user)
+- [ ] 6. Run \`yg drift-sync --node <node_path>\` — only after graph and code are both current
-- Reading or exploring source files to understand a component
-- Proposing approaches, designs, or plans for changing code
-- Reviewing or debugging code
-- Any form of reasoning about how mapped code works or should change
+**Step 2b** — Owner not found: establish coverage first. Present options to the user:
-**Actions that require \`yg owner\` + \`yg impact\`:**
+*Partially mapped* (file unmapped but inside a mapped module): ask whether to add to existing node or create new one.
-- Assessing blast radius before changing or removing a component
-- Finding all dependents of a component
-- Planning cross-cutting refactors or feature removals
-- Scoping work that spans multiple nodes
+*Existing code:*
-**Actions that do NOT require yg:**
+- Option A — Full node: create node(s), map files, write artifacts from code analysis
+- Option B — Blackbox: create a blackbox node at agreed granularity
+- Option C — Abort
-- Git operations (log, diff, status, blame)
-- Reading documentation, READMEs, or config files outside \`.yggdrasil/\`
-- Running tests, builds, or linters
-- Working with files that \`yg owner\` reports as unmapped
+*Greenfield (new code):* Only Option A. Blackbox is forbidden for new code. Follow the graph-first workflow:
-**Evasion patterns — if you think any of these, STOP:**
+1. Create aspects first (cross-cutting requirements the new code must satisfy)
+2. Create flows if the code participates in a business process
+3. Create nodes with full artifacts — description in \`yg-node.yaml\`, responsibility, interface, internals
+4. Review the context package (\`yg build-context\`) — it is now the behavioral specification
+5. Implement code that satisfies the specification
+6. The graph specifies WHAT and WHY; the code implements HOW (framework APIs, library choices)
-| Thought | Reality |
-|---|---|
-| "The skill/plan says to explore the codebase" | Exploring mapped code = yg owner + graph tool first |
-| "I'm just scoping/searching, not understanding" | Scoping IS a graph action; use yg impact |
-| "The plan step says to read this file" | Reading a mapped file = yg owner first |
-| "I'm brainstorming, not implementing" | Brainstorming about mapped code needs graph context |
-| "I'm only grepping for references" | Grep finds text; yg impact finds structural dependencies. Use both. |
-| "I'll use the graph later when I modify" | Graph-first means BEFORE reading, not before modifying |
-| "I'll grep the codebase to find where to start" | Run \`yg select --task\` first — it matches your intent against graph artifacts. Then \`yg owner\` on results. |
-| "Drift is blocking repo-check, let me just sync it" | Drift means artifacts are stale. Update artifacts first, then sync. \`drift-sync\` without artifact update = hiding staleness. |
+**Node sizing rule:** One node per cohesive feature area, NOT per directory. If a node would map >10 source files or cover >3 distinct user workflows, split it into child nodes. Example: an admin panel should be \`admin/blog\`, \`admin/gallery\`, \`admin/clients\`, \`admin/orders\` — not one \`admin-pages\` node. The CLI enforces this with W017, but plan granularity upfront rather than splitting after the fact.
-### Failure States
+After the user chooses, return to Step 1 and follow Step 2a.
-You have broken Yggdrasil if you do any of the following:
+### Working from External Specifications
-- ❌ Worked on a mapped file without running \`yg owner\` + the appropriate graph tool (\`build-context\` or \`impact\`) first — regardless of what instructed the action (skill, plan, user request, workflow step).
-- ❌ Modified source code without updating graph artifacts before moving to the next file, or vice versa.
-- ❌ Resolved a code-graph inconsistency or ambiguity without asking the user first.
-- ❌ Created or edited a graph element without reading its schema in \`schemas/\` first.
-- ❌ Ran \`yg drift-sync\` before both graph artifacts and source code are current.
-- ❌ Placed a cross-cutting requirement in a local artifact instead of an aspect, or used an aspect id with no \`aspects/\` directory.
-- ❌ Invented a rationale, business rule, or decision — or recorded a decision without documenting rejected alternatives and rationale (use "rationale: unknown" if unknown).
-- ❌ Used blackbox coverage for greenfield (new) code.
-- ❌ Deleted or shortened graph artifact content to reduce context package size instead of splitting the node.
+When the user provides external documents (specs, PRDs, design docs, reference docs) as input for implementation:
-### Escape Hatch
+1. **Read ALL spec documents BEFORE writing any code.** Understand the full scope — business context, feature specs, quality requirements, UX rules, deployment config.
+2. **Extract and route knowledge to the graph FIRST**, using the Information Routing table:
+   - Business rules, personas, pricing strategy, acquisition channels → aspects or root node artifacts
+   - Feature specifications (UI behavior, validation, workflows) → node responsibility/interface/internals artifacts
+   - Cross-cutting UX/quality requirements → aspects
+   - Business processes → flows
+3. **The graph is the specification; external docs are INPUT to the graph, not a parallel source of truth.** After the graph is populated, external docs become redundant — the graph is what future agents will read.
+4. **Spec knowledge is not code knowledge.** Specs contain business context (WHY the system exists, WHO it serves, WHAT it should do) that will never appear in source code. If you only document what you built, you lose what motivated building it.
+5. **Completeness test:** "If the external docs disappeared today, does the graph contain everything a future agent needs to understand the system — not just HOW it works, but WHY it exists and WHAT business value it delivers?"
-If the user explicitly requests a code-only change, comply but:
+**Common failure mode:** Agent reads spec → implements code → documents code in graph → spec knowledge (personas, pricing, UX rationale, quality targets) is lost because it was treated as "input I consumed" rather than "knowledge I must persist." The graph must absorb the spec, not just the code.
-- Warn: "This creates drift. Run \`yg drift\` next session to reconcile."
-- Do NOT run \`yg drift-sync\` — leave the drift visible.
+### Example: Correct vs Wrong
-### Environment Check
+<example_correct>
-Before preflight:
+User: "Fix the bug in payment.service.ts"
-- Verify \`yg\` CLI is available. If not found, inform user and stop.
-- If \`yg preflight\` shows 0 nodes → enter BOOTSTRAP MODE (see Operations).
-- If drift report shows >10 drifted nodes → report scope to user, ask which area to prioritize. Do not resolve all at once.
+1. yg build-context --file src/payment.service.ts → payment/payment-service
+2. Read YAML map — glossary, then artifact files
+3. Read source file, understand bug in graph context
+4. Fix bug
+5. Update payment-service artifacts (responsibility.md, interface.md if API changed)
+6. yg validate
+7. yg drift-sync --node payment/payment-service
-### Delegating to Subagents
+</example_correct>
-When you delegate work to a subagent (any subprocess, tool agent, or spawned assistant), the subagent does NOT inherit your Yggdrasil knowledge. Before any other instruction, the subagent MUST:
+<example_wrong>
-1. Read \`.yggdrasil/agent-rules.md\` — this is the complete operating manual
-2. Follow the Quick Start Protocol from that file before touching any mapped code
+User: "Fix the bug in payment.service.ts"
-Include this as the FIRST instruction in every subagent prompt:
+1. Read src/payment.service.ts ← WRONG: no graph context loaded
+2. Fix bug
+3. "I'll update the graph later" ← WRONG: deferred = forgotten
-\`\`\`
-BEFORE doing anything else: read .yggdrasil/agent-rules.md and follow its protocol.
-DELIVERABLES — all required, incomplete work will be rejected:
-  1. Working source code
-  2. Graph nodes with artifacts for every new/modified source file
-  3. \`yg validate\` passing
-\`\`\`
+Result: graph is stale, next agent asks user the same questions
-A subagent that delivers code without corresponding graph updates has not completed its task. Before accepting subagent output, verify: are there new or modified source files without corresponding graph coverage? If yes, the work is incomplete.`;
+</example_wrong>
-// prettier-ignore
-const OPERATIONS = `## OPERATIONS
+<example_correct>
+User: "Here are the spec docs. Implement the admin blog editor."
+1. Read ALL spec docs (blog-editor.md, autosave.md, user-persona.md, version-history.md)
+2. Extract cross-cutting patterns → create aspects (admin-ux-rules, autosave, version-history) if they don't exist
+3. Create flow if the blog participates in a business process
+4. Create node admin/blog with artifacts populated from spec (responsibility, interface, internals)
+5. Run yg build-context → the context package is now the behavioral specification
+6. Implement code that satisfies the specification
+7. Update artifacts with any implementation details that emerged during coding
+8. yg validate, yg drift-sync
+</example_correct>
+<example_wrong>
+User: "Here are the spec docs. Implement the admin blog editor."
+1. Read blog-editor.md spec
+2. Implement all the code ← WRONG: spec knowledge not captured in graph
+3. Create node admin-pages, map 20 admin files ← WRONG: too wide, W017
+4. Write responsibility.md summarizing what the code does ← WRONG: describes code, not spec intent
+5. Business context (persona, UX rules, autosave rationale) lost ← WRONG: spec was input, not persisted
+Result: graph mirrors code but misses WHY. Next agent reads graph, understands HOW but not WHO it's for or WHAT UX rules govern it.
+</example_wrong>
 ### Conversation Lifecycle
@@ -165,66 +171,26 @@ PREFLIGHT (every conversation, before any work):
   - [ ] 1. yg preflight → read unified report
   - [ ] 2. If drift: resolve per Drift Resolution, then yg drift-sync per node
   - [ ] 3. If validation errors: fix, re-run yg validate
-  Exception: read-only requests (explain, analyze) — skip preflight.
-UNDERSTANDING mapped code (questions, research, OR planning):
-  - [ ] 1. yg owner --file <path>
-  - [ ] 2. Owner found → yg build-context --node <path>. Read the YAML map
-         for topology, starting with the glossary at the top for aspect and
-         flow definitions, then read artifact files listed inline on each
-         element. For quick orientation, the map alone is sufficient. For
-         implementation, read all artifact files before changing code.
-  - [ ] 3. Owner not found → use file analysis, state it is not graph-backed.
+  No exceptions. You cannot know if a file is mapped without running yg.
+UNDERSTANDING any source file (questions, research, OR planning):
+  - [ ] 1. yg build-context --file <path>
+         Mapped → read the YAML map (glossary first, then artifact files).
+         Unmapped → use file analysis, state it is not graph-backed.
   Never use grep or raw file reads as primary understanding when graph coverage exists.
   Raw reads supplement the context package — they do not replace it.
+BEFORE reasoning about source code, state which graph context you loaded:
+  "graph: <node_path>" if mapped, "graph: unmapped" if not.
+  This is a required output step, not optional reflection.
 WRAP-UP (user signals "done", "wrap up", "that's enough"):
   - [ ] 1. yg drift --drifted-only → resolve
   - [ ] 2. yg validate → fix errors
   - [ ] 3. Report: which nodes and files were changed
-BEFORE ENDING ANY RESPONSE (self-audit):
-  - [ ] Did I interact with mapped code (read, research, or modify)? If yes → did I use a graph tool BEFORE reading source?
-  - [ ] Did I modify source code? If yes → did I update graph artifacts before moving to the next file?
-  - [ ] If you broke either rule, you have broken the protocol. Do not finish until both are fixed.
 \`\`\`
-### Modify Source Code
-You are not allowed to edit or create source code without establishing graph coverage first.
-**Step 1** — Check coverage: \`yg owner --file <path>\`
-**Step 2a** — Owner found: execute checklist:
-- [ ] 1. Read specification: \`yg build-context --node <node_path>\`
-- [ ] 2. Assess blast radius: \`yg impact --node <node_path>\` — review dependents, descendants, and co-aspect nodes before changing interfaces or shared behavior
-- [ ] 3. Modify source code
-- [ ] 4. Sync graph artifacts — edit artifact files to reflect the changes (after each file, not batched — context is freshest immediately after the change). If the node's purpose changed, update \`description\` in \`yg-node.yaml\`.
-- [ ] 5. Run \`yg validate\` — fix all errors (if unfixable after 3 attempts → stop, report to user)
-- [ ] 6. Run \`yg drift-sync --node <node_path>\` — only after graph and code are both current
-**Step 2b** — Owner not found: establish coverage first. Present options to the user:
-*Partially mapped* (file unmapped but inside a mapped module): ask whether to add to existing node or create new one.
-*Existing code:*
-- Option A — Full node: create node(s), map files, write artifacts from code analysis
-- Option B — Blackbox: create a blackbox node at agreed granularity
-- Option C — Abort
-*Greenfield (new code):* Only Option A. Blackbox is forbidden for new code. Follow the graph-first workflow:
-1. Create aspects first (cross-cutting requirements the new code must satisfy)
-2. Create flows if the code participates in a business process
-3. Create nodes with full artifacts — description in \`yg-node.yaml\`, responsibility, interface, internals
-4. Review the context package (\`yg build-context\`) — it is now the behavioral specification
-5. Implement code that satisfies the specification
-6. The graph specifies WHAT and WHY; the code implements HOW (framework APIs, library choices)
-After the user chooses, return to Step 1 and follow Step 2a.
 ### Modify Graph
 - [ ] 1. Read the relevant schema from \`schemas/\` before touching any YAML
@@ -234,90 +200,27 @@ After the user chooses, return to Step 1 and follow Step 2a.
 - [ ] 5. Verify affected source files are consistent — update if needed
 - [ ] 6. Run \`yg drift-sync\` for affected nodes
-### Reverse Engineering
-**Order:** aspects (cross-cutting patterns) → flows (business processes) → model nodes. Never create nodes before aspects and flows are understood.
-Per area checklist:
-- [ ] 1. \`yg owner --file <path>\` — confirm no coverage
-- [ ] 2. Determine node granularity — propose to user if unclear
-- [ ] 3. Create node directory, read \`schemas/yg-node.yaml\`, create \`yg-node.yaml\`
-- [ ] 3b. Write \`description\` in \`yg-node.yaml\` — a short summary of what the node does
-- [ ] 4. Analyze source — for each artifact type in \`yg-config.yaml artifacts\`: extract content, do not invent
-- [ ] 5. Identify relations — add to \`yg-node.yaml\`
-- [ ] 6. Identify cross-cutting requirements — add matching aspects, create if needed
-- [ ] 6b. For each aspect on the node: identify 2-5 code anchors (function names, constants) that evidence the pattern → add as \`anchors\` in the aspect entry in \`yg-node.yaml\`
-- [ ] 7. Identify business process participation — add to flow, ask user if process unclear
-- [ ] 8. \`yg validate\` — fix errors
-- [ ] 9. \`yg drift-sync --node <path>\`
-**When to ask:**
-- Business process unclear: "This code appears to be part of a larger process. Can you describe what it means from a business perspective?"
-- Constraint without rationale: "I see [constraint X]. Do you know why this exists? I want to record the reason, not just the rule."
-- Unexplained architectural choice: "I see [approach X]. What was the reason for this choice?"
-- Decision without alternatives: "You chose [X]. What alternatives did you consider, and why did you reject them?" Record the answer in the Decisions section of \`internals.md\`.
-- Decision without known rationale: Record the decision in \`internals.md\` with "rationale: unknown — inferred from code, not confirmed by developer." A recorded decision with unknown rationale is infinitely more valuable than no record at all, and safer than an invented rationale.
-### Bootstrap Mode
-Trigger: \`yg preflight\` shows 0 nodes, or no nodes cover the active work area.
-- [ ] 1. Identify the active work area (files the user wants to modify)
-- [ ] 2. Scan for cross-cutting patterns → create aspects
-- [ ] 3. Ask user about business processes → create flows if applicable
-- [ ] 4. Propose node structure for the area
-- [ ] 5. Create node(s) with initial artifacts, map files
-- [ ] 6. \`yg validate\`, \`yg drift-sync\`
-- [ ] 7. Proceed with user's original request
-Constraint: Do NOT map the entire repository. Focus on the active area. Expand incrementally.
-### Drift Resolution
-Always ask the user before resolving drift. Never auto-resolve.
-- **Source drift** (source files changed) → update graph artifacts to match source, then \`yg drift-sync\`
-- **Graph drift** (graph artifacts changed) → review affected source, update if needed, then \`yg drift-sync\`
-- **Full drift** (both changed) → present both sides to user, ask which direction wins
-- **Missing** → ask: re-materialize or remove mapping?
-- **Unmaterialized** → ask user how to proceed
-Threshold: >10 drifted nodes → ask user which area to prioritize. Do not resolve all at once.
-**Drift triage:** Prioritize aspects and \`internals.md\` (highest decay rate), then \`responsibility.md\` and \`interface.md\` (most stable).
-### Graph Audit
-When reviewing graph quality (triggered by user or quality improvement):
-**Step 1 — Consistency** (catches WRONG information):
+### Delegating to Subagents
-- [ ] 1. \`yg build-context --node <path>\`
-- [ ] 2. Read mapped source files
-- [ ] 3. For each claim in graph: verify against source code
-- [ ] 4. For each aspect: verify the pattern holds in THIS node. If it deviates, add \`exceptions\` to the aspect entry in \`yg-node.yaml\`
-- [ ] 5. Report inconsistencies
+When you delegate work to a subagent (any subprocess, tool agent, or spawned assistant), the subagent does NOT inherit your Yggdrasil knowledge. Before any other instruction, the subagent MUST:
-**Step 2 — Completeness** (catches MISSING information):
+1. Read \`.yggdrasil/agent-rules.md\` — this is the complete operating manual
+2. Follow the Quick Start Protocol from that file before touching any mapped code
-- [ ] 1. For each public method: is it in \`interface.md\`?
-- [ ] 2. For each error path: is it in \`interface.md\` (Failure Modes section)?
-- [ ] 3. For each behavioral invariant: is it in the graph?
-- [ ] 4. Report omissions separately from inconsistencies
+Include this as the FIRST instruction in every subagent prompt:
-### Error Recovery
+\`\`\`
+BEFORE doing anything else: read .yggdrasil/agent-rules.md and follow its protocol.
+DELIVERABLES — all required, incomplete work will be rejected:
+  1. Working source code
+  2. Graph nodes with artifacts for every new/modified source file
+  3. \`yg validate\` passing
+\`\`\`
-- **\`yg\` not found** → inform user: "yg CLI is not installed or not in PATH." Stop.
-- **Unfixable validate errors** → if not resolved after 3 attempts, stop and report to user. Do not loop.
-- **Budget warning (W005/W006)** → informational. \`yg validate\` shows a breakdown (own/hierarchy/aspects/flows/dependencies). Large inherited context means the system is complex — this is not a problem to fix, it is reality to acknowledge. Do not delete knowledge from artifacts. Do not attempt to "reduce" inherited context.
-- **Own budget warning (W015)** → own artifacts are large. Consider splitting this node's responsibilities into child nodes. Redistribute knowledge across children so total knowledge is preserved or increased, never reduced.
-- **Corrupted \`.yggdrasil/\` files** → report to user. Do not attempt repair.
-- **Incremental sync** → run \`yg drift-sync\` every 3-5 source files during multi-file tasks. Do not defer to end. But NEVER run \`yg drift-sync\` to silence a failing drift check — drift is a signal that artifacts need updating. First update artifacts, then sync.`;
+A subagent that delivers code without corresponding graph updates has not completed its task. Before accepting subagent output, verify: are there new or modified source files without corresponding graph coverage? If yes, the work is incomplete.`;
 // prettier-ignore
-const KNOWLEDGE_BASE = `## KNOWLEDGE BASE
+const REFERENCE = `## REFERENCE
 ### Graph Structure
@@ -382,6 +285,10 @@ When you encounter information, route it to the correct location:
 - **Shared across a domain** → parent node artifact. Children receive it through hierarchy.
 - **Technology stack or standard** → node artifact at the appropriate hierarchy level (e.g., root node's \`responsibility.md\` for single-stack repos, or deployment unit node for monorepos)
 - **Decision (why + why NOT):** one node → Decisions section of \`internals.md\` with format "Chose X over Y because Z"; category of nodes → aspect content files; tech choice → node artifact at the level where the technology applies. Always include rejected alternatives — they are the highest-value graph content. If the rationale is unknown: record the decision with "rationale: unknown" and note what CAN be observed from the code. Never invent a plausible-sounding rationale.
+- **Business strategy** (personas, pricing, acquisition channels, brand positioning) → root node artifact or dedicated business-context aspect. This knowledge has NO source file — it exists only in specs and conversations.
+- **Quality targets** (performance budgets, accessibility level, Lighthouse scores, test coverage goals) → aspect per quality dimension (e.g., \`performance-targets\`, \`accessibility\`). These are measurable cross-cutting constraints.
+- **UX patterns** (autosave, version history, empty states, confirmation modals) → aspect when the pattern applies to 3+ screens. UX patterns are cross-cutting even if they aren't architectural.
+- **Infrastructure/deployment** (domains, DNS, env vars, CI/CD, cron scheduling, hosting config) → infrastructure node or root node artifacts. Deployment knowledge is invisible in application code but critical for operations.
 ### Creating Aspects
@@ -430,18 +337,52 @@ Test: "Does this describe what happens in the world, or only in the software?" I
 - **Tools read, you write.** The \`yg\` CLI only reads, validates, and manages metadata. You create and edit files manually.
 - **Incremental sync.** Run \`yg drift-sync\` after every 3-5 source file changes. Do not defer to end of task. \`drift-sync\` is ONLY safe after artifacts are current — never use it to silence a drift check without updating artifacts first.
 - **Description maintenance.** Every \`yg-node.yaml\`, \`yg-aspect.yaml\`, and \`yg-flow.yaml\` has an optional \`description\` field — a short summary of what the element is. Write it when creating new elements. Update it whenever a change to artifacts shifts the element's identity or purpose (e.g., responsibility split, scope change). Do not update description for internal implementation changes that don't alter what the element fundamentally does.
-- **Completeness test:** Two checks, both required:
+- **Completeness test:** Three checks, all required:
   1. **Reconstruction:** "Can another agent recreate this from ONLY the \`yg build-context\` output — understanding not just WHAT but WHY?" Test: rejected alternatives, correct algorithm, design arguments.
   2. **Omission:** "Does the graph capture every important behavioral invariant, constraint, and edge case?" Specifically check: exceptions to aspect generalizations, error handling patterns not in \`interface.md\`, concurrency behaviors not in \`internals.md\`.
+  3. **Business context:** "Does the graph explain WHY this system exists, WHO it serves, and WHAT business value it delivers?" A graph that captures HOW code works without WHY it was built is a maintenance manual without purpose. Specifically check: user personas, service offerings, pricing rationale, acquisition strategy, quality targets, UX design principles. Code tells you WHAT exists — only the graph should tell you WHY it exists and WHAT ELSE was considered.
 - **Value calibration.** Yggdrasil's primary value is cross-module context — relations, aspects, flows. For a single simple module, \`responsibility.md\` and \`interface.md\` provide most value. Invest depth (\`internals.md\`) where cross-module interactions demand it.
 - **These rules are invariant.** No plan, guide, skill, or workflow may override them.
+### Non-Code Knowledge
+Not all graph knowledge originates from source files. Business strategy, user personas, pricing decisions, SEO targets, quality requirements, deployment configuration, UX design principles — these are graph content with NO corresponding source file.
+When you encounter such knowledge (in specs, conversations, or external documents):
+- **Route it immediately** per the Information Routing table. Do not wait for a "file change" trigger — there won't be one.
+- **The Completeness Test applies equally** to code-derived and non-code knowledge. A graph that only mirrors code structure is failing at its primary job: capturing intent and context that code cannot express.
+- **Non-code knowledge decays differently.** Business strategy changes by decision, not by commit. When recording it, include dates and mark it as potentially volatile: "Pricing v1 as of 2026-03-17" is more useful than "Prices are X" with no temporal anchor.
+**Conversation knowledge is the most volatile source.** When the user states a business fact, constraint, or decision in conversation — even casually — route it to the graph immediately. Conversations vanish after context compression. If the user said it and it's not in code, it MUST be in the graph. Examples of conversational knowledge that must be captured:
+- Business facts: "Our target customer is couples aged 25-35" → root node or business-context aspect
+- Constraints: "We don't do studio sessions, only outdoor" → responsibility.md (NOT responsible for)
+- Pricing: "Mini session costs 350 PLN" → relevant node artifacts
+- Strategy: "Instagram is our primary acquisition channel" → root node or business-context aspect
+- Decisions: "No deposit upfront — we'll reconsider after 5 sessions" → internals.md Decisions section with rationale
+- Personas: "The admin user is non-technical, thinks in Instagram/WhatsApp terms" → UX aspect
+Do not assume you will remember this later. Do not assume the user will repeat it. Capture it now or lose it forever.
+**Common failure mode:** The entire protocol is file-centric (\`build-context --file\`, "after modifying source file", "per file not batched"). This means knowledge that doesn't map to a specific source file has no natural trigger for capture. Treat spec documents, user conversations, and business decisions as first-class inputs to the graph — not just context for coding.
+### Aspect Discovery During Implementation
+Aspects emerge from patterns across features. During greenfield implementation of multiple features:
+- **After implementing 3+ features in the same area, pause and review:** Are there repeated patterns (autosave, version history, confirmation modals, empty states)? Are there shared UX rules from a persona doc? Are there quality requirements from specs? Extract them to aspects NOW.
+- **Do NOT wait until all features are done.** Aspect extraction after 3 features captures the pattern while context is fresh. After 30 features, the rationale is forgotten and the aspect becomes a mechanical extraction without WHY.
+- **Watch for "invisible" aspects:** UX patterns (autosave everywhere), quality constraints (WCAG level, Lighthouse targets), and business rules (Polish locale, price-in-grosz) are cross-cutting but don't feel "architectural." They are still aspects.
+- **Trigger:** If you notice yourself implementing the same pattern for the third time, stop coding and create the aspect first. Then continue with the aspect applied to the current and previous nodes.
 ### CLI Reference
 \`\`\`
 yg preflight [--quick]              Unified diagnostic: drift + status + validate.
-yg owner --file <path>              Find the node that owns this file.
-yg build-context --node <path>      Assemble context map with artifact paths (default).
+yg owner --file <path>              Find the node that owns this file (quick check).
+yg build-context --file <path>      Resolve owner + assemble context in one step.
+yg build-context --node <path>      Assemble context map for a known node.
 yg build-context --node <path> --full  Same map + file contents appended below separator.
 yg tree [--root <path>] [--depth N] Print graph structure.
 yg aspects                          List aspects with metadata (YAML output).
@@ -450,8 +391,9 @@ yg select --task <description> [--limit <n>]
                                     Find graph nodes relevant to a task description.
 yg deps --node <path> [--depth N] [--type structural|event|all]
                                     Show dependencies.
-yg impact --node <path> --simulate  Simulate blast radius of a planned change.
-yg impact --node <path> --method <name>  Filter impact to dependents consuming a specific method.
+yg impact --file <path>             Resolve owner + show blast radius in one step.
+yg impact --node <path> --simulate  Simulate blast radius (works with --file too).
+yg impact --node <path> --method <name>  Filter to dependents consuming a method (works with --file too).
 yg impact --aspect <id>             Show all nodes where aspect is effective.
 yg impact --flow <name>             Show flow participants and descendants.
 yg status                           Graph health: nodes, coverage, drift summary.
@@ -473,6 +415,203 @@ yg drift-sync --node <path> [--recursive] | --all
 | Process-level requirement | Flow \`aspects\` + aspect directory |
 | Context shared across a domain | Parent node artifact |
 | Technology stack | Node artifact at appropriate hierarchy level |
-| Coding standards | Node artifact at appropriate hierarchy level |`;
+| Coding standards | Node artifact at appropriate hierarchy level |
+| Business strategy (personas, pricing, channels) | Root node artifact or dedicated business-context aspect |
+| Quality targets (perf budgets, a11y, test goals) | Aspect per quality dimension |
+| UX patterns (autosave, version history, empty states) | Aspect when pattern applies to 3+ screens |
+| Infrastructure/deployment (domains, env vars, CI/CD) | Infrastructure node or root node artifacts |
+| External service config (Stripe fees, email limits) | Relevant node's \`internals.md\` Decisions section |
+| Feature spec from external doc | Node artifacts — translate spec into responsibility/interface/internals |`;
+// prettier-ignore
+const GUARD_RAILS = `## GUARD RAILS
+### Five Core Rules
+1. **Graph first.** Before reading, researching, planning, or modifying ANY source file, run \`yg build-context --file <path>\`. For blast radius, also run \`yg impact\`. The graph is your primary source of architectural understanding. For implementation-level precision (exact behavior, error paths, edge cases) — verify against source code after loading the context package.
+2. **The graph is the specification; code implements it.** The graph absorbs knowledge from every source — external docs, conversations, decisions — and must be self-sufficient. If all other sources disappeared, the graph alone must contain enough to understand the system. Do not leave knowledge in external documents and reference them — capture the knowledge in graph artifacts. Update graph artifacts immediately after each file change, while context is fresh — do not batch graph updates to the end of a task. Code and graph move together: code changed → graph updated before moving to the next file. Graph changed → source verified in the same response. When planning work — in any tool, skill, or workflow — graph updates are part of each step's definition of done, never a separate phase.
+3. **Never invent why.** The graph captures human intent. If you don't know why something was decided, ask. Never hallucinate rationale.
+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.
+5. **Ask before resolving ambiguity.** When multiple valid interpretations exist, stop, list options, ask the user. Never silently choose.
+### Recognizing Graph-Required Actions
+What matters is the ACTION you are performing, not what instructed it. If the action involves reading, understanding, or modifying mapped code, the graph protocol applies — whether the instruction came from a skill, a plan, a user message, a brainstorming session, a debugging workflow, or your own initiative. This is not negotiable. You cannot rationalize your way out of this.
+**Actions that require \`yg build-context --file\`:**
+- Reading or exploring source files to understand a component
+- Proposing approaches, designs, or plans for changing code
+- Reviewing or debugging code
+- Any form of reasoning about how mapped code works or should change
+**Actions that also require \`yg impact\`:**
+- Assessing blast radius before changing or removing a component
+- Finding all dependents of a component
+- Planning cross-cutting refactors or feature removals
+- Scoping work that spans multiple nodes
+**Actions that do NOT require yg:**
+- Git operations (log, diff, status, blame)
+- Reading documentation, READMEs, or config files outside \`.yggdrasil/\`
+- Running tests, builds, or linters
+- Working with files that \`yg build-context --file\` reports as unmapped
+### Evasion Patterns — if you think any of these, STOP
+| Thought | Reality |
+|---|---|
+| "The skill/plan says to explore the codebase" | Exploring mapped code = \`yg build-context --file\` first |
+| "I'm just scoping/searching, not understanding" | Scoping IS a graph action; use yg impact |
+| "The plan step says to read this file" | Reading any source file = \`yg build-context --file\` first |
+| "I'm brainstorming, not implementing" | Brainstorming about code needs graph context. You proved this by failing at it. |
+| "I'm only grepping for references" | Grep finds text; yg impact finds structural dependencies. Use both. |
+| "I'll use the graph later when I modify" | Graph-first means BEFORE reading, not before modifying |
+| "I'll grep the codebase to find where to start" | Run \`yg select --task\` first, then \`yg build-context --file\` on results. |
+| "Drift is blocking repo-check, let me just sync it" | Drift means artifacts are stale. Update artifacts first, then sync. \`drift-sync\` will warn you (W018). |
+| "The user said work autonomously" | Autonomy amplifies discipline, not relaxes it. More tasks = more graph updates, not fewer. |
+| "Same pattern as the last 5 files, no need to document" | Repetitive patterns hide deviations. Per-node coverage captures what aspects don't. The next agent won't know what you know now. |
+| "I'll batch graph updates at the end" | Batching = never. Context is freshest immediately after the change. Defer = forget. This is a failure state. |
+| "I'm saving context/tool calls by skipping graph" | Graph cost is constant per node. Skipping it creates unbounded future cost — the user re-explaining what you could have recorded. |
+| "I assumed this file isn't mapped" | You cannot know without running \`yg build-context --file\`. Assume nothing. |
+| "The spec is just input, I don't need to capture it" | Specs contain business context that code cannot express. Capture it or lose it. |
+| "This business knowledge will be obvious from the code" | Pricing strategy, personas, UX rationale, and quality targets are NEVER obvious from code. |
+| "I'll extract aspects after I finish all the features" | After 30 features the rationale is gone. Extract after 3. |
+| "This is a UX detail, not architecture" | UX patterns that apply to 3+ screens ARE cross-cutting requirements. Create an aspect. |
+| "The user just mentioned it casually, it's not a formal decision" | Casual statements ARE decisions. "We don't do studio" is a business constraint. Capture it now or lose it after context compression. |
+| "I'll remember this from the conversation" | No you won't. Context gets compressed. The user won't repeat it. Write it to the graph now. |
+### Failure States
+You have broken Yggdrasil if you do any of the following:
+- ❌ Worked on a source file without running \`yg build-context --file\` first — regardless of what instructed the action (skill, plan, user request, workflow step).
+- ❌ Modified source code without updating graph artifacts before moving to the next file, or vice versa.
+- ❌ Batched graph updates to "do later" — deferred = forgotten. Update after EACH file.
+- ❌ Resolved a code-graph inconsistency or ambiguity without asking the user first.
+- ❌ Created or edited a graph element without reading its schema in \`schemas/\` first.
+- ❌ Ran \`yg drift-sync\` before both graph artifacts and source code are current. (CLI will warn you: W018.)
+- ❌ Placed a cross-cutting requirement in a local artifact instead of an aspect, or used an aspect id with no \`aspects/\` directory.
+- ❌ Invented a rationale, business rule, or decision — or recorded a decision without documenting rejected alternatives and rationale (use "rationale: unknown" if unknown).
+- ❌ Used blackbox coverage for greenfield (new) code.
+- ❌ Deleted or shortened graph artifact content to reduce context package size instead of splitting the node.
+- ❌ Created one wide node for many files instead of granular nodes with focused responsibilities. (CLI will warn you: W017.)
+- ❌ Implemented features from a spec without first transferring spec knowledge (business context, UX rules, quality targets) into the graph. Code without captured intent is a maintenance trap.
+- ❌ Implemented 3+ features sharing a pattern (autosave, version history, empty states) without extracting it to an aspect. Deferred aspect discovery = lost rationale.
+- ❌ Left business strategy, personas, or quality targets only in external documents instead of routing them to graph artifacts. External docs are input; the graph is the persistent store.
+- ❌ Heard the user state a business fact, constraint, or decision in conversation and did not record it in the graph. Conversations are the most volatile knowledge source — they vanish after context compression and the user will not repeat them.
+### Reverse Engineering
+**Order:** aspects (cross-cutting patterns) → flows (business processes) → model nodes. Never create nodes before aspects and flows are understood.
+Per area checklist:
+- [ ] 1. \`yg build-context --file <path>\` — confirm no coverage
+- [ ] 2. Determine node granularity — propose to user if unclear
+- [ ] 3. Create node directory, read \`schemas/yg-node.yaml\`, create \`yg-node.yaml\`
+- [ ] 3b. Write \`description\` in \`yg-node.yaml\` — a short summary of what the node does
+- [ ] 4. Analyze source — for each artifact type in \`yg-config.yaml artifacts\`: extract content, do not invent
+- [ ] 5. Identify relations — add to \`yg-node.yaml\`
+- [ ] 6. Identify cross-cutting requirements — add matching aspects, create if needed
+- [ ] 6b. For each aspect on the node: identify 2-5 code anchors (function names, constants) that evidence the pattern → add as \`anchors\` in the aspect entry in \`yg-node.yaml\`
+- [ ] 7. Identify business process participation — add to flow, ask user if process unclear
+- [ ] 8. \`yg validate\` — fix errors
+- [ ] 9. \`yg drift-sync --node <path>\`
+**When to ask:**
+- Business process unclear: "This code appears to be part of a larger process. Can you describe what it means from a business perspective?"
+- Constraint without rationale: "I see [constraint X]. Do you know why this exists? I want to record the reason, not just the rule."
+- Unexplained architectural choice: "I see [approach X]. What was the reason for this choice?"
+- Decision without alternatives: "You chose [X]. What alternatives did you consider, and why did you reject them?" Record the answer in the Decisions section of \`internals.md\`.
+- Decision without known rationale: Record the decision in \`internals.md\` with "rationale: unknown — inferred from code, not confirmed by developer." A recorded decision with unknown rationale is infinitely more valuable than no record at all, and safer than an invented rationale.
+### Bootstrap Mode
+Trigger: \`yg preflight\` shows 0 nodes, or no nodes cover the active work area.
+- [ ] 1. Identify the active work area (files the user wants to modify)
+- [ ] 2. Scan for cross-cutting patterns → create aspects
+- [ ] 3. Ask user about business processes → create flows if applicable
+- [ ] 4. Propose node structure for the area
+- [ ] 5. Create node(s) with initial artifacts, map files
+- [ ] 6. \`yg validate\`, \`yg drift-sync\`
+- [ ] 7. Proceed with user's original request
+Constraint: Do NOT map the entire repository. Focus on the active area. Expand incrementally.
+### Drift Resolution
+Always ask the user before resolving drift. Never auto-resolve.
+- **Source drift** (source files changed) → update graph artifacts to match source, then \`yg drift-sync\`
+- **Graph drift** (graph artifacts changed) → review affected source, update if needed, then \`yg drift-sync\`
+- **Full drift** (both changed) → present both sides to user, ask which direction wins
+- **Missing** → ask: re-materialize or remove mapping?
+- **Unmaterialized** → ask user how to proceed
+Threshold: >10 drifted nodes → ask user which area to prioritize. Do not resolve all at once.
+**Drift triage:** Prioritize aspects and \`internals.md\` (highest decay rate), then \`responsibility.md\` and \`interface.md\` (most stable).
+### Graph Audit
+When reviewing graph quality (triggered by user or quality improvement):
+**Step 1 — Consistency** (catches WRONG information):
+- [ ] 1. \`yg build-context --node <path>\`
+- [ ] 2. Read mapped source files
+- [ ] 3. For each claim in graph: verify against source code
+- [ ] 4. For each aspect: verify the pattern holds in THIS node. If it deviates, add \`exceptions\` to the aspect entry in \`yg-node.yaml\`
+- [ ] 5. Report inconsistencies
+**Step 2 — Completeness** (catches MISSING information):
+- [ ] 1. For each public method: is it in \`interface.md\`?
+- [ ] 2. For each error path: is it in \`interface.md\` (Failure Modes section)?
+- [ ] 3. For each behavioral invariant: is it in the graph?
+- [ ] 4. Report omissions separately from inconsistencies
+**Step 3 — Non-Derivable Knowledge** (catches knowledge that exists ONLY in external docs or conversations, not in code):
+- [ ] 1. For each business rule embedded in code: is the WHY recorded in the graph, or only the WHAT visible in code?
+- [ ] 2. For each design decision: is the rationale AND rejected alternatives recorded?
+- [ ] 3. For each external constraint (brand guidelines, legal, UX persona, quality targets): is it in the graph?
+- [ ] 4. For each cross-cutting pattern implemented in 3+ places: does an aspect exist?
+- [ ] 5. Report non-derivable knowledge gaps separately — these are the highest-value omissions because they cannot be recovered by reading code.
+### Error Recovery
+- **\`yg\` not found** → inform user: "yg CLI is not installed or not in PATH." Stop.
+- **Unfixable validate errors** → if not resolved after 3 attempts, stop and report to user. Do not loop.
+- **Budget warning (W005/W006)** → informational. \`yg validate\` shows a breakdown (own/hierarchy/aspects/flows/dependencies). Large inherited context means the system is complex — this is not a problem to fix, it is reality to acknowledge. Do not delete knowledge from artifacts. Do not attempt to "reduce" inherited context.
+- **Own budget warning (W015)** → own artifacts are large. Consider splitting this node's responsibilities into child nodes. Redistribute knowledge across children so total knowledge is preserved or increased, never reduced.
+- **Corrupted \`.yggdrasil/\` files** → report to user. Do not attempt repair.
+- **Incremental sync** → run \`yg drift-sync\` every 3-5 source files during multi-file tasks. Do not defer to end. But NEVER run \`yg drift-sync\` to silence a failing drift check — drift is a signal that artifacts need updating. First update artifacts, then sync.
+### Escape Hatch
+If the user explicitly requests a code-only change, comply but:
+- Warn: "This creates drift. Run \`yg drift\` next session to reconcile."
+- Do NOT run \`yg drift-sync\` — leave the drift visible.
+### Environment Check
+Before preflight:
+- Verify \`yg\` CLI is available. If not found, inform user and stop.
+- If \`yg preflight\` shows 0 nodes → enter BOOTSTRAP MODE (see above).
+- If drift report shows >10 drifted nodes → report scope to user, ask which area to prioritize. Do not resolve all at once.
+<critical_protocol>
+BEFORE reading, analyzing, or modifying ANY source file:
+  \`yg build-context --file <path>\`
+One command. No exceptions. No "I'll do it later." No "this is just analysis."
+</critical_protocol>`;
-export const AGENT_RULES_CONTENT = [CORE_PROTOCOL, OPERATIONS, KNOWLEDGE_BASE].join('\n\n---\n\n') + '\n';
+export const AGENT_RULES_CONTENT = [PROTOCOL, REFERENCE, GUARD_RAILS].join('\n\n---\n\n') + '\n';