@pennyfarthing/core 9.2.0 → 9.3.0

package/pennyfarthing-dist/workflows/agent-docs.yaml

@@ -1,70 +0,0 @@
-# Agent Documentation Workflow
-# For agent file creation, updates, and improvements
-#
-# Flow: Orchestrator → Tech Writer → SM
-# Use for: Agent file updates, process improvements, skill maintenance
-
-workflow:
-  name: agent-docs
-  description: Agent file and process documentation updates
-  version: "1.0.0"
-
-  phases:
-    - name: setup
-      agent: sm
-      output: [session_file, story_context]
-      note: SM sets up the story but immediately hands off to Orchestrator
-
-    - name: analyze
-      agent: orchestrator
-      input: [session_file, story_context]
-      output: [audit_report, proposed_changes]
-      gate:
-        type: manual
-        condition: Changes identified and documented
-
-    - name: impl
-      agent: orchestrator
-      input: [audit_report, proposed_changes]
-      output: [updated_files]
-      gate:
-        type: validation
-        condition: Agent files parse correctly, no broken references
-
-    - name: review
-      agent: tech-writer
-      input: [updated_files]
-      output: [approval]
-      gate:
-        type: approval
-        condition: |
-          Documentation quality review:
-          - Clear and consistent structure
-          - No stale references
-          - Follows agent file conventions
-          - XML tags properly nested
-          - Examples are accurate
-
-    - name: finish
-      agent: sm
-      input: [approval]
-      output: [archived_session, story_summary]
-
-  triggers:
-    types: [docs, refactor, infrastructure]
-    labels: [agent-file, process-improvement, skill-update]
-    repos: [pennyfarthing]
-
-  notes: |
-    This workflow is for meta-work on the Pennyfarthing system itself:
-    - Updating agent definitions (.pennyfarthing/agents/*.md)
-    - Creating or updating skills (.claude/skills/*/skill.md)
-    - Process improvements and workflow refinements
-    - Agent coordination documentation
-
-    Tech Writer reviews for documentation quality, not code correctness.
-    Focus areas:
-    - Consistent XML tag usage across agents
-    - Clear handoff protocols
-    - Accurate subagent references
-    - No hardcoded theme/character names

package/pennyfarthing-dist/workflows/architecture/steps/step-01-initialize.md

@@ -1,113 +0,0 @@
-# Step 1: Initialize Architecture Session
-
-<purpose>
-Set up the architecture decision session by gathering inputs, detecting existing workflows, and establishing initial context for collaborative architectural discovery.
-</purpose>
-
-<instructions>
-Check for existing workflow and either resume from continuation or initialize fresh session. Gather required inputs (PRD, existing documentation, constraints), identify stakeholders, and present collaboration options to proceed.
-</instructions>
-
-<output>
-Session workspace initialized with frontmatter and either workflow continuation state or fresh initialization summary including discovered inputs, stakeholders, and ready-to-continue status.
-</output>
-
-<step-meta>
-number: 1
-name: initialize
-gate: false
-</step-meta>
-
-## Mandatory Execution Rules
-
-- READ the complete step file before taking any action
-- DETECT existing workflow state before initialization
-- NEVER generate content without user input
-- ALWAYS treat this as collaborative discovery between architectural peers
-- FOCUS on initialization only - don't look ahead to future steps
-
-## Execution Protocols
-
-- Show your analysis before taking any action
-- Initialize document and update frontmatter
-- Set up frontmatter `stepsCompleted: [1]` before loading next step
-- FORBIDDEN to load next step until setup is complete
-
-## Purpose
-
-Set up the architecture decision session by gathering inputs and establishing context.
-
-## Continuation Detection
-
-**First, check for existing workflow:**
-
-1. Look for existing `{output_file}`
-2. If exists, read complete file including frontmatter
-3. If frontmatter has `stepsCompleted` array → **Load `./step-01b-continue.md`**
-4. If not exists → proceed with fresh initialization below
-
-## Instructions
-
-1. **Verify required inputs exist**:
-   - Product Requirements Document (PRD) or feature brief
-   - Any existing architecture documentation
-   - Relevant ADRs from `docs/adr/`
-
-2. **Create session workspace**:
-   - Output file: `{output_file}`
-   - Working notes in session file
-
-3. **Identify stakeholders and constraints**:
-   - Who needs to approve this decision?
-   - What are the timeline constraints?
-   - Are there budget or resource limitations?
-
-## Actions
-
-- Check: `{output_file}` for existing workflow (continuation detection)
-- Read: `{planning_artifacts}/*prd*.md` or `{planning_artifacts}/*brief*.md`
-- Read: `docs/adr/*.md` (scan for relevant prior decisions)
-- Read: Existing architecture docs if referenced
-
-## Output
-
-Add to session file:
-
-```markdown
-## Architecture Session: {project_name}
-
-### Inputs Gathered
-- PRD: [path or "not found"]
-- Existing ADRs: [list relevant ones]
-- Constraints: [timeline, budget, resources]
-
-### Stakeholders
-- Decision maker: [name/role]
-- Reviewers: [list]
-```
-
-## Collaboration Menu
-
-After completing initialization, present options:
-
-- **[C] Continue** - Inputs gathered, proceed to Context Analysis
-- **[A] Advanced Elicitation** - Use discovery protocols to find additional context
-- **[R] Revise** - Need to locate missing inputs before proceeding
-
-## Success Metrics
-
-- Existing workflow detected and handed off to step-01b correctly
-- Fresh workflow initialized with proper setup
-- Input documents discovered and loaded
-- PRD requirement validated and communicated
-- User confirmed document setup before proceeding
-
-## Failure Modes
-
-- Proceeding with fresh initialization when existing workflow exists
-- Not detecting PRD requirement
-- Not confirming inputs with user before proceeding
-
-## Next Step
-
-After user selects [C], proceed to Context Analysis to understand the technical landscape.

