@davidorex/pi-workflows 0.26.0 → 0.28.1

package/templates/analyzers/patterns.md

@@ -1,15 +0,0 @@
-{% extends "analyzers/base-analyzer.md" %}
-
-{% block identity %}You are a design pattern analyst.{% endblock %}
-
-{% block checklist %}
-1. **Design patterns**: What patterns are used? Are they applied correctly?
-2. **Idioms**: What language/framework idioms are followed or violated?
-3. **Conventions**: Naming, file organization, import style — are they consistent?
-4. **Anti-patterns**: Are there patterns that work against the codebase?
-5. **Recommendations**: What patterns would improve the codebase?
-{% endblock %}
-
-{% block constraints %}
-Focus on patterns and conventions, not raw quality or architecture. Be specific — cite examples.
-{% endblock %}

package/templates/analyzers/quality-task.md

@@ -1,11 +0,0 @@
-Analyze code quality at `{{ path }}`.
-
-{% if exploration.files is defined %}
-## Codebase
-{% for file in exploration.files %}
-- `{{ file.path }}` ({{ file.lines }} lines)
-{% endfor %}
-{% endif %}
-
-Assess test coverage, error handling, code smells, and maintainability.
-Write your analysis as JSON conforming to the output schema.

package/templates/analyzers/quality.md

@@ -1,15 +0,0 @@
-{% extends "analyzers/base-analyzer.md" %}
-
-{% block identity %}You are a code quality analyst.{% endblock %}
-
-{% block checklist %}
-1. **Test coverage**: What is tested? What isn't? Are tests meaningful?
-2. **Error handling**: How are errors handled? Are there gaps?
-3. **Code smells**: Duplicated logic, overly complex functions, magic numbers?
-4. **Documentation**: Is the code documented? Are the docs accurate?
-5. **Maintainability**: How easy would it be to modify this code?
-{% endblock %}
-
-{% block constraints %}
-Focus on quality concerns, not architecture or design patterns. Be specific — cite files and line ranges.
-{% endblock %}

package/templates/analyzers/structure-task.md

@@ -1,17 +0,0 @@
-Analyze the code at `{{ path }}`.
-
-{% if exploration.files is defined %}
-## Prior Exploration
-{% for file in exploration.files %}
-- `{{ file.path }}` ({{ file.lines }} lines){% if file.exports %}: {{ file.exports | length }} exports{% endif %}
-{% endfor %}
-{% endif %}
-
-{% if exploration.types is defined %}
-## Known Types
-{% for t in exploration.types %}
-- `{{ t.name }}` ({{ t.kind }}) in `{{ t.file }}`
-{% endfor %}
-{% endif %}
-
-Write your analysis as JSON conforming to the output schema.

package/templates/analyzers/structure.md

@@ -1,15 +0,0 @@
-{% extends "analyzers/base-analyzer.md" %}
-
-{% block identity %}You are a code structure analyst.{% endblock %}
-
-{% block checklist %}
-1. **Architecture**: How is the code organized? What patterns are used?
-2. **Module boundaries**: Are responsibilities clearly separated?
-3. **Dependencies**: What are the key dependency relationships?
-4. **Entry points**: How does execution flow through the code?
-5. **Configuration**: How is the system configured?
-{% endblock %}
-
-{% block constraints %}
-Focus on structural concerns, not code quality or patterns. Be specific — cite files and directories.
-{% endblock %}

package/templates/architecture-designer/task.md

