@davidorex/pi-workflows 0.26.0 → 0.28.1

package/templates/shared/render-helpers.md

@@ -1,106 +0,0 @@
-{#-
-  Shared rendering helpers for per-item macros.
-
-  Captures repeated micro-patterns that previously lived inline in every
-  per-item macro file under `items/*.md`. The aim is one definition per
-  pattern, consumed by every per-item macro that uses it.
-
-  Helpers exported:
-    render_id_list_block(label, ids, depth)
-    render_id_single_block(label, id, depth)
-    render_id_list_inline(label, ids, depth)
-    render_id_single_inline(label, id, depth)
-    render_optional_scalar(label, value)
-
-  Output convention:
-    Block-style helpers emit `<Label>:\n` followed by `  - <id>\n` per entry
-    (or `  (none)\n` for present-but-empty arrays). Absent (undefined)
-    arrays emit nothing.
-
-    Inline-style helpers emit `  <Label>: <id>[, <id>...]\n` (or `(none)\n`
-    for empty). The two-space indent prefix is part of the inline shape used
-    by domain.related_requirements, requirements.traces_to/depends_on, and
-    tasks.depends_on/verification — it is the indent under a parent list
-    bullet, not arbitrary padding.
-
-  Depth contract:
-    Each helper that takes `depth` honours the same recursion budget as the
-    per-item macros: depth <= 0 emits bare ID text; depth > 0 calls resolve
-    + render_recursive (ambient Nunjucks globals registered by compileAgent
-    in @davidorex/pi-jit-agents) and falls back to bare-ID on resolve miss.
-    Cycles → `[cycle: <id>]` and missing per-item macros → `[unrendered:
-    <kind>/<id>]` are produced inside render_recursive itself, not here.
-
-  resolve(id) and render_recursive(loc, depth) are env-level globals
-  available to imported macros without re-import.
-
-  Empty-array convention:
-    `is defined` discriminates absent vs present. Present-but-empty arrays
-    render the label with `(none)`; absent fields render nothing. This
-    preserves the per-item macro contract documented in items/decisions.md
-    and mirrored across every per-item macro.
-
-  Output equivalence:
-    The helper bodies are byte-identical to the patterns they replace. The
-    existing render-*.test.ts assertions are the regression net. If a
-    helper drifts from the inline pattern's output, those tests break.
--#}
-
-{% macro render_id_list_block(label, ids, depth) %}{% if ids is defined %}{{ label }}:
-{% if ids | length > 0 %}{% for id in ids %}{% if depth > 0 %}{% set loc = resolve(id) %}{% if loc %}{{ render_recursive(loc, depth - 1) }}
-{% else %}  - {{ id }}
-{% endif %}{% else %}  - {{ id }}
-{% endif %}{% endfor %}{% else %}  (none)
-{% endif %}{% endif %}{% endmacro %}
-
-{% macro render_id_single_block(label, id, depth) %}{% if id is defined and id %}{{ label }}:
-{% if depth > 0 %}{% set loc = resolve(id) %}{% if loc %}{{ render_recursive(loc, depth - 1) }}
-{% else %}  - {{ id }}
-{% endif %}{% else %}  - {{ id }}
-{% endif %}{% endif %}{% endmacro %}
-
-{% macro render_id_list_inline(label, ids, depth) %}{% if ids is defined %}  {{ label }}: {% if ids | length > 0 %}{% for id in ids %}{% if depth > 0 %}{% set loc = resolve(id) %}{% if loc %}{{ render_recursive(loc, depth - 1) }}{% else %}{{ id }}{% endif %}{% else %}{{ id }}{% endif %}{% if not loop.last %}, {% endif %}{% endfor %}{% else %}(none){% endif %}
-{% endif %}{% endmacro %}
-
-{% macro render_id_single_inline(label, id, depth) %}{% if id %}  {{ label }}: {% if depth > 0 %}{% set loc = resolve(id) %}{% if loc %}{{ render_recursive(loc, depth - 1) }}{% else %}{{ id }}{% endif %}{% else %}{{ id }}{% endif %}
-{% endif %}{% endmacro %}
-
-{% macro render_optional_scalar(label, value) %}{% if value %}{{ label }}: {{ value }}
-{% endif %}{% endmacro %}
-
-{#-
-  Whole-block list scaffold (Plan 8 follow-up).
-
-  Centralises the truthy-guard + heading + per-item iteration shape that
-  previously repeated across the whole-block delegators in shared/macros.md
-  for `render_domain`, `render_tasks`, and `render_issues`. Each delegator
-  now reduces to one `{% call %}` block that supplies the per-item macro as
-  its body — the heading-and-loop chassis lives here once.
-
-  Two variants encode the two empty-handling regimes the legacy delegators
-  shipped, kept distinct so output stays byte-identical to the originals:
-
-    `render_whole_block_truthy(heading, items)`
-        Heading-and-loop fire whenever `items` is truthy (matches the
-        legacy `{% if data and data.<key> %}` guard used by tasks, issues,
-        domain). Empty arrays still emit the heading because `[]` is truthy
-        in Nunjucks — that surface is preserved deliberately.
-
-    `render_whole_block_nonempty(heading, items)`
-        Heading-and-loop fire only when `items | length > 0` (matches the
-        legacy `{% if data and data.requirements and data.requirements |
-        length > 0 %}` guard used by requirements). Empty arrays produce
-        nothing.
-
-  In both, the caller body (`{{ caller(item) }}`) is invoked once per item
-  with the item bound to the call-block parameter.
--#}
-{% macro render_whole_block_truthy(heading, items) %}{% if items %}
-## {{ heading }}
-{% for item in items %}{{ caller(item) }}{% endfor %}
-{% endif %}{% endmacro %}
-
-{% macro render_whole_block_nonempty(heading, items) %}{% if items and items | length > 0 %}
-## {{ heading }}
-{% for item in items %}{{ caller(item) }}{% endfor %}
-{% endif %}{% endmacro %}

package/templates/spec-implementer/task.md

@@ -1,53 +0,0 @@
-## Plan: {{ spec.name }}
-
-### Intent
-{{ spec.intent | default(spec.description, true) }}
-
-{% if spec.tasks %}
-### Tasks
-{% for task in spec.tasks %}
-{{ loop.index }}. {{ task }}
-{% endfor %}
-{% endif %}
-
-### Files to Change
-{% for f in spec.files_to_change | default(spec.files, true) %}
-- `{{ f }}`
-{% endfor %}
-
-### Acceptance Criteria
-{% for criterion in spec.acceptance_criteria %}
-- {{ criterion }}
-{% endfor %}
-
-{% if spec.context_needed %}
-### Context to Read First
-{% for ctx in spec.context_needed %}
-- `{{ ctx }}`
-{% endfor %}
-{% endif %}
-
-### Architecture Reference
-{% for module in architecture.modules %}
-- **{{ module.name }}** ({{ module.file }}): {{ module.responsibility }}
-{% endfor %}
-
-### Conventions
-{% for rule in conventions.rules %}
-- {{ rule.id }}: {{ rule.description }} ({{ rule.enforcement }})
-{% endfor %}
-
-## Instructions
-
-Implement this plan. Follow these steps:
-
-1. **Read context first**: Read the files listed under "Context to Read First" and any related source files to understand existing patterns
-2. **Implement each task**: Work through the task list in order, writing code that follows the project conventions
-3. **Run tests**: After implementation, run the relevant test suite to verify your changes work
-4. **Validate acceptance criteria**: Confirm each acceptance criterion is met
-
-Produce a JSON result conforming to this schema:
-
-```json
-{{ output_schema }}
-```

package/templates/synthesizer/system.md

@@ -1,3 +0,0 @@
-You are a report synthesizer. You receive typed analysis data from three independent reviewers (structure, quality, patterns) and produce a unified synthesis as structured JSON.
-
-Every finding must trace to specific data from the input analyses. Do not invent findings that aren't grounded in the input data.

package/templates/synthesizer/task.md

@@ -1,38 +0,0 @@
-Synthesize the following analyses into a unified report.
-
-## Structure Analysis
-Architecture: {{ structure.architecture.organization }}
-Patterns: {% for p in structure.architecture.patterns %}{{ p }}{% if not loop.last %}, {% endif %}{% endfor %}
-
-### Modules
-{% for m in structure.modules %}
-- **{{ m.name }}**: {{ m.responsibility }} ({{ m.files | length }} files)
-{% endfor %}
-
-### Dependencies
-{% for d in structure.dependencies %}
-- `{{ d.from }}` → `{{ d.to }}` ({{ d.type }})
-{% endfor %}
-
-## Quality Analysis
-{% for c in quality.concerns %}
-- [{{ c.severity }}] {{ c.description }}{% if c.file %} in `{{ c.file }}`{% endif %}
-{% endfor %}
-
-### Test Coverage
-- Tested: {% for t in quality.testCoverage.tested %}`{{ t }}`{% if not loop.last %}, {% endif %}{% endfor %}
-- Untested: {% for t in quality.testCoverage.untested %}`{{ t }}`{% if not loop.last %}, {% endif %}{% endfor %}
-
-### Maintainability: {{ quality.maintainability.score }}
-
-## Pattern Analysis
-{% for p in patterns.patterns %}
-- **{{ p.name }}**: {{ p.usage }}{% if not p.correct %} ⚠️{% endif %}
-{% endfor %}
-
-### Recommendations
-{% for r in patterns.recommendations %}
-- [{{ r.priority }}] **{{ r.pattern }}**: {{ r.suggestion }}
-{% endfor %}
-
-Write your synthesis as JSON conforming to the output schema.

package/templates/task-verifier/task.md

@@ -1,44 +0,0 @@
-Verify whether the following task implementation satisfies its acceptance criteria.
-
-## Task: {{ task_id }}
-
-## Acceptance Criteria
-
-{% for criterion in acceptance_criteria %}
-{{ loop.index }}. {{ criterion }}
-{% endfor %}
-
-## Implementation Changes
-
-{% if changes is mapping %}
-{% if changes.tasks is defined %}
-### Worker Results
-- Status: {{ changes.status | default("unknown") }}
-{% for t in changes.tasks %}
-- **{{ t.name }}**: {{ t.status }}{% if t.files_modified %} (files: {{ t.files_modified | join(", ") }}){% endif %}
-{% if t.notes %} — {{ t.notes }}{% endif %}
-{% endfor %}
-{% else %}
-```json
-{{ changes | dump(2) }}
-```
-{% endif %}
-{% else %}
-{{ changes }}
-{% endif %}
-
-## Instructions
-
-For EACH acceptance criterion above:
-
-1. Read the relevant source files to understand the current code state
-2. If the criterion is verifiable by command (test, build, lint), run the command
-3. If the criterion requires code inspection, read the files and assess
-4. Record your verdict: `passed`, `failed`, or `skipped`
-5. Provide specific evidence (file:line references, command output, code snippets)
-
-Then produce a JSON verification entry:
-
-```json
-{{ output_schema }}
-```

package/templates/task-worker/task.md

@@ -1,52 +0,0 @@
-## Task: {{ task.id }}
-
-### Description
-{{ task.description }}
-
-{% if task.phase %}
-### Phase
-{{ task.phase }}
-{% endif %}
-
-### Files
-{% for f in task.files %}
-- `{{ f }}`
-{% endfor %}
-
-### Acceptance Criteria
-{% for criterion in task.acceptance_criteria %}
-- [ ] {{ criterion }}
-{% endfor %}
-
-{% if task.depends_on %}
-### Dependencies (completed)
-{% for dep in task.depends_on %}
-- {{ dep }}
-{% endfor %}
-{% endif %}
-
-{% if task.notes %}
-### Notes
-{{ task.notes }}
-{% endif %}
-
-{% if context %}
-### Context
-{{ context }}
-{% endif %}
-
-## Instructions
-
-Implement this task. Follow these steps:
-
-1. **Read the target files** listed above to understand the current state
-2. **Implement changes** that satisfy each acceptance criterion
-3. **Stay within scope** — only modify the files listed, unless a new file is strictly necessary
-4. **Run tests** after implementation to verify nothing is broken
-5. **Validate each criterion** — confirm every acceptance criterion is addressed
-
-Produce a JSON result conforming to this schema:
-
-```json
-{{ output_schema }}
-```

package/templates/verifier/task.md

@@ -1,57 +0,0 @@
-You are verifying the output of a prior step against declared success criteria.
-
-## Success Criteria
-
-{% for criterion in criteria %}
-- {{ criterion }}
-{% endfor %}
-
-## Step Output to Verify
-
-```json
-{{ step_output | dump(2) }}
-```
-
-{% if files_to_check %}
-## Files to Check
-
-{% for f in files_to_check %}
-- `{{ f }}`
-{% endfor %}
-{% endif %}
-
-## Instructions
-
-For each criterion, choose the appropriate verification method and execute it:
-
-1. **command** — Run a shell command (test suite, build, lint) and report exit code + output as evidence
-2. **grep** — Search for specific patterns in files and report matches as evidence
-3. **inspect** — Read files and assess their content (use your judgment)
-4. **human** — Flag items that require human eyes and explain why automation cannot verify them
-
-### Process
-
-1. Evaluate each success criterion using the most appropriate verify method
-2. For `command` criteria: actually run the command and capture the output
-3. For `grep` criteria: search the relevant files and report what you find
-4. For `inspect` criteria: read the files and assess whether they meet the criterion
-5. For `human` criteria: describe what needs to be checked and why it needs a person
-6. Build truth claims from your observations, marking each as `verified`, `failed`, or `uncertain`
-7. Check that all referenced artifacts exist and are substantive (not stubs)
-8. Compute an overall score as "N/M" where N = passed criteria, M = total criteria
-9. Set status: `passed` if all criteria pass, `gaps_found` if any fail, `human_needed` if any require human review
-
-### Output Format
-
-Produce JSON conforming to the verifier-output schema with these fields:
-
-- `status`: "passed" | "gaps_found" | "human_needed"
-- `score`: "N/M" format
-- `truths[]`: observable claims with status and evidence
-- `criteria_results[]`: one entry per criterion with verify_method, status, expected/actual outcome, evidence
-- `artifacts[]`: (optional) file paths checked with existence/substance status
-- `requirements_coverage[]`: (optional) requirement satisfaction mapping
-- `human_verification[]`: (optional) items needing human review
-- `gaps[]`: (optional) failed or uncertain truths with reasons
-
-Be thorough. Run actual commands. Read actual files. Report what you observe, not what you assume.