wize-dev-kit 0.14.0 → 0.16.0

package/src/method-skills/3-solutioning/wize-create-architecture/architecture-decision-template.md

@@ -1,41 +0,0 @@
----
-status: draft
-owner: Tony Stark
-created: "{{created}}"
-stepsCompleted: []
-inputDocuments: []
----
-
-# Architecture — {{project_name}}
-
-## Summary
-
-{{One paragraph: stack family, runtime, primary data store, deploy target. The frame.}}
-
-## Stack
-
-- Language:
-- Front-end:
-- Back-end:
-- DB:
-- Auth:
-- Hosting:
-- Observability:
-- Test:
-
-## Components
-
-| Component | Responsibility | Boundary |
-|---|---|---|
-
-## Data model
-
-## Sequences
-
-## Cross-cutting concerns
-
-## NFR check
-
-## ADRs
-
-See `.wize/solutioning/adrs/`.

package/src/method-skills/3-solutioning/wize-create-architecture/customize.toml

@@ -1,20 +0,0 @@
-# Wize Dev Kit — overrides for the built-in workflow "wize-create-architecture".
-# DO NOT EDIT in the installed kit; copy to .wize/custom/workflows/wize-create-architecture/
-# for project-level overrides.
-
-[workflow]
-
-# Steps to run before standard activation (config load, greet).
-activation_steps_prepend = []
-
-# Steps to run after greet but before the workflow begins.
-activation_steps_append = []
-
-# Persistent facts the workflow keeps in mind for the whole run.
-persistent_facts = [
-  "file:{project-root}/.wize/knowledge/document-project/conventions.md",
-]
-
-# Scalar executed when Step 8 (Architecture Completion & Handoff) finishes.
-# Override wins. Leave empty for no custom post-completion behavior.
-on_complete = ""

package/src/method-skills/3-solutioning/wize-create-architecture/steps/step-01-init.md

@@ -1,95 +0,0 @@
-# Step 1: Architecture Workflow Initialization
-
-## Mandatory execution rules
-
-- 🛑 Never generate content without user input.
-- 📖 Always read the complete step file before acting.
-- ✅ Treat this as collaborative discovery between architectural peers.
-- 💬 Focus on initialization and setup only.
-- 🚪 Detect existing workflow state and handle continuation properly.
-- ⚠️ No time estimates.
-- ✅ Speak in `{communication_language}`; write artifacts in `{document_output_language}`.
-
-## Execution protocols
-
-- 🎯 Show analysis before taking action.
-- 💾 Initialize the document and update frontmatter.
-- 📖 Set `stepsCompleted: [1]` before loading the next step.
-- 🚫 Do not load the next step until setup is complete and the user confirms.
-
-## Context boundaries
-
-- Variables from `workflow.md` are available.
-- Previous context is what is in the output document + frontmatter.
-- Input document discovery happens in this step.
-
-## Task
-
-Initialize the Architecture workflow by detecting continuation state, discovering input documents, and setting up the document for collaborative architectural decision making.
-
-## Initialization sequence
-
-### 1. Check for existing workflow
-
-Check if `{output_folder}/solutioning/architecture.md` exists.
-
-- If it exists and has frontmatter with `stepsCompleted`, stop here and load `./step-01b-continue.md`.
-- If it exists but has no `stepsCompleted`, treat it as a legacy document: warn the user and offer to continue from it or start fresh.
-- If it does not exist, this is a fresh workflow.
-
-### 2. Discover input documents
-
-Search in `{output_folder}/planning/`, `{output_folder}/knowledge/`, and `{project-root}/docs/` for:
-
-- Product Brief (`*brief*.md`)
-- PRD (`*prd*.md`)
-- UX Scenarios / UX Design (`*ux*.md`)
-- Research (`*research*.md`)
-- Project Context (`**/project-context.md`)
-
-Confirm what was found with the user before proceeding.
-
-### 3. Validate required inputs
-
-If no PRD is found:
-
-> Architecture requires a PRD to work from. Please run `wize-create-prd` first or provide the PRD file path.
-
-Do not proceed without a PRD.
-
-### 4. Create initial document
-
-Copy `../architecture-decision-template.md` to `{output_folder}/solutioning/architecture.md`.
-
-Set frontmatter:
-
-```yaml
-status: draft
-owner: Tony Stark
-created: "{{date}}"
-stepsCompleted: []
-inputDocuments: [{{list of discovered files}}]
-```
-
-### 5. Report setup to user
-
-```
-Welcome {{user_name}}! I've set up your Architecture workspace for {{project_name}}.
-
-Documents found:
-- PRD: {count or "None — required"}
-- UX Design: {count or "None"}
-- Research: {count or "None"}
-- Project docs: {count or "None"}
-- Project context: {count of rules or "None"}
-
-Files loaded: {list or "No additional documents"}
-
-Ready to begin architectural decision making. Do you have any other documents you'd like to include?
-
-[C] Continue to project context analysis
-```
-
-## Next step
-
-After the user selects [C], load `./step-02-context.md`.