@@ -1,117 +0,0 @@
-## Project Identity
-
-**Name:** {{ project.name }}
-**Description:** {{ project.description }}
-**Core Value:** {{ project.core_value }}
-{% if project.stack %}
-
-### Stack
-{% for item in project.stack %}
-- {{ item }}
-{% endfor %}
-{% endif %}
-
-### Constraints
-{% for constraint in project.constraints %}
-- [{{ constraint.type }}] {{ constraint.description }}
-{% endfor %}
-
-### Scope Boundaries
-
-**In scope:**
-{% for item in project.scope_boundaries.in %}
-- {{ item }}
-{% endfor %}
-
-**Out of scope:**
-{% for item in project.scope_boundaries.out %}
-- {{ item }}
-{% endfor %}
-
-## Requirements
-
-### Must
-{% for req in requirements.requirements %}
-{% if req.priority == "must" %}
-- **{{ req.id }}** [{{ req.type }}]: {{ req.description }}
-{% endif %}
-{% endfor %}
-
-### Should
-{% for req in requirements.requirements %}
-{% if req.priority == "should" %}
-- **{{ req.id }}** [{{ req.type }}]: {{ req.description }}
-{% endif %}
-{% endfor %}
-
-### Could
-{% for req in requirements.requirements %}
-{% if req.priority == "could" %}
-- **{{ req.id }}** [{{ req.type }}]: {{ req.description }}
-{% endif %}
-{% endfor %}
-
-## Instructions
-
-Design the initial architecture for this project. Produce modules, patterns, and boundaries that satisfy the requirements above — starting with "must" requirements and ensuring "should" requirements have a clear home.
-
-### For each module, provide:
-
-1. **name** — short identifier (e.g., "api", "auth", "storage", "cli")
-2. **file** — primary file path relative to project root (e.g., "src/api.ts")
-3. **responsibility** — one sentence: what this module owns and what it does not
-4. **dependencies** — array of other module names this depends on (empty if none)
-5. **lines** — estimated lines of code (rough order of magnitude)
-
-### For each pattern, provide:
-
-1. **name** — recognized pattern name (e.g., "Repository Pattern", "Event Sourcing", "Middleware Pipeline")
-2. **description** — why this pattern is appropriate for this project's specific needs
-3. **used_in** — array of module names that implement this pattern
-
-### For boundaries, provide:
-
-An array of strings — each describing a hard architectural constraint. These should be specific to this project, not generic ("All database access goes through the storage module", not "separate concerns").
-
-### Design principles
-
-- Module count should be proportional to requirements — a 5-requirement project needs 3-5 modules, not 15
-- Every "must" functional requirement should map to at least one module's responsibility
-- Every "must" non-functional requirement should be addressed by a pattern or boundary
-- Dependencies should flow in one direction — avoid circular module dependencies
-- If the project has a stated stack, modules should use file extensions and conventions matching that stack
-- Prefer explicit boundaries over implicit conventions
-
-### Overview
-
-Write an `overview` paragraph (required) summarizing:
-- The architectural style (layered, modular, pipeline, etc.)
-- The key structural decisions and why they fit this project
-- How the architecture supports the core_value
-
-### Output format
-
-Produce a single JSON object:
-
-```json
-{
-  "overview": "string (required)",
-  "modules": [
-    {
-      "name": "string (required)",
-      "file": "string (required)",
-      "responsibility": "string (required)",
-      "dependencies": ["string"],
-      "lines": 100
-    }
-  ],
-  "patterns": [
-    {
-      "name": "string (required)",
-      "description": "string (required)",
-      "used_in": ["module-name"]
-    }
-  ],
-  "boundaries": ["string"]
-}
-```

package/templates/architecture-inferrer/task.md

@@ -1,61 +0,0 @@
-Infer the architecture of the project at `{{ path }}`.
-
-## Codebase Analysis
-
-{% if exploration.files is defined %}
-### Files
-{% for file in exploration.files %}
-- `{{ file.path }}` ({{ file.language | default("unknown") }}, {{ file.lines | default("?") }} lines){% if file.exports %} — {{ file.exports | length }} exports{% endif %}
-{% endfor %}
-{% endif %}
-
-{% if exploration.types is defined %}
-### Types
-{% for t in exploration.types %}
-- `{{ t.name }}` ({{ t.kind }}) in `{{ t.file }}`
-{% endfor %}
-{% endif %}
-
-{% if exploration.dependencies is defined %}
-### Dependencies
-{% for d in exploration.dependencies %}
-- `{{ d.from }}` → `{{ d.to }}` ({{ d.type | default("import") }})
-{% endfor %}
-{% endif %}
-
-{% if exploration.entryPoints is defined %}
-### Entry Points
-{% for ep in exploration.entryPoints %}
-- `{{ ep }}`
-{% endfor %}
-{% endif %}
-
-## Instructions
-
-From the analysis above and targeted code reads, produce an architecture block:
-
-1. **Modules** — each cohesive unit with a clear responsibility. For each:
-   - `name`: concise identifier (e.g., "block-api", "expression-engine")
-   - `file`: primary file path relative to project root
-   - `responsibility`: one-sentence description of what this module does
-   - `dependencies`: array of other module names this module depends on
-   - `lines`: approximate line count
-
-2. **Patterns** — design patterns evidenced in the code. For each:
-   - `name`: pattern name (e.g., "registry", "factory", "middleware")
-   - `description`: how this pattern is applied in this codebase
-   - `used_in`: array of module names that use this pattern
-
-3. **Boundaries** — architectural seams where modules interact through defined interfaces (e.g., "block-api validates all writes before persistence", "dispatch spawns subprocesses through a single entry point")
-
-4. **Overview** — one paragraph summarizing the architecture: what the system does, how it's organized, and what the key design decisions are
-
-Read entry points, config files, and module interfaces to confirm the exploration. Do not read every file.
-
-## Required Output Schema
-
-You MUST produce JSON conforming exactly to this schema. Every required field must be present.
-
-```json
-{{ output_schema }}
-```

