@pennyfarthing/core 9.2.0 → 9.3.0

package/pennyfarthing-dist/workflows/quick-spec/steps/step-04-review.md

@@ -1,203 +0,0 @@
----
-name: 'step-04-review'
-description: 'Review and finalize the tech-spec'
-
-workflow_path: '{project_root}/_bmad/bmm/workflows/bmad-quick-flow/quick-spec'
-wipFile: '{implementation_artifacts}/tech-spec-wip.md'
----
-
-<purpose>
-Review the complete tech-spec with the user to ensure it meets the READY FOR DEVELOPMENT standard, handle feedback and modifications, finalize the spec with status 'ready-for-dev', rename the WIP file to final form using the slug, and guide the user to the next development phase.
-</purpose>
-
-<instructions>
-Load the WIP file and present the complete spec content with summary statistics, display review menu (Approve/Changes/Questions/Advanced Elicitation/Party Mode), handle user feedback by making requested edits and re-presenting sections, verify spec meets READY FOR DEVELOPMENT standard, finalize by updating frontmatter with status: 'ready-for-dev' and stepsCompleted: [1, 2, 3, 4], rename WIP file to tech-spec-{slug}.md, and present final menu for Advanced Elicitation/Adversarial Review/Begin Development/Done/Party Mode.
-</instructions>
-
-<output>
-WIP file finalized and renamed to tech-spec-{slug}.md with status: 'ready-for-dev' and stepsCompleted: [1, 2, 3, 4]. User reviewed and approved complete spec meeting READY FOR DEVELOPMENT standard. Final menu presented with next-step options and recommended fresh context command for development phase.
-</output>
-
-# Step 4: Review & Finalize
-
-**Progress: Step 4 of 4** - Final Step
-
-## RULES:
-
-- MUST NOT skip steps.
-- MUST NOT optimize sequence.
-- MUST follow exact instructions.
-- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
-
-## CONTEXT:
-
-- Requires `{wipFile}` from Step 3. 
-- MUST present COMPLETE spec content. Iterate until user is satisfied.
-- **Criteria**: The spec MUST meet the **READY FOR DEVELOPMENT** standard defined in `workflow.md`.
-
-## SEQUENCE OF INSTRUCTIONS
-
-### 1. Load and Present Complete Spec
-
-**Read `{wipFile}` completely and extract `slug` from frontmatter for later use.**
-
-**Present to user:**
-
-"Here's your complete tech-spec. Please review:"
-
-[Display the complete spec content - all sections]
-
-"**Quick Summary:**
-
-- {task_count} tasks to implement
-- {ac_count} acceptance criteria to verify
-- {files_count} files to modify"
-
-**Present review menu:**
-
-```
-[y] Approve - finalize the spec
-[c] Changes - request modifications
-[q] Questions - ask about any section
-[a] Advanced Elicitation - dig deeper before approving
-[p] Party Mode - get expert feedback before approving
-```
-
-**HALT and wait for user selection.**
-
-#### Menu Handling:
-
-- **[y]**: Proceed to Section 3 (Finalize the Spec)
-- **[c]**: Proceed to Section 2 (Handle Review Feedback), then return here and redisplay menu
-- **[q]**: Answer questions, then redisplay this menu
-- **[a]**: Load and execute `{advanced_elicitation}`, then return here and redisplay menu
-- **[p]**: Load and execute `{party_mode_exec}`, then return here and redisplay menu
-
-### 2. Handle Review Feedback
-
-a) **If user requests changes:**
-
-- Make the requested edits to `{wipFile}`
-- Re-present the affected sections
-- Ask if there are more changes
-- Loop until user is satisfied
-
-b) **If the spec does NOT meet the "Ready for Development" standard:**
-
-- Point out the missing/weak sections (e.g., non-actionable tasks, missing ACs).
-- Propose specific improvements to reach the standard.
-- Make the edits once the user agrees.
-
-c) **If user has questions:**
-
-- Answer questions about the spec
-- Clarify any confusing sections
-- Make clarifying edits if needed
-
-### 3. Finalize the Spec
-
-**When user confirms the spec is good AND it meets the "Ready for Development" standard:**
-
-a) Update `{wipFile}` frontmatter:
-
-   ```yaml
-   ---
-   # ... existing values ...
-   status: 'ready-for-dev'
-   stepsCompleted: [1, 2, 3, 4]
-   ---
-   ```
-
-b) **Rename WIP file to final filename:**
-   - Using the `slug` extracted in Section 1
-   - Rename `{wipFile}` → `{implementation_artifacts}/tech-spec-{slug}.md`
-   - Store this as `finalFile` for use in menus below
-
-### 4. Present Final Menu
-
-a) **Display completion message and menu:**
-
-```
-**Tech-Spec Complete!**
-
-Saved to: {finalFile}
-
----
-
-**Next Steps:**
-
-[a] Advanced Elicitation - refine further
-[r] Adversarial Review - critique of the spec (highly recommended)
-[b] Begin Development - start implementing now (not recommended)
-[d] Done - exit workflow
-[p] Party Mode - get expert feedback before dev
-
----
-
-Once you are fully satisfied with the spec (ideally after **Adversarial Review** and maybe a few rounds of **Advanced Elicitation**), it is recommended to run implementation in a FRESH CONTEXT for best results.
-
-Copy this prompt to start dev:
-
-\`\`\`
-quick-dev {finalFile}
-\`\`\`
-
-This ensures the dev agent has clean context focused solely on implementation.
-```
-
-b) **HALT and wait for user selection.**
-
-#### Menu Handling:
-
-- **[a]**: Load and execute `{advanced_elicitation}`, then return here and redisplay menu
-- **[b]**: Load and execute `{quick_dev_workflow}` with the final spec file (warn: fresh context is better)
-- **[d]**: Exit workflow - display final confirmation and path to spec
-- **[p]**: Load and execute `{party_mode_exec}`, then return here and redisplay menu
-- **[r]**: Execute Adversarial Review:
-    1. **Invoke Adversarial Review Task**:
-       > With `{finalFile}` constructed, invoke the review task. If possible, use information asymmetry: run this task, and only it, in a separate subagent or process with read access to the project, but no context except the `{finalFile}`.
-       <invoke-task>Review {finalFile} using {project_root}/_bmad/core/tasks/review-adversarial-general.xml</invoke-task>
-       > **Platform fallback:** If task invocation not available, load the task file and execute its instructions inline, passing `{finalFile}` as the content.
-       > The task should: review `{finalFile}` and return a list of findings.
-
-    2. **Process Findings**:
-       > Capture the findings from the task output.
-       > **If zero findings:** HALT - this is suspicious. Re-analyze or request user guidance.
-       > Evaluate severity (Critical, High, Medium, Low) and validity (real, noise, undecided).
-       > DO NOT exclude findings based on severity or validity unless explicitly asked to do so.
-       > Order findings by severity.
-       > Number the ordered findings (F1, F2, F3, etc.).
-       > If TodoWrite or similar tool is available, turn each finding into a TODO, include ID, severity, validity, and description in the TODO; otherwise present findings as a table with columns: ID, Severity, Validity, Description
-
-    3. Return here and redisplay menu.
-
-### 5. Exit Workflow
-
-**When user selects [d]:**
-
-"**All done!** Your tech-spec is ready at:
-
-`{finalFile}`
-
-When you're ready to implement, run:
-
-```
-quick-dev {finalFile}
-```
-
-Ship it!"
-
----
-
-## REQUIRED OUTPUTS:
-
-- MUST update status to 'ready-for-dev'.
-- MUST rename file to `tech-spec-{slug}.md`.
-- MUST provide clear next-step guidance and recommend fresh context for dev.
-
-## VERIFICATION CHECKLIST:
-
-- [ ] Complete spec presented for review.
-- [ ] Requested changes implemented.
-- [ ] Spec verified against **READY FOR DEVELOPMENT** standard.
-- [ ] `stepsCompleted: [1, 2, 3, 4]` set and file renamed.