package/pennyfarthing-dist/workflows/architecture/steps/step-01b-continue.md

@@ -1,105 +0,0 @@
-# Step 1b: Workflow Continuation Handler
-
-<purpose>
-Detect existing architecture workflow state from session file and provide user with options to continue, restart, or review previous progress before proceeding.
-</purpose>
-
-<instructions>
-Read the existing output file and parse frontmatter to identify completed steps and current progress. Analyze the document state, summarize decisions made so far, and present continuation options with data loss prevention (archiving).
-</instructions>
-
-<output>
-Workflow continuation information displayed with summary of completed steps, current document state, and user-selectable options (Continue/Restart/View) with archive confirmation if restarting.
-</output>
-
-<step-meta>
-number: 1b
-name: continue
-gate: false
-</step-meta>
-
-## Mandatory Execution Rules
-
-- DETECT existing workflow state from output document frontmatter
-- READ complete document to understand current progress
-- PRESENT continuation options to user before proceeding
-- NEVER proceed without user confirmation
-
-## Purpose
-
-Handle workflow resumption when an existing architecture document is detected. This step is invoked automatically when step 1 finds an existing document with `stepsCompleted` in frontmatter.
-
-## Detection Trigger
-
-Step 1 redirects here when:
-1. Output file `{output_file}` already exists
-2. Document has frontmatter with `stepsCompleted` array
-3. Workflow was previously started but not completed
-
-## Instructions
-
-1. **Read Existing State**:
-   - Parse frontmatter for `stepsCompleted` array
-   - Identify last completed step
-   - Load document content to understand current progress
-
-2. **Analyze Progress**:
-   - Which steps are complete?
-   - What decisions have been made?
-   - Are there any inconsistencies?
-
-3. **Present Continuation Options**:
-   Based on current state, offer user choices:
-
-## Actions
-
-- Read: `{output_file}` completely (including frontmatter)
-- Parse: `stepsCompleted` from frontmatter
-- Analyze: Current document state
-
-## Output
-
-Present to user:
-
-```markdown
-## Workflow Continuation
-
-**Document found:** {output_file}
-**Steps completed:** {stepsCompleted}
-**Last step:** {last_step_name}
-
-### Current Document State
-{summary of what's been decided so far}
-
-### Continuation Options
-
-- **[C] Continue** - Resume from step {next_step}
-- **[R] Restart** - Start fresh (will archive existing document)
-- **[V] View** - Show complete document before deciding
-```
-
-## Continuation Flow
-
-After user selects [C]:
-1. Load the next incomplete step file
-2. Resume workflow from that point
-3. Continue normal step progression
-
-After user selects [R]:
-1. Archive existing document to `{output_file}.backup-{timestamp}`
-2. Return to step 1 for fresh initialization
-3. Proceed with new workflow
-
-## Success Metrics
-
-- Existing workflow detected and state loaded correctly
-- User informed of current progress
-- Continuation or restart handled smoothly
-- No data loss (archive before restart)
-
-## Failure Modes
-
-- Proceeding without user confirmation
-- Not loading complete existing document
-- Losing work by overwriting without archive
-- Misreading stepsCompleted array

package/pennyfarthing-dist/workflows/architecture/steps/step-02-context.md

