ultra-builder-pro-cli 0.10.0 → 0.11.0

package/skills/code-review-expert/references/integration-checklist.md

@@ -1,46 +0,0 @@
-# Integration Checklist
-
-## Entry Point Tracing
-
-For every new module/service/class:
-- **Ask**: "What entry point calls this code?"
-- **If none**: Flag as orphan code (P1)
-- **Trace**: handler → use case → domain → persistence (all layers reachable?)
-
-## Contract Validation
-
-For every boundary crossing:
-- **Ask**: "Is there a shared interface/type that both sides use?"
-- **If no shared type**: Flag missing contract (P2)
-- **Ask**: "Is there a test validating the contract?"
-- **If no contract test**: Flag missing contract test (P1)
-
-## Vertical Slice Assessment
-
-For the change as a whole:
-- **Ask**: "Does this change deliver a working end-to-end path for at least one user scenario?"
-- **If horizontal-only**: Flag as horizontal layer (P2)
-- **Ask**: "Can a user exercise this change right now, or does it need unfinished work?"
-- **If blocked by unfinished work**: Informational note (P3)
-
-## Integration Test Coverage
-
-| Boundary Type | Required Test | Common Mistake |
-|---------------|---------------|----------------|
-| HTTP endpoint | Real HTTP request/response | Testing handler function directly without HTTP layer |
-| Database query | Testcontainers with real DB | InMemoryRepository or jest.mock |
-| Queue/event | Real publish + consume | Mocking the event bus |
-| External API | Test Double with rationale | No test at all |
-
-## Data Flow Continuity
-
-- **Ask**: "Does data flow from source to destination without gaps?"
-- Check: Input validation → transformation → persistence → response
-- **Flag**: Any link in the chain that exists in code but has no test proving data flows through it
-
-## Key Questions
-
-- "What happens if I deploy this change alone? Does anything work?"
-- "Which entry point exercises this code path?"
-- "Where does the data this component produces get consumed?"
-- "Where does the data this component needs come from?"

package/skills/code-review-expert/references/security-checklist.md

@@ -1,100 +0,0 @@
-# Security and Reliability Checklist
-
-## Input/Output Safety
-
-- **XSS**: Unsafe HTML injection, raw HTML rendering without sanitization, unescaped templates, innerHTML assignments
-- **Injection**: SQL/NoSQL/command/GraphQL injection via string concatenation or template literals
-- **SSRF**: User-controlled URLs reaching internal services without allowlist validation
-- **Path traversal**: User input in file paths without sanitization (`../` attacks)
-- **Prototype pollution**: Unsafe object merging in JavaScript (`Object.assign`, spread with user input)
-
-## AuthN/AuthZ
-
-- Missing tenant or ownership checks for read/write operations
-- New endpoints without auth guards or RBAC enforcement
-- Trusting client-provided roles/flags/IDs
-- Broken access control (IDOR - Insecure Direct Object Reference)
-- Session fixation or weak session management
-
-## JWT & Token Security
-
-- Algorithm confusion attacks (accepting `none` or `HS256` when expecting `RS256`)
-- Weak or hardcoded secrets
-- Missing expiration (`exp`) or not validating it
-- Sensitive data in JWT payload (tokens are base64, not encrypted)
-- Not validating `iss` (issuer) or `aud` (audience)
-
-## Secrets and PII
-
-- API keys, tokens, or credentials in code/config/logs
-- Secrets in git history or environment variables exposed to client
-- Excessive logging of PII or sensitive payloads
-- Missing data masking in error messages
-
-## Supply Chain & Dependencies
-
-- Unpinned dependencies allowing malicious updates
-- Dependency confusion (private package name collision)
-- Importing from untrusted sources or CDNs without integrity checks
-- Outdated dependencies with known CVEs
-
-## CORS & Headers
-
-- Overly permissive CORS (`Access-Control-Allow-Origin: *` with credentials)
-- Missing security headers (CSP, X-Frame-Options, X-Content-Type-Options)
-- Exposed internal headers or stack traces
-
-## Runtime Risks
-
-- Unbounded loops, recursive calls, or large in-memory buffers
-- Missing timeouts, retries, or rate limiting on external calls
-- Blocking operations on request path (sync I/O in async context)
-- Resource exhaustion (file handles, connections, memory)
-- ReDoS (Regular Expression Denial of Service)
-
-## Cryptography
-
-- Weak algorithms (MD5, SHA1 for security purposes)
-- Hardcoded IVs or salts
-- Using encryption without authentication (ECB mode, no HMAC)
-- Insufficient key length
-
-## Race Conditions
-
-### Shared State Access
-- Multiple threads/goroutines/async tasks accessing shared variables without synchronization
-- Global state or singletons modified concurrently
-- Lazy initialization without proper locking (double-checked locking issues)
-- Non-thread-safe collections used in concurrent context
-
-### Check-Then-Act (TOCTOU)
-- `if (exists) then use` patterns without atomic operations
-- `if (authorized) then perform` where authorization can change
-- File existence check followed by file operation
-- Balance check followed by deduction (financial operations)
-- Inventory check followed by order placement
-
-### Database Concurrency
-- Missing optimistic locking (`version` column, `updated_at` checks)
-- Missing pessimistic locking (`SELECT FOR UPDATE`)
-- Read-modify-write without transaction isolation
-- Counter increments without atomic operations (`UPDATE SET count = count + 1`)
-- Unique constraint violations in concurrent inserts
-
-### Distributed Systems
-- Missing distributed locks for shared resources
-- Leader election race conditions
-- Cache invalidation races (stale reads after writes)
-- Event ordering dependencies without proper sequencing
-
-### Questions to Ask
-- "What happens if two requests hit this code simultaneously?"
-- "Is this operation atomic or can it be interrupted?"
-- "What shared state does this code access?"
-
-## Data Integrity
-
-- Missing transactions, partial writes, or inconsistent state updates
-- Weak validation before persistence (type coercion issues)
-- Missing idempotency for retryable operations
-- Lost updates due to concurrent modifications

