@pennyfarthing/core 9.2.0 → 9.3.0

package/pennyfarthing-dist/workflows/quick-dev/steps/step-02-context-gathering.md

@@ -1,143 +0,0 @@
----
-name: 'step-02-context-gathering'
-description: 'Quick context gathering for direct mode - identify files, patterns, dependencies'
-
-workflow_path: '{project_root}/_bmad/bmm/workflows/bmad-quick-flow/quick-dev'
-thisStepFile: './step-02-context-gathering.md'
-nextStepFile: './step-03-execute.md'
----
-
-<purpose>
-Gather sufficient context for Mode B (direct instructions) to create a realistic mental plan of tasks. Identify affected files, detect existing code patterns, note dependencies, and create preliminary acceptance criteria based on the user's request.
-</purpose>
-
-<instructions>
-1. Search codebase to identify files relevant to the user's task description
-2. Examine those files to discover existing patterns, conventions, and error handling approaches
-3. Identify dependencies (libraries, modules, configs) that may be affected
-4. Synthesize gathered information into a mental plan with ordered tasks and inferred acceptance criteria
-5. Present the plan to the user for confirmation before proceeding to execution
-6. Accept user feedback (y/n/adjust) and continue or refine the plan accordingly
-</instructions>
-
-<output>
-- List of files to modify (with their purposes)
-- Key patterns identified in the codebase
-- Dependencies and related files that might be affected
-- Mental plan with ordered tasks
-- Inferred acceptance criteria from the user request
-- User confirmation to proceed (y/n/adjust)
-- Explicit NEXT directive to step-03-execute.md once confirmed
-</output>
-
-# Step 2: Context Gathering (Direct Mode)
-
-**Goal:** Quickly gather context for direct instructions - files, patterns, dependencies.
-
-**Note:** This step only runs for Mode B (direct instructions). If `{execution_mode}` is "tech-spec", this step was skipped.
-
----
-
-## AVAILABLE STATE
-
-From step-01:
-
-- `{baseline_commit}` - Git HEAD at workflow start
-- `{execution_mode}` - Should be "direct"
-- `{project_context}` - Loaded if exists
-
----
-
-## EXECUTION SEQUENCE
-
-### 1. Identify Files to Modify
-
-Based on user's direct instructions:
-
-- Search for relevant files using glob/grep
-- Identify the specific files that need changes
-- Note file locations and purposes
-
-### 2. Find Relevant Patterns
-
-Examine the identified files and their surroundings:
-
-- Code style and conventions used
-- Existing patterns for similar functionality
-- Import/export patterns
-- Error handling approaches
-- Test patterns (if tests exist nearby)
-
-### 3. Note Dependencies
-
-Identify:
-
-- External libraries used
-- Internal module dependencies
-- Configuration files that may need updates
-- Related files that might be affected
-
-### 4. Create Mental Plan
-
-Synthesize gathered context into:
-
-- List of tasks to complete
-- Acceptance criteria (inferred from user request)
-- Order of operations
-- Files to touch
-
----
-
-## PRESENT PLAN
-
-Display to user:
-
-```
-**Context Gathered:**
-
-**Files to modify:**
-- {list files}
-
-**Patterns identified:**
-- {key patterns}
-
-**Plan:**
-1. {task 1}
-2. {task 2}
-...
-
-**Inferred AC:**
-- {acceptance criteria}
-
-Ready to execute? (y/n/adjust)
-```
-
-- **y:** Proceed to execution
-- **n:** Gather more context or clarify
-- **adjust:** Modify the plan based on feedback
-
----
-
-## NEXT STEP DIRECTIVE
-
-**CRITICAL:** When user confirms ready, explicitly state:
-
-- **y:** "**NEXT:** Loading `step-03-execute.md`"
-- **n/adjust:** Continue gathering context, then re-present plan
-
----
-
-## SUCCESS METRICS
-
-- Files to modify identified
-- Relevant patterns documented
-- Dependencies noted
-- Mental plan created with tasks and AC
-- User confirmed readiness to proceed
-
-## FAILURE MODES
-
-- Executing this step when Mode A (tech-spec)
-- Proceeding without identifying files to modify
-- Not presenting plan for user confirmation
-- Missing obvious patterns in existing code

package/pennyfarthing-dist/workflows/quick-dev/steps/step-03-execute.md