@@ -1,127 +0,0 @@
-# Step 2: Context Analysis
-
-<purpose>
-Analyze project context and requirements to identify technical constraints, current system landscape, and key architectural concerns that will drive pattern selection and design decisions.
-</purpose>
-
-<instructions>
-Extract technical constraints from PRD (performance, security, integration requirements). Map existing systems and patterns. Identify scalability, reliability, maintainability, and cost concerns. Generate analysis and present A/P/C collaboration menu for refinement.
-</instructions>
-
-<output>
-Architecture Context section in session file with Technical Constraints, Current Landscape overview, and Key Concerns documented. Update frontmatter stepsCompleted array after user confirms [C].
-</output>
-
-<step-meta>
-number: 2
-name: context-analysis
-gate: true
-</step-meta>
-
-## Mandatory Execution Rules
-
-- READ the complete step file before taking any action
-- ANALYZE loaded documents, don't assume or generate requirements
-- ALWAYS treat this as collaborative discovery between architectural peers
-- FOCUS on understanding project scope and requirements for architecture
-
-## Execution Protocols
-
-- Show your analysis before taking any action
-- Present A/P/C menu after generating context analysis
-- ONLY save when user chooses [C] Continue
-- Update frontmatter `stepsCompleted: [1, 2]` before loading next step
-- FORBIDDEN to load next step until [C] is selected
-
-## Purpose
-
-Analyze the project context and identify architectural concerns that will shape the decision.
-
-## Instructions
-
-1. **Extract Technical Constraints** from the PRD:
-   - Performance requirements (latency, throughput, scale)
-   - Security and compliance requirements
-   - Integration requirements with existing systems
-   - Technology mandates or restrictions
-
-2. **Map the Current Landscape**:
-   - What systems already exist?
-   - What are the integration points?
-   - What patterns are already in use?
-
-3. **Identify Key Concerns**:
-   - Scalability needs
-   - Reliability requirements
-   - Maintainability considerations
-   - Cost constraints
-
-## Actions
-
-- Read: `{planning_artifacts}/*prd*.md`
-- Read: `**/project-context.md` (if exists)
-- Grep: Search codebase for existing patterns
-
-## Output
-
-Add to session file:
-
-```markdown
-## Architecture Context
-
-### Technical Constraints
-- Performance: [requirements from PRD]
-- Security: [requirements]
-- Integration: [required touchpoints]
-
-### Current Landscape
-- Existing systems: [list]
-- Patterns in use: [list]
-- Tech stack: [languages, frameworks]
-
-### Key Concerns
-1. [Concern]: [Why it matters]
-2. [Concern]: [Why it matters]
-```
-
-<!-- GATE -->
-
-## Collaboration Menu (A/P/C)
-
-After generating context analysis, present choices:
-
-- **[A] Advanced Elicitation** - Use discovery protocols to develop deeper insights about project context and architectural implications
-- **[P] Party Mode** - Bring multiple perspectives to analyze project requirements from different architectural angles
-- **[C] Continue** - Save the content to the document and proceed to pattern selection
-- **[R] Revise** - Need to gather more information or clarify constraints
-
-## Advanced Elicitation Mode
-
-When user selects [A]:
-1. Ask probing questions about non-obvious constraints
-2. Explore edge cases and failure scenarios
-3. Identify implicit assumptions in requirements
-4. Dig deeper into integration complexity
-
-## Party Mode
-
-When user selects [P]:
-1. Present analysis from multiple viewpoints:
-   - **Security architect**: What could go wrong?
-   - **Performance engineer**: Where are the bottlenecks?
-   - **Operations**: How will this run in production?
-   - **Developer experience**: How maintainable is this?
-2. Synthesize perspectives into unified understanding
-
-## Success Metrics
-
-- Technical constraints extracted from PRD
-- Current landscape mapped accurately
-- Key concerns identified with rationale
-- User confirmed context before proceeding
-
-## Failure Modes
-
-- Generating requirements not found in documents
-- Proceeding without user confirmation
-- Missing critical constraints from PRD

package/pennyfarthing-dist/workflows/architecture/steps/step-03-patterns.md

