@davidorex/pi-workflows 0.14.6 → 0.28.0

package/package.json

@@ -1,6 +1,9 @@
 {
 	"name": "@davidorex/pi-workflows",
-	"version": "0.14.6",
+	"version": "0.28.0",
+	"publishConfig": {
+		"access": "public"
+	},
 	"description": "Workflow orchestration extension for Pi",
 	"license": "MIT",
 	"author": "David Ryan",
@@ -36,6 +39,10 @@
 		"./types": {
 			"types": "./dist/types.d.ts",
 			"default": "./dist/types.js"
+		},
+		"./auth-required": {
+			"types": "./dist/auth-required.d.ts",
+			"default": "./dist/auth-required.js"
 		}
 	},
 	"pi": {
@@ -52,24 +59,27 @@
 		"agents/",
 		"schemas/",
 		"workflows/",
-		"templates/",
 		"*.md"
 	],
 	"scripts": {
 		"clean": "rm -rf dist",
-		"build": "tsc -p tsconfig.build.json",
+		"build": "rm -rf dist && tsc -p tsconfig.build.json",
 		"prepublishOnly": "npm run clean && npm run build",
 		"test": "tsx --test src/*.test.ts"
 	},
 	"dependencies": {
 		"nunjucks": "^3.2.4",
 		"yaml": "^2.7.1",
-		"@davidorex/pi-project": "^0.14.6",
-		"@mariozechner/pi-ai": "^0.70.2",
-		"@mariozechner/pi-coding-agent": "^0.70.2",
-		"@mariozechner/pi-tui": "^0.70.2"
+		"@davidorex/pi-jit-agents": "^0.28.0",
+		"@davidorex/pi-context": "^0.28.0",
+		"@earendil-works/pi-ai": "^0.75.4",
+		"@earendil-works/pi-coding-agent": "^0.75.4",
+		"@earendil-works/pi-tui": "^0.75.4"
 	},
 	"devDependencies": {
 		"@types/nunjucks": "^3.2.6"
+	},
+	"engines": {
+		"node": ">=22.19.0"
 	}
 }

package/skill-narrative.md

@@ -28,7 +28,9 @@ Workflows are discovered from three locations (first match wins):
 | loop | `loop: { maxAttempts, steps }` | Repeat sub-steps until gate breaks or max reached |
 | parallel | `parallel: { a: ..., b: ... }` | Run named sub-steps concurrently |
 | pause | `pause: true` or `pause: "message"` | Pause execution, resumable later |
-| forEach | `forEach: "${{ expr }}"` | Iterate over an array, executing the step per element |
+| block | `block: { op: read\|write\|append\|update\|remove\|… }` | Validated in-process substrate block I/O via the block API — no LLM, no subprocess |
+
+`forEach: "${{ expr }}"` (iterate the step per array element) and `as:` are step MODIFIERS, not step types — they combine with any type above.
 </step_types>
 
 <expression_syntax>
@@ -64,7 +66,7 @@ Incomplete runs (failed or paused) are detected on next invocation. If the workf
 <output_validation>
 Steps with `output.schema` validate the agent's JSON output against a JSON Schema file. Validation failure marks the step as failed.
 
-Use `block:<name>` to reference project block schemas portably: `output.schema: block:project` resolves to `.project/schemas/project.schema.json` from cwd. Works across monorepo, npm install, and user-customized schemas. Combined with `retry: { maxAttempts: 2 }`, the agent gets the schema validation error injected into its retry prompt and can self-correct.
+Use `block:<name>` to reference project block schemas portably: `output.schema: block:project` resolves to `<substrate-dir>/schemas/project.schema.json` from cwd. Works across monorepo, npm install, and user-customized schemas. Combined with `retry: { maxAttempts: 2 }`, the agent gets the schema validation error injected into its retry prompt and can self-correct.
 </output_validation>
 
 <retry>
@@ -79,7 +81,7 @@ After execution, the workflow result is injected into the main LLM conversation.
 </completion_messages>
 
 <artifacts>