package/src/method-skills/3-solutioning/wize-create-architecture/steps/step-01b-continue.md

@@ -1,32 +0,0 @@
-# Step 1b: Continue Existing Architecture Workflow
-
-## Purpose
-
-Resume an architecture workflow that was previously started.
-
-## Rules
-
-- Read the existing `{output_folder}/solutioning/architecture.md` fully, including frontmatter.
-- Report the current `stepsCompleted` to the user.
-- Ask whether to continue from the last completed step or restart from a specific step.
-- Never discard already-written content without explicit user confirmation.
-
-## Continue menu
-
-```
-Existing architecture document found.
-
-Steps completed: {stepsCompleted}
-Last saved: {updated or created date}
-
-What would you like to do?
-[C] Continue from the next step ({next_step})
-[R] Restart from step 1
-[S] Pick a specific step to revisit
-```
-
-## Routing
-
-- [C] → load the step immediately after the highest value in `stepsCompleted`.
-- [R] → confirm overwrite risk, then return to `step-01-init.md` fresh setup.
-- [S] → present the list of steps and load the selected one.

package/src/method-skills/3-solutioning/wize-create-architecture/steps/step-02-context.md

@@ -1,126 +0,0 @@
-# Step 2: Project Context Analysis
-
-## Mandatory execution rules
-
-- 🛑 Never generate content without user input.
-- 📖 Always read the complete step file before acting.
-- ✅ Treat this as collaborative discovery.
-- 🎯 Analyze loaded documents; don't assume or generate requirements.
-- ⚠️ 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 context analysis.
-- 💾 Only save when the user chooses C (Continue).
-- 📖 Update frontmatter `stepsCompleted: [1, 2]` before loading the next step.
-- 🚫 Do not load the next step until C is selected.
-
-## Collaboration menu (A/P/C)
-
-- **A (Advanced Elicitation)** — invoke `wize-advanced-elicitation` for deeper architectural implications.
-- **P (Party Mode)** — invoke `wize-party-mode` to bring Tony, Fury, and Pepper into the conversation.
-- **C (Continue)** — save the content and proceed.
-
-After A or P, return to this menu.
-
-## Context boundaries
-
-- Current document and frontmatter from step 1 are available.
-- Input documents are loaded.
-- Focus on architectural implications only — no technology decisions yet.
-
-## Task
-
-Analyze the loaded project documents to understand architectural scope, requirements, and constraints.
-
-## Analysis sequence
-
-### 1. Review project requirements
-
-**From PRD:**
-
-- Extract functional requirements and their architectural implications.
-- Identify non-functional requirements (performance, security, compliance).
-- Note technical constraints or dependencies.
-
-**From Epics/Stories (if available):**
-
-- Map epic structure to architectural components.
-- Identify cross-cutting concerns that span multiple epics.
-
-**From UX Design (if available):**
-
-- Component complexity, real-time needs, platform-specific UI, accessibility level, responsive breakpoints, offline capability.
-
-### 2. Project scale assessment
-
-Complexity indicators:
-
-- Real-time features
-- Multi-tenancy
-- Regulatory compliance
-- Integration density
-- User interaction complexity
-- Data complexity and volume
-
-### 3. Reflect understanding to the user
-
-Present a concise summary:
-
-```
-I'm reviewing your project documentation for {{project_name}}.
-
-I see {{fr_count}} functional requirements and {{nfr_count}} non-functional requirements.
-{epics_loaded?}I also see {{epic_count}} epics with {{story_count}} stories.{/epics_loaded?}
-{ux_loaded?}A UX specification is present.{/ux_loaded?}
-
-Key architectural aspects:
-- [core functionality]
-- [critical NFRs]
-- [unique technical challenges]
-- [compliance requirements]
-
-Scale indicators:
-- Complexity: [low/medium/high/enterprise]
-- Primary domain: [web/mobile/api/backend/full-stack/etc]
-- Cross-cutting concerns: [list]
-
-Does this match your understanding?
-```
-
-### 4. Generate project context content
-
-Prepare the section to append:
-
-```markdown
-## Project Context Analysis
-
-### Requirements Overview
-
-**Functional Requirements:**
-{{analysis}}
-
-**Non-Functional Requirements:**
-{{analysis}}
-
-**Scale & Complexity:**
-- Primary domain: {{domain}}
-- Complexity level: {{level}}
-- Architectural components: {{count}}
-
-### Technical Constraints & Dependencies
-{{list}}
-
-### Cross-Cutting Concerns Identified
-{{list}}
-```
-
-### 5. Present content and menu
-
-Show the drafted content and present A/P/C. Only append when the user chooses C.
-
-## Next step
-
-After C, load `./step-03-starter.md`.