package/templates/audit-finding-verifier/task.md

@@ -1,59 +0,0 @@
-Verify whether the following audit findings have been resolved.
-
-## Audit Findings
-
-{% for finding in audit.findings %}
-### Finding: {{ finding.id }}
-
-**Description**: {{ finding.description }}
-**Severity**: {{ finding.severity | default("unspecified") }}
-**Category**: {{ finding.category | default("unspecified") }}
-**Principle**: {{ finding.principle | default("unspecified") }}
-
-**Locations**:
-{% for loc in finding.locations %}
-- `{{ loc.file }}` {% if loc.line %}line {{ loc.line }}{% endif %} {% if loc.description %} — {{ loc.description }}{% endif %}
-{% endfor %}
-
-{% if finding.fix %}
-**Fix suggestion**: {{ finding.fix.suggestion | default("none") }}
-{% endif %}
-
-{% if finding.resolution and finding.resolution.status == 'passed' %}
-*Previously marked as resolved — re-verify.*
-{% endif %}
----
-{% endfor %}
-
-## Implementation Results
-
-{% if implementation_results is iterable and implementation_results is not string %}
-{% for result in implementation_results %}
-- {{ result.spec_name | default(result.name | default("task")) }}: {{ result.status | default("unknown") }}
-{% endfor %}
-{% else %}
-```json
-{{ implementation_results | dump(2) }}
-```
-{% endif %}
-
-{% if conformance_reference %}
-## Conformance Reference
-
-```json
-{{ conformance_reference | dump(2) }}
-```
-{% endif %}
-
-## Instructions
-
-For EACH finding above:
-
-1. Read the code at the referenced location(s)
-2. Determine if the finding's described issue is addressed
-3. Record your verdict: `passed`, `failed`, or `needs_inspect`
-4. Provide specific evidence (code snippet, file:line reference)
-
-Do NOT use grep exit codes as evidence. Read the code and assess whether the issue described in the finding is genuinely resolved.
-
-Produce JSON output with a `findings` array containing one entry per finding, plus summary statistics.

package/templates/audit-fixer/task.md

@@ -1,67 +0,0 @@
-## Audit Findings to Fix
-
-### Principle: {{ task.principle }}
-### Category: {{ task.category }}
-### Severity: {{ task.severity }}
-
-### Findings
-
-{% for finding in task.findings %}
-#### {{ finding.id }}: {{ finding.description }}
-
-{% for loc in finding.locations %}
-- `{{ loc.file }}` lines {{ loc.lines | join(', ') }}
-{% endfor %}
-
-{% if finding.fix %}
-**Fix**: {{ finding.fix.suggestion }}
-{% if finding.fix.verify_method == "grep" %}
-**Verify**: pattern `{{ finding.fix.verify_pattern }}` should NOT match after fix
-{% endif %}
-{% endif %}
-
-{% endfor %}
-
-### Files to Modify
-
-{% for file in task.files %}
-- `{{ file }}`
-{% endfor %}
-
-### Acceptance Criteria
-
-{% for criterion in task.acceptance_criteria %}
-- {{ criterion }}
-{% endfor %}
-
-{% if conformance_reference %}
-### Conformance Reference
-
-{% for principle in conformance_reference.principles %}
-{% if principle.id == task.principle.split(':')[0] %}
-#### {{ principle.name }}
-
-{{ principle.description }}
-
-{% for rule in principle.rules %}
-- **{{ rule.id }}**: {{ rule.rule }}
-{% if rule.examples %}
-  - Correct: `{{ rule.examples[0] }}`
-{% endif %}
-{% if rule.anti_patterns %}
-  - Wrong: `{{ rule.anti_patterns[0] }}`
-{% endif %}
-{% endfor %}
-{% endif %}
-{% endfor %}
-{% endif %}
-
-## Instructions
-
-1. Read the files listed above to understand the current code
-2. Fix each finding according to the fix suggestion
-3. Ensure fixes follow the conformance reference principles
-4. Run the test suite: `node --experimental-strip-types --test src/*.test.ts`
-5. Fix any test failures caused by your changes
-
-Produce a JSON result conforming to the execution-results schema.

package/templates/audit-results-router/task.md

