wize-dev-kit 0.16.0 → 0.17.0

package/src/method-skills/3-solutioning/wize-check-implementation-readiness/workflow.md

@@ -1,22 +1,114 @@
 ---
+
 code: wize-check-implementation-readiness
+description: "Use quando a arquitetura e as stories estiverem prontas e precisar verificar se o projeto está pronto para entrar em implementação."
 name: Check Implementation Readiness
 phase: 3-solutioning
-owner: wize-agent-architect   # Tony Stark (with Hawkeye)
-status: stub
+owner: wize-agent-architect   # Tony Stark (with Hawkeye + Hill)
+status: ready
 ---
 
 # Check Implementation Readiness
 
-**Goal.** Before any story enters dev, confirm everything is in place.
+**Goal.** Before any story enters dev, confirm everything is in place. This is the **gate at the end of Phase 3**. Cheap; saves multiples of itself downstream.
+
+Tony chairs. Hill and Hawkeye sign off. Pepper and Mantis answer if pulled in.
+
+## Inputs
+
+- `.wize/planning/prd.md` (validated)
+- `.wize/planning/ux/ux-design/` + `index.md`
+- `.wize/planning/tech-vision.md`
+- `.wize/planning/nfr-principles.md`
+- `.wize/solutioning/architecture.md`
+- `.wize/solutioning/adrs/`
+- `.wize/solutioning/design-system/`
+- `.wize/solutioning/epics/` + `stories/`
+- `.wize/implementation/tea/risk-profile.md` (Hawkeye)
+- `.wize/config/tea.toml` (policy choice)
+
+## Outputs
+
+- `.wize/solutioning/readiness-{YYYY-MM-DD}.md` — checklist result + signoffs.
+
+## Checklist (Tony chairs)
+
+### Planning artifacts
+- [ ] PRD `status: validated`.
+- [ ] All open questions in PRD resolved (no `blocker` open).
+- [ ] Trigger map covers every PRD goal.
+
+### UX
+- [ ] Every In-scope item has at least one screen spec.
+- [ ] UX design index maps every screen → scenario → AC.
+- [ ] Design system tokens + components needed by the UX exist.
+
+### Strategy
+- [ ] Tech vision `status: aligned`.
+- [ ] NFR principles `status: aligned`; verifiers named for every non-negotiable.
+
+### Architecture
+- [ ] Architecture doc `status: ready-for-stories`.
+- [ ] ADRs cover every meaningful trade-off.
+- [ ] NFR check section answers *how* for each non-negotiable.
+
+### Stories
+- [ ] Every epic has 3–10 stories.
+- [ ] Every story has AC IDs from the PRD; the union per epic equals the epic's AC set.
+- [ ] No story is XL.
+- [ ] Each story names touch-points + `testid` + reuse of design-system components.
+
+### TEA
+- [ ] `tea-risk.md` exists.
+- [ ] `.wize/config/tea.toml` policy is committed (advisory / enforcing).
+- [ ] First-story `tea-design.md` is drafted (proof Hawkeye's contract works).
 
-## Checklist
-- [ ] Architecture doc exists and is signed (Tony + Fury approved).
-- [ ] All in-scope screens have UX specs (Mantis).
-- [ ] Design system tokens exist (Mantis).
-- [ ] Stories are sliced with ACs (Tony).
-- [ ] Hawkeye risk profile exists.
-- [ ] `.wize/config/tea.toml` policy choice is recorded.
+### Cross-cutting
+- [ ] CI runs tests + validators on every PR.
+- [ ] Lint/format on commit.
+- [ ] Branch protection on `main`.
+- [ ] Secrets vault wired; no secret in repo.
 
 ## Outcome
-Either `ready: true` or list of fix-asks.
+
+- **Ready** → write the readiness file, link from `sprint-planning`.
+- **Concerns** → list specifically what's missing, owner per item, deadline. Re-check.
+
+## Output template
+
+```markdown
+---
+status: ready | concerns
+date: YYYY-MM-DD
+chair: Tony Stark
+signoffs:
+  - Maria Hill (PM)
+  - Hawkeye (TEA)
+  - Mantis (UX) — async
+  - Fury (Strategy) — async
+---
+
+# Implementation Readiness — {{project_name}}
+
+## Result: Ready
+
+## Notes
+- Architecture covers 5 epics and 28 stories.
+- TEA policy: advisory; NFR gate per epic.
+- 2 ADRs accepted in this gate review (ADR-008, ADR-009).
+
+## Open items (carry forward, not blockers)
+- Marketing site for launch — separate track, owned by …
+- Stripe-Atlas back-office decision — by date X.
+```
+
+## Anti-patterns
+
+- "Looks ready" without running the checklist.
+- Signing off before Hawkeye has risk-profiled.
+- Closing concerns without re-checking.
+- Leaving CI configuration "for later" — never gets done.
+
+## Hand-off
+
+> Implementation readiness signed off. Hill, kick `wize-sprint-planning`. Hawkeye, your gate cadence is set: design per story, trace + review + gate per story, NFR per epic.

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

@@ -0,0 +1,41 @@
+---
+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

@@ -0,0 +1,20 @@
+# 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

@@ -0,0 +1,95 @@
+# 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

@@ -0,0 +1,32 @@
+# 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

@@ -0,0 +1,126 @@
+# 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

@@ -0,0 +1,110 @@
+# 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

@@ -0,0 +1,129 @@
+# 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`.