@bugzy-ai/bugzy 1.18.2 → 1.18.4

package/templates/init/.bugzy/runtime/handlers/messages/feedback.md

@@ -1,178 +0,0 @@
-# Feedback Message Handler
-
-Instructions for processing bug reports, test observations, and user feedback.
-
-## Detection Criteria
-
-This handler applies when:
-- User reports an issue, bug, or unexpected behavior
-- User shares test results or observations
-- User provides information (not asking a question or requesting action)
-- Keywords present: "found", "issue", "bug", "doesn't work", "broken", "observed", "noticed", "failed", "error"
-- Intent field from LLM layer is `feedback`
-- Re-routed from clarification handler (thread reply with no blocked task)
-
-## Processing Steps
-
-### Step 1: Parse Feedback
-
-Extract the following from the message:
-
-| Field | Description | Examples |
-|-------|-------------|----------|
-| **Type** | Category of feedback | `bug_report`, `test_result`, `observation`, `suggestion`, `general` |
-| **Severity** | Impact level | `critical`, `high`, `medium`, `low` |
-| **Component** | Affected area | "login", "checkout", "search", etc. |
-| **Description** | Core issue description | What happened |
-| **Expected** | What should happen (if stated) | Expected behavior |
-| **Steps** | How to reproduce (if provided) | Reproduction steps |
-
-**Type Detection**:
-- `bug_report`: "bug", "broken", "doesn't work", "error", "crash"
-- `test_result`: "test passed", "test failed", "ran tests", "testing showed"
-- `observation`: "noticed", "observed", "found that", "saw that"
-- `suggestion`: "should", "could we", "what if", "idea"
-- `general`: Default for unclassified feedback
-
-### Step 2: Check for Duplicates
-
-Search the knowledge base for similar entries:
-
-1. Read `.bugzy/runtime/knowledge-base.md`
-2. Search for:
-   - Same component + similar symptoms
-   - Matching keywords from the description
-   - Recent entries (last 30 days) with similar patterns
-3. If duplicate found:
-   - Reference the existing entry
-   - Note any new information provided
-   - Update existing entry if new details are valuable
-
-### Step 3: Update Knowledge Base
-
-Add or update entry in `.bugzy/runtime/knowledge-base.md`:
-
-**For Bug Reports**:
-```markdown
-### Bug Report: [Brief Description]
-**Reported**: [ISO date]
-**Source**: Slack - [username if available]
-**Component**: [component]
-**Severity**: [severity]
-**Status**: Under investigation
-
-**Description**: [full description]
-
-**Expected Behavior**: [if provided]
-
-**Steps to Reproduce**: [if provided]
-1. Step one
-2. Step two
-
-**Related**: [links to related issues/test cases if any]
-```
-
-**For Observations**:
-```markdown
-### Observation: [Brief Description]
-**Reported**: [ISO date]
-**Source**: Slack - [username if available]
-**Component**: [component]
-**Context**: [what was being done when observed]
-
-**Details**: [full observation]
-
-**Impact**: [potential impact on testing]
-```
-
-**For Test Results**:
-```markdown
-### Manual Test Result: [Test/Feature Name]
-**Reported**: [ISO date]
-**Source**: Slack - [username if available]
-**Result**: [passed/failed]
-**Component**: [component]
-
-**Details**: [what was tested, outcome]
-
-**Notes**: [any additional observations]
-```
-
-### Step 4: Determine Follow-up Actions
-
-Based on feedback type, consider additional actions:
-
-| Type | Potential Actions |
-|------|-------------------|
-| **bug_report (critical/high)** | Consider creating issue via issue-tracker if configured |
-| **bug_report (medium/low)** | Log in knowledge base, may inform future test cases |
-| **test_result** | Update relevant test case status if identifiable |
-| **observation** | May inform test plan updates |
-| **suggestion** | Log for future consideration |
-
-**Issue Tracker Integration** (if configured):
-- For critical/high severity bugs, check if issue-tracker agent is available
-- If so, create or link to an issue in the configured system
-- Reference the issue in the knowledge base entry
-
-### Step 5: Acknowledge and Confirm
-
-Respond to the user confirming:
-1. Feedback was received and understood
-2. Summary of what was captured
-3. What actions will be taken
-4. Any follow-up questions if needed
-
-## Response Guidelines
-
-**Structure**:
-```
-Thanks for reporting this. Here's what I've captured:
-
-[Summary of the feedback]
-
-I've logged this in the knowledge base under [category].
-[Any follow-up actions being taken]
-
-[Optional: Follow-up questions if clarification needed]
-```
-
-**Examples**:
-
-For bug report:
-```
-Thanks for reporting this. I've logged the following:
-
-Bug: Checkout fails when cart has more than 10 items
-- Severity: High
-- Component: Checkout
-- Status: Under investigation
-
-I've added this to the knowledge base. This may affect our checkout test coverage - I'll review TC-045 through TC-048 for related scenarios.
-
-Can you confirm which browser this occurred in?
-```
-
-For observation:
-```
-Good catch - I've noted this observation:
-
-The loading spinner on the dashboard takes longer than expected after the recent update.
-
-I've added this to the knowledge base under performance observations. This might be worth adding to our performance test suite.
-```
-
-## Context Loading Requirements
-
-Required:
-- [x] Knowledge base (`.bugzy/runtime/knowledge-base.md`) - for duplicate check and updates
-
-Conditional:
-- [ ] Test cases (`./test-cases/`) - if feedback relates to specific test
-- [ ] Test runs (`./test-runs/`) - if feedback relates to recent results
-
-## Memory Updates
-
-Required updates:
-- Knowledge base (`.bugzy/runtime/knowledge-base.md`) - add new entry or update existing
-- Optionally team communicator memory if tracking feedback sources

