@bugzy-ai/bugzy 1.5.0 → 1.7.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +10 -7
- package/dist/cli/index.cjs +6175 -5851
- package/dist/cli/index.cjs.map +1 -1
- package/dist/cli/index.js +6175 -5851
- package/dist/cli/index.js.map +1 -1
- package/dist/index.cjs +5568 -5303
- package/dist/index.cjs.map +1 -1
- package/dist/index.d.cts +5 -4
- package/dist/index.d.ts +5 -4
- package/dist/index.js +5565 -5301
- package/dist/index.js.map +1 -1
- package/dist/subagents/index.cjs +368 -51
- package/dist/subagents/index.cjs.map +1 -1
- package/dist/subagents/index.js +368 -51
- package/dist/subagents/index.js.map +1 -1
- package/dist/subagents/metadata.cjs +10 -2
- package/dist/subagents/metadata.cjs.map +1 -1
- package/dist/subagents/metadata.js +10 -2
- package/dist/subagents/metadata.js.map +1 -1
- package/dist/tasks/index.cjs +864 -2391
- package/dist/tasks/index.cjs.map +1 -1
- package/dist/tasks/index.d.cts +48 -5
- package/dist/tasks/index.d.ts +48 -5
- package/dist/tasks/index.js +862 -2389
- package/dist/tasks/index.js.map +1 -1
- package/dist/templates/init/.bugzy/runtime/knowledge-base.md +61 -0
- package/dist/templates/init/.bugzy/runtime/knowledge-maintenance-guide.md +97 -0
- package/dist/templates/init/.bugzy/runtime/subagent-memory-guide.md +87 -0
- package/dist/templates/init/.bugzy/runtime/templates/test-plan-template.md +41 -16
- package/dist/templates/init/.bugzy/runtime/templates/test-result-schema.md +498 -0
- package/dist/templates/init/.bugzy/runtime/test-execution-strategy.md +535 -0
- package/dist/templates/init/.bugzy/runtime/testing-best-practices.md +368 -14
- package/dist/templates/init/.gitignore-template +23 -2
- package/package.json +1 -1
- package/templates/init/.bugzy/runtime/templates/test-plan-template.md +41 -16
- package/templates/init/.env.testdata +18 -0
|
@@ -0,0 +1,61 @@
|
|
|
1
|
+
# Knowledge Base
|
|
2
|
+
|
|
3
|
+
> 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.
|
|
4
|
+
|
|
5
|
+
**Maintenance Guide**: See `knowledge-maintenance-guide.md` for instructions on how to maintain this knowledge base.
|
|
6
|
+
|
|
7
|
+
**Core Principle**: This document represents current understanding, not a history. When knowledge evolves, update existing entries rather than appending new ones.
|
|
8
|
+
|
|
9
|
+
---
|
|
10
|
+
|
|
11
|
+
## Project Knowledge
|
|
12
|
+
|
|
13
|
+
_This knowledge base will be populated as you work. Add new discoveries, update existing understanding, and remove outdated information following the maintenance guide principles._
|
|
14
|
+
|
|
15
|
+
### When to Update This File
|
|
16
|
+
|
|
17
|
+
- **ADD**: New factual information discovered, new patterns emerge, new areas become relevant
|
|
18
|
+
- **UPDATE**: Facts change, understanding deepens, multiple facts can be consolidated, language can be clarified
|
|
19
|
+
- **REMOVE**: Information becomes irrelevant, facts proven incorrect, entries superseded by better content
|
|
20
|
+
|
|
21
|
+
### Format Guidelines
|
|
22
|
+
|
|
23
|
+
- Use clear, declarative statements in present tense
|
|
24
|
+
- State facts confidently when known; flag uncertainty when it exists
|
|
25
|
+
- Write for someone reading this 6 months from now
|
|
26
|
+
- Keep entries relevant and actionable
|
|
27
|
+
- Favor consolidation over accumulation
|
|
28
|
+
|
|
29
|
+
---
|
|
30
|
+
|
|
31
|
+
## Example Structure
|
|
32
|
+
|
|
33
|
+
Below is an example structure. Feel free to organize knowledge in the way that makes most sense for this project:
|
|
34
|
+
|
|
35
|
+
### Architecture & Infrastructure
|
|
36
|
+
|
|
37
|
+
_System architecture, deployment patterns, infrastructure details_
|
|
38
|
+
|
|
39
|
+
### Testing Patterns
|
|
40
|
+
|
|
41
|
+
_Test strategies, common test scenarios, testing conventions_
|
|
42
|
+
|
|
43
|
+
### UI/UX Patterns
|
|
44
|
+
|
|
45
|
+
_User interface conventions, interaction patterns, design system details_
|
|
46
|
+
|
|
47
|
+
### Data & APIs
|
|
48
|
+
|
|
49
|
+
_Data models, API behaviors, integration patterns_
|
|
50
|
+
|
|
51
|
+
### Known Issues & Workarounds
|
|
52
|
+
|
|
53
|
+
_Current limitations, known bugs, and their workarounds_
|
|
54
|
+
|
|
55
|
+
### Domain Knowledge
|
|
56
|
+
|
|
57
|
+
_Business domain facts, terminology, rules, and context_
|
|
58
|
+
|
|
59
|
+
---
|
|
60
|
+
|
|
61
|
+
**Remember**: Every entry should answer "Will this help someone working on this project in 6 months?"
|
|
@@ -0,0 +1,97 @@
|
|
|
1
|
+
# Knowledge Maintenance Guide
|
|
2
|
+
|
|
3
|
+
## Overview
|
|
4
|
+
|
|
5
|
+
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.
|
|
6
|
+
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
## Core Principle: This is a Curated Snapshot, Not a Log
|
|
10
|
+
|
|
11
|
+
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.
|
|
12
|
+
|
|
13
|
+
---
|
|
14
|
+
|
|
15
|
+
## When to ADD
|
|
16
|
+
|
|
17
|
+
Add new entries when:
|
|
18
|
+
|
|
19
|
+
- New factual information is discovered
|
|
20
|
+
- New patterns or relationships emerge
|
|
21
|
+
- New areas of knowledge become relevant
|
|
22
|
+
|
|
23
|
+
**Check first**: Does this duplicate or overlap with existing entries?
|
|
24
|
+
|
|
25
|
+
---
|
|
26
|
+
|
|
27
|
+
## When to UPDATE
|
|
28
|
+
|
|
29
|
+
Update existing entries when:
|
|
30
|
+
|
|
31
|
+
- Facts change or we discover more accurate information
|
|
32
|
+
- Understanding deepens (replace shallow with deeper insight)
|
|
33
|
+
- Multiple related facts can be consolidated into one coherent statement
|
|
34
|
+
- Language can be clarified or made more precise
|
|
35
|
+
|
|
36
|
+
**Goal**: Replace outdated understanding with current understanding
|
|
37
|
+
|
|
38
|
+
---
|
|
39
|
+
|
|
40
|
+
## When to REMOVE
|
|
41
|
+
|
|
42
|
+
Remove entries when:
|
|
43
|
+
|
|
44
|
+
- Information becomes irrelevant to current needs
|
|
45
|
+
- Facts are proven incorrect (unless there's value in noting the correction)
|
|
46
|
+
- Information is superseded by better, more comprehensive entries
|
|
47
|
+
- Entry is redundant with other content
|
|
48
|
+
|
|
49
|
+
**Key question**: "If someone reads this in 6 months, will it help them?"
|
|
50
|
+
|
|
51
|
+
---
|
|
52
|
+
|
|
53
|
+
## Maintenance Principles
|
|
54
|
+
|
|
55
|
+
### 1. Favor Consolidation Over Addition
|
|
56
|
+
|
|
57
|
+
- Before adding, ask: "Can this merge with existing knowledge?"
|
|
58
|
+
- Example: Instead of 10 facts about a person, maintain 2-3 well-organized paragraphs
|
|
59
|
+
|
|
60
|
+
### 2. Update Rather Than Append
|
|
61
|
+
|
|
62
|
+
- When information evolves, replace the old statement
|
|
63
|
+
- Keep history only if the evolution itself is important
|
|
64
|
+
- Example: ~~"User is learning Python"~~ → "User is proficient in Python and focusing on FastAPI"
|
|
65
|
+
|
|
66
|
+
### 3. Regular Pruning
|
|
67
|
+
|
|
68
|
+
- Periodically review for outdated or low-value entries
|
|
69
|
+
- Ask: "Is this still accurate? Still relevant? Could it be stated better?"
|
|
70
|
+
- Aim for signal-to-noise ratio improvement
|
|
71
|
+
|
|
72
|
+
### 4. Quality Over Completeness
|
|
73
|
+
|
|
74
|
+
- Better to have 50 highly relevant, accurate facts than 500 marginally useful ones
|
|
75
|
+
- Prioritize insights over raw data
|
|
76
|
+
- Focus on what's actionable or decision-relevant
|
|
77
|
+
|
|
78
|
+
### 5. Resolve Contradictions Immediately
|
|
79
|
+
|
|
80
|
+
- If new information contradicts old, investigate and keep only the truth
|
|
81
|
+
- Don't accumulate conflicting statements
|
|
82
|
+
|
|
83
|
+
### 6. Use Clear, Declarative Statements
|
|
84
|
+
|
|
85
|
+
- Write in present tense: "User works at X" not "User mentioned they work at X"
|
|
86
|
+
- State facts confidently when known; flag uncertainty when it exists
|
|
87
|
+
- Avoid hedging unless genuinely uncertain
|
|
88
|
+
|
|
89
|
+
---
|
|
90
|
+
|
|
91
|
+
## Anti-Patterns to Avoid
|
|
92
|
+
|
|
93
|
+
| ❌ Don't Do This | ✅ Do This Instead |
|
|
94
|
+
|-----------------|-------------------|
|
|
95
|
+
| "On Tuesday user said X, then on Friday user said Y" | "User's position on X is Y" (keep most current) |
|
|
96
|
+
| Keeping every detail ever mentioned | Keeping relevant, current details |
|
|
97
|
+
| "User might like coffee, user mentioned tea once, user drinks water" | "User prefers tea; also drinks coffee occasionally" |
|
|
@@ -0,0 +1,87 @@
|
|
|
1
|
+
# Sub-Agent Memory: Maintenance Instructions
|
|
2
|
+
|
|
3
|
+
## What This Memory Is
|
|
4
|
+
|
|
5
|
+
A focused collection of knowledge relevant to your specific role. This is your working knowledge, not a log of interactions.
|
|
6
|
+
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
## When to ADD
|
|
10
|
+
|
|
11
|
+
Add when information:
|
|
12
|
+
- Directly impacts your decisions or outputs
|
|
13
|
+
- Represents a pattern or learning within your domain
|
|
14
|
+
- Prevents repeated mistakes in your area
|
|
15
|
+
|
|
16
|
+
**Check first**: Does this overlap with main agent knowledge or another sub-agent's domain?
|
|
17
|
+
|
|
18
|
+
---
|
|
19
|
+
|
|
20
|
+
## When to UPDATE
|
|
21
|
+
|
|
22
|
+
Update when:
|
|
23
|
+
- Preferences or requirements change within your domain
|
|
24
|
+
- Understanding deepens through repeated interactions
|
|
25
|
+
- Patterns evolve or are refined
|
|
26
|
+
- Multiple related facts can be consolidated
|
|
27
|
+
|
|
28
|
+
**Replace** outdated information with current understanding.
|
|
29
|
+
|
|
30
|
+
---
|
|
31
|
+
|
|
32
|
+
## When to REMOVE
|
|
33
|
+
|
|
34
|
+
Remove when:
|
|
35
|
+
- No longer relevant to current work
|
|
36
|
+
- Better handled by main agent's knowledge
|
|
37
|
+
- Proven incorrect or outdated
|
|
38
|
+
- Never actually used in decision-making
|
|
39
|
+
|
|
40
|
+
**Test**: "Has this influenced a decision recently? Will it influence one soon?"
|
|
41
|
+
|
|
42
|
+
---
|
|
43
|
+
|
|
44
|
+
## Core Rules
|
|
45
|
+
|
|
46
|
+
1. **Stay in your domain** - Don't duplicate main agent knowledge
|
|
47
|
+
2. **Operational over historical** - Keep patterns, not logs
|
|
48
|
+
3. **Patterns over instances** - Generalize from specific events
|
|
49
|
+
4. **Actionable over observational** - Every entry must answer "How does this change what I do?"
|
|
50
|
+
5. **Consolidate aggressively** - Aim for 10-30 high-signal entries
|
|
51
|
+
6. **Update as understanding crystallizes** - Refine vague into specific
|
|
52
|
+
|
|
53
|
+
---
|
|
54
|
+
|
|
55
|
+
## Quick Decision Tree
|
|
56
|
+
|
|
57
|
+
```
|
|
58
|
+
New information
|
|
59
|
+
│
|
|
60
|
+
├─ Relevant to my function? No → Ignore or suggest for main agent
|
|
61
|
+
│ Yes ↓
|
|
62
|
+
│
|
|
63
|
+
├─ Actionable (changes what I do)? No → Don't store
|
|
64
|
+
│ Yes ↓
|
|
65
|
+
│
|
|
66
|
+
├─ Duplicates existing? Yes → UPDATE existing entry
|
|
67
|
+
│ No ↓
|
|
68
|
+
│
|
|
69
|
+
└─ Belongs in main agent? Yes → Move to main agent
|
|
70
|
+
No → ADD to my memory
|
|
71
|
+
```
|
|
72
|
+
|
|
73
|
+
---
|
|
74
|
+
|
|
75
|
+
## Division with Main Agent
|
|
76
|
+
|
|
77
|
+
**Main Agent** stores:
|
|
78
|
+
- User's overall preferences and background
|
|
79
|
+
- Project-wide decisions
|
|
80
|
+
- Cross-cutting concerns
|
|
81
|
+
|
|
82
|
+
**You (Sub-Agent)** store:
|
|
83
|
+
- Domain-specific preferences and patterns
|
|
84
|
+
- Tactical learnings within your scope
|
|
85
|
+
- Working knowledge for your specific tasks
|
|
86
|
+
|
|
87
|
+
**When in doubt**: If multiple sub-agents could use it → Main agent
|
|
@@ -1,25 +1,50 @@
|
|
|
1
|
-
|
|
1
|
+
---
|
|
2
|
+
version: 1.0.0
|
|
3
|
+
created_at: [DATE]
|
|
4
|
+
updated_at: [DATE]
|
|
5
|
+
status: draft
|
|
6
|
+
---
|
|
2
7
|
|
|
3
|
-
|
|
8
|
+
# Test Plan: [PROJECT_NAME]
|
|
4
9
|
|
|
5
|
-
|
|
6
|
-
**Objective**: [What are we testing?]
|
|
10
|
+
## Overview
|
|
7
11
|
|
|
8
|
-
|
|
9
|
-
1. [Test case description]
|
|
10
|
-
2. [Test case description]
|
|
12
|
+
[2-3 sentences describing what the application does and the testing focus]
|
|
11
13
|
|
|
12
|
-
|
|
13
|
-
- [Expected outcome]
|
|
14
|
+
## Features to Test
|
|
14
15
|
|
|
15
|
-
###
|
|
16
|
-
|
|
16
|
+
### [Feature Area 1]
|
|
17
|
+
- [ ] Feature 1.1 - Brief description
|
|
18
|
+
- [ ] Feature 1.2 - Brief description
|
|
17
19
|
|
|
18
|
-
|
|
19
|
-
|
|
20
|
+
### [Feature Area 2]
|
|
21
|
+
- [ ] Feature 2.1 - Brief description
|
|
22
|
+
- [ ] Feature 2.2 - Brief description
|
|
20
23
|
|
|
21
|
-
|
|
22
|
-
- [
|
|
24
|
+
### [Feature Area 3]
|
|
25
|
+
- [ ] Feature 3.1 - Brief description
|
|
26
|
+
|
|
27
|
+
## Out of Scope
|
|
28
|
+
|
|
29
|
+
- Item 1 - Reason (e.g., requires native mobile app)
|
|
30
|
+
- Item 2 - Reason (e.g., backend-only, no UI)
|
|
31
|
+
|
|
32
|
+
## Test Environment
|
|
33
|
+
|
|
34
|
+
- **URL**: TEST_BASE_URL
|
|
35
|
+
- **User Credentials**: TEST_USER_EMAIL / TEST_USER_PASSWORD
|
|
36
|
+
- **Admin Credentials**: TEST_ADMIN_EMAIL / TEST_ADMIN_PASSWORD (if applicable)
|
|
37
|
+
|
|
38
|
+
## Automation Priority
|
|
39
|
+
|
|
40
|
+
| Priority | Criteria |
|
|
41
|
+
|----------|----------|
|
|
42
|
+
| High | Critical user flows, smoke tests, frequent regression areas |
|
|
43
|
+
| Medium | Important features, moderate user impact |
|
|
44
|
+
| Low | Edge cases, rarely used features |
|
|
23
45
|
|
|
24
46
|
## Notes
|
|
25
|
-
|
|
47
|
+
|
|
48
|
+
- See `./exploration-reports/` for detailed UI element discovery
|
|
49
|
+
- See `.bugzy/runtime/knowledge-base.md` for technical patterns
|
|
50
|
+
- See `.bugzy/runtime/project-context.md` for SDLC and team info
|