@bugzy-ai/bugzy 1.9.3 → 1.9.4

package/package.json

@@ -1,95 +1,95 @@
-{
-  "name": "@bugzy-ai/bugzy",
-  "version": "1.9.3",
-  "description": "Open-source AI agent configuration for QA automation with Claude Code",
-  "publishConfig": {
-    "access": "public"
-  },
-  "keywords": [
-    "ai",
-    "testing",
-    "qa",
-    "automation",
-    "claude",
-    "mcp",
-    "agent",
-    "test-automation",
-    "claude-code"
-  ],
-  "homepage": "https://github.com/bugzy-ai/bugzy#readme",
-  "bugs": {
-    "url": "https://github.com/bugzy-ai/bugzy/issues"
-  },
-  "repository": {
-    "type": "git",
-    "url": "git+https://github.com/bugzy-ai/bugzy.git"
-  },
-  "license": "MIT",
-  "author": "Bugzy Team",
-  "type": "module",
-  "exports": {
-    ".": {
-      "types": "./dist/index.d.ts",
-      "import": "./dist/index.js",
-      "require": "./dist/index.cjs"
-    },
-    "./tasks": {
-      "types": "./dist/tasks/index.d.ts",
-      "import": "./dist/tasks/index.js"
-    },
-    "./subagents": {
-      "types": "./dist/subagents/index.d.ts",
-      "import": "./dist/subagents/index.js"
-    },
-    "./subagents/metadata": {
-      "types": "./dist/subagents/metadata.d.ts",
-      "import": "./dist/subagents/metadata.js"
-    }
-  },
-  "main": "./dist/index.cjs",
-  "module": "./dist/index.js",
-  "types": "./dist/index.d.ts",
-  "bin": {
-    "bugzy": "./dist/cli/index.js"
-  },
-  "files": [
-    "dist",
-    "templates",
-    "README.md",
-    "LICENSE"
-  ],
-  "scripts": {
-    "build": "tsup",
-    "dev": "tsup --watch",
-    "test": "vitest run",
-    "test:ci": "vitest run",
-    "type-check": "tsc --noEmit",
-    "lint": "eslint src",
-    "prepublishOnly": "pnpm run build && pnpm run test:ci"
-  },
-  "dependencies": {
-    "chalk": "^5.3.0",
-    "commander": "^11.1.0",
-    "dotenv": "^16.3.1",
-    "figlet": "^1.9.3",
-    "gradient-string": "^3.0.0",
-    "gray-matter": "^4.0.3",
-    "inquirer": "^9.2.12",
-    "ora": "^7.0.1"
-  },
-  "devDependencies": {
-    "@types/figlet": "^1.7.0",
-    "@types/gradient-string": "^1.1.6",
-    "@types/inquirer": "^9.0.7",
-    "@types/node": "^20.10.5",
-    "@typescript-eslint/eslint-plugin": "^6.15.0",
-    "@typescript-eslint/parser": "^6.15.0",
-    "eslint": "^8.56.0",
-    "tsup": "^8.0.1",
-    "typescript": "^5.3.3",
-    "vitest": "^1.1.0"
-  },
-  "engines": {
-    "node": ">=18.0.0"
-  }
-}
+{
+  "name": "@bugzy-ai/bugzy",
+  "version": "1.9.4",
+  "description": "Open-source AI agent configuration for QA automation with Claude Code",
+  "publishConfig": {
+    "access": "public"
+  },
+  "keywords": [
+    "ai",
+    "testing",
+    "qa",
+    "automation",
+    "claude",
+    "mcp",
+    "agent",
+    "test-automation",
+    "claude-code"
+  ],
+  "homepage": "https://github.com/bugzy-ai/bugzy#readme",
+  "bugs": {
+    "url": "https://github.com/bugzy-ai/bugzy/issues"
+  },
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/bugzy-ai/bugzy.git"
+  },
+  "license": "MIT",
+  "author": "Bugzy Team",
+  "type": "module",
+  "exports": {
+    ".": {
+      "types": "./dist/index.d.ts",
+      "import": "./dist/index.js",
+      "require": "./dist/index.cjs"
+    },
+    "./tasks": {
+      "types": "./dist/tasks/index.d.ts",
+      "import": "./dist/tasks/index.js"
+    },
+    "./subagents": {
+      "types": "./dist/subagents/index.d.ts",
+      "import": "./dist/subagents/index.js"
+    },
+    "./subagents/metadata": {
+      "types": "./dist/subagents/metadata.d.ts",
+      "import": "./dist/subagents/metadata.js"
+    }
+  },
+  "main": "./dist/index.cjs",
+  "module": "./dist/index.js",
+  "types": "./dist/index.d.ts",
+  "bin": {
+    "bugzy": "./dist/cli/index.js"
+  },
+  "files": [
+    "dist",
+    "templates",
+    "README.md",
+    "LICENSE"
+  ],
+  "scripts": {
+    "build": "tsup",
+    "dev": "tsup --watch",
+    "test": "vitest run",
+    "test:ci": "vitest run",
+    "type-check": "tsc --noEmit",
+    "lint": "eslint src",
+    "prepublishOnly": "pnpm run build && pnpm run test:ci"
+  },
+  "dependencies": {
+    "chalk": "^5.3.0",
+    "commander": "^11.1.0",
+    "dotenv": "^16.3.1",
+    "figlet": "^1.9.3",
+    "gradient-string": "^3.0.0",
+    "gray-matter": "^4.0.3",
+    "inquirer": "^9.2.12",
+    "ora": "^7.0.1"
+  },
+  "devDependencies": {
+    "@types/figlet": "^1.7.0",
+    "@types/gradient-string": "^1.1.6",
+    "@types/inquirer": "^9.0.7",
+    "@types/node": "^20.10.5",
+    "@typescript-eslint/eslint-plugin": "^6.15.0",
+    "@typescript-eslint/parser": "^6.15.0",
+    "eslint": "^8.56.0",
+    "tsup": "^8.0.1",
+    "typescript": "^5.3.3",
+    "vitest": "^1.1.0"
+  },
+  "engines": {
+    "node": ">=18.0.0"
+  }
+}