@@ -1,138 +0,0 @@
----
-name: 'step-03-execute'
-description: 'Execute implementation - iterate through tasks, write code, run tests'
-
-workflow_path: '{project_root}/_bmad/bmm/workflows/bmad-quick-flow/quick-dev'
-thisStepFile: './step-03-execute.md'
-nextStepFile: './step-04-self-check.md'
----
-
-<purpose>
-Execute all planned tasks in sequence without pausing for approval between tasks. Write code following identified patterns, run tests to verify functionality, and only halt for blocking issues that require user guidance.
-</purpose>
-
-<instructions>
-1. For each task in the plan (from tech-spec or mental plan):
-   - Load relevant source files to understand context
-   - Implement changes following existing code patterns
-   - Write or update tests to verify the specific acceptance criteria for this task
-   - Mark task complete and move to the next task immediately
-2. Handle errors pragmatically: retry, look for patterns, test incrementally
-3. Only halt and request guidance if facing a blocking issue (3+ failures, ambiguous decision)
-4. Track all completed work for the next step (self-check)
-5. Once all tasks are complete (or blocked), proceed to step-04-self-check.md
-</instructions>
-
-<output>
-- Implemented code changes for all tasks
-- Tests written and passing for new/modified functionality
-- All existing tests still passing
-- List of completed tasks checked off
-- Any blocking issues documented with clear explanation
-- Ready to transition to self-check phase
-</output>
-
-# Step 3: Execute Implementation
-
-**Goal:** Implement all tasks, write tests, follow patterns, handle errors.
-
-**Critical:** Continue through ALL tasks without stopping for milestones.
-
----
-
-## AVAILABLE STATE
-
-From previous steps:
-
-- `{baseline_commit}` - Git HEAD at workflow start
-- `{execution_mode}` - "tech-spec" or "direct"
-- `{tech_spec_path}` - Tech-spec file (if Mode A)
-- `{project_context}` - Project patterns (if exists)
-
-From context:
-
-- Mode A: Tasks and AC extracted from tech-spec
-- Mode B: Tasks and AC from step-02 mental plan
-
----
-
-## EXECUTION LOOP
-
-For each task:
-
-### 1. Load Context
-
-- Read files relevant to this task
-- Review patterns from project-context or observed code
-- Understand dependencies
-
-### 2. Implement
-
-- Write code following existing patterns
-- Handle errors appropriately
-- Follow conventions observed in codebase
-- Add appropriate comments where non-obvious
-
-### 3. Test
-
-- Write tests if appropriate for the change
-- Run existing tests to catch regressions
-- Verify the specific AC for this task
-
-### 4. Mark Complete
-
-- Check off task: `- [x] Task N`
-- Continue to next task immediately
-
----
-
-## HALT CONDITIONS
-
-**HALT and request guidance if:**
-
-- 3 consecutive failures on same task
-- Tests fail and fix is not obvious
-- Blocking dependency discovered
-- Ambiguity that requires user decision
-
-**Do NOT halt for:**
-
-- Minor issues that can be noted and continued
-- Warnings that don't block functionality
-- Style preferences (follow existing patterns)
-
----
-
-## CONTINUOUS EXECUTION
-
-**Critical:** Do not stop between tasks for approval.
-
-- Execute all tasks in sequence
-- Only halt for blocking issues
-- Tests failing = fix before continuing
-- Track all completed work for self-check
-
----
-
-## NEXT STEP
-
-When ALL tasks are complete (or halted on blocker), load `step-04-self-check.md`.
-
----
-
-## SUCCESS METRICS
-
-- All tasks attempted
-- Code follows existing patterns
-- Error handling appropriate
-- Tests written where appropriate
-- Tests passing
-- No unnecessary halts
-
-## FAILURE MODES
-
-- Stopping for approval between tasks
-- Ignoring existing patterns
-- Not running tests after changes
-- Giving up after first failure
-- Not following project-context rules (if exists)

package/pennyfarthing-dist/workflows/quick-dev/steps/step-04-self-check.md