-Workflows can write post-completion files via the `artifacts` field. Paths may contain `${{ }}` expressions. Artifacts targeting `.project/*.json` are routed through `writeBlock()` for schema validation.
+Workflows can write post-completion files via the `artifacts` field. Paths may contain `${{ }}` expressions. Artifacts targeting `<substrate-dir>/*.json` are routed through `writeBlock()` for schema validation.
 
 Block artifact write failures are fatal — if the data doesn't conform to the block's schema, the workflow fails. Non-block artifact failures remain non-fatal (warning). On resume, all steps are preserved; only artifact processing re-runs, so fixing the schema issue or agent output and resuming avoids re-running expensive LLM steps.
 </artifacts>

package/skills/pi-workflows/SKILL.md

@@ -8,10 +8,10 @@ description: >
 ---
 
 <tools_reference>
-<tool name="workflow">
-Run a named workflow with typed input. Discovers workflows from .workflows/ and ~/.pi/agent/workflows/.
+<tool name="workflow-execute">
+Execute a named workflow with typed input. Discovers workflows from .workflows/ and ~/.pi/agent/workflows/. Auto-resumes the most recent compatible incomplete run unless fresh='true'. Use workflow-resume for explicit-only resume by runId.
 
-*Run a multi-step workflow with typed data flow between agents*
+*Execute a multi-step workflow with typed data flow (auto-resumes compatible incomplete runs)*
 
 | Parameter | Type | Required | Description |
 |-----------|------|----------|-------------|
@@ -20,6 +20,18 @@ Run a named workflow with typed input. Discovers workflows from .workflows/ and
 | `fresh` | string | no | Set to 'true' to start a fresh run, ignoring any incomplete prior runs |
 </tool>
 
+<tool name="workflow-resume">
+Explicitly resume an incomplete workflow run by name + runId. Rejects when no incomplete run exists for the workflow OR when runId does not match the most recent incomplete run. Use workflow-execute for default auto-resume; this surface is for explicit-only scenarios where the caller wants to fail loudly if the run is gone or has been superseded.
+
+*Explicitly resume an incomplete workflow run by name + runId (rejects on no-match)*
+
+| Parameter | Type | Required | Description |
+|-----------|------|----------|-------------|
+| `workflow` | string | yes | Workflow name |
+| `runId` | string | yes | Incomplete run ID — required, no auto-detect |
+| `input` | unknown | no | Optional input override; defaults to the original run's input |
+</tool>
+
 <tool name="workflow-list">
 List available workflows with names, descriptions, and sources.
 
@@ -61,6 +73,29 @@ Initialize .workflows/ directory for workflow run state.
 
 </tool>
 
+<tool name="render-item-by-id">
+Render a project block item by ID through its registered per-item macro. Resolves the item via the cross-block resolver, looks up the macro via the renderer registry, and renders with the supplied depth and depth-aware cross-reference recursion. Returns `[not-found: <id>]` on resolver miss and `[unrendered: <kind>/<id>]` on registry miss — same fallback markers `render_recursive` emits inside agent prompts.
+
+*Render a project block item as prompt text via its per-item macro (with depth-controlled cross-ref recursion)*
+
+| Parameter | Type | Required | Description |
+|-----------|------|----------|-------------|
+| `id` | string | yes | Kind-prefixed ID, e.g., DEC-NNNN / FEAT-NNN |
+| `depth` | number | no | 0 = bare-ID refs (default), 1 = inline direct cross-references, 2+ = recurse further |
+</tool>
+
+<tool name="enforce-budget">
+Check rendered text against an `x-prompt-budget` annotation on a schema field. Returns `{ output, warning }` — `output` is the original text passed through when under budget, or tail-truncated text with `[…truncated to budget]` marker when over; `warning` is null when no truncation occurred or a structured BudgetWarning record otherwise. Annotation absence is pass-through (no error). Mirrors the behaviour of the `enforceBudget` Nunjucks global registered by compileAgent.
+
+*Validate rendered text against a schema field's prompt budget — returns truncated output and warning*
+
+| Parameter | Type | Required | Description |
+|-----------|------|----------|-------------|
+| `rendered` | string | yes | Rendered text to check against the field's prompt budget |
+| `blockName` | string | yes | Block schema name (without .schema.json suffix), e.g. 'decisions' or 'features' |
+| `fieldPath` | string | yes | JSON-pointer-style path to the field, e.g. '/properties/decisions/items/properties/context' |
+</tool>
+
 </tools_reference>
 
 <commands_reference>