package/pennyfarthing-dist/workflows/quick-spec/tech-spec-template.md

@@ -1,74 +0,0 @@
----
-title: '{title}'
-slug: '{slug}'
-created: '{date}'
-status: 'in-progress'
-stepsCompleted: []
-tech_stack: []
-files_to_modify: []
-code_patterns: []
-test_patterns: []
----
-
-# Tech-Spec: {title}
-
-**Created:** {date}
-
-## Overview
-
-### Problem Statement
-
-{problem_statement}
-
-### Solution
-
-{solution}
-
-### Scope
-
-**In Scope:**
-{in_scope}
-
-**Out of Scope:**
-{out_of_scope}
-
-## Context for Development
-
-### Codebase Patterns
-
-{codebase_patterns}
-
-### Files to Reference
-
-| File | Purpose |
-| ---- | ------- |
-
-{files_table}
-
-### Technical Decisions
-
-{technical_decisions}
-
-## Implementation Plan
-
-### Tasks
-
-{tasks}
-
-### Acceptance Criteria
-
-{acceptance_criteria}
-
-## Additional Context
-
-### Dependencies
-
-{dependencies}
-
-### Testing Strategy
-
-{testing_strategy}
-
-### Notes
-
-{notes}

package/pennyfarthing-dist/workflows/quick-spec/workflow.yaml

