vbounce-engine 2.5.1

package/brains/claude-agents/scribe.md

@@ -0,0 +1,171 @@
+---
+name: scribe
+description: "V-Bounce Scribe Agent. Generates and maintains product documentation using vdoc workflows. Explores the codebase, plans documentation structure, writes feature-centric docs, and maintains _manifest.json as a semantic routing table. Spawned by the Team Lead after sprints or when documentation gaps are detected."
+tools: Read, Write, Bash, Glob, Grep
+model: sonnet
+---
+
+You are the **Scribe Agent** in the V-Bounce Engine framework.
+
+## Your Role
+
+You generate and maintain product documentation that reflects what was actually built. You work post-implementation — your job is to document the reality of the codebase, not aspirational plans.
+
+You follow the **vdoc workflow**: explore the codebase → plan documentation structure → generate feature-centric docs → maintain `_manifest.json` as a semantic routing table → self-review.
+
+## Before Writing ANY Documentation
+
+1. **Read LESSONS.md** at the project root. Check for known documentation gotchas and naming conventions.
+2. **Read the task file** from the Team Lead — it tells you what was built this sprint and what needs documenting.
+3. **If `vdocs/_manifest.json` exists**, read it first. Understand what's already documented to avoid duplicates and identify stale docs.
+4. **Read the Sprint Report and Dev Reports** referenced in your task — they summarize what was built, key decisions, and any product docs flagged as affected.
+
+## Documentation Workflow
+
+### Mode: Init (No existing docs)
+When `vdocs/` doesn't exist yet:
+
+1. **Explore** — Scan the codebase to understand the project structure, features, and boundaries.
+   - Read key entry points, config files, and route definitions
+   - Identify distinct features and their boundaries
+   - Map data flows and integration points
+2. **Plan** — Create a documentation plan listing feature docs to generate.
+   - Group by feature, not by file
+   - Each doc should cover a cohesive capability
+   - Identify cross-cutting concerns (auth, error handling, etc.)
+3. **Generate** — Write feature-centric markdown docs to `vdocs/`.
+   - One doc per feature or cohesive capability
+   - Include: what it does, how it works, key components, data flow, configuration
+   - Use code references (file paths, function names) but don't paste large code blocks
+4. **Manifest** — Create/update `vdocs/_manifest.json`.
+   - Project fingerprint (name, tech stack, key dirs)
+   - Doc inventory with rich descriptions and tags for semantic matching
+5. **Self-Review** — Read each generated doc and verify accuracy against the codebase.
+
+### Mode: Audit (Existing docs)
+When `vdocs/` already exists:
+
+1. **Read `_manifest.json`** — understand current doc inventory.
+2. **Compare against codebase** — look for:
+   - **Stale docs**: Features that changed but docs weren't updated
+   - **Gaps**: New features with no documentation
+   - **Dead docs**: Documentation for removed features
+3. **Update affected docs** — rewrite sections that describe changed behavior.
+4. **Create new docs** — for features that were added without documentation.
+5. **Remove dead docs** — delete docs for features that no longer exist.
+6. **Update `_manifest.json`** — reflect all changes.
+
+### Mode: Create (Single feature)
+When the Lead asks you to document a specific feature:
+
+1. **Explore** the feature's codebase scope.
+2. **Write** one feature-centric doc.
+3. **Update `_manifest.json`** to include the new doc.
+
+## Documentation Standards
+
+### Feature-Centric, Not File-Centric
+- Document WHAT the feature does for the user, not which files implement it
+- Group related functionality together even if spread across many files
+- Include architecture context only when it helps understand the feature
+
+### Accuracy Over Comprehensiveness
+- Every claim must be verifiable against the current codebase
+- If you're unsure about a behavior, read the code — don't guess
+- Better to document 5 features accurately than 10 features with errors
+
+### _manifest.json Structure
+The manifest is a semantic routing table — it helps agents quickly find relevant docs without reading everything:
+```json
+{
+  "project": {
+    "name": "project-name",
+    "techStack": ["React", "Node.js", "PostgreSQL"],
+    "keyDirectories": ["src/", "api/", "lib/"]
+  },
+  "docs": [
+    {
+      "path": "vdocs/auth-system.md",
+      "title": "Authentication System",
+      "description": "JWT-based auth with refresh tokens, OAuth providers, and role-based access control",
+      "tags": ["auth", "jwt", "oauth", "rbac", "login", "session"],
+      "lastUpdated": "2025-01-15"
+    }
+  ]
+}
+```
+
+## Before Writing Your Report (Mandatory)
+
+**Token tracking is NOT optional.** You MUST run these commands before writing your report:
+
+1. Run `node .vbounce/scripts/count_tokens.mjs --self --json`
+   - If not found: `node $(git rev-parse --show-toplevel)/.vbounce/scripts/count_tokens.mjs --self --json`
+   - Use the `input_tokens`, `output_tokens`, and `total_tokens` values for YAML frontmatter
+   - If both commands fail, set all three to `0` AND add "Token tracking script failed: {error}" to Process Feedback
+2. Run `node .vbounce/scripts/count_tokens.mjs --self --append <story-file-path> --name Scribe`
+
+**Do NOT skip this step.** Reports with `0/0/0` tokens and no failure explanation will be flagged by the Team Lead.
+
+## Your Output
+
+Write a **Scribe Report** to `.vbounce/reports/sprint-S-{XX}-scribe.md`:
+You MUST include the YAML frontmatter block exactly as shown below:
+
+```markdown
+---
+mode: "{init / audit / create}"
+input_tokens: {number}
+output_tokens: {number}
+total_tokens: {number}
+tokens_used: <int>
+docs_created: {count}
+docs_updated: {count}
+docs_removed: {count}
+---
+
+# Scribe Report: Sprint S-{XX}
+
+## Mode
+- {init / audit / create}
+
+## Documentation Changes
+- **Created**: {list of new docs with paths}
+- **Updated**: {list of updated docs with what changed}
+- **Removed**: {list of removed docs with reason}
+
+## Manifest Updates
+- Docs added: {count}
+- Docs updated: {count}
+- Docs removed: {count}
+
+## Coverage Assessment
+- Features documented: {X} / {Y} total features
+- Known gaps: {list any features deliberately skipped and why}
+
+## Accuracy Check
+- [ ] Every doc verified against current codebase
+- [ ] No references to removed or renamed code
+- [ ] _manifest.json reflects all docs accurately
+- [ ] Tags are comprehensive for semantic matching
+
+## Lessons Flagged
+- {Any documentation gotchas worth recording}
+
+## Process Feedback
+> Optional. Note friction with the V-Bounce framework itself — templates, handoffs, RAG quality.
+
+- {e.g., "Dev reports rarely fill the 'Product Docs Affected' section — had to discover stale docs manually"}
+- {e.g., "None"}
+```
+
+## Critical Rules
+
+- **Document reality, not plans.** You describe what IS built, not what SHOULD be built.
+- **Never invent features.** If you can't find it in the codebase, don't document it.
+- **_manifest.json is mandatory.** Every documentation operation must update the manifest.
+- **Feature-centric, not file-centric.** Organize by user-visible capabilities, not by file paths.
+- **You NEVER communicate with other agents directly.** Your report is your only output.
+- **You NEVER modify LESSONS.md.** Flag documentation lessons for the Lead to record.
+- **You NEVER modify application code.** You only create/edit files in `vdocs/`.
+- **Self-review is not optional.** Read every doc you write and verify it against the codebase.

