1 files changed, 9 insertions, 4 deletions
diff --git a/skills/module-audit-and-test.json b/skills/module-audit-and-test.json
index 5dfddcc..3f3ede9 100644
--- a/skills/module-audit-and-test.json
+++ b/skills/module-audit-and-test.json
@@ -1,9 +1,14 @@
 {
   "name": "module-audit-and-test",
-  "description": "",
-  "tags": [],
+  "description": "module-audit-and-test",
+  "tags": [
+    "regression",
+    "testing",
+    "quality-assurance",
+    "modules"
+  ],
   "category": "dev",
   "created": "2026-06-18T00:41:25.711Z",
-  "updated": "2026-06-18T00:41:25.711Z",
-  "content": "---\nname: module-audit-and-test\ndescription: Procedural guide for auditing module source code and performing rigorous testing to ensure stability, security, and performance.\ntags: [modules, audit, testing, quality-assurance, dev]\n---\n\n# Module Audit & Testing Workflow\n\nThis skill provides a standardized approach to auditing existing modules and testing new or modified code within the WebX11 ecosystem.\n\n## 1. Audit Phase (Static Analysis)\nBefore running code, perform a static review of the module source.\n\n### Steps to Audit:\n1. **Retrieve Source**: Use `view_module(name=\"ModuleName\")` to examine the code.\n2. **Security Check**: \n   - Look for unsafe command executions or uncontrolled input handling.\n   - Ensure destructive operations (e.g., `write_file`, `delete_file`) have appropriate guards or confirmations.\n3. **Logic Review**:\n   - Check for edge cases in parameters.\n   - Verify that the module handles errors gracefully (try-catch blocks).\n   - Ensure the module adheres to the expected return formats (JSON, strings, etc.).\n4. **Dependency Check**: Verify that all required helper functions or external APIs are correctly called and exist.\n\n## 2. Testing Phase (Dynamic Analysis)\nOnce the audit is complete, validate the module's behavior in a sandbox environment.\n\n### Testing Strategy:\n- **Happy Path**: Test the most common use case with valid inputs.\n- **Boundary Testing**: Test with empty strings, extremely large inputs, or null values.\n- **Error Path**: Intentionally provide invalid inputs to see if the module returns a helpful error instead of crashing.\n- **Integration Testing**: If the module interacts with other system components (VFS, Web, etc.), verify the end-to-end flow.\n\n### Execution Loop:\n1. **Edit/Modify**: Use `edit_module(name=\"ModuleName\")` to apply fixes.\n2. **Isolated Test**: Use `test_module(name=\"ModuleName\")`. This runs the module in a temporary context without affecting the global state.\n3. **Live Reload**: If tests pass, use `reload_module(name=\"ModuleName\")` to push the changes to the active system.\n\n## 3. Validation Checklist\n- [ ] Does the module perform its intended function?\n- [ ] Does it handle errors without crashing the terminal?\n- [ ] Are there any obvious security vulnerabilities?\n- [ ] Is the code clean and maintainable?\n- [ ] Does it perform efficiently without causing system lag?\n\n## Summary of Commands\n| Action | Command |\n| :--- | :--- |\n| View Source | `view_module(name=\"...\")` |\n| Modify Code | `edit_module(name=\"...\")` |\n| Test Sandbox | `test_module(name=\"...\")` |\n| Deploy | `reload_module(name=\"...\")` |\n| Check Status | `get_module_status()` |\n"
+  "updated": "2026-06-24T21:58:03.530Z",
+  "content": "---\nname: module-audit-and-test\ncategory: dev\ntags: [regression, testing, quality-assurance, modules]\n---\n\n# Module Regression & Testing Framework\n\nThis skill provides a formal methodology for ensuring that module modifications do not introduce regressions and that new features meet quality standards.\n\n## 1. Testing Levels\n- **Unit Test**: Isolating a single function within a module using `test_module`.\n- **Integration Test**: Testing the module's interaction with other modules or the VFS.\n- **Regression Test**: Running a set of known \"golden\" inputs and comparing outputs to ensure previous fixes remain active.\n\n## 2. The Regression Workflow\nWhen modifying a module, follow this cycle:\n\n### Phase A: Baselining (Pre-Edit)\n1. **Capture Current State**: Run the module with 3-5 standard inputs and save the output to a file in `/tests/baselines/[module_name]/`.\n2. **Identify Edge Cases**: Document at least one \"failure mode\" (e.g., empty input, oversized payload) that the module currently handles correctly.\n\n### Phase B: Controlled Modification\n1. **Edit**: Use `edit_module` to implement the change.\n2. **Verify**: Use `test_module` to confirm the specific fix/feature works in isolation.\n\n### Phase C: Regression Run (Post-Edit)\n1. **Compare**: Re-run the baseline inputs.\n2. **Diff Analysis**: Compare current output vs. baseline. Any unexpected change is a regression.\n3. **Edge Case Check**: Re-verify the previously identified failure modes.\n\n## 3. VFS Test Registry Structure\nMaintain tests in the following hierarchy:\n- `/tests/baselines/` $\\to$ Expected outputs for stable versions.\n- `/tests/suites/` $\\to$ Scripts or lists of inputs to be run sequentially.\n- `/tests/logs/` $\\to$ Execution history of test runs.\n\n## 4. Failure Protocol\nIf a regression is found:\n1. **Revert**: Use `reload_module` to return to the original state.\n2. **Analyze**: Use `debug-deep-dive` to find the conflict between the new logic and the baseline.\n3. **Refine**: Rewrite the logic to accommodate both the new feature and the baseline requirement.\n"
 }
 \ No newline at end of file