@@ -78,7 +113,7 @@ Subcommands: `init`, `list`, `run`, `resume`, `validate`, `status`, `help`
 </keyboard_shortcuts>
 
 <bundled_resources>
-26 agents, 15 schemas, 15 workflows, 33 templates bundled.
+26 agents, 15 schemas, 15 workflows bundled.
 See references/bundled-resources.md for full inventory.
 </bundled_resources>
 
@@ -127,7 +162,7 @@ See references/bundled-resources.md for full inventory.
 </agent_input>
 
 <agent_input name="handoff-writer">
-- `project_state` [required] — Current project state (from projectState() or /project status — includes phases, blocks, gaps, decisions, recent commits)
+- `project_state` [required] — Current project state (from contextState() or /context status — includes phases, blocks, gaps, decisions, recent commits)
 - `path` string [required] — Root path of the project
 </agent_input>
 
@@ -212,7 +247,7 @@ See references/bundled-resources.md for full inventory.
 | `filter-names` | warning | Expression filters are recognized |
 | `steptype-metadata` | error | retry/input/output declarations match step type capabilities |
 | `inputschema-required` | error | Agent required input keys are provided by step |
-| `contextblocks-existence` | warning | Declared context blocks exist in .project/ |
+| `contextblocks-existence` | warning | Declared context blocks exist in the substrate dir |
 | `template-alignment` | error | Template variables match step inputs and source schemas |
 
 </validation_vocabulary>
@@ -239,7 +274,9 @@ Workflows are discovered from three locations (first match wins):
 | loop | `loop: { maxAttempts, steps }` | Repeat sub-steps until gate breaks or max reached |
 | parallel | `parallel: { a: ..., b: ... }` | Run named sub-steps concurrently |
 | pause | `pause: true` or `pause: "message"` | Pause execution, resumable later |
-| forEach | `forEach: "${{ expr }}"` | Iterate over an array, executing the step per element |
+| block | `block: { op: read\|write\|append\|update\|remove\|… }` | Validated in-process substrate block I/O via the block API — no LLM, no subprocess |
+
+`forEach: "${{ expr }}"` (iterate the step per array element) and `as:` are step MODIFIERS, not step types — they combine with any type above.
 </step_types>
 
 <expression_syntax>
@@ -275,7 +312,7 @@ Incomplete runs (failed or paused) are detected on next invocation. If the workf
 <output_validation>
 Steps with `output.schema` validate the agent's JSON output against a JSON Schema file. Validation failure marks the step as failed.
 
-Use `block:<name>` to reference project block schemas portably: `output.schema: block:project` resolves to `.project/schemas/project.schema.json` from cwd. Works across monorepo, npm install, and user-customized schemas. Combined with `retry: { maxAttempts: 2 }`, the agent gets the schema validation error injected into its retry prompt and can self-correct.
+Use `block:<name>` to reference project block schemas portably: `output.schema: block:project` resolves to `<substrate-dir>/schemas/project.schema.json` from cwd. Works across monorepo, npm install, and user-customized schemas. Combined with `retry: { maxAttempts: 2 }`, the agent gets the schema validation error injected into its retry prompt and can self-correct.
 </output_validation>
 
 <retry>
@@ -290,7 +327,7 @@ After execution, the workflow result is injected into the main LLM conversation.
 </completion_messages>
 
 <artifacts>
-Workflows can write post-completion files via the `artifacts` field. Paths may contain `${{ }}` expressions. Artifacts targeting `.project/*.json` are routed through `writeBlock()` for schema validation.
+Workflows can write post-completion files via the `artifacts` field. Paths may contain `${{ }}` expressions. Artifacts targeting `<substrate-dir>/*.json` are routed through `writeBlock()` for schema validation.
 
 Block artifact write failures are fatal — if the data doesn't conform to the block's schema, the workflow fails. Non-block artifact failures remain non-fatal (warning). On resume, all steps are preserved; only artifact processing re-runs, so fixing the schema issue or agent output and resuming avoids re-running expensive LLM steps.
 </artifacts>