@@ -1,27 +0,0 @@
-# quick-spec Workflow - Migrated from BMAD format
-# Generated by migrate-bmad-workflow.mjs
-
-workflow:
-  name: quick-spec
-  description: Conversational spec engineering - ask questions, investigate code, produce implementation-ready tech-spec.
-  version: "1.0.0"
-  type: stepped
-
-  # Step configuration
-  steps:
-    path: ./steps/
-    pattern: step-*.md
-
-  # Variables available in step files
-  variables:
-    project_root: .
-    planning_artifacts: ./artifacts
-    output_file: artifacts/quick-spec.md
-
-  # Agent assignment (customize as needed)
-  agent: architect
-
-  # Triggers - when to suggest this workflow
-  triggers:
-    types: [quick-spec]
-    tags: [quick-spec, stepped]

package/pennyfarthing-dist/workflows/research/steps-domain/step-01-init.md

@@ -1,159 +0,0 @@
-# Domain Research Step 1: Domain Research Scope Confirmation
-
-<purpose>
-Confirm domain research scope and approach with the user to establish clear boundaries for comprehensive domain analysis including industry analysis, regulatory environment, technology patterns, economic factors, and supply chain considerations.
-</purpose>
-
-<instructions>
-1. Confirm understanding of user's domain research goals and topic
-2. Present the five key domain research focus areas (industry analysis, regulatory environment, technology patterns, economic factors, supply chain)
-3. Explain research approach with web search verification and source validation
-4. Present [C] continue option for user confirmation
-5. Document scope confirmation in research file only after user selects [C]
-6. Update frontmatter stepsCompleted to [1] before loading next step
-</instructions>
-
-<output>
-Document scope confirmation containing:
-- Research topic and goals confirmation
-- Five domain research focus areas clearly listed
-- Research methodology explanation (web verification, multi-source validation, confidence levels)
-- Scope confirmation documented in research file with date
-- Proper routing to step-02-domain-analysis.md
-</output>
-
-## MANDATORY EXECUTION RULES (READ FIRST):
-
-- 🛑 NEVER generate content without user confirmation
-
-- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
-- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
-- ✅ FOCUS EXCLUSIVELY on confirming domain research scope and approach
-- 📋 YOU ARE A DOMAIN RESEARCH PLANNER, not content generator
-- 💬 ACKNOWLEDGE and CONFIRM understanding of domain research goals
-- 🔍 This is SCOPE CONFIRMATION ONLY - no web research yet
-- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
-
-## EXECUTION PROTOCOLS:
-
-- 🎯 Show your analysis before taking any action
-- ⚠️ Present [C] continue option after scope confirmation
-- 💾 ONLY proceed when user chooses C (Continue)
-- 📖 Update frontmatter `stepsCompleted: [1]` before loading next step
-- 🚫 FORBIDDEN to load next step until C is selected
-
-## CONTEXT BOUNDARIES:
-
-- Research type = "domain" is already set
-- **Research topic = "{{research_topic}}"** - discovered from initial discussion
-- **Research goals = "{{research_goals}}"** - captured from initial discussion
-- Focus on industry/domain analysis with web research
-- Web search is required to verify and supplement your knowledge with current facts
-
-## YOUR TASK:
-
-Confirm domain research scope and approach for **{{research_topic}}** with the user's goals in mind.
-
-## DOMAIN SCOPE CONFIRMATION:
-
-### 1. Begin Scope Confirmation
-
-Start with domain scope understanding:
-"I understand you want to conduct **domain research** for **{{research_topic}}** with these goals: {{research_goals}}
-
-**Domain Research Scope:**
-
-- **Industry Analysis**: Industry structure, market dynamics, and competitive landscape
-- **Regulatory Environment**: Compliance requirements, regulations, and standards
-- **Technology Patterns**: Innovation trends, technology adoption, and digital transformation
-- **Economic Factors**: Market size, growth trends, and economic impact
-- **Supply Chain**: Value chain analysis and ecosystem relationships
-
-**Research Approach:**
-
-- All claims verified against current public sources
-- Multi-source validation for critical domain claims
-- Confidence levels for uncertain domain information
-- Comprehensive domain coverage with industry-specific insights
-
-### 2. Scope Confirmation
-
-Present clear scope confirmation:
-"**Domain Research Scope Confirmation:**
-
-For **{{research_topic}}**, I will research:
-
-✅ **Industry Analysis** - market structure, key players, competitive dynamics
-✅ **Regulatory Requirements** - compliance standards, legal frameworks
-✅ **Technology Trends** - innovation patterns, digital transformation
-✅ **Economic Factors** - market size, growth projections, economic impact
-✅ **Supply Chain Analysis** - value chain, ecosystem, partnerships
-
-**All claims verified against current public sources.**
-
-**Does this domain research scope and approach align with your goals?**
-[C] Continue - Begin domain research with this scope
-
-### 3. Handle Continue Selection
-
-#### If 'C' (Continue):
-
-- Document scope confirmation in research file
-- Update frontmatter: `stepsCompleted: [1]`
-- Load: `./step-02-domain-analysis.md`
-
-## APPEND TO DOCUMENT:
-
-When user selects 'C', append scope confirmation:
-
-```markdown
-## Domain Research Scope Confirmation
-
-**Research Topic:** {{research_topic}}
-**Research Goals:** {{research_goals}}
-
-**Domain Research Scope:**
-
-- Industry Analysis - market structure, competitive landscape
-- Regulatory Environment - compliance requirements, legal frameworks
-- Technology Trends - innovation patterns, digital transformation
-- Economic Factors - market size, growth projections
-- Supply Chain Analysis - value chain, ecosystem relationships
-
-**Research Methodology:**
-
-- All claims verified against current public sources
-- Multi-source validation for critical domain claims
-- Confidence level framework for uncertain information
-- Comprehensive domain coverage with industry-specific insights
-
-**Scope Confirmed:** {{date}}
-```
-
-## SUCCESS METRICS:
-
-✅ Domain research scope clearly confirmed with user
-✅ All domain analysis areas identified and explained
-✅ Research methodology emphasized
-✅ [C] continue option presented and handled correctly
-✅ Scope confirmation documented when user proceeds
-✅ Proper routing to next domain research step
-
-## FAILURE MODES:
-
-❌ Not clearly confirming domain research scope with user
-❌ Missing critical domain analysis areas
-❌ Not explaining that web search is required for current facts
-❌ Not presenting [C] continue option
-❌ Proceeding without user scope confirmation
-❌ Not routing to next domain research step
-
-❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
-❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
-❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
-
-## NEXT STEP:
-
-After user selects 'C', load `./step-02-domain-analysis.md` to begin industry analysis.
-
-Remember: This is SCOPE CONFIRMATION ONLY - no actual domain research yet, just confirming the research approach and scope!