package/skills/code-review-expert/references/solid-checklist.md

@@ -1,65 +0,0 @@
-# SOLID Smell Prompts
-
-## SRP (Single Responsibility)
-
-- File owns unrelated concerns (e.g., HTTP + DB + domain rules in one file)
-- Large class/module with low cohesion or multiple reasons to change
-- Functions that orchestrate many unrelated steps
-- God objects that know too much about the system
-- **Ask**: "What is the single reason this module would change?"
-
-## OCP (Open/Closed)
-
-- Adding a new behavior requires editing many switch/if blocks
-- Feature growth requires modifying core logic rather than extending
-- No plugin/strategy/hook points for variation
-- **Ask**: "Can I add a new variant without touching existing code?"
-
-## LSP (Liskov Substitution)
-
-- Subclass checks for concrete type or throws for base method
-- Overridden methods weaken preconditions or strengthen postconditions
-- Subclass ignores or no-ops parent behavior
-- **Ask**: "Can I substitute any subclass without the caller knowing?"
-
-## ISP (Interface Segregation)
-
-- Interfaces with many methods, most unused by implementers
-- Callers depend on broad interfaces for narrow needs
-- Empty/stub implementations of interface methods
-- **Ask**: "Do all implementers use all methods?"
-
-## DIP (Dependency Inversion)
-
-- High-level logic depends on concrete IO, storage, or network types
-- Hard-coded implementations instead of abstractions or injection
-- Import chains that couple business logic to infrastructure
-- **Ask**: "Can I swap the implementation without changing business logic?"
-
----
-
-## Common Code Smells
-
-| Smell | Signs |
-|-------|-------|
-| **Long method** | Function > 30 lines, multiple levels of nesting |
-| **Feature envy** | Method uses more data from another class than its own |
-| **Data clumps** | Same group of parameters passed together repeatedly |
-| **Primitive obsession** | Using strings/numbers instead of domain types |
-| **Shotgun surgery** | One change requires edits across many files |
-| **Divergent change** | One file changes for many unrelated reasons |
-| **Dead code** | Unreachable or never-called code |
-| **Speculative generality** | Abstractions for hypothetical future needs |
-| **Magic numbers/strings** | Hardcoded values without named constants |
-
----
-
-## Refactor Heuristics
-
-1. **Split by responsibility, not by size** - A small file can still violate SRP
-2. **Introduce abstraction only when needed** - Wait for the second use case
-3. **Keep refactors incremental** - Isolate behavior before moving
-4. **Preserve behavior first** - Add tests before restructuring
-5. **Name things by intent** - If naming is hard, the abstraction might be wrong
-6. **Prefer composition over inheritance** - Inheritance creates tight coupling
-7. **Make illegal states unrepresentable** - Use types to enforce invariants

