@rune-kit/rune 2.1.1

package/skills/skill-forge/SKILL.md

@@ -0,0 +1,317 @@
+---
+name: skill-forge
+description: Use when creating new Rune skills, editing existing skills, or verifying skill quality before deployment. Applies TDD discipline to skill authoring — test before write, verify before ship.
+metadata:
+  author: runedev
+  version: "1.0.0"
+  layer: L2
+  model: opus
+  group: creation
+  tools: "Read, Write, Edit, Bash, Glob, Grep"
+---
+
+# skill-forge
+
+## Purpose
+
+The skill that builds skills. Applies Test-Driven Development to skill authoring: write a pressure test first, watch agents fail without the skill, write the skill to fix those failures, then close loopholes until bulletproof. Ensures every Rune skill is battle-tested before it enters the mesh.
+
+## Triggers
+
+- `/rune skill-forge` — manual invocation to create or edit a skill
+- Auto-trigger: when user says "create a skill", "new skill", "add skill to rune"
+- Auto-trigger: when editing any `skills/*/SKILL.md` file
+
+## Calls (outbound)
+
+- `scout` (L3): scan existing skills for patterns and naming conventions
+- `plan` (L2): structure complex skills with multiple phases
+- `hallucination-guard` (L3): verify referenced skills/tools actually exist
+- `verification` (L3): validate SKILL.md format compliance
+- `journal` (L3): record skill creation decisions in ADR
+
+## Called By (inbound)
+
+- `cook` (L1): when the feature being built IS a new skill
+
+## Workflow
+
+### Phase 1 — DISCOVER
+
+Before writing anything, understand the landscape:
+
+1. **Scan existing skills** via `scout` — is this already covered?
+2. **Check for overlap** — will this duplicate or conflict with existing skills?
+3. **Identify layer** — L1 (orchestrator), L2 (workflow hub), L3 (utility)?
+4. **Identify mesh connections** — what calls this? What does this call?
+
+<HARD-GATE>
+If a skill with >70% overlap already exists → extend it, don't create new.
+The mesh grows stronger by deepening connections, not by adding nodes.
+</HARD-GATE>
+
+### Phase 2 — RED (Baseline Test)
+
+**Write the test BEFORE writing the skill.**
+
+Create a pressure scenario that exposes the problem the skill solves:
+
+```markdown
+## Pressure Scenario: [skill-name]
+
+### Setup
+[Describe the situation an agent faces]
+
+### Pressures (combine 2-3)
+- Time pressure: "This is urgent, just do it"
+- Sunk cost: "I already wrote 200 lines, can't restart"
+- Complexity: "Too many moving parts to follow process"
+- Authority: "Senior dev says skip testing"
+- Exhaustion: "We're 50 tool calls deep"
+
+### Expected Failure (without skill)
+[What the agent will probably do wrong]
+
+### Success Criteria (with skill)
+[What the agent should do instead]
+```
+
+Run the scenario with a subagent WITHOUT the skill. Document:
+- **Exact behavior** — what did the agent do?
+- **Rationalizations** — verbatim excuses for skipping discipline
+- **Failure point** — where exactly did it go wrong?
+
+<HARD-GATE>
+You MUST observe at least one failure before writing the skill.
+No failure observed = you don't understand the problem well enough to write the solution.
+</HARD-GATE>
+
+### Phase 3 — GREEN (Write Minimal Skill)
+
+Write the SKILL.md addressing ONLY the failures observed in Phase 2.
+
+Follow `docs/SKILL-TEMPLATE.md` format. Required sections:
+
+| Section | Required | Purpose |
+|---|---|---|
+| Frontmatter | YES | Name, description, metadata |
+| Purpose | YES | One paragraph, ecosystem role |
+| Triggers | YES | When to invoke |
+| Calls / Called By | YES | Mesh connections |
+| Workflow | YES | Step-by-step execution |
+| Output Format | YES | Structured, parseable output |
+| Constraints | YES | 3-7 MUST/MUST NOT rules |
+| Sharp Edges | YES | Known failure modes |
+| Done When | YES | Verifiable completion criteria |
+| Cost Profile | YES | Token estimate |
+| Mesh Gates | L1/L2 only | Progression guards |
+
+#### Frontmatter Rules
+
+```yaml
+---
+name: kebab-case-max-64-chars    # letters, numbers, hyphens only
+description: Use when [specific triggers]. [Symptoms that signal this skill applies].
+metadata:
+  layer: L1|L2|L3
+  model: haiku|sonnet|opus       # haiku=scan, sonnet=code, opus=architecture
+  group: [see template]
+---
+```
+
+**Description rules:**
+- MUST start with "Use when..."
+- MUST describe triggering conditions, NOT workflow
+- MUST be third person
+- MUST NOT summarize what the skill does internally
+
+```yaml
+# BAD: Summarizes workflow — agent reads description, skips full content
+description: TDD workflow that writes tests first, then code, then refactors
+
+# GOOD: Only triggers — agent must read full content to know workflow
+description: Use when implementing any feature or bugfix, before writing code
+```
+
+**Why this matters:** When description summarizes the workflow, agents take the shortcut — they follow the description and skip the full SKILL.md. Tested and confirmed.
+
+#### Writing Constraints
+
+Every constraint MUST block a specific failure mode observed in Phase 2:
+
+```markdown
+# BAD: Generic rule
+1. MUST write good code
+
+# GOOD: Blocks specific failure with consequence
+1. MUST run tests after each fix — batch-and-pray causes cascading regressions
+```
+
+#### Anti-Rationalization Table
+
+Capture every excuse from Phase 2 baseline testing:
+
+```markdown
+| Excuse | Reality |
+|--------|---------|
+| "[verbatim excuse from test]" | [why it's wrong + what to do instead] |
+```
+
+### Phase 4 — VERIFY (Green Check)
+
+Run the SAME pressure scenario from Phase 2, now WITH the skill loaded.
+
+Check:
+- Does the agent follow the skill's workflow?
+- Are all constraints respected under pressure?
+- Does the output match the defined format?
+
+<HARD-GATE>
+If agent still fails with skill loaded → skill is insufficient.
+Go back to Phase 3, strengthen the weak section. Do NOT ship.
+</HARD-GATE>
+
+### Phase 5 — REFACTOR (Close Loopholes)
+
+Run additional pressure scenarios with varied pressures. For each new failure:
+
+1. Identify the rationalization
+2. Add it to the anti-rationalization table
+3. Add explicit constraint or sharp edge
+4. Re-run verification
+
+Repeat until no new failures emerge in 2 consecutive test runs.
+
+### Phase 6 — INTEGRATE
+
+Wire the skill into the mesh:
+
+1. **Update `docs/ARCHITECTURE.md`** — add to correct layer/group table
+2. **Update `CLAUDE.md`** — increment skill count, add to layer list
+3. **Add mesh connections** — update SKILL.md of skills that should call/be called by this one
+4. **Verify no conflicts** — new skill's output format compatible with consumers?
+
+### Phase 7 — SHIP
+
+```bash
+git add skills/[skill-name]/SKILL.md
+git add docs/ARCHITECTURE.md CLAUDE.md
+# Add any updated existing skills
+git commit -m "feat: add [skill-name] — [one-line purpose]"
+```
+
+## Skill Quality Checklist
+
+**Format:**
+- [ ] Name is kebab-case, max 64 chars, letters/numbers/hyphens only
+- [ ] Description starts with "Use when...", does NOT summarize workflow
+- [ ] All template sections present
+- [ ] Constraints are specific (not generic "write good code")
+- [ ] Sharp edges have severity + mitigation
+
+**Content:**
+- [ ] Baseline test run BEFORE skill was written
+- [ ] At least one observed failure documented
+- [ ] Anti-rationalization table from real test failures
+- [ ] Mesh connections bidirectional (calls AND called-by both updated)
+- [ ] Output format is structured and parseable by other skills
+
+**Architecture:**
+- [ ] Layer assignment correct (L1=orchestrate, L2=workflow, L3=utility)
+- [ ] Model assignment correct (haiku=scan, sonnet=code, opus=architect)
+- [ ] No >70% overlap with existing skills
+- [ ] ARCHITECTURE.md updated
+- [ ] CLAUDE.md updated
+
+## Adapting Existing Skills
+
+When editing, not creating:
+
+<HARD-GATE>
+Same TDD cycle applies to edits.
+1. Write a test that exposes the gap in the current skill
+2. Run baseline — confirm the skill fails on this scenario
+3. Edit the skill to address the gap
+4. Verify the edit fixes the gap WITHOUT breaking existing behavior
+</HARD-GATE>
+
+"Just adding a section" is not an excuse to skip testing.
+
+## Token Efficiency Guidelines
+
+Skills are loaded into context when invoked. Every word costs tokens.
+
+| Skill Type | Target | Notes |
+|---|---|---|
+| L3 utility (haiku) | <300 words | Runs frequently, keep lean |
+| L2 workflow hub | <500 words | Moderate frequency |
+| L1 orchestrator | <800 words | Runs once per workflow |
+| Reference sections | Extract to separate file | >100 lines → own file |
+
+Techniques:
+- Reference `--help` instead of documenting all flags
+- Cross-reference other skills instead of repeating content
+- One excellent example > three mediocre ones
+- Inline code only if <50 lines, otherwise separate file
+
+## Output Format
+
+```
+## Skill Forge Report
+- **Skill**: [name] (L[layer])
+- **Action**: CREATE | EDIT
+- **Status**: SHIPPED | NEEDS_WORK | BLOCKED
+
+### Baseline Test
+- Scenario: [test scenario description]
+- Result WITHOUT skill: [observed failure]
+- Result WITH skill: [observed success or remaining gap]
+
+### Quality Checklist
+- Format: [pass/fail count]
+- Content: [pass/fail count]
+- Architecture: [pass/fail count]
+
+### Files Created/Modified
+- skills/[name]/SKILL.md — [created | modified]
+- docs/ARCHITECTURE.md — [updated | skipped]
+- CLAUDE.md — [updated | skipped]
+
+### Mesh Impact
+- New connections: [count] ([list of skills])
+- Bidirectional check: PASS | FAIL
+```
+
+## Constraints
+
+1. MUST run baseline test BEFORE writing skill — no skill without observed failure
+2. MUST verify skill fixes the observed failures — green check required before ship
+3. MUST NOT create skill with >70% overlap with existing — extend instead
+4. MUST follow SKILL-TEMPLATE.md format — all required sections present
+5. MUST update ARCHITECTURE.md and CLAUDE.md on every new skill
+6. MUST NOT ship skill that fails its own pressure test
+7. MUST write description as triggers only — never summarize workflow in description
+
+## Sharp Edges
+
+| Failure Mode | Severity | Mitigation |
+|---|---|---|
+| Writing skill without baseline test | CRITICAL | Phase 2 HARD-GATE: must observe failure first |
+| Description summarizes workflow → agents skip content | HIGH | Phase 3 description rules: "Use when..." triggers only |
+| New skill duplicates existing skill | HIGH | Phase 1 HARD-GATE: >70% overlap → extend, don't create |
+| Skill passes test but breaks mesh connections | MEDIUM | Phase 6 integration: verify output compatibility |
+| Editing skill without testing the edit | MEDIUM | Adapting section: same TDD cycle for edits |
+| Overly verbose skill burns context tokens | MEDIUM | Token efficiency guidelines: layer-based word targets |
+
+## Done When
+
+- Baseline test documented with observed failures
+- SKILL.md follows template format completely
+- Skill passes pressure test (agent complies with skill loaded)
+- No new failures in 2 consecutive varied-pressure test runs
+- Mesh connections wired (ARCHITECTURE.md, CLAUDE.md, related skills)
+- Git committed with conventional commit message
+
+## Cost Profile
+
+~3000-8000 tokens per skill creation (opus for Phase 2-5 reasoning, haiku for scout/verification). Most cost is in the iterative test-refine loop (Phase 4-5). Budget 2-4 test iterations per skill.