package/templates/init/.bugzy/runtime/handlers/messages/question.md

@@ -1,122 +0,0 @@
-# Question Message Handler
-
-Instructions for processing questions about the project, tests, coverage, or testing status.
-
-## Detection Criteria
-
-This handler applies when:
-- Message contains question words (what, how, which, where, why, when, do, does, is, are, can)
-- Question relates to tests, test plan, coverage, test results, or project artifacts
-- User is seeking information, NOT requesting an action
-- Intent field from LLM layer is `question`
-
-## Processing Steps
-
-### Step 1: Classify Question Type
-
-Analyze the question to determine the primary type:
-
-| Type | Indicators | Primary Context Sources |
-|------|------------|------------------------|
-| **Coverage** | "what tests", "do we have", "is there a test for", "covered" | test-cases/, test-plan.md |
-| **Results** | "did tests pass", "what failed", "test results", "how many" | test-runs/ |
-| **Knowledge** | "how does", "what is", "explain", feature/component questions | knowledge-base.md |
-| **Plan** | "what's in scope", "test plan", "testing strategy", "priorities" | test-plan.md |
-| **Process** | "how do I", "when should", "what's the workflow" | project-context.md |
-
-### Step 2: Load Relevant Context
-
-Based on question type, load the appropriate files:
-
-**For Coverage questions**:
-1. Read `test-plan.md` for overall test strategy
-2. List files in `./test-cases/` directory
-3. Search test case files for relevant keywords
-
-**For Results questions**:
-1. List directories in `./test-runs/` (sorted by date, newest first)
-2. Read `summary.json` from relevant test run directories
-3. Extract pass/fail counts, failure reasons
-
-**For Knowledge questions**:
-1. Read `.bugzy/runtime/knowledge-base.md`
-2. Search for relevant entries
-3. Also check test-plan.md for feature descriptions
-
-**For Plan questions**:
-1. Read `test-plan.md`
-2. Extract relevant sections (scope, priorities, features)
-
-**For Process questions**:
-1. Read `.bugzy/runtime/project-context.md`
-2. Check for workflow documentation
-
-### Step 3: Formulate Answer
-
-Compose the answer following these guidelines:
-
-1. **Be specific**: Quote relevant sections from source files
-2. **Cite sources**: Mention which files contain the information
-3. **Structure clearly**: Use bullet points for multiple items
-4. **Quantify when possible**: "We have 12 test cases covering login..."
-5. **Acknowledge gaps**: If information is incomplete, say so
-
-### Step 4: Offer Follow-up
-
-End responses with:
-- Offer to provide more detail if needed
-- Suggest related information that might be helpful
-- For coverage gaps, offer to create test cases
-
-## Response Guidelines
-
-**Structure**:
-```
-[Direct answer to the question]
-
-[Supporting details/evidence with file references]
-
-[Optional: Related information or follow-up offer]
-```
-
-**Examples**:
-
-For "Do we have tests for login?":
-```
-Yes, we have 4 test cases covering the login feature:
-- TC-001: Successful login with valid credentials
-- TC-002: Login failure with invalid password
-- TC-003: Login with remember me option
-- TC-004: Password reset flow
-
-These are documented in ./test-cases/TC-001.md through TC-004.md.
-Would you like details on any specific test case?
-```
-
-For "How many tests passed in the last run?":
-```
-The most recent test run (2024-01-15 14:30) results:
-- Total: 24 tests
-- Passed: 21 (87.5%)
-- Failed: 3
-
-Failed tests:
-- TC-012: Checkout timeout (performance issue)
-- TC-015: Image upload failed (file size validation)
-- TC-018: Search pagination broken
-
-Results are in ./test-runs/20240115-143000/summary.json
-```
-
-## Context Loading Requirements
-
-Required (based on question type):
-- [ ] Test plan (`test-plan.md`) - for coverage, plan, knowledge questions
-- [ ] Test cases (`./test-cases/`) - for coverage questions
-- [ ] Test runs (`./test-runs/`) - for results questions
-- [ ] Knowledge base (`.bugzy/runtime/knowledge-base.md`) - for knowledge questions
-- [ ] Project context (`.bugzy/runtime/project-context.md`) - for process questions
-
-## Memory Updates
-
-None required - questions are read-only operations. No state changes needed.