package/src/method-skills/3-solutioning/wize-create-architecture/steps/step-03-starter.md

@@ -1,110 +0,0 @@
-# Step 3: Starter Template Evaluation
-
-## Mandatory execution rules
-
-- 🛑 Never generate content without user input.
-- ✅ Treat this as collaborative discovery.
-- 🌐 Search the web to verify current versions and options.
-- ⚠️ 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 starter analysis.
-- 💾 Only save when the user chooses C.
-- 📖 Update frontmatter `stepsCompleted: [1, 2, 3]` before loading the next step.
-
-## Collaboration menu (A/P/C)
-
-- **A (Advanced Elicitation)** — explore unconventional starter options.
-- **P (Party Mode)** — evaluate starter trade-offs from multiple perspectives.
-- **C (Continue)** — save and move to architectural decisions.
-
-## Context boundaries
-
-- Project context from step 2 is available.
-- No architectural decisions made yet — this step evaluates foundations.
-
-## Task
-
-Discover technical preferences and evaluate starter template options, establishing solid architectural foundations.
-
-## Starter evaluation sequence
-
-### 0. Check existing technical preferences
-
-If `.wize/knowledge/document-project/conventions.md` or `project-context.md` exist, surface any already-documented technical rules.
-
-### 1. Discover user technical preferences
-
-Ask about:
-
-- Languages and frameworks
-- Databases
-- Cloud / hosting / deployment
-- Third-party services (auth, payments, analytics)
-- Team experience level
-
-### 2. Identify primary technology domain
-
-Map the project to one of:
-
-- Web application
-- Mobile app
-- API / backend
-- CLI tool
-- Full-stack
-- Desktop
-
-### 3. Research current starter options
-
-Search the web for current, maintained starter templates matching the domain.
-
-### 4. Present starter options
-
-For each viable starter, document:
-
-- Technology decisions already made by the starter
-- Architectural patterns established
-- Development experience features
-- Maintenance status
-
-### 5. Get selection
-
-Present a recommended starter and ask for confirmation.
-
-### 6. Generate starter content
-
-Append to `architecture.md`:
-
-```markdown
-## Starter Template Evaluation
-
-### Primary Technology Domain
-{{domain}}
-
-### Starter Options Considered
-{{analysis}}
-
-### Selected Starter: {{starter_name}}
-
-**Rationale:** {{why}}
-
-**Initialization Command:**
-```bash
-{{command}}
-```
-
-**Architectural Decisions Provided by Starter:**
-- Language & Runtime: ...
-- Styling Solution: ...
-- Build Tooling: ...
-- Testing Framework: ...
-- Code Organization: ...
-- Development Experience: ...
-```
-
-## Next step
-
-After C, load `./step-04-decisions.md`.

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`.