buildwright 0.0.10 → 0.0.11

package/README.md

@@ -369,7 +369,8 @@ Every spec and implementation follows:
 | Principle | Meaning |
 |-----------|---------|
 | **KISS** | Keep It Simple — prefer simple over clever |
-| **YAGNI** | You Aren't Gonna Need It — build only what's needed now |
+| **YAGNI** | You Aren't Gonna Need It — build only what's needed now, no speculative abstractions |
+| **DRY** | Don't Repeat Yourself — reuse existing code, extract common logic |
 | **No Premature Optimization** | Make it work first, optimize with data |
 | **Boring Technology** | Proven tools over shiny new ones |
 | **Fail Fast** | Validate early, error loudly |

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "buildwright",
-  "version": "0.0.10",
+  "version": "0.0.11",
   "description": "Agent-first autonomous development workflow. Ship code you don't read.",
   "license": "MIT",
   "engines": {

package/templates/.buildwright/agents/staff-engineer.md

@@ -35,6 +35,8 @@ You are a **Staff Engineer** with 15+ years of experience building production sy
 - Security vulnerabilities
 - Performance foot-guns
 - Unnecessary complexity
+- Duplicated logic that should reuse existing functions or be extracted into shared utilities
+- Unnecessary new types or abstractions when existing ones suffice
 - Missing validation
 - Poor abstractions
 - Technical debt being introduced
@@ -107,6 +109,8 @@ Only flag issues where:
 - Security vulnerabilities with a concrete exploit path (defer to security phase in /bw-ship)
 - Data loss or corruption risk with a traceable scenario
 - Missing validation at system boundaries where untrusted input enters
+- Reimplemented logic that already exists elsewhere in the codebase (DRY violation with concrete duplicate identified)
+- New types, wrappers, or abstractions not required by current requirements (YAGNI violation)
 
 Do NOT flag:
 - Potential issues that depend on specific inputs or runtime state

package/templates/.buildwright/commands/bw-new-feature.md

@@ -148,6 +148,7 @@ find . -type f -name "*.ts" | xargs grep -l "[relevant terms]"
 - How does similar functionality work today?
 - What patterns are used for this type of feature?
 - What services/utilities already exist that I should use?
+- What types/structs already exist that I can reuse instead of creating new ones?
 - What would break if I change this?
 
 ### 2.3 Read Existing Tests
@@ -208,6 +209,13 @@ Create `docs/specs/[feature-name]/research.md`:
 - [Service]: [what it does, how to use]
 - [Utility]: [what it does, how to use]
 
+### Reusable Types & Functions
+- [Function/Type]: [location] — [what it does, how to reuse]
+- [Function/Type]: [location] — [what it does, how to reuse]
+
+Flag any near-duplicates found during research. If two utilities do similar things,
+recommend which one to use and whether to consolidate.
+
 ### Integration Points
 - [System A]: Will need to integrate via [method]
 - [System B]: [description]
@@ -433,9 +441,11 @@ For each milestone:
 
 2. **Implement**
    - Follow patterns identified in research.md
-   - Use existing services/utilities discovered
+   - Use existing services/utilities discovered — do NOT reimplement
+   - Reuse existing types and structures — create new ones only when no existing type fits
+   - If you find yourself writing logic that resembles something in the codebase, stop and reuse or extract
    - Write minimal code to pass tests
-   - Remember: KISS, YAGNI
+   - Remember: KISS, YAGNI, DRY
 
 3. **Verify (with retry)**
    ```bash
@@ -453,6 +463,8 @@ For each milestone:
 
 After each milestone passes verification, briefly self-review for:
 - **Simplicity**: Is this the simplest solution? Any unnecessary complexity?
+- **Duplication**: Does this duplicate existing functions, types, or logic? Can anything be reused or extracted?
+- **Necessity**: Is every new type, abstraction, and code path required by the current requirements? Remove anything speculative.
 - **Correctness**: Any logic errors or missed edge cases in the new code?
 - **Conventions**: Does the new code follow established project patterns?
 
@@ -522,6 +534,6 @@ PIPELINE STATUS
 ✅ Code Reviewed (Staff Engineer)
 ✅ Shipped
 
-Quality gates running in CI. Will auto-merge on pass.
+Quality gates running in CI. PR ready for team review.
 ═══════════════════════════════════════════════════════════════
 ```

package/templates/.buildwright/commands/bw-quick.md

@@ -96,6 +96,7 @@ find . -name "*.test.*" -o -name "*.spec.*" | xargs grep -l "[relevant terms]"
 Understand:
 - Current implementation
 - Patterns used in these files
+- Existing functions, types, and utilities that can be reused instead of reimplemented
 - Related tests
 
 **Do NOT write a research document. Keep it in context.**
@@ -122,8 +123,9 @@ Commit: `test: add test for [task]`
 
 - Fix the bug / add the feature
 - Follow existing patterns in the file
+- Reuse existing functions and types — do NOT reimplement what already exists
 - Minimal changes only
-- KISS, YAGNI
+- KISS, YAGNI, DRY
 
 ### 3.3 Update Documentation
 

package/templates/.buildwright/commands/bw-ship.md

@@ -153,7 +153,7 @@ git diff HEAD
 
 **Phase A — Repository Context:** Understand existing patterns, conventions, error handling, and testing approaches.
 
-**Phase B — Comparative Analysis:** Does new code follow established patterns? Does it bypass or weaken existing controls?
+**Phase B — Comparative Analysis:** Does new code follow established patterns? Does it reuse existing utilities and types instead of reimplementing? Does it bypass or weaken existing controls?
 
 **Phase C — Issue Assessment:** Review changes for real issues. For each: verify it's real, confirm it was INTRODUCED by these changes, assign confidence (only report ≥ 80).
 
@@ -236,7 +236,7 @@ If `gh` is not available, provide the PR creation URL.
 ╠═══════════════════════════════════════════════════════════════╣
 ║                                                               ║
 ║  Quality gates will run in CI.                                ║
-║  PR will auto-merge when all gates pass.                      ║
+║  PR ready for team review when all gates pass.                ║
 ║                                                               ║
 ╚═══════════════════════════════════════════════════════════════╝
 ```

package/templates/.buildwright/steering/quality-gates.md

@@ -31,5 +31,5 @@ These automated gates replace human code review. ALL must pass for merge.
 - [ ] Rate limiting on sensitive endpoints
 - [ ] Audit logging for transactions
 
-## Auto-Merge Criteria
-When ALL gates pass → PR auto-merges → Deploy triggers
+## Merge Policy
+When ALL gates pass → PR is ready for merge (team follows their own merge process)

package/templates/.github/workflows/quality-gates.yml

@@ -133,18 +133,3 @@ jobs:
             go) govulncheck ./... || echo "govulncheck not installed" ;;
             python) pip-audit || safety check || echo "No Python audit tool" ;;
           esac
-
-  auto-merge:
-    needs: quality
-    runs-on: ubuntu-latest
-    if: github.event_name == 'pull_request'
-    permissions:
-      contents: write
-      pull-requests: write
-    steps:
-      - name: Auto-merge on quality pass
-        uses: pascalgn/automerge-action@v0.15.6
-        env:
-          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
-          MERGE_METHOD: squash
-          MERGE_LABELS: ""

package/templates/CLAUDE.md

@@ -119,6 +119,8 @@ When a feature touches multiple domains (e.g., DB + API + UI):
    - Build only what's required NOW
    - No speculative features "for later"
    - Avoid abstractions until they're proven needed
+   - No wrapper types, adapter layers, or extension points "just in case"
+   - If the requirements don't ask for it, don't build it
 
 3. **No Premature Optimization**
    - Make it work first, then make it fast (if needed)
@@ -135,6 +137,12 @@ When a feature touches multiple domains (e.g., DB + API + UI):
    - Throw errors early with clear messages
    - No silent failures
 
+6. **DRY (Don't Repeat Yourself)**
+   - Before writing new code, search for existing functions, types, and utilities that already do the job
+   - Reuse existing structures — if `User` exists, don't create `UserDTO` or `UserEntity` unless the codebase already separates those concerns
+   - If two pieces of code do similar things, extract the common part rather than duplicating
+   - Prefer importing over reimplementing
+
 ## Code Standards
 - Follow existing patterns in the codebase exactly
 - Keep files under 500 lines; split proactively

package/templates/scripts/sync-agents.sh

@@ -60,7 +60,11 @@ sync_dir() {
     tmpdir=$(mktemp -d)
     cp -R "$src/"* "$tmpdir/" 2>/dev/null || true
     if [ -n "$rewrite_from" ] && [ -n "$rewrite_to" ]; then
-      find "$tmpdir" -name "*.md" -exec sed -i "s|$rewrite_from|$rewrite_to|g" {} + 2>/dev/null || true
+      # Only rewrite @@.buildwright/ (read instructions) → tool-specific path
+      # Bare .buildwright/ (write/canonical instructions) stays untouched
+      find "$tmpdir" -name "*.md" -exec sed -i '' \
+        -e "s|@@${rewrite_from}|${rewrite_to}|g" \
+        {} + 2>/dev/null || true
     fi
     if ! diff -rq "$tmpdir" "$dst" > /dev/null 2>&1; then
       echo "OUT OF SYNC: $dst differs from $src"
@@ -71,8 +75,12 @@ sync_dir() {
     mkdir -p "$dst"
     rsync -a --delete "$src/" "$dst/" 2>/dev/null || (rm -rf "$dst"/* && cp -R "$src/"* "$dst/")
     # Rewrite path references for tool-specific copies
+    # @@.buildwright/ = "resolve to tool-specific dir" → gets rewritten
+    # Bare .buildwright/ = "canonical path" → stays untouched
     if [ -n "$rewrite_from" ] && [ -n "$rewrite_to" ]; then
-      find "$dst" -name "*.md" -exec sed -i "s|$rewrite_from|$rewrite_to|g" {} + 2>/dev/null || true
+      find "$dst" -name "*.md" -exec sed -i '' \
+        -e "s|@@${rewrite_from}|${rewrite_to}|g" \
+        {} + 2>/dev/null || true
     fi
     echo "  synced $src → $dst"
   fi