package/skills/pi-workflows/references/bundled-resources.md

@@ -64,39 +64,3 @@
 - `workflows/resumable-analysis.workflow.yaml`
 - `workflows/self-implement.workflow.yaml`
 - `workflows/typed-analysis.workflow.yaml`
-
-## templates/ (33 files)
-
-- `templates/analyzers/base-analyzer.md`
-- `templates/analyzers/patterns-task.md`
-- `templates/analyzers/patterns.md`
-- `templates/analyzers/quality-task.md`
-- `templates/analyzers/quality.md`
-- `templates/analyzers/structure-task.md`
-- `templates/analyzers/structure.md`
-- `templates/architecture-designer/task.md`
-- `templates/architecture-inferrer/task.md`
-- `templates/audit-finding-verifier/task.md`
-- `templates/audit-fixer/task.md`
-- `templates/audit-results-router/task.md`
-- `templates/decomposer/task.md`
-- `templates/explorer/system.md`
-- `templates/explorer/task.md`
-- `templates/gap-identifier/task.md`
-- `templates/gap-resolution-assessor/task.md`
-- `templates/handoff-writer/task.md`
-- `templates/investigator/task.md`
-- `templates/phase-author/task.md`
-- `templates/plan-creator/task.md`
-- `templates/plan-decomposer/task.md`
-- `templates/project-definer/task.md`
-- `templates/project-inferrer/task.md`
-- `templates/requirements-gatherer/task.md`
-- `templates/researcher/task.md`
-- `templates/shared/macros.md`
-- `templates/spec-implementer/task.md`
-- `templates/synthesizer/system.md`
-- `templates/synthesizer/task.md`
-- `templates/task-verifier/task.md`
-- `templates/task-worker/task.md`
-- `templates/verifier/task.md`

package/workflows/analyze-existing-project.workflow.yaml

@@ -85,4 +85,4 @@ completion:
     **Architecture:** ${{ steps.infer-architecture.output.modules | length }} modules, ${{ steps.infer-architecture.output.patterns | length }} patterns
     **Gaps:** ${{ steps.identify-issues.output.issues | length }} identified
 
-    Use `/project status` to see the full state. Use `/project validate` to check cross-block references.
+    Use `/context status` to see the full state. Use `/context validate` to check cross-block references.

package/workflows/init-new-project.workflow.yaml

@@ -78,4 +78,4 @@ completion:
     **Architecture:** ${{ steps.design-architecture.output.modules | length }} modules
     **Plan:** phases and tasks created
 
-    Use `/project status` to see the full state. Use `/project validate` to check cross-block references.
+    Use `/context status` to see the full state. Use `/context validate` to check cross-block references.

package/workflows/plan-from-requirements.workflow.yaml

@@ -44,5 +44,5 @@ completion:
   template: |
     Plan created from requirements. Tasks written to .project/tasks.json.
 
-    Use `/project status` to see the phase and task breakdown.
-    Use `/project validate` to check cross-block references.
+    Use `/context status` to see the phase and task breakdown.
+    Use `/context validate` to check cross-block references.

package/templates/analyzers/base-analyzer.md

@@ -1,9 +0,0 @@
-{% block identity %}You are a code analyst.{% endblock %} Given an exploration summary and a code path to analyze:
-
-{% block checklist %}
-1. Analyze the code thoroughly
-{% endblock %}
-
-{% block constraints %}
-Be specific — cite files and line ranges where applicable.
-{% endblock %}

package/templates/analyzers/patterns-task.md

@@ -1,11 +0,0 @@
-Analyze design patterns at `{{ path }}`.
-
-{% if exploration.files is defined %}
-## Codebase
-{% for file in exploration.files %}
-- `{{ file.path }}` ({{ file.lines }} lines)
-{% endfor %}
-{% endif %}
-
-Identify patterns, conventions, and anti-patterns. Provide recommendations.
-Write your analysis as JSON conforming to the output schema.

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.