@@ -1,37 +0,0 @@
-Review the audit fix results and produce a routing manifest.
-
-## Implementation Results
-
-{% if implementation_results is iterable and implementation_results is not string %}
-{% for result in implementation_results %}
-### Task: {{ result.spec_name | default(result.name | default("unnamed")) }}
-
-- Status: {{ result.status | default("unknown") }}
-{% if result.decisions %}
-- Decisions: {{ result.decisions | length }}
-{% endif %}
-{% if result.issues %}
-- Issues flagged: {{ result.issues | length }}
-{% endif %}
-{% endfor %}
-{% else %}
-```json
-{{ implementation_results | dump(2) }}
-```
-{% endif %}
-
-## Verification Results
-
-```json
-{{ verification | dump(2) }}
-```
-
-## Instructions
-
-Produce a routing manifest with:
-
-1. **decisions** — validated decisions from implementation results (with complete id, description, rationale fields)
-2. **new_issues** — genuine issues that should be tracked (with stable id, description, status: "open", category, priority)
-3. **summary** — accurate summary of what was completed, what failed, what needs inspection
-
-Only include items that are well-formed and represent genuine project artifacts. Do not route items that are missing required fields or describe hypothetical concerns.

package/templates/decomposer/task.md

@@ -1,56 +0,0 @@
-## Decomposition Request
-
-**Gap:** {{ gap.id }} — {{ gap.description }}
-
-## Investigation Findings
-
-**Complexity:** {{ investigation.complexity }}
-**Summary:** {{ investigation.summary }}
-
-### Affected Files
-{% for f in investigation.affected_files %}
-- `{{ f.path }}` — {{ f.role }}: {{ f.current_behavior }}
-{% endfor %}
-
-### Constraints
-{% for c in investigation.constraints %}
-- {{ c }}
-{% endfor %}
-
-### Risks
-{% for r in investigation.risks %}
-- {{ r }}
-{% endfor %}
-
-{% if research %}
-## Research Findings
-
-### Patterns
-{% for p in research.patterns %}
-- **{{ p.name }}**: {{ p.description }} — {{ p.applicability }}
-{% endfor %}
-
-### Recommendations
-{% for r in research.recommendations %}
-- {{ r }}
-{% endfor %}
-{% endif %}
-
-## Instructions
-
-Decompose this gap into implementation specs. Each spec is a unit of work for a single implementing agent.
-
-1. Break the work into the smallest meaningful units
-2. Declare file targets for each spec
-3. Set `depends_on` for specs that must be sequential (shared files, interface dependencies)
-4. Mark `parallel_safe` for specs that can run concurrently
-5. Write acceptance criteria that are verifiable (grep patterns, test commands, not "it works")
-6. Estimate complexity per spec
-
-## Required Output Schema
-
-You MUST produce JSON conforming exactly to this schema. Every required field must be present.
-
-```json
-{{ output_schema }}
-```

package/templates/explorer/system.md

@@ -1,3 +0,0 @@
-You are a code explorer. Given a path, produce a comprehensive structural overview as JSON.
-
-Include files with their sizes, exports, imports, and line counts. Identify types, interfaces, and key functions. Map dependencies between files.

package/templates/explorer/task.md

@@ -1,9 +0,0 @@
-Explore the code at `{{ path }}`.
-
-Produce a JSON object with:
-- `files`: array of { path, type, language, lines, exports, imports }
-- `types`: array of { name, file, line, kind, definition }
-- `dependencies`: array of { from, to, type }
-- `entryPoints`: array of file paths that serve as entry points
-
-Write your findings as valid JSON.

package/templates/gap-identifier/task.md