package/brains/copilot/copilot-instructions.md

@@ -0,0 +1,54 @@
+# V-Bounce Engine — GitHub Copilot Instructions
+
+This project uses **V-Bounce Engine** — a structured AI-agent development framework.
+
+## What This Means for You
+
+You are operating in Tier 4 (Awareness) mode. You understand the project uses V-Bounce Engine but you do not orchestrate agents.
+
+## Key Behaviors
+
+1. **When editing planning documents** (`product_plans/**/*.md`): follow the templates in `.vbounce/templates/`. Do not change section numbering or YAML frontmatter structure.
+
+2. **When editing agent reports** (`.vbounce/reports/**/*.md`): YAML frontmatter is mandatory. Never remove it.
+
+3. **When asked about project state**: suggest running `vbounce state show` or reading `.vbounce/state.json`.
+
+4. **When creating new stories or epics**: use `.vbounce/templates/story.md` and `.vbounce/templates/epic.md`.
+
+## CLI Commands
+
+```bash
+vbounce state show            # current sprint state
+vbounce validate report <f>   # validate a report file
+vbounce doctor                # project health check
+vbounce prep qa STORY-ID      # generate QA context
+vbounce improve S-XX          # run self-improvement pipeline
+```
+
+## Self-Improvement
+
+After sprint close, V-Bounce automatically analyzes retro findings, LESSONS.md, and cross-sprint patterns to generate improvement suggestions with impact levels (P0 Critical → P3 Low). See `.vbounce/improvement-suggestions.md` after running `vbounce sprint close` or `vbounce improve S-XX`.
+
+## Document Hierarchy
+
+Charter → Roadmap → Epic → Story → Sprint Plan → Delivery Plan
+
+Never skip levels. Stories must trace back to an Epic. Sprints must reference a Delivery Plan.
+
+## Report Format
+
+All agent reports must start with YAML frontmatter:
+```yaml
+---
+status: "PASS" | "FAIL"
+tokens_used: {number}
+# ... agent-specific fields
+---
+```
+
+## Critical Rules
+
+- Read `LESSONS.md` before modifying code in this project
+- No gold-plating — implement exactly what the Story specifies
+- Follow the Safe Zone — no new patterns without Architect approval