package/skills/skill-router/SKILL.md

@@ -0,0 +1,267 @@
+---
+name: skill-router
+description: "Meta-enforcement layer that routes EVERY agent action through the correct skill. MUST check this routing table before ANY response involving code, files, or technical decisions. Default: route to rune:cook for code tasks. Prevents rationalization, enforces check-before-act discipline."
+user-invocable: false
+metadata:
+  author: runedev
+  version: "1.1.0"
+  layer: L0
+  model: haiku
+  group: orchestrator
+  tools: "Read, Glob, Grep"
+---
+
+## Live Routing Context
+
+Routing overrides (if available): !`cat .rune/metrics/routing-overrides.json 2>/dev/null || echo "No adaptive routing rules active."`
+
+Recent skill usage: !`cat .rune/metrics/skills.json 2>/dev/null | head -20 || echo "No metrics collected yet."`
+
+# skill-router
+
+## Purpose
+
+The missing enforcement layer for Rune. While individual skills have HARD-GATEs and constraints, nothing forces the agent to *check* for the right skill before acting. `skill-router` fixes this by intercepting every user request and routing it through the correct skill(s) before any code is written, any file is read, or any clarifying question is asked.
+
+This is L0 — it sits above L1 orchestrators. It doesn't do work itself; it ensures the right skill does the work.
+
+## Triggers
+
+- **ALWAYS** — This skill is conceptually active on every user message
+- Loaded via system prompt or plugin description, not invoked manually
+- The agent MUST internalize this routing table and apply it before every response
+
+## Calls (outbound connections)
+
+- Any skill (L1-L3): routes to the correct skill based on intent detection
+
+## Called By (inbound connections)
+
+- None — this is the entry point. Nothing calls skill-router; it IS the first check.
+
+## Workflow
+
+### Step 0 — Check Routing Overrides (H3 Adaptive Routing)
+
+Before standard routing, check if adaptive routing rules exist:
+
+1. Use `Read` on `.rune/metrics/routing-overrides.json`
+2. If the file exists and has active rules, scan each rule's `condition` against the current user intent
+3. If a rule matches:
+   - Apply the override action (e.g., "route to problem-solver before debug")
+   - Log: "Adaptive routing: applying rule [id] — [action]"
+4. If no file exists or no rules match, proceed to standard routing (Step 1)
+
+**Override constraints**:
+- Overrides MUST NOT bypass layer discipline (L3 cannot call L1)
+- Overrides MUST NOT skip quality gates (sentinel, preflight, verification)
+- Overrides MUST NOT route to non-existent skills
+- If an override seems wrong, announce it and let user decide to keep or disable
+
+**Model hint support** (Adaptive Model Re-balancing):
+- Override entries may include `"model_hint": "opus"` — this signals that a skill previously failed at sonnet-level and needed opus reasoning depth
+- When a model_hint is present, announce: "Adaptive routing: this skill previously required opus-level reasoning for [context]. Escalating model."
+- Model hints are written by cook Phase 8 when debug-fix loops hit max retries on the same error pattern
+- Model hints do NOT override explicit user model preferences
+
+### Step 0.5 — STOP before responding
+
+Before generating ANY response (including clarifying questions), the agent MUST:
+
+1. **Classify the user's intent** using the routing table below
+2. **Identify which skill(s) match** — if even 1% chance a skill applies, invoke it
+3. **Invoke the skill** via the Skill tool
+4. **Follow the skill's instructions** — the skill dictates the workflow, not the agent
+
+### Step 1 — Intent Classification (Progressive Disclosure)
+
+Skills are organized into 3 tiers for discoverability. **Tier 1 skills handle 90% of user requests.**
+
+#### Tier 1 — Primary Entry Points (User-Facing)
+
+These 5 skills are the main interface. Most user intents route here first:
+
+| User Intent | Route To | When |
+|---|---|---|
+| Build / implement / add feature / fix bug | `rune:cook` | Any code change request |
+| Large multi-part task / parallel work | `rune:team` | 5+ files or 3+ modules |
+| Deploy + launch + marketing | `rune:launch` | Ship to production |
+| Legacy code / rescue / modernize | `rune:rescue` | Old/messy codebase |
+| Check project health / full audit | `rune:audit` | Quality assessment |
+| New project / bootstrap / scaffold | `rune:scaffold` | Greenfield project creation |
+
+**Default route**: If unclear, route to `rune:cook`. Cook handles 70% of all requests.
+
+#### Tier 2 — Power User Skills (Direct Invocation)
+
+For users who know exactly what they want:
+
+| User Intent | Route To | Priority |
+|---|---|---|
+| Plan / design / architect | `rune:plan` | L2 — requires opus |
+| Brainstorm / explore ideas | `rune:brainstorm` | L2 — before plan |
+| Review code / check quality | `rune:review` | L2 |
+| Write tests | `rune:test` | L2 — TDD |
+| Refactor | `rune:surgeon` | L2 — incremental |
+| Deploy (without marketing) | `rune:deploy` | L2 |
+| Security concern | `rune:sentinel` | L2 — opus for critical |
+| Performance issue | `rune:perf` | L2 |
+| Database change | `rune:db` | L2 |
+| Received code review / PR feedback | `rune:review-intake` | L2 |
+| Protect / audit / document business logic | `rune:logic-guardian` | L2 |
+| Create / edit a Rune skill | `rune:skill-forge` | L2 — requires opus |
+| Incident / outage | `rune:incident` | L2 |
+| UI/UX design | `rune:design` | L2 |
+| Fix bug / debug only (no fix) | `rune:debug` → `rune:fix` | L2 chain |
+| Marketing assets only | `rune:marketing` | L2 |
+| Gather requirements / BA / elicit needs | `rune:ba` | L2 — requires opus |
+| Generate / update docs | `rune:docs` | L2 |
+| Build MCP server | `rune:mcp-builder` | L2 |
+| Red-team / challenge a plan / stress-test | `rune:adversary` | L2 — requires opus |
+
+#### Tier 3 — Internal Skills (Called by Other Skills)
+
+These are rarely invoked directly — they're called by Tier 1/2 skills:
+
+| Skill | Called By | Purpose |
+|---|---|---|
+| `rune:scout` | cook, plan, team | Codebase scanning |
+| `rune:fix` | debug, cook | Apply code changes |
+| `rune:preflight` | cook | Quality gate |
+| `rune:verification` | cook, fix | Run lint/test/build |
+| `rune:hallucination-guard` | cook, fix | Verify imports |
+| `rune:completion-gate` | cook | Validate claims |
+| `rune:sentinel-env` | cook, scaffold, onboard | Environment pre-flight |
+| `rune:research` / `rune:docs-seeker` | any | Look up docs |
+| `rune:session-bridge` | cook, team | Save context |
+| `rune:git` | cook, scaffold, team, launch | Semantic commits, PRs, branches |
+| `rune:doc-processor` | docs, marketing | PDF/DOCX/XLSX/PPTX generation |
+| "Done" / "ship it" / "xong" | — | `rune:verification` → commit |
+
+#### Tier 4 — Domain Extension Packs (L4)
+
+When user intent matches a domain-specific pattern or user explicitly invokes an L4 trigger command, route to the L4 pack. The agent reads the pack's PACK.md and follows the matching skill's workflow.
+
+| User Intent / Domain Signal | Route To | Pack File |
+|---|---|---|
+| Frontend UI, design system, a11y, animation | `@rune/ui` | `extensions/ui/PACK.md` |
+| API design, auth, middleware, rate limiting | `@rune/backend` | `extensions/backend/PACK.md` |
+| Docker, CI/CD, monitoring, server setup | `@rune/devops` | `extensions/devops/PACK.md` |
+| React Native, Flutter, mobile app, app store | `@rune/mobile` | `extensions/mobile/PACK.md` |
+| OWASP, pentest, secrets, compliance | `@rune/security` | `extensions/security/PACK.md` |
+| Trading, fintech, charts, market data | `@rune/trading` | `extensions/trading/PACK.md` |
+| Multi-tenant, billing, SaaS subscription | `@rune/saas` | `extensions/saas/PACK.md` |
+| Shopify, payments, cart, inventory | `@rune/ecommerce` | `extensions/ecommerce/PACK.md` |
+| LLM, RAG, embeddings, fine-tuning | `@rune/ai-ml` | `extensions/ai-ml/PACK.md` |
+| Three.js, WebGL, game loop, physics | `@rune/gamedev` | `extensions/gamedev/PACK.md` |
+| Blog, CMS, MDX, i18n, SEO | `@rune/content` | `extensions/content/PACK.md` |
+| Analytics, A/B testing, funnels, dashboards | `@rune/analytics` | `extensions/analytics/PACK.md` |
+
+**L4 routing rules:**
+1. If user explicitly invokes an L4 trigger (e.g., `/rune rag-patterns`), read the PACK.md and follow the skill workflow directly
+2. If the intent also involves implementation, route to `cook` (L1) first — cook will detect L4 context in Phase 1.5
+3. L4 packs supplement L1/L2 workflows — they are domain knowledge, not standalone orchestrators
+4. L4 packs can call L3 utilities (scout, verification) but CANNOT call L1 or L2 skills
+5. If the L4 pack file is not found on disk, skip silently and proceed with standard routing
+
+### Step 2 — Compound Intent Resolution
+
+Many requests combine intents. Route to the HIGHEST-PRIORITY skill first:
+
+```
+Priority: L1 > L2 > L3
+Within same layer: process skills > implementation skills
+
+Example: "Add auth and deploy it"
+  → rune:cook (add auth) FIRST
+  → rune:deploy SECOND (after cook completes)
+
+Example: "Fix the login bug and add tests"
+  → rune:debug (diagnose) FIRST
+  → rune:fix (apply fix) SECOND
+  → rune:test (add tests) THIRD
+
+L4 integration: If cook is the primary route AND a domain pack matches,
+cook handles orchestration while the L4 pack provides domain patterns.
+Both are active — cook for workflow, L4 for domain knowledge.
+```
+
+### Step 3 — Anti-Rationalization Gate
+
+The agent MUST NOT bypass routing with these excuses:
+
+| Thought | Reality | Action |
+|---|---|---|
+| "This is too simple for a skill" | Simple tasks still benefit from structure | Route it |
+| "I already know how to do this" | Skills have constraints you'll miss | Route it |
+| "Let me just read the file first" | Skills tell you HOW to read | Route first |
+| "I need more context before routing" | Route first, skill will gather context | Route it |
+| "The user just wants a quick answer" | Quick answers can still be wrong | Check routing table |
+| "No skill matches exactly" | Pick closest match, or use scout + plan | Route it |
+| "I'll apply the skill patterns mentally" | Mental application misses constraints | Actually invoke it |
+| "This is just a follow-up" | Follow-ups can change intent | Re-check routing |
+
+### Step 4 — Execute
+
+Once routed:
+1. Announce: "Using `rune:<skill>` to [purpose]"
+2. Invoke the skill via Skill tool
+3. Follow the skill's workflow exactly
+4. If the skill has a checklist/phases, track via TodoWrite
+
+## Routing Exceptions
+
+These DO NOT need skill routing:
+- Pure conversational responses ("hello", "thanks")
+- Answering questions about Rune itself (meta-questions)
+- Single-line factual answers with no code impact
+- Resuming an already-active skill workflow
+
+## Output Format
+
+```
+## Routing Decision
+- **Intent**: [classified user intent]
+- **Skill**: rune:[skill-name]
+- **Confidence**: HIGH | MEDIUM | LOW
+- **Override**: [routing override applied, if any]
+- **Reason**: [one-line justification for skill selection]
+```
+
+For multi-skill chains:
+```
+## Routing Chain
+1. rune:[skill-1] — [purpose]
+2. rune:[skill-2] — [purpose]
+3. rune:[skill-3] — [purpose]
+```
+
+## Constraints
+
+1. MUST check routing table before EVERY response that involves code, files, or technical decisions
+2. MUST invoke skill via Skill tool — "mentally applying" a skill is NOT acceptable
+3. MUST NOT write code without routing through at least one skill first
+4. MUST NOT skip routing because "it's faster" — speed without correctness wastes more time
+5. MUST re-route on intent change — if user shifts from "plan" to "implement", switch skills
+6. MUST announce which skill is being used and why — transparency builds trust
+7. MUST follow skill's internal workflow, not override it with own judgment
+
+## Sharp Edges
+
+| Failure Mode | Severity | Mitigation |
+|---|---|---|
+| Agent writes code without invoking any skill | CRITICAL | Constraint 3: code REQUIRES skill routing. No exceptions. |
+| Agent "mentally applies" skill without invoking | HIGH | Constraint 2: must use Skill tool for full content |
+| Routes to wrong skill, wastes a full workflow | MEDIUM | Step 2 compound resolution + re-route on mismatch |
+| Over-routing trivial tasks (e.g., "what time is it") | LOW | Routing Exceptions section covers non-technical queries |
+| Skill invocation adds latency to simple tasks | LOW | Acceptable trade-off: correctness > speed |
+
+## Done When
+
+- This skill is never "done" — it's a persistent routing layer
+- Success = every agent response passes through routing check
+- Failure = any code written without skill invocation
+
+## Cost Profile
+
+~0 tokens (routing logic is internalized from this document). Cost comes from the skills it routes to, not from skill-router itself. The routing table is loaded once and cached in context.