wize-dev-kit 0.15.0 → 0.16.0

package/src/method-skills/3-solutioning/wize-create-architecture/steps/step-04-decisions.md

@@ -1,129 +0,0 @@
-# Step 4: Core Architectural Decisions
-
-## Mandatory execution rules
-
-- 🛑 Never generate content without user input.
-- ✅ Treat this as collaborative discovery between peers.
-- 🌐 Search the web to verify current technology versions.
-- ⚠️ No time estimates.
-- ✅ Speak in `{communication_language}`; write artifacts in `{document_output_language}`.
-
-## Execution protocols
-
-- 🎯 Show analysis before taking action.
-- ⚠️ Present A/P/C menu after each major decision category.
-- 💾 Only save when the user chooses C.
-- 📖 Update frontmatter `stepsCompleted: [1, 2, 3, 4]` before loading the next step.
-
-## Collaboration menu (A/P/C)
-
-- **A (Advanced Elicitation)** — explore innovative approaches to a specific decision.
-- **P (Party Mode)** — review trade-offs from multiple perspectives.
-- **C (Continue)** — save current decisions and proceed.
-
-## Context boundaries
-
-- Project context from step 2 is available.
-- Starter template choice from step 3 is available.
-- Focus on decisions not already made by the starter or existing preferences.
-
-## Task
-
-Facilitate collaborative architectural decision making for the remaining critical choices.
-
-## Decision categories
-
-### Category 1: Data Architecture
-
-- Database choice (if not determined by starter)
-- Data modeling approach
-- Validation strategy
-- Migration approach
-- Caching strategy
-
-### Category 2: Authentication & Security
-
-- Authentication method
-- Authorization patterns
-- Security middleware
-- Encryption approach
-- API security strategy
-
-### Category 3: API & Communication
-
-- API design patterns (REST, GraphQL, tRPC, etc.)
-- Error handling standards
-- Rate limiting
-- Inter-service communication
-
-### Category 4: Frontend Architecture (if applicable)
-
-- State management
-- Component architecture
-- Routing
-- Performance optimization
-
-### Category 5: Infrastructure & Deployment
-
-- Hosting strategy
-- CI/CD approach
-- Environment configuration
-- Monitoring and logging
-- Scaling strategy
-
-## Decision format
-
-For each decision, record:
-
-- Category
-- Decision
-- Version (if applicable)
-- Rationale
-- Affects (components or epics)
-- Provided by starter? (yes/no)
-
-## Generate decisions content
-
-Append to `architecture.md`:
-
-```markdown
-## Core Architectural Decisions
-
-### Decision Priority Analysis
-
-**Critical Decisions (block implementation):**
-{{list}}
-
-**Important Decisions (shape architecture):**
-{{list}}
-
-**Deferred Decisions (post-MVP):**
-{{list}}
-
-### Data Architecture
-...
-
-### Authentication & Security
-...
-
-### API & Communication Patterns
-...
-
-### Frontend Architecture
-...
-
-### Infrastructure & Deployment
-...
-
-### Decision Impact Analysis
-
-**Implementation Sequence:**
-{{ordered list}}
-
-**Cross-Component Dependencies:**
-{{how decisions affect each other}}
-```
-
-## Next step
-
-After C, load `./step-05-patterns.md`.

package/src/method-skills/3-solutioning/wize-create-architecture/steps/step-05-patterns.md

