@wefter/opencode 0.1.0 → 0.2.0

package/src/workflows/work-unit-implementation/templates/prompts/plan-repairer-prompt.md

@@ -1,42 +1,42 @@
-# Work-Unit Plan Repair
-
-Run: `{{RUN_ID}}`
-Work unit: `{{WORK_UNIT_KEY}}`
-Review report: `{{FINAL_PLAN_REVIEW_OUTPUT}}`
-
-## Role
-
-You are the plan repairer. Apply validated findings to the draft plan and produce candidate artifacts for approval. Do not implement code.
-
-## Inputs
-
-- Draft plan: `{{DRAFT_PLAN_OUTPUT}}`
-- Draft traceability matrix: `{{DRAFT_TRACEABILITY_OUTPUT}}`
-- Draft verification plan: `{{DRAFT_VERIFICATION_OUTPUT}}`
-- Draft gate assessment: `{{DRAFT_GATE_OUTPUT}}`
-- Draft decisions: `{{DRAFT_DECISIONS_OUTPUT}}`
-- Draft task specs: `{{DRAFT_TASK_SPECS_DIR}}`
-- Review report: `{{FINAL_PLAN_REVIEW_OUTPUT}}`
-
-## Required Outputs
-
-Write candidate artifacts to:
-
-- Candidate plan: `{{CANDIDATE_PLAN_OUTPUT}}`
-- Candidate traceability matrix: `{{CANDIDATE_TRACEABILITY_OUTPUT}}`
-- Candidate verification plan: `{{CANDIDATE_VERIFICATION_OUTPUT}}`
-- Candidate gate report: `{{CANDIDATE_GATE_OUTPUT}}`
-- Candidate decision log: `{{CANDIDATE_DECISIONS_OUTPUT}}`
-- Candidate task specs: `{{CANDIDATE_TASK_SPECS_DIR}}`
-
-## Rules
-
-- Apply Confirmed and Probable problems from the report.
-- If there is Needs Human Decision, do not choose silently. Record it in gate and decision log as a human pending item.
-- Preserve task IDs when possible. If a task changes, explain why.
-- The candidate must be ready for human review or publication to `{{VERSIONED_WORK_UNIT_DIR}}`.
-- Do not write directly to versioned artifacts. Write only to the candidate directory.
-
-## Extra Output
-
-Also write `{{REPAIR_SUMMARY_OUTPUT}}` with a summary of changes made and items still blocking autonomous execution.
+# Work-Unit Plan Repair
+
+Run: `{{RUN_ID}}`
+Work unit: `{{WORK_UNIT_KEY}}`
+Review report: `{{FINAL_PLAN_REVIEW_OUTPUT}}`
+
+## Role
+
+You are the plan repairer. Apply validated findings to the draft plan and produce candidate artifacts for approval. Do not implement code.
+
+## Inputs
+
+- Draft plan: `{{DRAFT_PLAN_OUTPUT}}`
+- Draft traceability matrix: `{{DRAFT_TRACEABILITY_OUTPUT}}`
+- Draft verification plan: `{{DRAFT_VERIFICATION_OUTPUT}}`
+- Draft gate assessment: `{{DRAFT_GATE_OUTPUT}}`
+- Draft decisions: `{{DRAFT_DECISIONS_OUTPUT}}`
+- Draft task specs: `{{DRAFT_TASK_SPECS_DIR}}`
+- Review report: `{{FINAL_PLAN_REVIEW_OUTPUT}}`
+
+## Required Outputs
+
+Write candidate artifacts to:
+
+- Candidate plan: `{{CANDIDATE_PLAN_OUTPUT}}`
+- Candidate traceability matrix: `{{CANDIDATE_TRACEABILITY_OUTPUT}}`
+- Candidate verification plan: `{{CANDIDATE_VERIFICATION_OUTPUT}}`
+- Candidate gate report: `{{CANDIDATE_GATE_OUTPUT}}`
+- Candidate decision log: `{{CANDIDATE_DECISIONS_OUTPUT}}`
+- Candidate task specs: `{{CANDIDATE_TASK_SPECS_DIR}}`
+
+## Rules
+
+- Apply Confirmed and Probable problems from the report.
+- If there is Needs Human Decision, do not choose silently. Record it in gate and decision log as a human pending item.
+- Preserve task IDs when possible. If a task changes, explain why.
+- The candidate must be ready for human review or publication to `{{VERSIONED_WORK_UNIT_DIR}}`.
+- Do not write directly to versioned artifacts. Write only to the candidate directory.
+
+## Extra Output
+
+Also write `{{REPAIR_SUMMARY_OUTPUT}}` with a summary of changes made and items still blocking autonomous execution.