@@ -1,145 +0,0 @@
-# Step 3: Pattern Selection
-
-<purpose>
-Identify and evaluate architectural patterns that address identified concerns with verification of current technology versions, trade-off analysis, and selection of patterns that best fit the project requirements.
-</purpose>
-
-<instructions>
-Survey applicable patterns (microservices, event-driven, CQRS, circuit breakers, etc.) based on context concerns. Search web for current stable versions and best practices. Evaluate trade-offs (complexity, team familiarity, overhead, system fit). Select 1-3 primary patterns with rationale.
-</instructions>
-
-<output>
-Pattern Analysis section with Technology Versions table, Candidate Patterns comparison, Selected Pattern(s) with justification, and Rejected Alternatives. Update frontmatter stepsCompleted array after user confirms [C].
-</output>
-
-<step-meta>
-number: 3
-name: pattern-selection
-gate: false
-</step-meta>
-
-## Mandatory Execution Rules
-
-- READ the complete step file before taking any action
-- SEARCH the web to verify current technology versions - NEVER trust hardcoded versions
-- ALWAYS treat this as collaborative discovery between architectural peers
-- FOCUS on evaluating patterns with up-to-date information
-
-## Execution Protocols
-
-- Show your analysis before taking any action
-- Search the web to verify current versions and options
-- Present A/P/C menu after generating pattern analysis
-- ONLY save when user chooses [C] Continue
-- Update frontmatter `stepsCompleted: [1, 2, 3]` before loading next step
-- FORBIDDEN to load next step until [C] is selected
-
-## Purpose
-
-Identify and evaluate architectural patterns that could address the identified concerns, with current technology verification.
-
-## Instructions
-
-1. **Survey Applicable Patterns**:
-   Based on the context analysis, identify patterns that address the key concerns:
-   - For scalability: microservices, event-driven, CQRS
-   - For reliability: circuit breakers, bulkheads, retries
-   - For maintainability: clean architecture, hexagonal, modular monolith
-   - For integration: API gateway, message broker, service mesh
-
-2. **Verify Current Versions** (web search):
-   For any frameworks or technologies being considered:
-   - What is the current stable version?
-   - What are the recommended starter templates?
-   - Are there breaking changes in recent releases?
-
-3. **Evaluate Trade-offs**:
-   For each candidate pattern, consider:
-   - Complexity cost vs. benefit
-   - Team familiarity
-   - Operational overhead
-   - Fit with existing systems
-
-4. **Select Primary Pattern(s)**:
-   Choose 1-3 patterns that best address the requirements.
-
-## Actions
-
-- Review: Architecture pattern references
-- Search: Web for current framework versions and best practices
-- Compare: Pattern fit against constraints from Step 2
-- Document: Trade-off analysis
-
-## Output
-
-Add to session file:
-
-```markdown
-## Pattern Analysis
-
-### Technology Versions (as of {date})
-| Technology | Current Version | Notes |
-|------------|-----------------|-------|
-| [Tech 1] | [version] | [stability, LTS status] |
-| [Tech 2] | [version] | [stability, LTS status] |
-
-### Candidate Patterns
-
-| Pattern | Addresses | Trade-offs | Fit Score |
-|---------|-----------|------------|-----------|
-| [Pattern 1] | [concerns] | [pros/cons] | [1-5] |
-| [Pattern 2] | [concerns] | [pros/cons] | [1-5] |
-| [Pattern 3] | [concerns] | [pros/cons] | [1-5] |
-
-### Selected Pattern(s)
-1. **[Primary pattern]**: [Why this fits best]
-2. **[Secondary pattern]** (if needed): [Why]
-
-### Rejected Alternatives
-- [Pattern]: [Why not suitable]
-```
-
-## Collaboration Menu (A/P/C)
-
-After generating pattern analysis, present choices:
-
-- **[A] Advanced Elicitation** - Use discovery protocols to explore unconventional patterns or custom approaches
-- **[P] Party Mode** - Bring multiple perspectives to evaluate pattern trade-offs for different use cases
-- **[C] Continue** - Save the content and proceed to component design
-- **[R] Revise** - Need to reconsider patterns or gather more information
-
-## Advanced Elicitation Mode
-
-When user selects [A]:
-1. Explore hybrid patterns combining multiple approaches
-2. Investigate emerging patterns not yet mainstream
-3. Consider domain-specific architectural patterns
-4. Question assumptions about pattern applicability
-
-## Party Mode
-
-When user selects [P]:
-1. Present pattern evaluation from multiple viewpoints:
-   - **Pragmatist**: What's the simplest thing that works?
-   - **Futurist**: What if requirements change significantly?
-   - **Skeptic**: What could go wrong with this pattern?
-   - **Operator**: How will this pattern affect day-to-day operations?
-2. Synthesize perspectives into pattern recommendation
-
-## Success Metrics
-
-- Patterns evaluated against context constraints
-- Current technology versions verified via web search
-- Trade-offs clearly documented
-- User confirmed pattern selection before proceeding
-
-## Failure Modes
-
-- Using outdated technology versions
-- Not considering team familiarity
-- Selecting overly complex patterns for simple problems
-- Proceeding without user confirmation
-
-## Next Step
-
-After user selects [C], proceed to Component Design to define the system structure.