@@ -1,109 +0,0 @@
-# Step 5: Implementation Patterns & Consistency Rules
-
-## Mandatory execution rules
-
-- 🛑 Never generate content without user input.
-- ✅ Treat this as collaborative discovery.
-- 🎯 Focus on patterns that prevent AI agent implementation conflicts.
-- 🎯 Emphasize what agents could decide differently if not specified.
-- ⚠️ No time estimates.
-- ✅ Speak in `{communication_language}`; write artifacts in `{document_output_language}`.
-
-## Execution protocols
-
-- 🎯 Show analysis before taking action.
-- ⚠️ Present A/P/C menu after generating patterns content.
-- 💾 Only save when the user chooses C.
-- 📖 Update frontmatter `stepsCompleted: [1, 2, 3, 4, 5]` before loading the next step.
-
-## Collaboration menu (A/P/C)
-
-- **A (Advanced Elicitation)** — develop additional consistency patterns.
-- **P (Party Mode)** — identify conflict points from multiple perspectives.
-- **C (Continue)** — save and move to project structure.
-
-## Context boundaries
-
-- Core decisions from step 4 are complete.
-- Technology stack is decided.
-- Focus on HOW agents should implement, not WHAT.
-
-## Task
-
-Define implementation patterns and consistency rules so multiple AI agents write compatible code.
-
-## Pattern categories
-
-### Naming patterns
-
-- Database table/column naming
-- API endpoint naming
-- File and directory naming
-- Component/function/variable naming
-- Route parameter formats
-
-### Structure patterns
-
-- Where tests live
-- How components are organized
-- Where utilities and helpers go
-- Configuration file organization
-
-### Format patterns
-
-- API response wrappers
-- Error response structures
-- Date/time formats
-- JSON field naming (snake_case vs camelCase)
-
-### Communication patterns
-
-- Event naming conventions
-- Event payload structures
-- State update patterns
-- Action naming conventions
-- Logging formats and levels
-
-### Process patterns
-
-- Loading state handling
-- Error recovery
-- Retry implementation
-- Authentication flow
-- Validation timing and methods
-
-## Generate patterns content
-
-Append to `architecture.md`:
-
-```markdown
-## Implementation Patterns & Consistency Rules
-
-### Naming Patterns
-...
-
-### Structure Patterns
-...
-
-### Format Patterns
-...
-
-### Communication Patterns
-...
-
-### Process Patterns
-...
-
-### Enforcement Guidelines
-
-**All AI agents MUST:**
-- ...
-
-### Pattern Examples
-**Good:** ...
-**Anti-patterns:** ...
-```
-
-## Next step
-
-After C, load `./step-06-structure.md`.

package/src/method-skills/3-solutioning/wize-create-architecture/steps/step-06-structure.md

@@ -1,97 +0,0 @@
-# Step 6: Project Structure & Boundaries
-
-## Mandatory execution rules
-
-- 🛑 Never generate content without user input.
-- ✅ Treat this as collaborative discovery.
-- 🗺️ Create a complete project tree, not generic placeholders.
-- 🗺️ Map requirements/epics to architectural components.
-- ⚠️ No time estimates.
-- ✅ Speak in `{communication_language}`; write artifacts in `{document_output_language}`.
-
-## Execution protocols
-
-- 🎯 Show analysis before taking action.
-- ⚠️ Present A/P/C menu after generating project structure.
-- 💾 Only save when the user chooses C.
-- 📖 Update frontmatter `stepsCompleted: [1, 2, 3, 4, 5, 6]` before loading the next step.
-
-## Collaboration menu (A/P/C)
-
-- **A (Advanced Elicitation)** — explore innovative project organization.
-- **P (Party Mode)** — evaluate structure trade-offs.
-- **C (Continue)** — save and move to validation.
-
-## Context boundaries
-
-- All previous decisions are complete.
-- Implementation patterns are defined.
-- Focus on physical project structure and component boundaries.
-
-## Task
-
-Define the complete project structure and architectural boundaries based on all decisions made.
-
-## Structure sequence
-
-### 1. Analyze requirements mapping
-
-Map epics or FR categories to directories/services.
-
-### 2. Define project directory structure
-
-Create a complete, technology-specific tree:
-
-- Root configuration files
-- Source code organization
-- Test organization
-- Build and distribution
-
-### 3. Define integration boundaries
-
-- API boundaries
-- Component boundaries
-- Service boundaries
-- Data boundaries
-
-### 4. Map requirements to structure
-
-For each epic or feature cluster:
-
-```markdown
-Epic: User Management
-- Components: src/components/features/users/
-- Services: src/services/users/
-- API Routes: src/app/api/users/
-- Database: prisma/migrations/...
-- Tests: tests/features/users/
-```
-
-## Generate structure content
-
-Append to `architecture.md`:
-
-```markdown
-## Project Structure & Boundaries
-
-### Complete Project Directory Structure
-```
-{{tree}}
-```
-
-### Architectural Boundaries
-...
-
-### Requirements to Structure Mapping
-...
-
-### Integration Points
-...
-
-### File Organization Patterns
-...
-```
-
-## Next step
-
-After C, load `./step-07-validation.md`.

package/src/method-skills/3-solutioning/wize-create-architecture/steps/step-07-validation.md