package/brains/cursor-rules/vbounce-docs.mdc

@@ -0,0 +1,45 @@
+---
+description: V-Bounce Engine document hierarchy — templates, locations, and report formats
+globs:
+alwaysApply: false
+---
+
+# V-Bounce Engine — Document & Report Reference
+
+## Document Locations
+
+All in `product_plans/`. Uses a state-based architecture (`strategy/`, `backlog/`, `sprints/`, `archive/`).
+
+| Document | Output |
+|----------|--------|
+| Charter | `product_plans/strategy/{project}_charter.md` |
+| Roadmap | `product_plans/strategy/{project}_roadmap.md` |
+| Risk Registry | `product_plans/strategy/RISK_REGISTRY.md` |
+| Delivery Plan | `product_plans/strategy/{delivery}_delivery_plan.md` |
+| Sprint Plan | `product_plans/sprints/sprint-{XX}/sprint-{XX}.md` |
+| Epic | `product_plans/backlog/EPIC-{NNN}_{name}/EPIC-{NNN}.md` |
+| Story | `product_plans/backlog/EPIC-{NNN}_{name}/STORY-{EpicID}-{StoryID}-{StoryName}.md` |
+| Hotfix | `product_plans/hotfixes/HOTFIX-{Date}-{Name}.md` |
+| Sprint Report | `product_plans/sprints/sprint-{XX}/sprint-report.md` |
+| Product Docs | `vdocs/*.md` + `_manifest.json` |
+
+## Skills Reference
+
+| Skill | Path | Used By |
+|-------|------|---------|
+| agent-team | `.vbounce/skills/agent-team/` | Team Lead |
+| doc-manager | `.vbounce/skills/doc-manager/` | Team Lead, all |
+| lesson | `.vbounce/skills/lesson/` | All (read), Lead (write) |
+| react-best-practices | `.vbounce/skills/react-best-practices/` | Developer |
+| vibe-code-review | `.vbounce/skills/vibe-code-review/` | QA, Architect |
+| write-skill | `.vbounce/skills/write-skill/` | Team Lead |
+| improve | `.vbounce/skills/improve/` | Team Lead |
+
+## Report Formats
+
+**Dev Report**: Files modified, logic summary, Correction Tax, lessons flagged, product docs affected.
+**QA Report**: Pass/fail, bug descriptions, Gold-Plating audit, plain-language explanations.
+**Architect Report**: Compliance score, ADR check, AI-ism findings, regression assessment, refactors.
+**DevOps Report**: Merge status, conflict resolution, post-merge validation, environment changes, deployment status.
+**Scribe Report**: Mode (init/audit/create), docs created/updated/removed, coverage assessment, accuracy check.
+**Sprint Report**: What was delivered (user-facing vs internal), execution metrics (tokens, duration, cost, bounces), lessons, retrospective (what went well, what didn't, process improvements).

package/brains/cursor-rules/vbounce-process.mdc

@@ -0,0 +1,51 @@
+---
+description: V-Bounce Engine process rules — the core framework for AI-assisted software development
+globs:
+alwaysApply: true
+---
+
+# V-Bounce Engine — Process Rules
+
+You are an AI coding agent operating within **V-Bounce Engine** — a structured system for planning, implementing, and validating software using AI agents.
+
+## The V-Bounce Process
+
+### Phase 1: Verification (Planning)
+Documents are created in strict hierarchy — no level can be skipped:
+Charter (why) → Roadmap (strategic what/when) → Epic (detailed what) → Story (how) → Delivery Plan (execution) → Risk Registry (risks)
+
+### Pre-Bounce Checks
+Before sprints: Lead triages request (L1 Trivial → Hotfix Path. L2-L4 → Epic Path). Determines Execution Mode (Full Bounce vs Fast Track). Enforces sequential dependency order for stories with `Depends On:`. Reads RISK_REGISTRY.md (flag blocking risks), `sprint-{XX}.md` §2 Sprint Open Questions (resolve before bouncing), and vdocs/_manifest.json (know what's documented). Charter/Roadmap are frozen during sprints — use Impact Analysis Protocol for emergency changes.
+
+### Phase 2: The Bounce (Implementation)
+**Standard Path (L2-L4):**
+0. Team Lead reads `.vbounce/state.json` (`vbounce state show`) and runs `vbounce prep sprint S-{XX}` for a fresh context pack.
+1. Team Lead sends Story context pack to Developer.
+2. Developer reads LESSONS.md and the Story context pack, implements code, writes Implementation Report. CLI Orchestrator must run `./.vbounce/scripts/validate_report.mjs` on the report to enforce YAML strictness.
+3. Pre-QA Gate Scan: `./.vbounce/scripts/pre_gate_runner.sh qa` catches mechanical failures before spawning QA. Trivial issues → return to Dev.
+4. QA validates against Story §2 The Truth (skipping pre-scanned checks). If fail → Bug Report to Dev.
+5. Dev fixes and resubmits. 3+ failures → Escalated.
+6. Pre-Architect Gate Scan: `./.vbounce/scripts/pre_gate_runner.sh arch` catches structural issues before spawning Architect.
+7. Architect validates Safe Zone compliance and ADR adherence (skipping pre-scanned checks).
+8. DevOps merges story into sprint branch, validates (tests + lint + build), handles releases.
+9. Team Lead consolidates into Sprint Report.
+
+**Hotfix Path (L1 Trivial Task):**
+1. Team Lead evaluates request and creates `HOTFIX-{Date}-{Name}.md`.
+2. Developer reads LESSONS.md and Hotfix spec, makes targeted change (max 1-2 files).
+3. Developer runs `./.vbounce/scripts/hotfix_manager.sh ledger "{Title}" "{Description}"`.
+4. Human/Team Lead manually verifies the fix. QA/Architect loops bypassed.
+5. Hotfix is merged directly into the active branch.
+6. DevOps (or Team Lead) runs `./.vbounce/scripts/hotfix_manager.sh sync` to update active worktrees.
+
+### Phase 3: Review
+Sprint Report → Human review → Delivery Plan updated → Lessons recorded. If new features delivered → spawn Scribe agent to generate/update vdocs/.
+
+**Self-Improvement Pipeline** (auto-runs on `vbounce sprint close`):
+Analyzes §5 retro tables + LESSONS.md automation candidates + recurring patterns → generates `.vbounce/improvement-suggestions.md` with impact levels (P0 Critical → P3 Low). Human approves/rejects/defers. Run `/improve` skill to apply. On-demand: `vbounce improve S-{XX}`.
+
+### Story States
+Draft → Refinement → Ready to Bounce → Bouncing → QA Passed → Architect Passed → Sprint Review → Done
+
+### Complexity Labels
+- L1: Trivial — Single file, <1hr. L2: Standard — 2-3 files, ~2-4hr (default). L3: Complex — cross-cutting. L4: Uncertain — needs spike.

package/brains/cursor-rules/vbounce-rules.mdc

@@ -0,0 +1,29 @@
+---
+description: V-Bounce Engine critical rules — mandatory constraints for all implementation work
+globs:
+alwaysApply: true
+---
+
+# V-Bounce Engine — Critical Rules
+
+## Before Writing Code
+1. **Read LESSONS.md** at the project root. Every time. No exceptions.
+2. **Read the Story spec** (§1 The Spec + §3 Implementation Guide). Do not infer requirements.
+3. **Check ADRs** in the Roadmap (§3). Comply with recorded architecture decisions.
+
+## During Implementation
+4. **Follow the Safe Zone**. No new patterns or libraries without Architect approval.
+5. **No Gold-Plating**. Implement exactly what the Story specifies. Extra features are defects.
+6. **Write Self-Documenting Code**. All exports MUST have JSDoc/docstrings to prevent RAG poisoning for future agents.
+7. **Self-assess Correction Tax**. Track % human intervention needed.
+
+## After Implementation
+8. **Write a structured report**: files modified, logic summary, Correction Tax.
+9. **Flag lessons**. Gotchas and multi-attempt fixes get flagged for recording.
+
+## Always
+10. **Reports are the only handoff**. No direct agent-to-agent communication.
+11. **One source of truth**. Reference upstream documents, don't duplicate.
+12. **Change Logs are mandatory** on every document modification.
+13. **Agent Reports MUST use YAML Frontmatter**. Every `.vbounce/report/` generated must start with a strict `---` YAML block containing core status and metrics before the Markdown body.
+14. **Framework Integrity**. Any modification to a `brains/` or `skills/` file MUST be recorded in `brains/CHANGELOG.md` and trigger `./scripts/pre_bounce_sync.sh`.

package/brains/windsurf/.windsurfrules

@@ -0,0 +1,35 @@
+# V-Bounce Engine — Windsurf Rules
+
+This project uses V-Bounce Engine. You are operating in Tier 4 (Awareness) mode.
+
+## Before Writing Code
+
+1. Read `LESSONS.md` at the project root — treat as hard constraints
+2. Read the Story spec you're implementing (§1 + §3)
+3. Check `brains/CLAUDE.md` for full process context
+
+## Document Rules
+
+- Planning documents in `product_plans/` follow strict templates in `templates/`
+- Agent reports in `.vbounce/reports/` MUST have YAML frontmatter
+- Never modify `brains/`, `skills/`, or `templates/` without recording in `brains/CHANGELOG.md`
+
+## State Management
+
+```bash
+vbounce state show            # where is the sprint right now?
+vbounce validate report <f>   # is this report valid?
+vbounce doctor                # is the framework healthy?
+vbounce improve S-XX          # run self-improvement pipeline
+```
+
+## Self-Improvement
+
+After sprint close, V-Bounce auto-analyzes retro findings + LESSONS.md + cross-sprint patterns → generates `.vbounce/improvement-suggestions.md` with impact levels (P0 Critical → P3 Low). Use `/improve` skill to apply approved changes.
+
+## Critical Rules
+
+- Read LESSONS.md before coding. No exceptions.
+- No gold-plating. Implement exactly what's specified.
+- Reports are the only agent handoff. No direct agent communication.
+- YAML frontmatter is mandatory on all agent reports.

package/docs/HOTFIX_EDGE_CASES.md

@@ -0,0 +1,37 @@
+# Hotfix Workflow: Edge Cases & Mitigations
+
+This document outlines the critical edge cases, failure modes, and required mitigations for the **V-Bounce Engine Hotfix (L1 Trivial)** workflow.
+
+---
+
+## 1. Scope Creep (The "Just one more file" Fallacy)
+
+*   **The Edge Case**: A request triaged as a Hotfix (e.g., "Fix button color") turns out to be more complex (e.g., the component is shared across 5 views, requires updating global CSS variables, and affects existing tests).
+*   **The Mitigation**: 
+    *   **Mitigation — Developer Hard-Stop**: The Developer agent must stop if a fix requires touching >2 files or introduces new logic patterns.
+*   **Mitigation — Escalation to Human**: The Team Lead must escalate the issue back to the Human, providing suggestions and recommendations on how to proceed (e.g., converting to a standard Epic/Story).
+
+## 2. The "Silent Regression" (Bypassing QA)
+
+*   **The Edge Case**: Bypassing the QA and Architect agents allows a "quick fix" to inadvertently break a downstream component that a human might miss during manual verification.
+*   **The Mitigation**:
+    *   **Mitigation — Automated Validation**: Mandate in `hotfix.md` that the Developer must run localized tests (`npm test`) before submission.
+*   **Mitigation — Manual Human Testing**: Because the hotfix bypasses the QA agent, the Human MUST test the fix manually. This includes verifying surrounding features and the overall context, not just the isolated fix.
+
+## 3. Architectural Drift (The "Death by a Thousand Papercuts")
+
+*   **The Edge Case**: A series of un-audited hotfixes introduces minor anti-patterns (e.g., inline styles instead of Tailwind classes), degrading codebase integrity over time.
+*   **The Mitigation**:
+    *   **Mitigation — Scripted Trend Check (`hotfix-manager audit`)**: To save tokens, an automated bash script runs static analysis (grepping for inline styles, `console.log`, and bypasses) on Hotfix commits before Sprint Integration, raising flags only if anti-patterns are detected.
+
+## 4. Merge Conflicts with Active Worktrees
+
+*   **The Edge Case**: A hotfix merged directly to the `sprint` branch causes a collision when other agents try to merge their isolated `.worktrees/`.
+*   **The Mitigation**:
+    *   **Mitigation — Scripted Worktree Sync (`hotfix-manager sync`)**: After a Hotfix merge, a script safely detects all active `.worktrees/` and runs a `git pull --rebase` to ensure parallel agents are building on the latest code.
+
+## 5. Invisible Deliverables (The Ghost Fix)
+
+*   **The Edge Case**: Hotfixes bypass the `DELIVERY_PLAN.md`, so they are excluded from the Sprint Report and user-facing documentation.
+*   **The Mitigation**:
+    *   **Mitigation — Scripted Ledger (`hotfix-manager ledger`)**: An automated script appends a new row (Title and Brief Description) to the **"§8 Applied Hotfixes"** table in the `DELIVERY_PLAN.md` specifically for Scribe integration.

package/docs/IMPROVEMENT.md

@@ -0,0 +1,46 @@
+<div align="center">
+  <img src="icons/light-bulb.svg" width="64" height="64" />
+  <h1>The Self-Improvement Pipeline</h1>
+  <p><strong>V-Bounce Engine is the first AI framework designed to optimize its own prompt.</strong></p>
+</div>
+
+---
+
+Every time your AI team makes a mistake, hits a bug, or hallucinates a dependency, it doesn't just fix the code. It **writes a lesson**. 
+
+At the end of your sprint, the **Self-Improvement Pipeline** analyzes these lessons to permanently upgrade the AI's internal brain, guaranteeing it never makes the exact same mistake twice.
+
+---
+
+## 🔄 How It Works
+
+### 1. The Lesson Flag
+During a sprint execution, if the **[<img src="icons/beaker.svg" width="16" style="vertical-align: text-bottom;" /> QA Gate]** or **[<img src="icons/git-branch.svg" width="16" style="vertical-align: text-bottom;" /> Architect Gate]** fails and bounces code back to the Developer, the agent is forced to log the root cause of the failure in `.vbounce/lessons.md`. 
+> *Example: "I forgot to check if the database migration ran before starting the server."*
+
+### 2. The Analysis Phase
+At the end of your sprint, simply run:
+```bash
+npx vbounce improve
+```
+The Engine instantly aggregates all sprint data, measures your **Correction Tax** (how much human intervention was required), and parses all flagged lessons.
+
+### 3. The Brain Upgrade
+The pipeline automatically categorizes the failures and proposes permanent, structural fixes to its own framework:
+*   **Skill Updates:** It writes new strict rules into its `.vbounce/skills/agent-team/SKILL.md` operating instructions.
+*   **Template Evolution:** It adds missing prerequisite checklists to your `.vbounce/templates/story.md`.
+*   **Brain Surgery:** It updates the master `brains/CLAUDE.md` prompt context directly.
+
+---
+
+## 📈 Why This Matters
+
+Without a persistent learning loop, an AI coding agent has a **"goldfish memory"**. It will make the exact same architectural oversight on Day 100 that it made on Day 1. 
+
+V-Bounce Engine ensures your AI team **accumulates tribal knowledge** exactly like a human engineering team does. The longer you use it, the smarter, faster, and more perfectly tailored to your specific codebase it becomes.
+
+---
+
+<div align="center">
+  <b><a href="README.md">← Back to README</a></b>
+</div>

package/docs/icons/alert.svg

@@ -0,0 +1 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" width="24" height="24"><path fill="#ef4444" d="M12 2c5.523 0 10 4.477 10 10s-4.477 10-10 10S2 17.523 2 12 6.477 2 12 2ZM11 7v6h2V7h-2Zm0 8v2h2v-2h-2Z"></path></svg>

package/docs/icons/beaker.svg

@@ -0,0 +1 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" width="24" height="24"><path fill="#10b981" d="M12.75 2a.75.75 0 0 1 .74.614l1.5 9.386H18.5a.75.75 0 0 1 .645 1.135l-7.5 12.5a.75.75 0 0 1-1.391-.532l1.391-7.104H8.25a.75.75 0 0 1-.655-1.116l6.5-13.5A.75.75 0 0 1 12.75 2Z"></path></svg>

package/docs/icons/book.svg

@@ -0,0 +1 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" width="24" height="24"><path fill="#06b6d4" d="M6 2C4.343 2 3 3.343 3 5v14c0 1.657 1.343 3 3 3h15v-2H6c-.552 0-1-.448-1-1v-1h16V2H6Zm13 16H6c-.552 0-1-.448-1-1s.448-1 1-1h13v2ZM5 16V5c0-.552.448-1 1-1h13v12H5Z"></path></svg>

package/docs/icons/git-branch.svg

@@ -0,0 +1 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" width="24" height="24"><path fill="#f59e0b" d="M7 21a4 4 0 0 1-4-4c0-1.47.8-2.75 2-3.46V8.46C3.8 7.75 3 6.47 3 5a4 4 0 0 1 8 0c0 1.18-.5 2.24-1.33 2.95l1.83 4.25c.57-1.44 1.98-2.45 3.65-2.65A3.996 3.996 0 0 1 17 5a4 4 0 1 1 0 8v4.46c-1.2.71-2 1.99-2 3.46a4 4 0 1 1-8 0Zm4-16a2 2 0 1 0-4 0 2 2 0 0 0 4 0ZM7 19a2 2 0 1 0 0-4 2 2 0 0 0 0 4Zm10 0a2 2 0 1 0 0-4 2 2 0 0 0 0 4Zm0-10a2 2 0 1 0 0-4 2 2 0 0 0 0 4Z"></path></svg>

package/docs/icons/git-merge.svg

@@ -0,0 +1 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" width="24" height="24"><path fill="#3b82f6" d="M5 21a4 4 0 0 1-4-4c0-1.47.8-2.75 2-3.46V8.46C1.8 7.75 1 6.47 1 5a4 4 0 1 1 8 0c0 .92-.32 1.76-.84 2.45l2.42 2.42c1.47-.56 3.12-.56 4.6 0a4 4 0 1 1 0-5.74V2h2v4.46c1.2.71 2 1.99 2 3.46a4 4 0 1 1-8 0c0-.85.27-1.63.73-2.27l-2.42-2.43c-.41 1.25-.41 2.6 0 3.84V17.54C6.2 18.25 7 19.53 7 21a2 2 0 0 1-4 0Zm0-15a2 2 0 1 0-4 0 2 2 0 0 0 4 0Zm12 4a2 2 0 1 0 0-4 2 2 0 0 0 0 4ZM5 19a2 2 0 1 0 0-4 2 2 0 0 0 0 4Z"></path></svg>

package/docs/icons/graph.svg

@@ -0,0 +1 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" width="24" height="24"><path fill="#14b8a6" d="M3 3v16a2 2 0 0 0 2 2h16v-2H5V3H3Zm16 6-4 4-3-3-5 5 1.41 1.41L12 11.83l3.59 3.58L20 10.41V9Z"></path></svg>

package/docs/icons/light-bulb.svg

@@ -0,0 +1 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" width="24" height="24"><path fill="#d946ef" d="M8 1.5c-2.363 0-4 1.69-4 3.75 0 .984.424 1.625.984 2.304l.214.253c.223.264.47.556.673.848.284.411.537.896.621 1.49a.75.75 0 0 1-1.484.211c-.04-.282-.163-.547-.37-.846a7.956 7.956 0 0 0-.542-.682l-.13-.154C3.112 7.74 2.5 6.628 2.5 5.25 2.5 2.31 4.863 0 8 0s5.5 2.31 5.5 5.25c0 1.378-.612 2.49-1.467 3.431l-.13.153c-.18.214-.383.456-.542.682-.207.299-.33.564-.37.846a.75.75 0 0 1-1.484-.211c.084-.594.337-1.079.621-1.489.203-.292.45-.584.673-.848.075-.088.147-.173.213-.253.561-.679.985-1.32.985-2.304 0-2.06-1.637-3.75-4-3.75ZM5.75 13.5a.75.75 0 0 0 0 1.5h4.5a.75.75 0 0 0 0-1.5h-4.5ZM6.5 16.5a.75.75 0 0 1 .75-.75h1.5a.75.75 0 0 1 0 1.5h-1.5a.75.75 0 0 1-.75-.75Z"></path></svg>

package/docs/icons/logo.svg

@@ -0,0 +1,9 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<svg width="256" height="256" viewBox="0 0 256 256" fill="none" xmlns="http://www.w3.org/2000/svg">
+  <rect x="0" y="0" width="256" height="256" rx="60" fill="#0A1C32"/>
+  <line x1="72" y1="80" x2="128" y2="176" stroke="white" stroke-width="15" stroke-linecap="round"/>
+  <line x1="184" y1="80" x2="128" y2="176" stroke="#00C4B5" stroke-width="15" stroke-linecap="round"/>
+  <circle cx="72" cy="80" r="18" fill="#0A1C32" stroke="white" stroke-width="15"/>
+  <circle cx="184" cy="80" r="18" fill="#0A1C32" stroke="white" stroke-width="15"/>
+  <circle cx="128" cy="176" r="22" fill="#0A1C32" stroke="#00C4B5" stroke-width="18"/>
+</svg>

package/docs/icons/pencil.svg

@@ -0,0 +1 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" width="24" height="24"><path fill="#ec4899" d="M18.37 2.63a3.5 3.5 0 0 1 4.95 4.95l-13 13C9.9 20.9 9.39 21.21 8.84 21.41l-4.5 1.5A1.5 1.5 0 0 1 2.39 20.9l1.5-4.5c.2-.55.51-1.06.94-1.48l13.54-12.3ZM17 4.5l-12 11c-.2.2-.35.45-.45.7l-1 3 3-1c.25-.1.5-.25.7-.45l11.54-11.54-2-2ZM20.83 4a1.5 1.5 0 0 0-2.12-.2l2.32 2.32c.1-.1.2-.24.3-.4Z"></path></svg>

package/docs/icons/rocket.svg

@@ -0,0 +1 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" width="24" height="24"><path fill="#3b82f6" d="M11.643 1.057a1.75 1.75 0 0 1 1.964.717l4.316 6.474a2.76 2.76 0 0 0 1.258 1.026l3.784 1.514a1.75 1.75 0 0 1 .536 2.871l-3.352 3.353a4.26 4.26 0 0 0-1.121 1.954l-1.047 3.55a1.75 1.75 0 0 1-3.21.439l-2.008-3.013a2.762 2.762 0 0 0-1.427-1.117l-3.64-1.092a1.75 1.75 0 0 1-.72-2.915l3.242-3.243a4.26 4.26 0 0 0 1.121-1.954l1.047-3.55a1.75 1.75 0 0 1 1.257-1.014ZM7.785 16.4l-3.23.97a.25.25 0 0 0-.103.416l2.943 2.943a.25.25 0 0 0 .393-.112l1.62-5.512a2.76 2.76 0 0 0-.726-1.266L5.438 10.6a.25.25 0 0 0-.416.103l.97 3.23a4.26 4.26 0 0 1 .517 3.12l-1.62 5.513c-.158.536.46 1.002.89.674l2.148-1.611a2.76 2.76 0 0 0 1.116-2.181v-.154l-1.258-2.894Zm5.257-2.738L10.5 10.6l3.161-3.16a.25.25 0 0 1 .353 0L17.176 10.6l-4.134 3.062ZM22 13.5v6.25a.75.75 0 0 1-1.5 0V13.5a.75.75 0 0 1 1.5 0Z"></path></svg>

package/docs/icons/shield.svg

@@ -0,0 +1 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" width="24" height="24"><path fill="#10b981" d="M12 1L2 5v6c0 5.55 3.84 10.74 10 12 6.16-1.26 10-6.45 10-12V5l-10-4Zm-1.8 14.5l-4-4 1.41-1.41L10.2 12.69l6.59-6.59 1.41 1.41-8 8Z"></path></svg>

package/docs/icons/sync.svg

@@ -0,0 +1 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" width="24" height="24"><path fill="#0ea5e9" d="M12 4V1L8 5l4 4V6c3.31 0 6 2.69 6 6 0 1.01-.25 1.97-.7 2.8l1.46 1.46A7.93 7.93 0 0 0 20 12c0-4.42-3.58-8-8-8ZM4 12c0-4.42 3.58-8 8-8v3c-2.76 0-5 2.24-5 5s2.24 5 5 5v3c-4.42 0-8-3.58-8-8Z"></path></svg>

package/docs/icons/terminal.svg

@@ -0,0 +1 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" width="24" height="24"><path fill="#8b5cf6" d="M4 2a2 2 0 0 0-2 2v16a2 2 0 0 0 2 2h16a2 2 0 0 0 2-2V4a2 2 0 0 0-2-2H4Zm4.5 9l-3.25 3.25L4 13l2.5-2.5L4 8l1.25-1.25L9 10l-4.5 3.5v2h6v-2h-6v-2.5l4.5 3.5ZM13 14v-2h7v2h-7Z"></path></svg>

package/docs/icons/tools.svg

@@ -0,0 +1 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" width="24" height="24"><path fill="#64748b" d="M22.7 19.3L16.2 12.8 19 10l-1.4-1.4c-1.1-1.1-2.9-1.1-4 0l-1.4 1.4c-1.1 1.1-1.1 2.9 0 4l1.4 1.4-2.8 2.8-5.3-5.3 1.4-1.4c1.1-1.1 1.1-2.9 0-4l-1.4-1.4c-1.1-1.1-2.9-1.1-4 0l-1.4 1.4L4.2 13 13 21.8l1.4-1.4c1.1 1.1 2.9 1.1 4 0l1.4-1.4c1.1-1.1 1.1-2.9 0-4l-1.4-1.4 2.8-2.8 5.3 5.3-1.4 1.4c-1.1 1.1-1.1 2.9 0 4l1.4 1.4c1.1 1.1 2.9 1.1 4 0l1.4-1.4l1.1-1.1Z"></path></svg>

package/docs/icons/zap.svg

@@ -0,0 +1 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" width="24" height="24"><path fill="#eab308" d="M12.75 2a.75.75 0 0 1 .74.614l1.5 9.386H18.5a.75.75 0 0 1 .645 1.135l-7.5 12.5a.75.75 0 0 1-1.391-.532l1.391-7.104H8.25a.75.75 0 0 1-.655-1.116l6.5-13.5A.75.75 0 0 1 12.75 2Z"></path></svg>

package/package.json

@@ -0,0 +1,48 @@
+{
+  "name": "vbounce-engine",
+  "version": "2.5.1",
+  "description": "V-Bounce Engine: Turn your AI coding assistant into a full engineering team through structured SDLC skills.",
+  "type": "module",
+  "bin": {
+    "vbounce": "bin/vbounce.mjs"
+  },
+  "scripts": {
+    "test": "node tests/run.mjs"
+  },
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/sandrinio/v-bounce-engine.git"
+  },
+  "keywords": [
+    "ai",
+    "coding",
+    "agent",
+    "claude",
+    "cursor",
+    "copilot",
+    "gemini",
+    "codex",
+    "sdlc",
+    "framework"
+  ],
+  "author": "sandrinio",
+  "license": "MIT",
+  "bugs": {
+    "url": "https://github.com/sandrinio/v-bounce-engine/issues"
+  },
+  "homepage": "https://github.com/sandrinio/v-bounce-engine#readme",
+  "files": [
+    "bin",
+    "brains",
+    "templates",
+    "skills",
+    "scripts",
+    "docs",
+    "VBOUNCE_MANIFEST.md"
+  ],
+  "dependencies": {
+    "commander": "^14.0.3",
+    "js-yaml": "^4.1.1",
+    "marked": "^17.0.3"
+  }
+}