@@ -1,135 +0,0 @@
----
-name: 'step-04-self-check'
-description: 'Self-audit implementation against tasks, tests, AC, and patterns'
-
-workflow_path: '{project_root}/_bmad/bmm/workflows/bmad-quick-flow/quick-dev'
-thisStepFile: './step-04-self-check.md'
-nextStepFile: './step-05-adversarial-review.md'
----
-
-<purpose>
-Perform a comprehensive self-audit of the implementation before external review. Verify that all tasks are complete, tests pass, acceptance criteria are satisfied, and code follows project patterns. Update tech-spec status if in Mode A. Provide a clear summary for the adversarial review phase.
-</purpose>
-
-<instructions>
-1. Verify all tasks marked complete with no skipped work
-2. Run full test suite and confirm all tests passing
-3. For each acceptance criterion, verify it is demonstrably satisfied
-4. Review all modified code to ensure it follows existing patterns and project-context rules
-5. If Mode A (tech-spec): load tech-spec file, mark all tasks as [x], update status to "Implementation Complete", save
-6. Present implementation summary to transition to review phase
-7. Load step-05-adversarial-review.md to proceed
-</instructions>
-
-<output>
-- Verification checklist: Tasks ✓, Tests ✓, AC ✓, Patterns ✓
-- Test suite run results (all passing)
-- Tech-spec updated with completion status (Mode A only)
-- Implementation summary showing what was built, files modified, and test status
-- Transition message to adversarial review phase
-</output>
-
-# Step 4: Self-Check
-
-**Goal:** Audit completed work against tasks, tests, AC, and patterns before external review.
-
----
-
-## AVAILABLE STATE
-
-From previous steps:
-
-- `{baseline_commit}` - Git HEAD at workflow start
-- `{execution_mode}` - "tech-spec" or "direct"
-- `{tech_spec_path}` - Tech-spec file (if Mode A)
-- `{project_context}` - Project patterns (if exists)
-
----
-
-## SELF-CHECK AUDIT
-
-### 1. Tasks Complete
-
-Verify all tasks are marked complete:
-
-- [ ] All tasks from tech-spec or mental plan marked `[x]`
-- [ ] No tasks skipped without documented reason
-- [ ] Any blocked tasks have clear explanation
-
-### 2. Tests Passing
-
-Verify test status:
-
-- [ ] All existing tests still pass
-- [ ] New tests written for new functionality
-- [ ] No test warnings or skipped tests without reason
-
-### 3. Acceptance Criteria Satisfied
-
-For each AC:
-
-- [ ] AC is demonstrably met
-- [ ] Can explain how implementation satisfies AC
-- [ ] Edge cases considered
-
-### 4. Patterns Followed
-
-Verify code quality:
-
-- [ ] Follows existing code patterns in codebase
-- [ ] Follows project-context rules (if exists)
-- [ ] Error handling consistent with codebase
-- [ ] No obvious code smells introduced
-
----
-
-## UPDATE TECH-SPEC (Mode A only)
-
-If `{execution_mode}` is "tech-spec":
-
-1. Load `{tech_spec_path}`
-2. Mark all tasks as `[x]` complete
-3. Update status to "Implementation Complete"
-4. Save changes
-
----
-
-## IMPLEMENTATION SUMMARY
-
-Present summary to transition to review:
-
-```
-**Implementation Complete!**
-
-**Summary:** {what was implemented}
-**Files Modified:** {list of files}
-**Tests:** {test summary - passed/added/etc}
-**AC Status:** {all satisfied / issues noted}
-
-Proceeding to adversarial code review...
-```
-
----
-
-## NEXT STEP
-
-Proceed immediately to `step-05-adversarial-review.md`.
-
----
-
-## SUCCESS METRICS
-
-- All tasks verified complete
-- All tests passing
-- All AC satisfied
-- Patterns followed
-- Tech-spec updated (if Mode A)
-- Summary presented
-
-## FAILURE MODES
-
-- Claiming tasks complete when they're not
-- Not running tests before proceeding
-- Missing AC verification
-- Ignoring pattern violations
-- Not updating tech-spec status (Mode A)

package/pennyfarthing-dist/workflows/quick-dev/steps/step-05-adversarial-review.md