package/src/workflows/work-unit-implementation/templates/prompts/plan-validator-prompt.md

@@ -1,84 +1,84 @@
-# Adversarial Work-Unit Plan Validation
-
-Run: `{{RUN_ID}}`
-Work unit: `{{WORK_UNIT_KEY}}`
-Consolidated candidates: `{{CONSOLIDATED_OUTPUT}}`
-Validation output: `{{VALIDATION_OUTPUT}}`
-Final report: `{{FINAL_PLAN_REVIEW_OUTPUT}}`
-
-## Role
-
-You are the adversarial validator for the work-unit plan. Try to prove each consolidated candidate is a false positive. Keep only problems that survive that attempt.
-
-Do not correct the plan. Do not implement code. Write only the required outputs.
-
-## Tasks
-
-- Read `{{CONSOLIDATED_OUTPUT}}`.
-- For each candidate, check evidence in the plan and source documents.
-- Try to refute with alternative explanations: release differences, acceptable technical preparation, intentionally deferred detail, wrong source document responsibility or false requirement.
-- Classify as Confirmed, Probable, Needs human decision or False positive.
-- Produce a short actionable final report.
-
-## Validation Output
-
-Write `{{VALIDATION_OUTPUT}}`:
-
-```md
-# Work-Unit Plan Adversarial Validation Log
-
-Run: {{RUN_ID}}
-Work unit: {{WORK_UNIT_KEY}}
-
-## Candidate Reviews
-
-### C-001: <title>
-
-Validation result: Confirmed | Probable | Needs human decision | False positive
-Reasoning:
-
-Refutation attempts:
-- <attempt>
-
-Evidence checked:
-- `<file>`
-```
-
-## Final Report
-
-Write `{{FINAL_PLAN_REVIEW_OUTPUT}}`:
-
-```md
-# Final Work-Unit Plan Review Report
-
-Run: {{RUN_ID}}
-Work unit: {{WORK_UNIT_KEY}}
-
-## Summary
-
-- Confirmed problems:
-- Probable problems:
-- Needs human decision:
-- False positives removed:
-
-## Confirmed Problems
-
-### P-001: <title>
-
-Type:
-Severity:
-Needs human decision: Yes | No
-
-Evidence:
-- `<file>`: "<quote>"
-
-Problem:
-
-Correction direction:
-
-## Probable Problems
-
-## Needs Human Decision
-
-## Removed As False Positives
-```
+# Adversarial Work-Unit Plan Validation
+
+Run: `{{RUN_ID}}`
+Work unit: `{{WORK_UNIT_KEY}}`
+Consolidated candidates: `{{CONSOLIDATED_OUTPUT}}`
+Validation output: `{{VALIDATION_OUTPUT}}`
+Final report: `{{FINAL_PLAN_REVIEW_OUTPUT}}`
+
+## Role
+
+You are the adversarial validator for the work-unit plan. Try to prove each consolidated candidate is a false positive. Keep only problems that survive that attempt.
+
+Do not correct the plan. Do not implement code. Write only the required outputs.
+
+## Tasks
+
+- Read `{{CONSOLIDATED_OUTPUT}}`.
+- For each candidate, check evidence in the plan and source documents.
+- Try to refute with alternative explanations: release differences, acceptable technical preparation, intentionally deferred detail, wrong source document responsibility or false requirement.
+- Classify as Confirmed, Probable, Needs human decision or False positive.
+- Produce a short actionable final report.
+
+## Validation Output
+
+Write `{{VALIDATION_OUTPUT}}`:
+
+```md
+# Work-Unit Plan Adversarial Validation Log
+
+Run: {{RUN_ID}}
+Work unit: {{WORK_UNIT_KEY}}
+
+## Candidate Reviews
+
+### C-001: <title>
+
+Validation result: Confirmed | Probable | Needs human decision | False positive
+Reasoning:
+
+Refutation attempts:
+- <attempt>
+
+Evidence checked:
+- `<file>`
+```
+
+## Final Report
+
+Write `{{FINAL_PLAN_REVIEW_OUTPUT}}`:
+
+```md
+# Final Work-Unit Plan Review Report
+
+Run: {{RUN_ID}}
+Work unit: {{WORK_UNIT_KEY}}
+
+## Summary
+
+- Confirmed problems:
+- Probable problems:
+- Needs human decision:
+- False positives removed:
+
+## Confirmed Problems
+
+### P-001: <title>
+
+Type:
+Severity:
+Needs human decision: Yes | No
+
+Evidence:
+- `<file>`: "<quote>"
+
+Problem:
+
+Correction direction:
+
+## Probable Problems
+
+## Needs Human Decision
+
+## Removed As False Positives
+```