package/templates/init/.bugzy/runtime/knowledge-base.md

@@ -1,61 +1,61 @@
-# Knowledge Base
-
-> A curated collection of factual knowledge about this project - what we currently know and believe to be true. This is NOT a historical log, but a living reference that evolves as understanding improves.
-
-**Maintenance Guide**: See `knowledge-maintenance-guide.md` for instructions on how to maintain this knowledge base.
-
-**Core Principle**: This document represents current understanding, not a history. When knowledge evolves, update existing entries rather than appending new ones.
-
----
-
-## Project Knowledge
-
-_This knowledge base will be populated as you work. Add new discoveries, update existing understanding, and remove outdated information following the maintenance guide principles._
-
-### When to Update This File
-
-- **ADD**: New factual information discovered, new patterns emerge, new areas become relevant
-- **UPDATE**: Facts change, understanding deepens, multiple facts can be consolidated, language can be clarified
-- **REMOVE**: Information becomes irrelevant, facts proven incorrect, entries superseded by better content
-
-### Format Guidelines
-
-- Use clear, declarative statements in present tense
-- State facts confidently when known; flag uncertainty when it exists
-- Write for someone reading this 6 months from now
-- Keep entries relevant and actionable
-- Favor consolidation over accumulation
-
----
-
-## Example Structure
-
-Below is an example structure. Feel free to organize knowledge in the way that makes most sense for this project:
-
-### Architecture & Infrastructure
-
-_System architecture, deployment patterns, infrastructure details_
-
-### Testing Patterns
-
-_Test strategies, common test scenarios, testing conventions_
-
-### UI/UX Patterns
-
-_User interface conventions, interaction patterns, design system details_
-
-### Data & APIs
-
-_Data models, API behaviors, integration patterns_
-
-### Known Issues & Workarounds
-
-_Current limitations, known bugs, and their workarounds_
-
-### Domain Knowledge
-
-_Business domain facts, terminology, rules, and context_
-
----
-
-**Remember**: Every entry should answer "Will this help someone working on this project in 6 months?"
+# Knowledge Base
+
+> A curated collection of factual knowledge about this project - what we currently know and believe to be true. This is NOT a historical log, but a living reference that evolves as understanding improves.
+
+**Maintenance Guide**: See `knowledge-maintenance-guide.md` for instructions on how to maintain this knowledge base.
+
+**Core Principle**: This document represents current understanding, not a history. When knowledge evolves, update existing entries rather than appending new ones.
+
+---
+
+## Project Knowledge
+
+_This knowledge base will be populated as you work. Add new discoveries, update existing understanding, and remove outdated information following the maintenance guide principles._
+
+### When to Update This File
+
+- **ADD**: New factual information discovered, new patterns emerge, new areas become relevant
+- **UPDATE**: Facts change, understanding deepens, multiple facts can be consolidated, language can be clarified
+- **REMOVE**: Information becomes irrelevant, facts proven incorrect, entries superseded by better content
+
+### Format Guidelines
+
+- Use clear, declarative statements in present tense
+- State facts confidently when known; flag uncertainty when it exists
+- Write for someone reading this 6 months from now
+- Keep entries relevant and actionable
+- Favor consolidation over accumulation
+
+---
+
+## Example Structure
+
+Below is an example structure. Feel free to organize knowledge in the way that makes most sense for this project:
+
+### Architecture & Infrastructure
+
+_System architecture, deployment patterns, infrastructure details_
+
+### Testing Patterns
+
+_Test strategies, common test scenarios, testing conventions_
+
+### UI/UX Patterns
+
+_User interface conventions, interaction patterns, design system details_
+
+### Data & APIs
+
+_Data models, API behaviors, integration patterns_
+
+### Known Issues & Workarounds
+
+_Current limitations, known bugs, and their workarounds_
+
+### Domain Knowledge
+
+_Business domain facts, terminology, rules, and context_
+
+---
+
+**Remember**: Every entry should answer "Will this help someone working on this project in 6 months?"