@@ -1,124 +0,0 @@
-# Step 7: Architecture Validation & Completion
-
-## Mandatory execution rules
-
-- 🛑 Never generate content without user input.
-- ✅ Validate all requirements are covered by architectural decisions.
-- ⚠️ No time estimates.
-- ✅ Speak in `{communication_language}`; write artifacts in `{document_output_language}`.
-
-## Execution protocols
-
-- 🎯 Show analysis before taking action.
-- ✅ Run validation checks on the complete architecture.
-- ⚠️ Present A/P/C menu after generating validation results.
-- 💾 Only save when the user chooses C.
-- 📖 Update frontmatter `stepsCompleted: [1, 2, 3, 4, 5, 6, 7]` before loading the next step.
-
-## Collaboration menu (A/P/C)
-
-- **A (Advanced Elicitation)** — address complex architectural issues found.
-- **P (Party Mode)** — review validation from multiple perspectives.
-- **C (Continue)** — save validation results and complete the architecture.
-
-## Context boundaries
-
-- Complete architecture document is available.
-- All decisions, patterns, and structure are defined.
-- Focus on validation, gap analysis, and coherence.
-
-## Task
-
-Validate the complete architecture for coherence, completeness, and readiness.
-
-## Validation sequence
-
-### 1. Coherence validation
-
-- Decision compatibility
-- Pattern consistency
-- Structure alignment
-
-### 2. Requirements coverage validation
-
-- Epic/feature coverage
-- Functional requirements coverage
-- Non-functional requirements coverage
-
-### 3. Implementation readiness validation
-
-- Decision completeness
-- Structure completeness
-- Pattern completeness
-
-### 4. Gap analysis
-
-Identify critical, important, and nice-to-have gaps.
-
-### 5. Generate validation content
-
-Append to `architecture.md`:
-
-```markdown
-## Architecture Validation Results
-
-### Coherence Validation
-...
-
-### Requirements Coverage Validation
-...
-
-### Implementation Readiness Validation
-...
-
-### Gap Analysis Results
-...
-
-### Validation Issues Addressed
-...
-
-### Architecture Completeness Checklist
-
-**Requirements Analysis**
-- [ ] Project context thoroughly analyzed
-- [ ] Scale and complexity assessed
-- [ ] Technical constraints identified
-- [ ] Cross-cutting concerns mapped
-
-**Architectural Decisions**
-- [ ] Critical decisions documented with versions
-- [ ] Technology stack fully specified
-- [ ] Integration patterns defined
-- [ ] Performance considerations addressed
-
-**Implementation Patterns**
-- [ ] Naming conventions established
-- [ ] Structure patterns defined
-- [ ] Communication patterns specified
-- [ ] Process patterns documented
-
-**Project Structure**
-- [ ] Complete directory structure defined
-- [ ] Component boundaries established
-- [ ] Integration points mapped
-- [ ] Requirements to structure mapping complete
-
-### Architecture Readiness Assessment
-
-**Overall Status:** [READY FOR IMPLEMENTATION / READY WITH MINOR GAPS / NOT READY]
-**Confidence Level:** [high/medium/low]
-**Key Strengths:** ...
-**Areas for Future Enhancement:** ...
-
-### Implementation Handoff
-
-**AI Agent Guidelines:**
-- Follow all architectural decisions exactly as documented.
-- Use implementation patterns consistently.
-- Respect project structure and boundaries.
-- Refer to this document for all architectural questions.
-```
-
-## Next step
-
-After C, load `./step-08-complete.md`.

package/src/method-skills/3-solutioning/wize-create-architecture/steps/step-08-complete.md

@@ -1,59 +0,0 @@
-# Step 8: Architecture Completion & Handoff
-
-## Mandatory execution rules
-
-- 🛑 Never generate content without user input.
-- ✅ Treat this as collaborative completion.
-- 🎯 Provide clear next steps for implementation.
-- ⚠️ No time estimates.
-- ✅ Speak in `{communication_language}`; write artifacts in `{document_output_language}`.
-
-## Execution protocols
-
-- 🎯 Show completion summary and implementation guidance.
-- 📖 Update frontmatter with final workflow state.
-- 🚫 This is the final step.
-
-## Task
-
-Complete the architecture workflow and guide the user to the next phase.
-
-## Completion sequence
-
-### 1. Summarize achievements
-
-Congratulate the user and summarize what was built together:
-
-- Architecture document path
-- Number of ADRs produced
-- Key decisions made
-- Patterns defined
-- Validation status
-
-### 2. Update frontmatter
-
-```yaml
-status: ready-for-stories
-owner: Tony Stark
-updated: "{{date}}"
-stepsCompleted: [1, 2, 3, 4, 5, 6, 7, 8]
-workflowType: architecture
-lastStep: 8
-```
-
-### 3. Next steps guidance
-
-```
-Architecture complete. Next:
-1. Hawkeye: run wize-tea-risk to build the global risk profile.
-2. Tony: run wize-create-epics-and-stories to slice the work.
-3. Use `/wize` (or `/wize-help`) anytime to check what comes next.
-```
-
-## On complete
-
-Run `{workflow.on_complete}` if non-empty.
-
-## Workflow complete
-
-The architecture is now the single source of truth for all technical decisions, ensuring consistent implementation across the project lifecycle.