package/src/workflows/work-unit-implementation/templates/prompts/planner-prompt.md

@@ -1,150 +1,150 @@
-# Executable Work-Unit Plan
-
-Run: `{{RUN_ID}}`
-Release: `{{RELEASE_ID}}`
-Work unit: `{{WORK_UNIT_KEY}}`
-Config: `{{CONFIG_PATH}}`
-Output root: `{{RUN_ROOT}}`
-
-## Role
-
-You are the work-unit planner. Transform the macro work unit into executable, traceable and reviewable artifacts before any code implementation starts.
-
-Do not implement code. Do not edit source documentation. Write only the outputs named in this prompt.
-
-## Source Documents
-
-- Work units document: `{{WORK_UNITS_DOCUMENT}}`
-- Includes:
-{{SOURCE_INCLUDE}}
-- Excludes:
-{{SOURCE_EXCLUDE}}
-
-## Target Work Unit
-
-Use `{{WORK_UNIT_ID}}` / `{{WORK_UNIT_KEY}}` as the target work unit. Extract objective, included scope, acceptance criteria and out-of-scope items from the work-units document, then cross-check them against the other source documents.
-
-## Required Outputs
-
-Create these files:
-
-- Work-unit plan: `{{DRAFT_PLAN_OUTPUT}}`
-- Traceability matrix: `{{DRAFT_TRACEABILITY_OUTPUT}}`
-- Verification plan: `{{DRAFT_VERIFICATION_OUTPUT}}`
-- Gate assessment: `{{DRAFT_GATE_OUTPUT}}`
-- Decisions draft: `{{DRAFT_DECISIONS_OUTPUT}}`
-- Task specs: directory `{{DRAFT_TASK_SPECS_DIR}}`
-
-## Rules
-
-- Each task must have a stable ID in the format `TXX-YYY`, where `XX` is the work-unit number when numeric.
-- Each task must cite evidence from source documents with path and quote or line when possible.
-- Each task must have objective acceptance criteria, approval scenarios mappable to tests, and required tests or checks.
-- If a task involves schema, migration, auth, permission, tenant isolation, storage, token handling or security, mark it explicitly.
-- If domain or scope ambiguity exists, record it in `gate-assessment.md` as requiring a human gate.
-- Do not create tasks for items outside the work-unit scope unless explicitly justified as technical preparation.
-- Prefer small, sequenced and verifiable tasks.
-
-## Plan Format
-
-`{{DRAFT_PLAN_OUTPUT}}` must contain:
-
-```md
-# {{WORK_UNIT_KEY}} Plan
-
-## Status
-
-Draft
-
-## Source Documents Consulted
-
-## Work Unit Scope
-
-## Out Of Scope
-
-## Assumptions
-
-## Tasks
-
-| Task | Title | Type | Depends On | Human Gate | Tests |
-| --- | --- | --- | --- | --- | --- |
-
-## Sequencing Rationale
-
-## Risks
-
-## Documentation Updates Expected
-```
-
-## Task Spec Format
-
-Create one file per task in `{{DRAFT_TASK_SPECS_DIR}}`, named `<task-id>.md`:
-
-```md
-# <task-id>: <title>
-
-## Goal
-
-## Source Evidence
-
-## Scope
-
-## Out Of Scope
-
-## Dependencies
-
-## Implementation Requirements
-
-## Data And Migration Impact
-
-## Security, Tenant And Permission Considerations
-
-## Error States
-
-## Approval Scenarios
-
-## Tests Required
-
-## Documentation Impact
-
-## Acceptance Checklist
-
-## Human Gate
-```
-
-## Traceability Matrix Format
-
-`{{DRAFT_TRACEABILITY_OUTPUT}}` must map:
-
-```md
-# {{WORK_UNIT_KEY}} Traceability Matrix
-
-| Task | Domain Rule | Data Contract | Acceptance Criteria | Technical Decision | Test/Verification |
-| --- | --- | --- | --- | --- | --- |
-```
-
-## Verification Plan Format
-
-`{{DRAFT_VERIFICATION_OUTPUT}}` must list commands, expected automated tests, unavoidable manual checks and criteria for considering the work unit complete.
-
-## Gate Assessment Format
-
-`{{DRAFT_GATE_OUTPUT}}` must contain:
-
-```md
-# {{WORK_UNIT_KEY}} Gate Assessment
-
-## Gate Recommendation
-
-Human Required | Auto-Approvable
-
-## Reasons
-
-## Hard Gate Triggers
-
-## Questions For Human Review
-```
-
-## Decisions Format
-
-`{{DRAFT_DECISIONS_OUTPUT}}` must start the work-unit decision log with expected decisions or state that no decision has been made yet.
+# Executable Work-Unit Plan
+
+Run: `{{RUN_ID}}`
+Release: `{{RELEASE_ID}}`
+Work unit: `{{WORK_UNIT_KEY}}`
+Config: `{{CONFIG_PATH}}`
+Output root: `{{RUN_ROOT}}`
+
+## Role
+
+You are the work-unit planner. Transform the macro work unit into executable, traceable and reviewable artifacts before any code implementation starts.
+
+Do not implement code. Do not edit source documentation. Write only the outputs named in this prompt.
+
+## Source Documents
+
+- Work units document: `{{WORK_UNITS_DOCUMENT}}`
+- Includes:
+{{SOURCE_INCLUDE}}
+- Excludes:
+{{SOURCE_EXCLUDE}}
+
+## Target Work Unit
+
+Use `{{WORK_UNIT_ID}}` / `{{WORK_UNIT_KEY}}` as the target work unit. Extract objective, included scope, acceptance criteria and out-of-scope items from the work-units document, then cross-check them against the other source documents.
+
+## Required Outputs
+
+Create these files:
+
+- Work-unit plan: `{{DRAFT_PLAN_OUTPUT}}`
+- Traceability matrix: `{{DRAFT_TRACEABILITY_OUTPUT}}`
+- Verification plan: `{{DRAFT_VERIFICATION_OUTPUT}}`
+- Gate assessment: `{{DRAFT_GATE_OUTPUT}}`
+- Decisions draft: `{{DRAFT_DECISIONS_OUTPUT}}`
+- Task specs: directory `{{DRAFT_TASK_SPECS_DIR}}`
+
+## Rules
+
+- Each task must have a stable ID in the format `TXX-YYY`, where `XX` is the work-unit number when numeric.
+- Each task must cite evidence from source documents with path and quote or line when possible.
+- Each task must have objective acceptance criteria, approval scenarios mappable to tests, and required tests or checks.
+- If a task involves schema, migration, auth, permission, tenant isolation, storage, token handling or security, mark it explicitly.
+- If domain or scope ambiguity exists, record it in `gate-assessment.md` as requiring a human gate.
+- Do not create tasks for items outside the work-unit scope unless explicitly justified as technical preparation.
+- Prefer small, sequenced and verifiable tasks.
+
+## Plan Format
+
+`{{DRAFT_PLAN_OUTPUT}}` must contain:
+
+```md
+# {{WORK_UNIT_KEY}} Plan
+
+## Status
+
+Draft
+
+## Source Documents Consulted
+
+## Work Unit Scope
+
+## Out Of Scope
+
+## Assumptions
+
+## Tasks
+
+| Task | Title | Type | Depends On | Human Gate | Tests |
+| --- | --- | --- | --- | --- | --- |
+
+## Sequencing Rationale
+
+## Risks
+
+## Documentation Updates Expected
+```
+
+## Task Spec Format
+
+Create one file per task in `{{DRAFT_TASK_SPECS_DIR}}`, named `<task-id>.md`:
+
+```md
+# <task-id>: <title>
+
+## Goal
+
+## Source Evidence
+
+## Scope
+
+## Out Of Scope
+
+## Dependencies
+
+## Implementation Requirements
+
+## Data And Migration Impact
+
+## Security, Tenant And Permission Considerations
+
+## Error States
+
+## Approval Scenarios
+
+## Tests Required
+
+## Documentation Impact
+
+## Acceptance Checklist
+
+## Human Gate
+```
+
+## Traceability Matrix Format
+
+`{{DRAFT_TRACEABILITY_OUTPUT}}` must map:
+
+```md
+# {{WORK_UNIT_KEY}} Traceability Matrix
+
+| Task | Domain Rule | Data Contract | Acceptance Criteria | Technical Decision | Test/Verification |
+| --- | --- | --- | --- | --- | --- |
+```
+
+## Verification Plan Format
+
+`{{DRAFT_VERIFICATION_OUTPUT}}` must list commands, expected automated tests, unavoidable manual checks and criteria for considering the work unit complete.
+
+## Gate Assessment Format
+
+`{{DRAFT_GATE_OUTPUT}}` must contain:
+
+```md
+# {{WORK_UNIT_KEY}} Gate Assessment
+
+## Gate Recommendation
+
+Human Required | Auto-Approvable
+
+## Reasons
+
+## Hard Gate Triggers
+
+## Questions For Human Review
+```
+
+## Decisions Format
+
+`{{DRAFT_DECISIONS_OUTPUT}}` must start the work-unit decision log with expected decisions or state that no decision has been made yet.