@@ -1,129 +0,0 @@
----
-name: 'step-05-adversarial-review'
-description: 'Construct diff and invoke adversarial review task'
-
-workflow_path: '{project_root}/_bmad/bmm/workflows/bmad-quick-flow/quick-dev'
-thisStepFile: './step-05-adversarial-review.md'
-nextStepFile: './step-06-resolve-findings.md'
----
-
-<purpose>
-Construct a complete diff of all changes made during the workflow and invoke an adversarial review to identify potential issues. The review should be skeptical and comprehensive, not confirmatory. Process findings into a structured list for the user to address.
-</purpose>
-
-<instructions>
-1. Construct diff from baseline_commit: if Git repo, use `git diff {baseline_commit}`; if no Git, list all modified files with their current state
-2. Include all untracked files created during this workflow (step 2-4 only)
-3. Invoke the adversarial review task with the complete diff as input
-4. Receive findings from the review task
-5. If zero findings found, halt and request guidance (this is suspicious)
-6. For each finding, evaluate severity (Critical/High/Medium/Low) and validity (real/noise/undecided)
-7. Order findings by severity, number them (F1, F2, etc.)
-8. Present findings as structured list (table or TODO format) to the user
-9. Load step-06-resolve-findings.md to let user choose resolution approach
-</instructions>
-
-<output>
-- Complete diff of all changes since baseline_commit
-- Adversarial review findings list with ID, severity, validity, and description
-- Ordered by severity (Critical → Low)
-- Ready for user to choose resolution approach (walk-through/auto-fix/skip)
-</output>
-
-# Step 5: Adversarial Code Review
-
-**Goal:** Construct diff of all changes, invoke adversarial review task, present findings.
-
----
-
-## AVAILABLE STATE
-
-From previous steps:
-
-- `{baseline_commit}` - Git HEAD at workflow start (CRITICAL for diff)
-- `{execution_mode}` - "tech-spec" or "direct"
-- `{tech_spec_path}` - Tech-spec file (if Mode A)
-
----
-
-### 1. Construct Diff
-
-Build complete diff of all changes since workflow started.
-
-### If `{baseline_commit}` is a Git commit hash:
-
-**Tracked File Changes:**
-
-```bash
-git diff {baseline_commit}
-```
-
-**New Untracked Files:**
-Only include untracked files that YOU created during this workflow (steps 2-4).
-Do not include pre-existing untracked files.
-For each new file created, include its full content as a "new file" addition.
-
-### If `{baseline_commit}` is "NO_GIT":
-
-Use best-effort diff construction:
-
-- List all files you modified during steps 2-4
-- For each file, show the changes you made (before/after if you recall, or just current state)
-- Include any new files you created with their full content
-- Note: This is less precise than Git diff but still enables meaningful review
-
-### Capture as {diff_output}
-
-Merge all changes into `{diff_output}`.
-
-**Note:** Do NOT `git add` anything - this is read-only inspection.
-
----
-
-### 2. Invoke Adversarial Review
-
-With `{diff_output}` constructed, invoke the review task. If possible, use information asymmetry: run this step, and only it, in a separate subagent or process with read access to the project, but no context except the `{diff_output}`.
-
-```xml
-<invoke-task>Review {diff_output} 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 `{diff_output}` as the content.
-
-The task should: review `{diff_output}` and return a list of findings.
-
----
-
-### 3. 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
-
----
-
-## NEXT STEP
-
-With findings in hand, load `step-06-resolve-findings.md` for user to choose resolution approach.
-
----
-
-## SUCCESS METRICS
-
-- Diff constructed from baseline_commit
-- New files included in diff
-- Task invoked with diff as input
-- Findings received
-- Findings processed into TODOs or table and presented to user
-
-## FAILURE MODES
-
-- Missing baseline_commit (can't construct accurate diff)
-- Not including new untracked files in diff
-- Invoking task without providing diff input
-- Accepting zero findings without questioning
-- Presenting fewer findings than the review task returned without explicit instruction to do so

package/pennyfarthing-dist/workflows/quick-dev/steps/step-06-resolve-findings.md

@@ -1,163 +0,0 @@
----
-name: 'step-06-resolve-findings'
-description: 'Handle review findings interactively, apply fixes, update tech-spec with final status'
-
-workflow_path: '{project_root}/_bmad/bmm/workflows/bmad-quick-flow/quick-dev'
-thisStepFile: './step-06-resolve-findings.md'
----
-
-<purpose>
-Present the user with three options for handling adversarial review findings: walk through each finding individually for discussion and decision, automatically fix items classified as "real", or skip all findings and proceed. Apply chosen approach, update tech-spec with final status, and provide completion summary.
-</purpose>
-
-<instructions>
-1. Present three resolution options to user: [1] Walk-through, [2] Auto-fix, [3] Skip
-2. Execute chosen option:
-   - Walk-through: For each finding, present context, ask fix/skip/discuss, apply fixes as requested
-   - Auto-fix: Filter to "real" findings, apply all fixes, report results
-   - Skip: Acknowledge findings were reviewed, note user chose to proceed without fixes
-3. If Mode A (tech-spec): Load tech-spec file, update status to "Completed", add review notes section with findings summary, save
-4. Present completion output explaining what was implemented at appropriate detail level
-5. Inform user the workflow is complete and ready to commit
-</instructions>
-
-<output>
-- Findings status (all addressed, auto-fixed with count, or skipped)
-- List of applied fixes (if applicable)
-- Tech-spec updated with completion status and review notes (Mode A only)
-- Final completion summary with what was implemented, files modified, tests status, findings summary
-- Clear next steps for user (commit changes, run more tests, or start new session)
-</output>
-
-# Step 6: Resolve Findings
-
-**Goal:** Handle adversarial review findings interactively, apply fixes, finalize tech-spec.
-
----
-
-## AVAILABLE STATE
-
-From previous steps:
-
-- `{baseline_commit}` - Git HEAD at workflow start
-- `{execution_mode}` - "tech-spec" or "direct"
-- `{tech_spec_path}` - Tech-spec file (if Mode A)
-- Findings table from step-05
-
----
-
-## RESOLUTION OPTIONS
-
-Present choice to user:
-
-```
-How would you like to handle these findings?
-
-**[1] Walk through** - Discuss each finding individually
-**[2] Auto-fix** - Automatically fix issues classified as "real"
-**[3] Skip** - Acknowledge and proceed to commit
-```
-
----
-
-## OPTION 1: WALK THROUGH
-
-For each finding in order:
-
-1. Present the finding with context
-2. Ask: **fix now / skip / discuss**
-3. If fix: Apply the fix immediately
-4. If skip: Note as acknowledged, continue
-5. If discuss: Provide more context, re-ask
-6. Move to next finding
-
-After all findings processed, summarize what was fixed/skipped.
-
----
-
-## OPTION 2: AUTO-FIX
-
-1. Filter findings to only those classified as "real"
-2. Apply fixes for each real finding
-3. Report what was fixed:
-
-```
-**Auto-fix Applied:**
-- F1: {description of fix}
-- F3: {description of fix}
-...
-
-Skipped (noise/uncertain): F2, F4
-```
-
----
-
-## OPTION 3: SKIP
-
-1. Acknowledge all findings were reviewed
-2. Note that user chose to proceed without fixes
-3. Continue to completion
-
----
-
-## UPDATE TECH-SPEC (Mode A only)
-
-If `{execution_mode}` is "tech-spec":
-
-1. Load `{tech_spec_path}`
-2. Update status to "Completed"
-3. Add review notes:
-   ```
-   ## Review Notes
-   - Adversarial review completed
-   - Findings: {count} total, {fixed} fixed, {skipped} skipped
-   - Resolution approach: {walk-through/auto-fix/skip}
-   ```
-4. Save changes
-
----
-
-## COMPLETION OUTPUT
-
-```
-**Review complete. Ready to commit.**
-
-**Implementation Summary:**
-- {what was implemented}
-- Files modified: {count}
-- Tests: {status}
-- Review findings: {X} addressed, {Y} skipped
-
-{Explain what was implemented based on user_skill_level}
-```
-
----
-
-## WORKFLOW COMPLETE
-
-This is the final step. The Quick Dev workflow is now complete.
-
-User can:
-
-- Commit changes
-- Run additional tests
-- Start new Quick Dev session
-
----
-
-## SUCCESS METRICS
-
-- User presented with resolution options
-- Chosen approach executed correctly
-- Fixes applied cleanly (if applicable)
-- Tech-spec updated with final status (Mode A)
-- Completion summary provided
-- User understands what was implemented
-
-## FAILURE MODES
-
-- Not presenting resolution options
-- Auto-fixing "noise" or "uncertain" findings
-- Not updating tech-spec after resolution (Mode A)
-- No completion summary
-- Leaving user unclear on next steps