ultra-builder-pro-cli 0.10.0 → 0.11.0

package/skills/ultra-research/steps/step-31-solution-strategy.md

@@ -1,172 +0,0 @@
-# Step 31: Solution Strategy & Tech Stack
-
-## MANDATORY EXECUTION RULES
-
-- WEB SEARCH REQUIRED — verify all technology claims
-- USE Context7 MCP for framework documentation
-- COMPARE TOP 3 OPTIONS for every major tech decision
-- EVERY CHOICE needs RATIONALE — "it's popular" is not enough
-- WRITE output to spec file BEFORE presenting to user
-- ALL output in English (spec files); conversation in Chinese
-
-## PREREQUISITES
-
-- Step 30 (Architecture Context) completed with [C]
-- `.ultra/specs/architecture.md` §1-3 exist
-
-## CONTEXT BOUNDARIES
-
-- Focus: Tech stack selection with evidence-based rationale (arc42 §4)
-- Decisions must satisfy quality goals from §1
-- Decisions must respect constraints from §2
-- Compare options — never recommend without alternatives analyzed
-
-## SEARCH STRATEGY (MANDATORY)
-
-For each major technology decision:
-
-```
-Search: "[option A] vs [option B] vs [option C] {{product_domain}} 2024 2025"
-Search: "[chosen framework] production performance benchmarks"
-Search: "[chosen framework] scalability limitations"
-Search: "[chosen database] vs alternatives for {{use_case}}"
-```
-
-Use Context7 MCP: Query official docs for each selected technology.
-
-## EXECUTION SEQUENCE
-
-### 1. Identify Key Technology Decisions
-
-Based on system context (§3) and quality goals (§1):
-
-| Decision Area | What to Decide |
-|--------------|---------------|
-| Language/Runtime | Primary programming language |
-| Web Framework | API/web framework |
-| Database | Primary data store |
-| Caching | Caching layer (if needed) |
-| Authentication | Auth approach |
-| Hosting | Cloud/infrastructure |
-| CI/CD | Build and deploy pipeline |
-| Monitoring | Observability stack |
-
-### 2. Compare Options (Top 3 per Decision)
-
-For each decision, research and compare 3 options:
-
-| Criterion | Option A | Option B | Option C |
-|-----------|---------|---------|---------|
-| Quality goal fit | [How it meets §1 goals] | ... | ... |
-| Constraint fit | [How it respects §2] | ... | ... |
-| Community/maturity | [Stars, contributors, releases] | ... | ... |
-| Performance | [Benchmarks with source] | ... | ... |
-| Learning curve | [Team skill match] | ... | ... |
-| Cost | [Licensing, hosting costs] | ... | ... |
-
-### 3. Make Decisions with Rationale
-
-For each decision:
-- **Chosen**: [Option]
-- **Rationale**: [Why this one — reference quality goals and constraints]
-- **Trade-off accepted**: [What we give up]
-- **Risk**: [What could go wrong]
-- **Migration path**: [How to change if this doesn't work]
-
-### 4. Write Output
-
-**WRITE IMMEDIATELY** to `.ultra/specs/architecture.md` §4:
-
-```markdown
-## §4 Solution Strategy
-
-### Technology Decisions
-
-#### Language & Runtime
-- **Chosen**: [Language/Runtime]
-- **Alternatives considered**: [Option B], [Option C]
-- **Rationale**: [Why — reference §1 quality goals]
-- **Trade-off**: [What we give up]
-- **Source**: [Benchmark/doc URL]
-
-#### Web Framework
-- **Chosen**: [Framework]
-- **Alternatives considered**: [Option B], [Option C]
-- **Rationale**: [Why]
-- **Trade-off**: [What we give up]
-- **Source**: [URL]
-
-#### Database
-- **Chosen**: [Database]
-- **Alternatives considered**: [Option B], [Option C]
-- **Rationale**: [Why]
-- **Trade-off**: [What we give up]
-- **Source**: [URL]
-
-#### Authentication
-- **Chosen**: [Approach]
-- **Alternatives considered**: [Option B], [Option C]
-- **Rationale**: [Why]
-- **Source**: [URL]
-
-#### Hosting & Infrastructure
-- **Chosen**: [Platform]
-- **Alternatives considered**: [Option B], [Option C]
-- **Rationale**: [Why]
-- **Estimated cost**: [$X/month at launch scale]
-- **Source**: [URL]
-
-### Tech Stack Summary
-
-| Layer | Technology | Version | Purpose |
-|-------|-----------|---------|---------|
-| Frontend | [Tech] | [Ver] | [What it does] |
-| Backend | [Tech] | [Ver] | [What it does] |
-| Database | [Tech] | [Ver] | [What it does] |
-| Cache | [Tech] | [Ver] | [What it does] |
-| Auth | [Tech] | [Ver] | [What it does] |
-| Hosting | [Tech] | - | [What it does] |
-| CI/CD | [Tech] | - | [What it does] |
-| Monitoring | [Tech] | - | [What it does] |
-
-### Decision Confidence
-- **Overall**: [X]%
-- **Most confident**: [Decision] — [Why]
-- **Least confident**: [Decision] — [Risk]
-```
-
-### 5. Present to User and Gate
-
-```
-[C] Continue — Tech stack defined, proceed to Building Blocks
-[R] Revise — Reconsider specific technology choices
-[D] Discuss — Deep-dive on a specific decision
-```
-
-**HALT — wait for user response before proceeding.**
-
-### 6. Handle Response
-
-- **[C]**: Load next step: `./step-32-building-blocks.md`
-- **[R]**: Revise decisions, update architecture.md §4, re-present
-- **[D]**: Deep-dive with additional research, then re-present
-
-## SUCCESS METRICS
-
-- Top 3 options compared for every major decision
-- Every choice has explicit rationale referencing quality goals
-- Trade-offs stated honestly
-- All claims verified via web search or Context7
-- Output written to architecture.md §4
-
-## FAILURE MODES
-
-- Single option considered ("just use React")
-- No rationale beyond popularity
-- Ignoring constraints from §2
-- Not verifying version compatibility
-- Technology choices that conflict with quality goals
-
-## NEXT STEP
-
-After user selects [C], read and follow: `./step-32-building-blocks.md`

package/skills/ultra-research/steps/step-32-building-blocks.md

@@ -1,188 +0,0 @@
-# Step 32: Building Blocks & Runtime Scenarios
-
-## MANDATORY EXECUTION RULES
-
-- MODULE DECOMPOSITION must follow Functional Core / Imperative Shell pattern
-- EVERY MODULE must trace to at least one feature from product.md §5
-- RUNTIME SCENARIOS must cover the top 3 user scenarios from product.md §3
-- WRITE output to spec file BEFORE presenting to user
-- ALL output in English (spec files); conversation in Chinese
-
-## PREREQUISITES
-
-- Step 31 (Solution Strategy) completed with [C]
-- `.ultra/specs/architecture.md` §1-4 exist
-
-## CONTEXT BOUNDARIES
-
-- Focus: Module decomposition and runtime behavior (arc42 §5-6)
-- Structure follows: `src/{domain/, application/usecases/, infrastructure/}`
-- Domain logic is pure (no IO); Infrastructure handles IO
-- This step bridges product (WHAT) to code (HOW)
-
-## EXECUTION SEQUENCE
-
-### 1. Module Decomposition
-
-Based on features from product.md §5 and tech stack from §4:
-
-**Layer structure**:
-```
-src/
-├── domain/           # Functional Core (pure logic)
-│   ├── entities/     # Domain objects
-│   ├── values/       # Value objects
-│   └── services/     # Domain services (pure functions)
-├── application/      # Use cases (orchestration)
-│   └── usecases/     # One file per use case
-├── infrastructure/   # Imperative Shell (IO)
-│   ├── http/         # HTTP handlers/routes
-│   ├── persistence/  # Database repositories
-│   └── external/     # External API clients
-└── config/           # Configuration
-```
-
-Map each feature to modules:
-- Feature 1 → domain/entities/X, application/usecases/Y, infrastructure/http/Z
-
-### 2. Define Key Interfaces
-
-For each module boundary, define the contract:
-
-| Interface | Provider | Consumer | Data |
-|-----------|---------|----------|------|
-| [Interface A] | [Module] | [Module] | [DTO/Entity] |
-
-### 3. Runtime Scenarios
-
-For the top 3 user scenarios from product.md §3, describe the runtime flow:
-
-**Scenario S1**: [Name]
-```
-User → HTTP Handler → Use Case → Domain Service → Repository → Database
-                                                              ↓
-User ← HTTP Response ← Use Case ← Domain Entity ← Repository ← Query Result
-```
-
-### 4. Write Output
-
-**WRITE IMMEDIATELY** to `.ultra/specs/architecture.md` §5-6:
-
-```markdown
-## §5 Building Block View
-
-### Level 1: System Decomposition
-
-| Module | Layer | Responsibility | Dependencies |
-|--------|-------|---------------|-------------|
-| [Module A] | Domain | [What it does] | None (pure) |
-| [Module B] | Application | [What it orchestrates] | [Module A] |
-| [Module C] | Infrastructure | [What IO it handles] | [Module B] |
-
-### Module Details
-
-#### domain/
-- **entities/[Entity]**: [Description, key fields, business rules]
-- **values/[ValueObject]**: [Description, validation rules]
-- **services/[Service]**: [Pure functions, input → output]
-
-#### application/usecases/
-- **[UseCase1]**: [Input → orchestration → output]
-- **[UseCase2]**: [Input → orchestration → output]
-
-#### infrastructure/
-- **http/[Handler]**: [Routes, request/response mapping]
-- **persistence/[Repository]**: [Database operations]
-- **external/[Client]**: [External API integration]
-
-### Feature → Module Mapping
-
-| Feature | Domain | Application | Infrastructure |
-|---------|--------|------------|---------------|
-| [Feature 1] | [Entities] | [UseCases] | [Handlers, Repos] |
-| [Feature 2] | [Entities] | [UseCases] | [Handlers, Repos] |
-
-## §6 Runtime Scenarios
-
-### Scenario 1: [S1 Name from product.md]
-
-**Trigger**: [User action]
-**Flow**:
-1. User sends [request type] to [endpoint]
-2. [Handler] validates input, maps to [DTO]
-3. [UseCase] orchestrates: loads [Entity] via [Repository]
-4. [DomainService] applies business logic (pure)
-5. [Repository] persists result
-6. [Handler] returns [response]
-
-**Data flow**: [Input] → [Transformation] → [Output]
-**Error paths**: [What can go wrong and how it's handled]
-
-### Scenario 2: [S2 Name]
-[Same structure]
-
-### Scenario 3: [S3 Name]
-[Same structure]
-
-### Round 3 Summary
-
-**Architecture Design Confidence**:
-- **Quality goal coverage**: [X]%
-- **Tech stack confidence**: [X]%
-- **Module clarity**: [X]%
-- **Overall R3 confidence**: [X]%
-```
-
-### 5. Write Round 3 Research Report
-
-**WRITE** to `.ultra/docs/research/architecture-design-{date}.md`:
-
-```markdown
-# Round 3: Architecture Design
-
-> **Confidence**: [X]%
-> **Steps completed**: 30-32
-> **Completed**: [date]
-
-## Key Decisions
-[Tech stack choices with rationale]
-
-## Architecture Pattern
-[Functional Core / Imperative Shell overview]
-
-## Risk Areas
-[Where architecture is weakest]
-```
-
-### 6. Present to User and Gate
-
-```
-[C] Continue — Architecture defined, proceed to Round 4 (Deployment & Quality)
-[R] Revise — Adjust modules or scenarios
-```
-
-**HALT — wait for user response before proceeding.**
-
-### 7. Handle Response
-
-- **[C]**: Load next step: `./step-40-deployment.md`
-- **[R]**: Revise, update architecture.md §5-6, re-present
-
-## SUCCESS METRICS
-
-- Every module traces to a feature
-- Functional Core / Imperative Shell separation clear
-- Top 3 runtime scenarios documented with data flow
-- Error paths identified
-- Round 3 research report written
-
-## FAILURE MODES
-
-- Modules that don't map to any feature (orphan code)
-- Business logic in infrastructure layer
-- Missing error paths in runtime scenarios
-- No interface contracts between modules
-
-## NEXT STEP
-
-After user selects [C], read and follow: `./step-40-deployment.md`

package/skills/ultra-research/steps/step-40-deployment.md

@@ -1,123 +0,0 @@
-# Step 40: Deployment & Infrastructure
-
-## MANDATORY EXECUTION RULES
-
-- WEB SEARCH REQUIRED — verify infrastructure pricing and capabilities
-- INCLUDE cost estimates with sources
-- DEFINE environments: dev, staging, production
-- WRITE output to spec file BEFORE presenting to user
-- ALL output in English (spec files); conversation in Chinese
-
-## PREREQUISITES
-
-- Step 32 (Building Blocks) completed with [C]
-- `.ultra/specs/architecture.md` §1-6 exist
-
-## SEARCH STRATEGY (MANDATORY)
-
-```
-Search: "{{chosen_hosting}} pricing calculator {{product_domain}}"
-Search: "{{chosen_hosting}} deployment best practices"
-Search: "{{chosen_tech_stack}} CI/CD pipeline setup"
-Search: "{{chosen_tech_stack}} docker deployment production"
-```
-
-## EXECUTION SEQUENCE
-
-### 1. Define Deployment Topology
-
-Map the infrastructure for each environment.
-
-### 2. Define CI/CD Pipeline
-
-Build → Test → Deploy stages with quality gates.
-
-### 3. Estimate Costs
-
-Use web search for real pricing data.
-
-### 4. Write Output
-
-**WRITE IMMEDIATELY** to `.ultra/specs/architecture.md` §7-9:
-
-```markdown
-## §7 Deployment View
-
-### Environments
-
-| Environment | Purpose | Infrastructure | URL Pattern |
-|------------|---------|---------------|-------------|
-| Development | Local dev | [Docker Compose / local] | localhost:X |
-| Staging | Pre-prod testing | [Cloud provider details] | staging.X |
-| Production | Live users | [Cloud provider details] | X.com |
-
-### Production Topology
-- **Compute**: [Service type, instance size, count]
-- **Database**: [Managed service, tier, backup]
-- **Cache**: [Service, tier]
-- **CDN**: [Provider]
-- **DNS**: [Provider]
-
-### CI/CD Pipeline
-
-| Stage | Tool | Trigger | Quality Gate |
-|-------|------|---------|-------------|
-| Build | [Tool] | Push to branch | Compilation success |
-| Unit Test | [Runner] | Post-build | 80%+ coverage, 0 failures |
-| Integration Test | [Runner] | Post-unit | All green |
-| Security Scan | [Tool] | Post-test | No critical/high |
-| Deploy Staging | [Tool] | Merge to main | All gates passed |
-| Deploy Production | [Tool] | Manual approval | Staging verified |
-
-## §8 Crosscutting Concerns
-
-### Logging
-- **Format**: Structured JSON
-- **Fields**: timestamp, level, service, traceId, message, context
-- **Tool**: [Logging framework]
-
-### Authentication
-- **Method**: [JWT / OAuth2 / etc]
-- **Provider**: [Auth service]
-- **Session**: [Strategy]
-
-### Error Handling
-- **Pattern**: Result/Either in domain, global handler in infrastructure
-- **Alerting**: [When and how]
-
-## §9 Cost Estimate
-
-| Service | Monthly Cost | Annual Cost | Source |
-|---------|-------------|------------|--------|
-| Compute | $[X] | $[X] | [URL] |
-| Database | $[X] | $[X] | [URL] |
-| Other | $[X] | $[X] | [URL] |
-| **Total** | **$[X]** | **$[X]** | |
-
-_Assumptions: [user count, traffic, storage]_
-```
-
-### 5. Present to User and Gate
-
-```
-[C] Continue — Deployment defined, proceed to Quality & Risks
-[R] Revise — Adjust infrastructure or costs
-```
-
-**HALT — wait for user response before proceeding.**
-
-### 6. Handle Response
-
-- **[C]**: Load next step: `./step-41-quality-risks.md`
-- **[R]**: Revise, update architecture.md §7-9, re-present
-
-## SUCCESS METRICS
-
-- All environments defined
-- CI/CD pipeline with quality gates
-- Cost estimates with sources
-- Crosscutting concerns (logging, auth, errors) addressed
-
-## NEXT STEP
-
-After user selects [C], read and follow: `./step-41-quality-risks.md`

package/skills/ultra-research/steps/step-41-quality-risks.md

@@ -1,135 +0,0 @@
-# Step 41: Quality Scenarios & Risks
-
-## MANDATORY EXECUTION RULES
-
-- QUALITY SCENARIOS must be specific and testable
-- RISKS need probability AND impact AND mitigation
-- BE HONEST — don't minimize risks to make the plan look good
-- WRITE output to spec file BEFORE presenting to user
-- ALL output in English (spec files); conversation in Chinese
-
-## PREREQUISITES
-
-- Step 40 (Deployment) completed with [C]
-- `.ultra/specs/architecture.md` §1-9 exist
-
-## EXECUTION SEQUENCE
-
-### 1. Define Quality Scenarios
-
-For each quality goal from §1, create testable scenarios:
-
-| Quality Goal | Scenario | Stimulus | Response | Measure |
-|-------------|---------|----------|----------|---------|
-| Performance | Load test | 1000 concurrent users | Response time | p95 < 200ms |
-| Availability | Node failure | One server dies | Auto-recovery | < 30s downtime |
-| Security | Injection | SQL injection attempt | Blocked | 0 success |
-
-### 2. Identify Risks
-
-Categories: Technical, Business, Operational, External.
-
-For each risk:
-- **Probability**: High / Medium / Low
-- **Impact**: High / Medium / Low
-- **Mitigation**: What we'll do to reduce it
-- **Contingency**: What we'll do if it happens anyway
-
-### 3. Identify Technical Debt
-
-What are we knowingly deferring? Document it now so it doesn't get forgotten.
-
-### 4. Write Output
-
-**WRITE IMMEDIATELY** to `.ultra/specs/architecture.md` §10-12:
-
-```markdown
-## §10 Quality Scenarios
-
-| # | Quality Attribute | Scenario | Stimulus | Expected Response | Metric |
-|---|------------------|---------|----------|------------------|--------|
-| Q1 | Performance | [Scenario] | [Stimulus] | [Response] | [Target] |
-| Q2 | Scalability | [Scenario] | [Stimulus] | [Response] | [Target] |
-| Q3 | Security | [Scenario] | [Stimulus] | [Response] | [Target] |
-| Q4 | Availability | [Scenario] | [Stimulus] | [Response] | [Target] |
-| Q5 | Maintainability | [Scenario] | [Stimulus] | [Response] | [Target] |
-
-## §11 Risks & Technical Debt
-
-### Risk Register
-
-| # | Risk | Category | Probability | Impact | Score | Mitigation | Contingency |
-|---|------|----------|------------|--------|-------|-----------|-------------|
-| R1 | [Risk] | Technical | High | High | 9 | [Action] | [Fallback] |
-| R2 | [Risk] | Business | Medium | High | 6 | [Action] | [Fallback] |
-| R3 | [Risk] | External | Low | Medium | 2 | [Action] | [Fallback] |
-
-### Known Technical Debt
-
-| # | Debt Item | Reason for Deferral | Impact if Not Addressed | Address By |
-|---|----------|--------------------|-----------------------|-----------|
-| TD1 | [Item] | [Why deferred] | [Consequence] | [Timeline] |
-| TD2 | [Item] | [Why deferred] | [Consequence] | [Timeline] |
-
-## §12 Architecture Decision Records
-
-| # | Decision | Context | Options | Chosen | Rationale |
-|---|---------|---------|---------|--------|-----------|
-| ADR-1 | [Decision] | [Why needed] | [A, B, C] | [Choice] | [Why] |
-| ADR-2 | [Decision] | [Why needed] | [A, B, C] | [Choice] | [Why] |
-
-### Round 4 Summary
-
-**Quality & Deployment Confidence**:
-- **Deployment readiness**: [X]%
-- **Risk coverage**: [X]%
-- **Quality scenario coverage**: [X]%
-- **Overall R4 confidence**: [X]%
-```
-
-### 5. Write Round 4 Research Report
-
-**WRITE** to `.ultra/docs/research/quality-deployment-{date}.md`:
-
-```markdown
-# Round 4: Quality & Deployment
-
-> **Confidence**: [X]%
-> **Steps completed**: 40-41
-> **Completed**: [date]
-
-## Key Findings
-[Infrastructure decisions + cost summary]
-
-## Top Risks
-[Top 3 risks with scores]
-
-## Technical Debt
-[Items knowingly deferred]
-```
-
-### 6. Present to User and Gate
-
-```
-[C] Continue — Architecture complete, proceed to Research Synthesis
-[R] Revise — Adjust quality scenarios or risks
-```
-
-**HALT — wait for user response before proceeding.**
-
-### 7. Handle Response
-
-- **[C]**: Load next step: `./step-99-synthesis.md`
-- **[R]**: Revise, update architecture.md §10-12, re-present
-
-## SUCCESS METRICS
-
-- Quality scenarios are specific and testable
-- At least 5 risks identified with mitigation
-- Technical debt documented with timelines
-- ADRs capture key architecture decisions
-- Round 4 research report written
-
-## NEXT STEP
-
-After user selects [C], read and follow: `./step-99-synthesis.md`