Updates to v1.0.0

Author: pdudotdev

.claude.example/settings.local.json

@@ -1,7 +1,7 @@
 {
   "permissions": {
     "allow": [
-      "mcp__netkb__*",
+      "mcp__yanaa__*",
       "Bash(netkb/bin/python:*)",
       "Bash(netkb/bin/pip:*)",
       "Bash(ls:*)"

.claude.example/skills/audit-codebase/SKILL.md

@@ -5,11 +5,11 @@ context: fork
 disable-model-invocation: true
 ---
 
-# /audit-codebase — netKB Codebase Audit
+# /audit-codebase — YANAA Codebase Audit
 
-You are a Senior Software Engineer performing a full, professional, and deep analysis of the entire codebase — code logic, code quality, and cleanliness. Check for any mistakes, bugs, inconsistencies, edge case failures, gaps, stale code or references, silent failures, and unhandled exceptions. Make sure everything is in sync with the current implementation of netKB.
+You are a Senior Software Engineer performing a full, professional, and deep analysis of the entire codebase — code logic, code quality, and cleanliness. Check for any mistakes, bugs, inconsistencies, edge case failures, gaps, stale code or references, silent failures, and unhandled exceptions. Make sure everything is in sync with the current implementation of YANAA.
 
-Pay particular attention to any ways the agent can hang or enter infinite loops that might consume tokens and time — netKB is an MCP server used by client companies, and reliability matters.
+Pay particular attention to any ways the agent can hang or enter infinite loops that might consume tokens and time — YANAA is an MCP server used by client companies, and reliability matters.
 
 Be thorough. Be rigorous. Every finding must be earned with evidence.
 
@@ -27,9 +27,9 @@ Be thorough. Be rigorous. Every finding must be earned with evidence.
 
 ## Background Material
 
-Before starting, read these three files. They contain netKB-specific domain knowledge — known risk areas, integration patterns, and cross-module contracts you need to verify:
+Before starting, read these three files. They contain YANAA-specific domain knowledge — known risk areas, integration patterns, and cross-module contracts you need to verify:
 
-- `.claude/skills/audit-codebase/checklists/async-safety.md` — netKB's async patterns and known concurrency risk areas
+- `.claude/skills/audit-codebase/checklists/async-safety.md` — YANAA's async patterns and known concurrency risk areas
 - `.claude/skills/audit-codebase/checklists/integration.md` — Vault, NetBox, ChromaDB, and Scrapli integration points to examine
 - `.claude/skills/audit-codebase/checklists/sync-check.md` — cross-module contracts that must be verified (tool registrations, model enums, platform map keys, CLAUDE.md accuracy)
 

.claude.example/skills/audit-codebase/checklists/async-safety.md

@@ -1,4 +1,4 @@
-# Async Safety Checklist — netKB
+# Async Safety Checklist — YANAA
 
 Use this during Phase 3. For each item, determine PASS, FAIL, or N/A based on the code you read in Phase 2.
 

.claude.example/skills/audit-codebase/checklists/integration.md

@@ -1,4 +1,4 @@
-# Integration Point Checklist — netKB
+# Integration Point Checklist — YANAA
 
 Use this during Phase 6. For each integration point, verify the listed behaviors against the code you read in Phase 2.
 
@@ -23,7 +23,7 @@ Use this during Phase 6. For each integration point, verify the listed behaviors
 | Import-time `load_devices()` call | `core/inventory.py` calls `load_devices()` at module level. If NetBox is unreachable, what exception propagates? Does it crash the server import chain or get caught? |
 | Missing `primary_ip` | Does `load_devices()` skip devices with `primary_ip=None`? Verify the check is present and the device is excluded without crashing. |
 | Missing `platform` or `cli_style` | Does `load_devices()` skip devices with missing custom fields? Is a warning logged? |
-| `load_intent()` prefix fallback | Does it try `netkb-` prefix first, then fall back to `dblcheck-`? Verify both code paths exist. |
+| `load_intent()` prefix fallback | Does it try `yanaa-` prefix first, then fall back to `dblcheck-`? Verify both code paths exist. |
 | NetBox session timeout | `(5, 15)` — verify it's applied to the pynetbox session object before requests. |
 | Empty NetBox result | If `load_devices()` returns an empty dict (no devices in NetBox), does the server start with empty inventory and return clean errors on unknown device queries? |
 
@@ -49,4 +49,4 @@ Use this during Phase 6. For each integration point, verify the listed behaviors
 | Per-connection credential lookup | `get_secret()` is called in `_build_cli()` for every SSH connection. Since Vault results are cached, only the first connection to each cli_style pays the HTTP cost. Verify this is correct. |
 | MikroTik `+ct` suffix | Is `f"{username}+ct"` applied for MikroTik connections specifically, and NOT for other platforms? |
 | VyOS transport | Does VyOS use a different scrapli transport class (`Ssh2Options` or `TransportSsh2Options`) compared to other platforms? Is this set correctly in `_build_cli()`? |
-| Credential path per cli_style | Is the Vault path per cli_style (`netkb/router{cli_style}`) correct for all platforms, or does it use a shared path? |
+| Credential path per cli_style | Is the Vault path per cli_style (`yanaa/router{cli_style}`) correct for all platforms, or does it use a shared path? |

.claude.example/skills/audit-codebase/checklists/sync-check.md

@@ -1,4 +1,4 @@
-# Component Synchronization Checklist — netKB
+# Component Synchronization Checklist — YANAA
 
 Use this during Phase 7. For each check, verify the cross-module contract holds. Report PASS or FAIL with evidence (file:line).
 

.claude.example/skills/audit-security/SKILL.md

@@ -5,9 +5,9 @@ context: fork
 disable-model-invocation: true
 ---
 
-# /audit-security — netKB Security Audit
+# /audit-security — YANAA Security Audit
 
-You are a Senior Application Security Engineer and a seasoned pentester. Do a thorough, careful, well-thought and well-planned analysis of the codebase as you would do a professional security audit — to uncover any potential or real risks, threats, vulnerabilities, and prompt injection vectors that netKB is exposed to. Focus on what really matters from a security standpoint, not minor details.
+You are a Senior Application Security Engineer and a seasoned pentester. Do a thorough, careful, well-thought and well-planned analysis of the codebase as you would do a professional security audit — to uncover any potential or real risks, threats, vulnerabilities, and prompt injection vectors that YANAA is exposed to. Focus on what really matters from a security standpoint, not minor details.
 
 Be ruthless in your analysis. Be objective and cold like an external Senior Auditor looking to catch the internal dev team off-guard.
 
@@ -26,7 +26,7 @@ Deployment: `.github/workflows/ci.yml`, `requirements.txt`
 
 ## Background Material
 
-Before starting, read these two files. They contain netKB's complete attack surface map and threat model so you don't have to reconstruct them from scratch:
+Before starting, read these two files. They contain YANAA's complete attack surface map and threat model so you don't have to reconstruct them from scratch:
 
 - `.claude/skills/audit-security/checklists/attack-surfaces.md` — trust boundary map, entry points, and data flow per user-controlled input
 - `.claude/skills/audit-security/checklists/threat-model.md` — threat actors, assets to protect, and STRIDE-lite analysis per component
@@ -76,7 +76,7 @@ Pay special attention to the VRF field — it is the only user-controlled value
 **Consolidation rule:** If any input receives a verdict of PARTIAL or INEFFECTIVE and the worst-case impact is credential exposure or command execution, it MUST appear as a numbered S1/S2 finding in Section 2 with a full attack chain — not only as a note in this section. An input boundary gap that enables credential theft or arbitrary command execution is a finding, not an observation.
 
 ### 4. Prompt Injection Analysis
-netKB is an MCP server — its tool output is consumed directly by an LLM. Analyze all four injection vectors:
+YANAA is an MCP server — its tool output is consumed directly by an LLM. Analyze all four injection vectors:
 1. Device SSH output → LLM context
 2. RAG knowledge base content → LLM context
 3. NetBox inventory data (device names, fields) → LLM context via error messages

.claude.example/skills/audit-security/checklists/attack-surfaces.md

@@ -1,6 +1,6 @@
-# Attack Surfaces — netKB
+# Attack Surfaces — YANAA
 
-Use this during Phase 3. This defines every entry point into netKB and the data flow for each user-controlled input.
+Use this during Phase 3. This defines every entry point into YANAA and the data flow for each user-controlled input.
 
 ---
 
@@ -12,7 +12,7 @@ Use this during Phase 3. This defines every entry point into netKB and the data
         | Tool calls (JSON arguments, LLM-generated, untrusted)
         | No authentication layer
         v
-[netKB MCP Server — FastMCP]
+[YANAA MCP Server — FastMCP]
         |
         |-- search_knowledge_base ──> [ChromaDB / HuggingFace Embeddings] (local)
         |
@@ -82,7 +82,7 @@ MCP tool call
   → command_template.replace("{vrf}", vrf_name)
   → SSH command string sent to device
 ```
-**Risk zone:** String interpolation into CLI command. This is the highest-risk data flow in netKB.
+**Risk zone:** String interpolation into CLI command. This is the highest-risk data flow in YANAA.
 Key question: Does `_VRF_RE` reject all values that could alter command semantics?
 
 ### `query` (KBQuery)

.claude.example/skills/audit-security/checklists/threat-model.md

@@ -1,4 +1,4 @@
-# Threat Model — netKB
+# Threat Model — YANAA
 
 Use this during Phase 3 and Phase 8 (self-challenge). Defines the realistic threat actors, assets to protect, and STRIDE-lite analysis per component.
 

.claude.example/skills/audit-testing/SKILL.md

@@ -5,7 +5,7 @@ context: fork
 disable-model-invocation: true
 ---
 
-# /audit-testing — netKB Test Quality Audit
+# /audit-testing — YANAA Test Quality Audit
 
 You are a Senior QA Architect and Engineer. Do a thorough, careful, well-thought and well-planned analysis of all automated tests under `testing/` (including `testing/live/`). See if there are any gaps in testing when it comes to the codebase and project overall — did we miss anything important that should have been part of the test suites? Are we testing all the RELEVANT features and security guardrails that can be tested automatically?
 
@@ -34,7 +34,7 @@ You need to understand what the code does in order to judge whether the tests ar
 
 ## Background Material
 
-Before starting, read these two files. They contain netKB-specific domain knowledge that will help you identify issues more precisely:
+Before starting, read these two files. They contain YANAA-specific domain knowledge that will help you identify issues more precisely:
 
 - `.claude/skills/audit-testing/checklists/ghost-pass.md` — patterns and questions for detecting ghost passes
 - `.claude/skills/audit-testing/checklists/coverage-matrix.md` — pre-built module → test file mapping to verify and complete

.claude.example/skills/audit-testing/checklists/coverage-matrix.md

@@ -1,4 +1,4 @@
-# Coverage Matrix — netKB
+# Coverage Matrix — YANAA
 
 Use this during Phase 5. The table below is a pre-built starting point based on the known codebase structure. Verify it is still accurate (files exist, mappings are correct), then fill in the "Functions Tested" and "Functions NOT Tested" columns based on your reading of the test files.