package/src/method-skills/3-solutioning/wize-project-context/workflow.md

@@ -1,120 +0,0 @@
----
-
-code: wize-project-context
-description: "Use quando precisar estabelecer ou atualizar o contexto do projeto (stack, convenções, restrições) para orientar a solução."
-name: Project Context
-phase: 3-solutioning
-owner: wize-agent-architect   # Tony Stark
-status: ready
----
-
-# Project Context
-
-**Goal.** Consolidate the 5 foundational artifacts (brief, PRD, UX, architecture, risk profile) into a single `.wize/knowledge/project-context.md` so other agents (Shuri, Hawkeye, Mantis, Wizer) can read the project in one shot instead of stitching it from 5 files.
-
-Tony drives. Peggy polishes prose. Wizer is on call for cross-cutting drift.
-
-## When to run
-
-- After Phase 3 closeout (architecture + ADRs + risk profile all exist).
-- After any major change to brief / PRD / architecture (rerun).
-- Before sprint planning if context feels stale.
-
-## When NOT to run
-
-- During greenfield with no artifacts yet (run only after brief + PRD exist).
-- As a CI step (manual; expensive to run on every commit).
-
-## Inputs
-
-- `.wize/planning/brief.md` — Vision, Audience.
-- `.wize/planning/prd.md` — Goals, scope.
-- `.wize/planning/ux/ux-design/index.md` — UX stack, key screens.
-- `.wize/solutioning/architecture.md` — Tech stack, components.
-- `.wize/solutioning/adrs/*.md` — Key decisions.
-- `.wize/implementation/tea/risk-profile.md` — Active risks.
-
-## Output
-
-- `.wize/knowledge/project-context.md` (5 sections, YAML frontmatter, `last_updated` date).
-
-## Steps
-
-### 1. Vision and Audience
-
-Copy from `brief.md` (or `prd.md` if brief is missing). One paragraph each. Mark the source file in a comment.
-
-### 2. Tech stack
-
-From `architecture.md`, list: runtime, framework, database, key libraries, build tool. One bullet per item. Skip items that are "TBD".
-
-### 3. Key ADRs
-
-List the 5 most recent ADRs from `.wize/solutioning/adrs/`. For each: title, decision, why. Older ADRs are out of scope; refer to `adrs/index.md` for the full list.
-
-### 4. Active risks
-
-Copy from `risk-profile.md` the top 5 risks (highest prob × impact). One bullet per risk with the mitigation. Defer the rest.
-
-### 5. Active sprint
-
-Read `.wize/implementation/sprint-status.yaml` and include: sprint number, capacity, in-progress stories. Skip if no active sprint.
-
-### 6. Hand off
-
-Output is a markdown file. Wizer uses this file to seed `/wize`, `/wize-help`, `/wize-dev-story`, and `/wize-onboarding` reads.
-
-## Output template
-
-```markdown
----
-generated: YYYY-MM-DD
-last_updated: YYYY-MM-DD
-sources:
-  - .wize/planning/brief.md
-  - .wize/planning/prd.md
-  - .wize/planning/ux/ux-design/index.md
-  - .wize/solutioning/architecture.md
-  - .wize/solutioning/adrs/
-  - .wize/implementation/tea/risk-profile.md
----
-
-# Project Context — {project_name}
-
-## Vision
-{paragraph from brief.md}
-
-## Audience
-{paragraph from brief.md or prd.md}
-
-## Tech stack
-- Runtime: {value}
-- Framework: {value}
-- Database: {value}
-- Key libraries: {value}
-- Build: {value}
-
-## Key ADRs
-1. **{title}** — {decision}. Why: {why}.
-2. ...
-
-## Active risks
-1. **{R-id}** — {description}. Mitigation: {mitigation}.
-2. ...
-
-## Active sprint
-- Sprint: {N}
-- Capacity: {days}
-- In-progress: {stories}
-```
-
-## Anti-patterns Tony rejects
-
-- Reading all 6 sources in full and dumping them. Summarize in 5 sections.
-- Editing the project-context.md by hand. (Always re-run the workflow to keep `last_updated` honest.)
-- Skipping the frontmatter. Other agents parse it.
-- Including items marked "TBD". Surface them in the `Open questions` section instead.
-
-## Hand-off
-
-> "Project context updated at `.wize/knowledge/project-context.md`. {N} sources, 5 sections, {date}. Next: `/wize-onboarding` (Wizer) reads this for first contact."