package/templates/init/.bugzy/runtime/knowledge-maintenance-guide.md

@@ -1,97 +1,97 @@
-# Knowledge Maintenance Guide
-
-## Overview
-
-This document provides instructions for maintaining a **Context** or **Knowledge Base** - a living collection of factual knowledge that is actively curated and updated rather than simply accumulated over time.
-
----
-
-## Core Principle: This is a Curated Snapshot, Not a Log
-
-This document represents **what we currently know and believe to be true**, not a history of what we've learned. Think of it as a living reference that evolves as understanding improves.
-
----
-
-## When to ADD
-
-Add new entries when:
-
-- New factual information is discovered
-- New patterns or relationships emerge
-- New areas of knowledge become relevant
-
-**Check first**: Does this duplicate or overlap with existing entries?
-
----
-
-## When to UPDATE
-
-Update existing entries when:
-
-- Facts change or we discover more accurate information
-- Understanding deepens (replace shallow with deeper insight)
-- Multiple related facts can be consolidated into one coherent statement
-- Language can be clarified or made more precise
-
-**Goal**: Replace outdated understanding with current understanding
-
----
-
-## When to REMOVE
-
-Remove entries when:
-
-- Information becomes irrelevant to current needs
-- Facts are proven incorrect (unless there's value in noting the correction)
-- Information is superseded by better, more comprehensive entries
-- Entry is redundant with other content
-
-**Key question**: "If someone reads this in 6 months, will it help them?"
-
----
-
-## Maintenance Principles
-
-### 1. Favor Consolidation Over Addition
-
-- Before adding, ask: "Can this merge with existing knowledge?"
-- Example: Instead of 10 facts about a person, maintain 2-3 well-organized paragraphs
-
-### 2. Update Rather Than Append
-
-- When information evolves, replace the old statement
-- Keep history only if the evolution itself is important
-- Example: ~~"User is learning Python"~~ → "User is proficient in Python and focusing on FastAPI"
-
-### 3. Regular Pruning
-
-- Periodically review for outdated or low-value entries
-- Ask: "Is this still accurate? Still relevant? Could it be stated better?"
-- Aim for signal-to-noise ratio improvement
-
-### 4. Quality Over Completeness
-
-- Better to have 50 highly relevant, accurate facts than 500 marginally useful ones
-- Prioritize insights over raw data
-- Focus on what's actionable or decision-relevant
-
-### 5. Resolve Contradictions Immediately
-
-- If new information contradicts old, investigate and keep only the truth
-- Don't accumulate conflicting statements
-
-### 6. Use Clear, Declarative Statements
-
-- Write in present tense: "User works at X" not "User mentioned they work at X"
-- State facts confidently when known; flag uncertainty when it exists
-- Avoid hedging unless genuinely uncertain
-
----
-
-## Anti-Patterns to Avoid
-
-| ❌ Don't Do This | ✅ Do This Instead |
-|-----------------|-------------------|
-| "On Tuesday user said X, then on Friday user said Y" | "User's position on X is Y" (keep most current) |
-| Keeping every detail ever mentioned | Keeping relevant, current details |
-| "User might like coffee, user mentioned tea once, user drinks water" | "User prefers tea; also drinks coffee occasionally" |
+# Knowledge Maintenance Guide
+
+## Overview
+
+This document provides instructions for maintaining a **Context** or **Knowledge Base** - a living collection of factual knowledge that is actively curated and updated rather than simply accumulated over time.
+
+---
+
+## Core Principle: This is a Curated Snapshot, Not a Log
+
+This document represents **what we currently know and believe to be true**, not a history of what we've learned. Think of it as a living reference that evolves as understanding improves.
+
+---
+
+## When to ADD
+
+Add new entries when:
+
+- New factual information is discovered
+- New patterns or relationships emerge
+- New areas of knowledge become relevant
+
+**Check first**: Does this duplicate or overlap with existing entries?
+
+---
+
+## When to UPDATE
+
+Update existing entries when:
+
+- Facts change or we discover more accurate information
+- Understanding deepens (replace shallow with deeper insight)
+- Multiple related facts can be consolidated into one coherent statement
+- Language can be clarified or made more precise
+
+**Goal**: Replace outdated understanding with current understanding
+
+---
+
+## When to REMOVE
+
+Remove entries when:
+
+- Information becomes irrelevant to current needs
+- Facts are proven incorrect (unless there's value in noting the correction)
+- Information is superseded by better, more comprehensive entries
+- Entry is redundant with other content
+
+**Key question**: "If someone reads this in 6 months, will it help them?"
+
+---
+
+## Maintenance Principles
+
+### 1. Favor Consolidation Over Addition
+
+- Before adding, ask: "Can this merge with existing knowledge?"
+- Example: Instead of 10 facts about a person, maintain 2-3 well-organized paragraphs
+
+### 2. Update Rather Than Append
+
+- When information evolves, replace the old statement
+- Keep history only if the evolution itself is important
+- Example: ~~"User is learning Python"~~ → "User is proficient in Python and focusing on FastAPI"
+
+### 3. Regular Pruning
+
+- Periodically review for outdated or low-value entries
+- Ask: "Is this still accurate? Still relevant? Could it be stated better?"
+- Aim for signal-to-noise ratio improvement
+
+### 4. Quality Over Completeness
+
+- Better to have 50 highly relevant, accurate facts than 500 marginally useful ones
+- Prioritize insights over raw data
+- Focus on what's actionable or decision-relevant
+
+### 5. Resolve Contradictions Immediately
+
+- If new information contradicts old, investigate and keep only the truth
+- Don't accumulate conflicting statements
+
+### 6. Use Clear, Declarative Statements
+
+- Write in present tense: "User works at X" not "User mentioned they work at X"
+- State facts confidently when known; flag uncertainty when it exists
+- Avoid hedging unless genuinely uncertain
+
+---
+
+## Anti-Patterns to Avoid
+
+| ❌ Don't Do This | ✅ Do This Instead |
+|-----------------|-------------------|
+| "On Tuesday user said X, then on Friday user said Y" | "User's position on X is Y" (keep most current) |
+| Keeping every detail ever mentioned | Keeping relevant, current details |
+| "User might like coffee, user mentioned tea once, user drinks water" | "User prefers tea; also drinks coffee occasionally" |

package/templates/init/.bugzy/runtime/project-context.md

@@ -1,35 +1,35 @@
-# Project Context
-
-## Customer Information
-**Customer Name:** {{CUSTOMER_NAME}}
-**Primary Contact:** [To be filled]
-
-## Project Information
-**Project Name:** {{PROJECT_NAME}}
-**Description:** [To be filled]
-**Repository:** [To be filled]
-
-## Development Process
-**Methodology:** [Agile/Waterfall/Hybrid - To be filled]
-**Sprint Length:** [e.g., 2 weeks - To be filled]
-**Current Sprint:** [To be filled]
-
-## QA Integration
-**QA Entry Point:** [e.g., After development complete, During development - To be filled]
-**Definition of Done:** [QA criteria for story completion - To be filled]
-**Sign-off Process:** [Who approves test results - To be filled]
-
-## Tools & Systems
-**Bug Tracking:** {{BUG_TRACKING_SYSTEM}}
-**Documentation:** {{DOCUMENTATION_SYSTEM}}
-**CI/CD Platform:** [e.g., GitHub Actions, Jenkins - To be filled]
-**Communication:** [e.g., Slack channel - To be filled]
-
-## Team Contacts
-**Product Owner:** [Name and contact - To be filled]
-**Tech Lead:** [Name and contact - To be filled]
-**QA Lead:** [Name and contact - To be filled]
-**DevOps Contact:** [Name and contact - To be filled]
-
-## Notes
-[Any additional context about the project, special requirements, or considerations]
+# Project Context
+
+## Customer Information
+**Customer Name:** {{CUSTOMER_NAME}}
+**Primary Contact:** [To be filled]
+
+## Project Information
+**Project Name:** {{PROJECT_NAME}}
+**Description:** [To be filled]
+**Repository:** [To be filled]
+
+## Development Process
+**Methodology:** [Agile/Waterfall/Hybrid - To be filled]
+**Sprint Length:** [e.g., 2 weeks - To be filled]
+**Current Sprint:** [To be filled]
+
+## QA Integration
+**QA Entry Point:** [e.g., After development complete, During development - To be filled]
+**Definition of Done:** [QA criteria for story completion - To be filled]
+**Sign-off Process:** [Who approves test results - To be filled]
+
+## Tools & Systems
+**Bug Tracking:** {{BUG_TRACKING_SYSTEM}}
+**Documentation:** {{DOCUMENTATION_SYSTEM}}
+**CI/CD Platform:** [e.g., GitHub Actions, Jenkins - To be filled]
+**Communication:** [e.g., Slack channel - To be filled]
+
+## Team Contacts
+**Product Owner:** [Name and contact - To be filled]
+**Tech Lead:** [Name and contact - To be filled]
+**QA Lead:** [Name and contact - To be filled]
+**DevOps Contact:** [Name and contact - To be filled]
+
+## Notes
+[Any additional context about the project, special requirements, or considerations]