@@ -1,103 +0,0 @@
-Identify gaps in the project at `{{ path }}`.
-
-## Architecture
-
-{% if architecture.overview %}
-{{ architecture.overview }}
-{% endif %}
-
-### Modules
-{% if architecture.modules is defined %}
-{% for m in architecture.modules %}
-- **{{ m.name }}** (`{{ m.file }}`{% if m.lines %}, {{ m.lines }} lines{% endif %}): {{ m.responsibility }}
-{% endfor %}
-{% endif %}
-
-{% if architecture.patterns is defined %}
-### Patterns
-{% for p in architecture.patterns %}
-- **{{ p.name }}**: {{ p.description }}{% if p.used_in %} — used in: {{ p.used_in | join(", ") }}{% endif %}
-{% endfor %}
-{% endif %}
-
-{% if architecture.boundaries is defined %}
-### Boundaries
-{% for b in architecture.boundaries %}
-- {{ b }}
-{% endfor %}
-{% endif %}
-
-## Codebase Analysis
-
-{% if exploration.files is defined %}
-### Files ({{ exploration.files | length }} total)
-{% for file in exploration.files %}
-- `{{ file.path }}` ({{ file.language | default("unknown") }}, {{ file.lines | default("?") }} lines){% if file.exports %} — {{ file.exports | length }} exports{% endif %}
-{% endfor %}
-{% endif %}
-
-{% if exploration.types is defined %}
-### Types
-{% for t in exploration.types %}
-- `{{ t.name }}` ({{ t.kind }}) in `{{ t.file }}`
-{% endfor %}
-{% endif %}
-
-## Instructions
-
-Cross-reference the architecture and analysis to identify gaps. Use targeted reads to verify findings.
-
-### Gap categories to check
-
-1. **missing** — functionality that should exist based on architecture but doesn't
-   - Test files for source modules (find test files, compare against source)
-   - Error handling for public APIs
-   - Documentation for exported interfaces
-   - Schema validation for user-facing inputs
-
-2. **incomplete** — partially implemented functionality
-   - TODO/FIXME/HACK comments (`grep -r "TODO\|FIXME\|HACK"`)
-   - Stub or placeholder implementations
-   - Functions that return hardcoded values or throw "not implemented"
-
-3. **defect** — likely bugs or incorrect behavior
-   - Uncaught promise rejections, missing null checks
-   - Type assertions that bypass safety (`as any`, `!` operator overuse)
-   - Error paths that swallow exceptions silently
-
-4. **technical-debt** — code that works but hampers maintenance
-   - Duplicated logic across modules
-   - Outdated patterns inconsistent with the rest of the codebase
-   - Overly complex functions (high cyclomatic complexity)
-
-5. **improvement** — opportunities to improve existing working code
-   - Performance bottlenecks
-   - Missing caching or memoization for expensive operations
-   - Public APIs that could be more ergonomic
-
-6. **question** — ambiguities requiring human or further investigation
-   - Unclear design decisions without documented rationale
-   - Behavior that could be intentional or accidental
-
-### Gap ID format
-
-Use the pattern: `gap-{abbrev}-{nnn}` where abbrev is:
-- `miss` for missing, `inc` for incomplete, `def` for defect
-- `debt` for technical-debt, `imp` for improvement, `q` for question
-
-### Priority calibration
-
-- **critical**: blocks further development or causes data loss
-- **high**: significant impact on reliability, correctness, or developer experience
-- **medium**: notable but workable; should be addressed in normal development
-- **low**: minor cleanup or cosmetic; address opportunistically
-
-Set `source` to `"agent"` for all gaps. Set `status` to `"open"` for all gaps.
-
-## Required Output Schema
-
-You MUST produce JSON conforming exactly to this schema. Every required field must be present.
-
-```json
-{{ output_schema }}
-```

package/templates/gap-resolution-assessor/task.md

@@ -1,48 +0,0 @@
-Assess whether the implementation resolves this gap.
-
-## Gap
-
-**ID**: {{ gap.id }}
-**Description**: {{ gap.description }}
-**Category**: {{ gap.category | default("unspecified") }}
-**Priority**: {{ gap.priority | default("unspecified") }}
-
-## Investigation Findings
-
-```json
-{{ investigation | dump(2) }}
-```
-
-## Implementation Results
-
-{% if implementation_results is iterable and implementation_results is not string %}
-{% for result in implementation_results %}
-### Spec: {{ result.spec_name | default("unnamed") }}
-- Status: {{ result.status | default("unknown") }}
-- Files changed: {{ result.files_changed | default([]) | join(", ") }}
-{% if result.commit_hash %}- Commit: {{ result.commit_hash }}{% endif %}
-{% endfor %}
-{% else %}
-```json
-{{ implementation_results | dump(2) }}
-```
-{% endif %}
-
-## Check Results
-
-- Status: {{ check_results.status }}
-{% if check_results.errors | length > 0 %}
-- Errors:
-{% for err in check_results.errors %}
-  - {{ err }}
-{% endfor %}
-{% endif %}
-
-## Instructions
-
-1. Read the gap description above. Understand what root cause it identifies.
-2. Examine the implementation results — what files were changed and what was the stated work.
-3. Run `git diff HEAD~{{ implementation_results | length | default(1) }}` (or appropriate range) to see actual code changes.
-4. Judge: do the code changes address the root cause described in the gap?
-5. If tests failed or lint errors exist, the gap is NOT resolved regardless of code quality.
-6. Produce your assessment as JSON.