package/skills/ultra-research/steps/step-00-problem-validation.md

@@ -1,154 +0,0 @@
-# Step 00: Problem Validation
-
-## MANDATORY EXECUTION RULES
-
-- NEVER skip this step — unvalidated problems lead to wasted research
-- DO NOT generate solutions — this step validates the PROBLEM only
-- ASK questions ONE AT A TIME via AskUserQuestion — do not batch
-- PUSH on vague answers — "interesting" is not validation, "paying for it" is
-- WRITE output to spec file BEFORE presenting to user
-- ALL output in English (spec files); conversation in Chinese
-
-## PREREQUISITES
-
-- `.ultra/specs/discovery.md` exists (created by /ultra-init)
-- User has provided initial product idea or description
-
-## CONTEXT BOUNDARIES
-
-- Focus: Is this problem real, painful, and worth solving?
-- NOT about solutions, features, or architecture
-- NOT about market size (that's step-02)
-- You are a skeptical advisor, not a cheerleader
-
-## EXECUTION SEQUENCE
-
-### 1. Detect Product Stage
-
-Ask via AskUserQuestion to determine which forcing questions apply:
-
-| Stage | Indicators | Questions |
-|-------|-----------|-----------|
-| Pre-product (idea, no users) | No existing product | Q1, Q2, Q3 |
-| Has users (not paying) | Product exists, free users | Q2, Q4, Q5 |
-| Has paying customers | Revenue exists | Q4, Q5, Q6 |
-| Pure engineering/infra | Internal tool, no market | Q2, Q4 only |
-
-### 2. Ask Forcing Questions (ONE AT A TIME)
-
-For each applicable question, ask via AskUserQuestion. Push until you hear the "evidence" column — not the "red flags" column.
-
-#### Q1: Demand Reality
-**Ask**: "What is the strongest evidence someone actually wants this — not 'is interested,' but would be genuinely upset if it disappeared?"
-- **Push until you hear**: Specific behavior — paying, expanding usage, panicking when it breaks
-- **Red flags**: "People say it's interesting", waitlist signups, VC enthusiasm
-
-#### Q2: Status Quo
-**Ask**: "What are users doing RIGHT NOW to solve this — even badly? What does that workaround cost them?"
-- **Push until you hear**: Specific workflow — hours wasted, dollars lost, tools duct-taped together
-- **Red flags**: "Nothing — no solution exists" (if nobody is doing anything, the problem may not be painful enough)
-
-#### Q3: Desperate Specificity
-**Ask**: "Name the actual human who needs this most. Title? What gets them promoted? What gets them fired?"
-- **Push until you hear**: A name, a role, a specific consequence they face
-- **Red flags**: Category-level answers: "enterprises", "SMBs", "marketing teams"
-
-#### Q4: Narrowest Wedge
-**Ask**: "What is the smallest version someone would pay real money for — this week, not after you build the platform?"
-- **Push until you hear**: One feature, one workflow, shippable in days
-- **Red flags**: "Need full platform first", "can't strip it down"
-
-#### Q5: Observation & Surprise
-**Ask**: "Have you watched someone use this without helping them? What surprised you?"
-- **Push until you hear**: A specific surprise that contradicted assumptions
-- **Red flags**: "We sent a survey", "nothing surprising"
-
-#### Q6: Future-Fit
-**Ask**: "If the world looks meaningfully different in 3 years, does your product become more essential or less?"
-- **Push until you hear**: Specific claim about how user's world changes and why that increases value
-- **Red flags**: "Market growing 20% per year", "AI makes everything better"
-
-### 3. Smart-Skip Rules
-
-- If an earlier answer already covers a later question, skip it
-- If user says "just do it" or provides a fully formed plan → fast-track with note
-- Maximum 4 questions per session — prioritize by stage
-
-### 4. Synthesize & Write Output
-
-**WRITE IMMEDIATELY** to `.ultra/specs/discovery.md` §0:
-
-```markdown
-## §0 Problem Validation Summary
-
-### Product Stage
-- **Stage**: [Pre-product / Has users / Has paying customers / Engineering/Infra]
-- **Evidence**: [What indicates this stage]
-
-### Demand Signal
-- **Strength**: [Strong / Moderate / Weak / Unvalidated]
-- **Evidence**: [Specific behaviors observed]
-- **Risk**: [What could invalidate this demand]
-
-### Status Quo Analysis
-- **Current solutions**: [What users do today]
-- **Cost of workaround**: [Time, money, friction]
-- **Switching motivation**: [Why they'd change]
-
-### Target User Profile
-- **Primary**: [Specific role/person description]
-- **Stakes**: [What gets them promoted / fired]
-- **Pain frequency**: [Daily / Weekly / Occasional]
-
-### Narrowest Wedge
-- **MVP scope**: [Single feature/workflow]
-- **Willingness to pay**: [Evidence level]
-- **Ship timeline**: [Days / Weeks / Months]
-
-### Validation Confidence
-- **Overall**: [X]%
-- **Strongest signal**: [What gives most confidence]
-- **Biggest risk**: [What could be wrong]
-- **Recommended next step**: [Proceed / Investigate further / Pivot]
-```
-
-### 5. Present to User and Gate
-
-Show the Problem Validation Summary to user.
-
-Present assessment honestly — if the problem feels weak, say so. Better to catch it now.
-
-```
-[C] Continue — Problem validated, proceed to Opportunity Discovery
-[R] Revise — Discuss specific concerns before proceeding
-[P] Pivot — Problem is weak, explore different angle
-```
-
-**HALT — wait for user response before proceeding.**
-
-### 6. Handle Response
-
-- **[C]**: Load next step: `./step-01-opportunity-discovery.md`
-- **[R]**: Discuss concerns, revise §0, re-present
-- **[P]**: Help user reframe the problem, restart step-00
-
-## SUCCESS METRICS
-
-- Product stage correctly identified
-- At least 2 forcing questions asked and answered with evidence
-- Problem Validation Summary written to discovery.md §0
-- Confidence assessment is honest (not inflated)
-- User has explicitly confirmed [C] before proceeding
-
-## FAILURE MODES
-
-- Asking all 6 questions regardless of stage (wastes user time)
-- Accepting vague answers without pushing ("people are interested" → push harder)
-- Skipping this step because user seems confident
-- Inflating confidence to keep user happy
-- Not writing output before presenting to user
-- Proceeding without explicit [C] confirmation
-
-## NEXT STEP
-
-After user selects [C], read and follow: `./step-01-opportunity-discovery.md`

package/skills/ultra-research/steps/step-01-opportunity-discovery.md

@@ -1,172 +0,0 @@
-# Step 01: Opportunity Discovery
-
-## MANDATORY EXECUTION RULES
-
-- WEB SEARCH REQUIRED — verify opportunities against real market data
-- Frame opportunities from CUSTOMER perspective, not product perspective
-- Generate multiple solutions per opportunity — never commit to the first idea
-- WRITE output to spec file BEFORE presenting to user
-- ALL output in English (spec files); conversation in Chinese
-
-## PREREQUISITES
-
-- Step 00 (Problem Validation) completed with [C]
-- `.ultra/specs/discovery.md` §0 exists
-
-## CONTEXT BOUNDARIES
-
-- Focus: Map the opportunity space using Opportunity Solution Tree (Teresa Torres)
-- Opportunities are CUSTOMER NEEDS, not features
-- Frame as: "I struggle to..." / "I wish I could..." / "It frustrates me that..."
-- Based on *Continuous Discovery Habits* methodology
-
-## SEARCH STRATEGY (MANDATORY)
-
-Execute these web searches in parallel:
-
-```
-Search: "{{product_domain}} user pain points complaints"
-Search: "{{product_domain}} customer needs unmet"
-Search: "{{product_domain}} market gaps opportunities"
-Search: "{{product_domain}} user research findings"
-```
-
-Citation requirement: Every factual claim MUST include `Source: [URL]`
-No-source claims → mark as `⚠️ Speculation`
-
-## EXECUTION SEQUENCE
-
-### 1. Define Desired Outcome
-
-Ask user via AskUserQuestion:
-"What single measurable business/product outcome are we pursuing? (e.g., 'Reduce customer onboarding time by 50%', 'Reach $1M ARR in 12 months')"
-
-If user is unsure, help them formulate one from step-00 findings.
-
-### 2. Map Opportunity Space
-
-Using web search results + step-00 insights, identify 5-8 customer opportunities.
-
-**Frame each opportunity from customer perspective:**
-- BAD: "Add AI-powered search" (this is a solution)
-- GOOD: "I struggle to find relevant results in large document collections" (this is an opportunity)
-
-### 3. Prioritize Opportunities
-
-Score each opportunity using Dan Olsen's Opportunity Score:
-
-```
-Opportunity Score = Importance × (1 - Satisfaction)
-```
-
-Where:
-- **Importance** (1-10): How much does this matter to the target user?
-- **Satisfaction** (0-1): How well do current solutions address this? (0 = not at all, 1 = perfectly)
-
-Rank by score. Focus on top 2-3 opportunities.
-
-### 4. Solution Brainstorm
-
-For each top opportunity (top 2-3), generate 3+ solution approaches from different perspectives:
-
-| Perspective | Approach |
-|------------|---------|
-| PM perspective | User workflow optimization |
-| Designer perspective | Experience/interaction innovation |
-| Engineer perspective | Technical capability leverage |
-
-**Rule**: Never commit to the first idea. The best solution often emerges from comparing alternatives.
-
-### 5. Write Output
-
-**WRITE IMMEDIATELY** to `.ultra/specs/discovery.md` §1:
-
-```markdown
-## §1 Opportunity Space
-
-### Desired Outcome
-- **Outcome**: [Single measurable outcome]
-- **Metric**: [How we measure it]
-- **Timeline**: [When we expect to see movement]
-
-### Opportunity Map
-
-| # | Opportunity (Customer Framing) | Importance | Satisfaction | Score | Source |
-|---|-------------------------------|-----------|-------------|-------|--------|
-| O1 | "I struggle to..." | 9 | 0.2 | 7.2 | [URL] |
-| O2 | "I wish I could..." | 8 | 0.3 | 5.6 | [URL] |
-| O3 | "It frustrates me that..." | 7 | 0.4 | 4.2 | [URL] |
-| O4 | ... | ... | ... | ... | ... |
-| O5 | ... | ... | ... | ... | ... |
-
-### Prioritized Opportunities (Top 3)
-
-#### Opportunity 1: [Customer-framed description]
-- **Importance**: [X]/10 — [Why this matters]
-- **Current satisfaction**: [X] — [How users cope today]
-- **Score**: [X]
-- **Evidence**: [Source URL]
-
-**Solution Approaches:**
-1. **PM approach**: [Description] — Pros: [...] Cons: [...]
-2. **Design approach**: [Description] — Pros: [...] Cons: [...]
-3. **Engineering approach**: [Description] — Pros: [...] Cons: [...]
-
-#### Opportunity 2: [Customer-framed description]
-[Same structure]
-
-#### Opportunity 3: [Customer-framed description]
-[Same structure]
-
-### Opportunities Deprioritized
-| # | Opportunity | Score | Reason for Deprioritization |
-|---|------------|-------|-----------------------------|
-| O4 | ... | ... | [Why not now] |
-| O5 | ... | ... | [Why not now] |
-
-### Key Insight
-[One paragraph: What is the non-obvious insight from this opportunity analysis?]
-```
-
-### 6. Present to User and Gate
-
-Show the Opportunity Space summary. Highlight:
-- The top 3 opportunities and why they ranked highest
-- Any surprising findings from web research
-- Which solution approaches seem most promising
-
-```
-[C] Continue — Opportunity space mapped, proceed to Market Assessment
-[R] Revise — Adjust opportunity scoring or add missing opportunities
-[D] Discuss — Explore specific opportunities in more depth
-```
-
-**HALT — wait for user response before proceeding.**
-
-### 7. Handle Response
-
-- **[C]**: Load next step: `./step-02-market-assessment.md`
-- **[R]**: Revise scoring/opportunities, update discovery.md §1, re-present
-- **[D]**: Deep-dive into specific opportunity, then re-present gate
-
-## SUCCESS METRICS
-
-- Desired outcome is specific and measurable
-- At least 5 opportunities identified, framed from customer perspective
-- Opportunity scores calculated with importance and satisfaction ratings
-- Top 3 opportunities each have 3+ solution approaches
-- All factual claims have source citations
-- Output written to discovery.md §1
-
-## FAILURE MODES
-
-- Framing opportunities as features/solutions instead of customer needs
-- Scoring without web research evidence
-- Only generating 1 solution per opportunity
-- Accepting user's first solution idea without exploring alternatives
-- Missing citation sources for market claims
-- Not writing output before presenting to user
-
-## NEXT STEP
-
-After user selects [C], read and follow: `./step-02-market-assessment.md`