package/templates/init/.bugzy/runtime/handlers/messages/status.md

@@ -1,146 +0,0 @@
-# Status Message Handler
-
-Instructions for processing status requests about tests, tasks, or executions.
-
-## Detection Criteria
-
-This handler applies when:
-- User asks about progress or status
-- Keywords present: "status", "progress", "how is", "what happened", "results", "how did", "update on"
-- Questions about test runs, task completion, or execution state
-- Intent field from LLM layer is `status`
-
-## Processing Steps
-
-### Step 1: Identify Status Scope
-
-Determine what the user is asking about:
-
-| Scope | Indicators | Data Sources |
-|-------|------------|--------------|
-| **Latest test run** | "last run", "recent tests", "how did tests go" | Most recent test-runs/ directory |
-| **Specific test** | Test ID mentioned (TC-XXX), specific feature name | test-runs/*/TC-XXX/, test-cases/TC-XXX.md |
-| **All tests / Overall** | "overall", "all tests", "test coverage", "pass rate" | All test-runs/ summaries |
-| **Specific feature** | Feature name mentioned | Filter test-runs by feature |
-| **Task progress** | "is the task done", "what's happening with" | team-communicator memory |
-
-### Step 2: Gather Status Data
-
-**For Latest Test Run**:
-1. List directories in `./test-runs/` sorted by name (newest first)
-2. Read `summary.json` from the most recent directory
-3. Extract: total tests, passed, failed, skipped, execution time
-4. For failures, extract brief failure reasons
-
-**For Specific Test**:
-1. Find test case file in `./test-cases/TC-XXX.md`
-2. Search test-runs for directories containing this test ID
-3. Get most recent result for this specific test
-4. Include: last run date, result, failure reason if failed
-
-**For Overall Status**:
-1. Read all `summary.json` files in test-runs/
-2. Calculate aggregate statistics:
-   - Total runs in period (last 7 days, 30 days, etc.)
-   - Overall pass rate
-   - Most commonly failing tests
-   - Trend (improving/declining)
-
-**For Task Progress**:
-1. Read `.bugzy/runtime/memory/team-communicator.md`
-2. Check for active tasks, blocked tasks, recently completed tasks
-3. Extract relevant task status
-
-### Step 3: Format Status Report
-
-Present status clearly and concisely:
-
-**For Latest Test Run**:
-```
-Test Run: [YYYYMMDD-HHMMSS]
-Status: [Completed/In Progress]
-
-Results:
-- Total: [N] tests
-- Passed: [N] ([%])
-- Failed: [N] ([%])
-- Skipped: [N]
-
-[If failures exist:]
-Failed Tests:
-- [TC-XXX]: [Brief failure reason]
-- [TC-YYY]: [Brief failure reason]
-
-Duration: [X minutes]
-```
-
-**For Specific Test**:
-```
-Test: [TC-XXX] - [Test Name]
-
-Latest Result: [Passed/Failed]
-Run Date: [Date/Time]
-
-[If failed:]
-Failure Reason: [reason]
-Last Successful: [date if known]
-
-[If passed:]
-Consecutive Passes: [N] (since [date])
-```
-
-**For Overall Status**:
-```
-Test Suite Overview (Last [N] Days)
-
-Total Test Runs: [N]
-Average Pass Rate: [%]
-
-Trend: [Improving/Stable/Declining]
-
-Most Reliable Tests:
-- [TC-XXX]: [100%] pass rate
-- [TC-YYY]: [100%] pass rate
-
-Flaky/Failing Tests:
-- [TC-ZZZ]: [40%] pass rate - [common failure reason]
-- [TC-AAA]: [60%] pass rate - [common failure reason]
-
-Last Run: [date/time] - [X/Y passed]
-```
-
-### Step 4: Provide Context and Recommendations
-
-Based on the status:
-
-**For failing tests**:
-- Suggest reviewing the test case
-- Mention if this is a new failure or recurring
-- Link to relevant knowledge base entries if they exist
-
-**For overall declining trends**:
-- Highlight which tests are causing the decline
-- Suggest investigation areas
-
-**For good results**:
-- Acknowledge the healthy state
-- Mention any tests that were previously failing and are now passing
-
-## Response Guidelines
-
-- Lead with the most important information (pass/fail summary)
-- Use clear formatting (bullet points, percentages)
-- Include timestamps so users know data freshness
-- Offer to drill down into specifics if summary was given
-- Keep responses scannable - use structure over paragraphs
-
-## Context Loading Requirements
-
-Required (based on scope):
-- [ ] Test runs (`./test-runs/`) - for any test status
-- [ ] Test cases (`./test-cases/`) - for specific test details
-- [ ] Team communicator memory (`.bugzy/runtime/memory/team-communicator.md`) - for task status
-
-## Memory Updates
-
-None required - status checks are read-only operations. No state changes needed.