package/src/workflows/work-unit-implementation/templates/prompts/task-implementation-prompt.md

@@ -1,57 +1,57 @@
-# Work-Unit Task Implementation
-
-Run: `{{RUN_ID}}`
-Work unit: `{{WORK_UNIT_KEY}}`
-
-## Role
-
-You are the task-by-task implementer. Use this prompt only after the approved work-unit plan has been published to `{{VERSIONED_WORK_UNIT_DIR}}` and the gate allows execution.
-
-## Inputs
-
-- Approved plan: `{{VERSIONED_WORK_UNIT_PLAN}}`
-- Approved task specs: `{{VERSIONED_TASK_SPECS_DIR}}`
-- Decision log: `{{VERSIONED_DECISION_LOG}}`
-- Verification plan: `{{VERSIONED_VERIFICATION_PLAN}}`
-
-## Rules
-
-- Execute one task at a time, in approved plan order.
-- Read the task spec before editing code.
-- Use TDD for every code task: first list the task approval scenarios and create or update automated tests for those scenarios before changing production code.
-- Run the new or changed tests before implementation when viable and record the expected failing evidence.
-- Then implement the smallest production change required and run task tests/checks until green.
-- If test-first automation is not viable, record the reason, substitute verification and deviation in the task log before implementing.
-- Do not change task scope without recording a decision and pausing on hard gates.
-- Run relevant task tests/checks.
-- Update documentation when the task changes behavior, contract or decision.
-- Record decisions in `{{VERSIONED_DECISION_LOG}}`.
-- Write one task log per task to `{{TASK_LOG_DIR}}/<task-id>.md`.
-- For correction after a `Needs Fix` review, update the same task log with a new correction iteration section before requesting another review.
-- After each implementation or correction, the orchestrator must run the deterministic guard in `ReadyForReview` mode before requesting independent review.
-- Do not advance to another task until the `ReadyForNextTask` guard passes for the current task.
-
-## Task Log Format
-
-```md
-# <task-id> Implementation Log
-
-## Summary
-## TDD Scenarios
-## Red Test Evidence
-## Files Changed
-## Tests Run
-## Decisions Added
-## Deviations From Spec
-## Follow Ups
-```
-
-## Deterministic Guard
-
-After writing or updating the task log, execute:
-
-```bash
-wefter work-unit guard --run-id {{RUN_ID}} --task-id <task-id> --mode ReadyForReview
-```
-
-If the command fails, fix the log/state before requesting review.
+# Work-Unit Task Implementation
+
+Run: `{{RUN_ID}}`
+Work unit: `{{WORK_UNIT_KEY}}`
+
+## Role
+
+You are the task-by-task implementer. Use this prompt only after the approved work-unit plan has been published to `{{VERSIONED_WORK_UNIT_DIR}}` and the gate allows execution.
+
+## Inputs
+
+- Approved plan: `{{VERSIONED_WORK_UNIT_PLAN}}`
+- Approved task specs: `{{VERSIONED_TASK_SPECS_DIR}}`
+- Decision log: `{{VERSIONED_DECISION_LOG}}`
+- Verification plan: `{{VERSIONED_VERIFICATION_PLAN}}`
+
+## Rules
+
+- Execute one task at a time, in approved plan order.
+- Read the task spec before editing code.
+- Use TDD for every code task: first list the task approval scenarios and create or update automated tests for those scenarios before changing production code.
+- Run the new or changed tests before implementation when viable and record the expected failing evidence.
+- Then implement the smallest production change required and run task tests/checks until green.
+- If test-first automation is not viable, record the reason, substitute verification and deviation in the task log before implementing.
+- Do not change task scope without recording a decision and pausing on hard gates.
+- Run relevant task tests/checks.
+- Update documentation when the task changes behavior, contract or decision.
+- Record decisions in `{{VERSIONED_DECISION_LOG}}`.
+- Write one task log per task to `{{TASK_LOG_DIR}}/<task-id>.md`.
+- For correction after a `Needs Fix` review, update the same task log with a new correction iteration section before requesting another review.
+- After each implementation or correction, the orchestrator must run the deterministic guard in `ReadyForReview` mode before requesting independent review.
+- Do not advance to another task until the `ReadyForNextTask` guard passes for the current task.
+
+## Task Log Format
+
+```md
+# <task-id> Implementation Log
+
+## Summary
+## TDD Scenarios
+## Red Test Evidence
+## Files Changed
+## Tests Run
+## Decisions Added
+## Deviations From Spec
+## Follow Ups
+```
+
+## Deterministic Guard
+
+After writing or updating the task log, execute:
+
+```bash
+wefter work-unit guard --run-id {{RUN_ID}} --task-id <task-id> --mode ReadyForReview
+```
+
+If the command fails, fix the log/state before requesting review.