create-harness-vibe-coding 0.6.2 → 0.6.4

package/templates/optional/skills/ui-ux-review/.claude/skills/ui-ux-review/SKILL.md

@@ -1,40 +1,40 @@
----
-name: ui-ux-review
-description: Screenshot-driven UI and UX review for responsive behavior, accessibility, visual polish, and task clarity.
----
-
-# UI/UX Review
-
-## When To Use
-
-Use this skill when reviewing or changing user-facing screens, layouts, visual hierarchy, interaction states, accessibility, or responsive behavior.
-
-## Docs To Load
-
-- `Harness/workflows/ui-ux-review.md`
-- `Harness/PLAN.md`
-- Existing design system, component, or style documentation.
-
-## Required Inputs
-
-- Screens, routes, or components under review.
-- Target users and primary tasks.
-- Breakpoints, themes, and accessibility expectations.
-
-## Allowed Writes
-
-- UI code and style files already in scope for the task.
-- Screenshot or audit artifacts in existing evidence folders.
-- `Harness/PLAN.md` when the review is part of a tracked plan.
-
-## Output Format
-
-Return prioritized findings with file or screen references, evidence, recommended fixes, commands run, and residual risks.
-
-## PLAN.md Updates
-
-Update `Harness/PLAN.md` only for tracked review tasks or when recording required evidence.
-
-## dispatch.md Usage
-
-Use `Harness/dispatch.md` only for independent review streams such as separate routes or breakpoints.
+---
+name: ui-ux-review
+description: Screenshot-driven UI and UX review for responsive behavior, accessibility, visual polish, and task clarity.
+---
+
+# UI/UX Review
+
+## When To Use
+
+Use this skill when reviewing or changing user-facing screens, layouts, visual hierarchy, interaction states, accessibility, or responsive behavior.
+
+## Docs To Load
+
+- `Harness/workflows/ui-ux-review.md`
+- `Harness/PROGRESS.md` and current task `tasks/<id>/PLAN.md`
+- Existing design system, component, or style documentation.
+
+## Required Inputs
+
+- Screens, routes, or components under review.
+- Target users and primary tasks.
+- Breakpoints, themes, and accessibility expectations.
+
+## Allowed Writes
+
+- UI code and style files already in scope for the task.
+- Screenshot or audit artifacts in existing evidence folders.
+- Current task `tasks/<id>/PLAN.md` when the review is part of a tracked plan.
+
+## Output Format
+
+Return prioritized findings with file or screen references, evidence, recommended fixes, commands run, and residual risks.
+
+## PROGRESS.md & Task PLAN.md Updates
+
+Update current task `tasks/<id>/PLAN.md` only for tracked review tasks or when recording required evidence.
+
+## dispatch.md Usage
+
+Use `Harness/dispatch.md` only for independent review streams such as separate routes or breakpoints.

package/templates/common/.claude/skills/harness-build-loop/SKILL.md

@@ -1,23 +0,0 @@
----
-name: harness-build-loop
-description: Use for implementation, review, debugging, verification, and closing a feature.
----
-
-# Harness Build Loop
-
-Load:
-
-- `Harness/agent-workflow.md`
-- `Harness/subagents.md` when more than one agent, reviewer, or recovery pass is useful
-- `Harness/dispatch.md` when more than one agent is useful
-- `Harness/PROGRESS.md`
-- `Harness/tasks/<task-id>/PROGRESS.md` and `Harness/tasks/<task-id>/PLAN.md` when available
-- current feature doc if present
-
-Follow:
-
-```text
-acceptance criteria -> failing test/manual check -> implementation -> verify -> review -> docs sync
-```
-
-Close only with recorded verification evidence.

package/templates/common/.claude/skills/harness-context/SKILL.md

@@ -1,26 +0,0 @@
----
-name: harness-context
-description: Use before spawning subagents, splitting work, or when context is growing.
----
-
-# Harness Context
-
-Load:
-
-- `Harness/subagents.md`
-- `Harness/context-loading.md`
-- `Harness/dispatch.md` when more than one agent is useful
-- `Harness/PROGRESS.md`
-- `Harness/tasks/<task-id>/PROGRESS.md` and `Harness/tasks/<task-id>/PLAN.md` when available
-- current feature doc if present
-
-For each subagent or bounded pass, provide:
-
-- role
-- task
-- mode
-- read boundary
-- write boundary
-- dependency
-- injected docs
-- return format

package/templates/common/.claude/skills/harness-lifecycle/SKILL.md

@@ -1,20 +0,0 @@
----
-name: harness-lifecycle
-description: Use for raw ideas, vague product requests, 0-1 planning, PRD work, scope decisions, or feedback loops.
----
-
-# Harness Lifecycle
-
-Load:
-
-- `Harness/lifecycle.md`
-- `Harness/research/PRD.md`
-- `Harness/PROGRESS.md`
-- `Harness/tasks/<task-id>/PROGRESS.md` and `Harness/tasks/<task-id>/PLAN.md` when available
-
-Output:
-
-- current phase
-- blocking questions or recorded assumptions
-- next artifact to fill
-- gate before coding

package/templates/common/.claude/skills/harness-research/SKILL.md

@@ -1,30 +0,0 @@
----
-name: harness-research
-description: Use for market, product, stack, dependency, API, pricing, legal, security, or open-source research before PRD or architecture decisions.
----
-
-# Harness Research
-
-Load:
-
-- `Harness/research/README.md`
-- `Harness/research/research-results.md`
-- `Harness/PROGRESS.md`
-- `Harness/tasks/<task-id>/PROGRESS.md` and `Harness/tasks/<task-id>/PLAN.md` when available
-
-Define:
-
-- research question
-- decision needed
-- source boundaries
-- tool choice: local / GitHub / Tavily / TinyFish / built-in web search / user-provided sources
-- fallback when the preferred tool is unavailable
-- return format
-
-Return:
-
-- queries and tools used
-- sources with links and source type
-- adopted / rejected / watch decisions
-- risks and unknowns
-- patch-ready `Harness/research/research-results.md` update

package/templates/common/.claude/skills/harness-router/SKILL.md

@@ -1,16 +0,0 @@
----
-name: harness-router
-description: Use at the start of any task, or when unsure which harness document applies. Keeps context small by routing to one primary doc.
----
-
-# Harness Router
-
-1. Read `Harness/README.md`.
-2. Identify the current situation from "Load By Task".
-3. Apply routing priority before loading extra files:
-   - `/wf`, `wf mode`, `workflow mode`, `wk mode`, long, difficult, uncertain, repeated-failure, migration, architecture-heavy, browser-visible, or broad multi-agent implementation work routes to `wf-mode` first.
-   - Bounded subagent-only coordination routes to `subagent-orchestrator`.
-4. Load only the listed primary doc(s). Let `wf-mode` decide when to load subagent docs.
-5. If the task grows, update `Harness/tasks/<task-id>/PROGRESS.md` and use `harness-context`.
-
-Do not bulk-read `Harness/`.

package/templates/common/.claude/skills/wf-mode/SKILL.md

@@ -1,55 +0,0 @@
----
-name: wf-mode
-description: Use for /wf, wf mode, workflow mode, wk mode, long difficult tasks, multi-file or multi-agent work, low-confidence decisions, repeated failures, migrations, architecture-heavy changes, browser-visible work, or any task that needs exploration -> second plan -> implementation -> review -> verification -> recovery.
----
-
-# WF Mode
-
-Load:
-
-- `Harness/WF.md`
-- `Harness/PROGRESS.md`
-- `Harness/tasks/<task-id>/PROGRESS.md` and `Harness/tasks/<task-id>/PLAN.md` when active
-- `Harness/agent-workflow.md` when implementation, review, or verification starts
-- `Harness/subagents.md`, `Harness/dispatch.md`, and `Harness/context-loading.md` immediately for explicit WF/WK mode; otherwise only when coordinating subagents or bounded role passes
-- current feature doc when one exists
-- `Harness/workflows/browser-e2e.md` when browser-visible behavior is affected and the workflow is installed
-
-Follow:
-
-```text
-intake + 95% confidence gate
--> parallel read-only exploration
--> synthesis and second plan
--> failing test or manual check
--> bounded implementation
--> review
--> verification
--> debugger recovery loop when verification fails (dispatch context-master then memory-master, or use /wf-learn)
--> context-master session analysis + knowledge extraction
--> memory-master consolidation
--> close with evidence
-```
-
-Rules:
-
-- Update `Harness/tasks/<task-id>/PROGRESS.md#Heartbeat` before long commands, after failures, before handoff, and at closeout.
-- Explicit `/wf`, `wf mode`, `workflow mode`, or `wk mode` MUST use `subagent-orchestrator` and spawn at least 3 distinct subagents from `.claude/agents/` before second planning.
-- Use the 7:3 collaboration bias from `Harness/WF.md`: default to multi-agent collaboration for substantial work; use solo mode only for clearly small/local tasks outside explicit WF/WK mode.
-- Use `subagent-orchestrator` and `Harness/subagents.md` when the task has broad reading, cross-layer impact, independent review needs, or repeated failures.
-- Subagents return findings and PLAN patch suggestions. Only the main agent writes to task PROGRESS.md and PLAN.md.
-- If subagents are unavailable, emulate the same roles as separate bounded passes.
-- Do not claim browser/UI acceptance without real-browser evidence from Chrome DevTools, CDP, Playwright, or documented manual browser checks.
-- If `Harness/workflows/browser-e2e.md` is not installed, use `Harness/WF.md#Browser And API Evidence` as the fallback evidence contract or ask the user before adding the optional workflow.
-- Before closeout, dispatch `context-master` then `memory-master` (or use `/wf-learn`) to extract and consolidate lessons. Do not skip — the auto-trigger is unreliable; make this a mandatory gate.
-
-Return:
-
-- changed files
-- agents or bounded passes used
-- memory-master / context-master dispatches
-- commands run
-- browser/API evidence when applicable
-- review findings
-- remaining risks
-- updated heartbeat status

package/templates/common/docs/domain/ports.md

@@ -1,76 +0,0 @@
-# Port Contracts — {{projectName}}
-
-> **Responsibility**: Define cross-layer interface contracts. These are the "legal contracts" of a layered architecture. Each port documents not only its signature, but also preconditions, postconditions, and error semantics.
->
-> **Principle**: Port documentation != API reference documentation. It is a contract that specifies caller obligations and implementer guarantees.
->
-> Philosophical origins: Bertrand Meyer's Design by Contract (Eiffel) + Alistair Cockburn's hexagonal architecture port documentation.
-
----
-
-## 1. Port Classification
-
-Create a port only for a real boundary: external service, storage, SDK, process, browser/API boundary, permission boundary, or cross-layer dependency. Do not create a port only because an interface might be useful someday.
-
-### 1.1 Driving Ports (Inbound — external calls application)
-
-| Port | Definition Location | Purpose |
-| --- | --- | --- |
-| `{{INBOUND_PORT_1}}` | `{{LOCATION}}` | {{DESCRIPTION}} |
-
-### 1.2 Driven Ports (Outbound — application calls external)
-
-| Port | Definition Location | Purpose |
-| --- | --- | --- |
-| `{{OUTBOUND_PORT_1}}` | `{{LOCATION}}` | {{DESCRIPTION}} |
-
----
-
-## 2. Port Definition Template
-
-Fill in each port using the format below:
-
-- **Category**: Driving / Driven
-- **Definition Location**: `{{FILE_PATH}}`
-- **Contract Class**: `{{CLASS_OR_INTERFACE}}`
-
-### Purpose
-
-{{WHAT_THIS_PORT_DOES}}
-
-### Methods
-
-**Preconditions** (caller must guarantee):
-- {{PRECONDITION_1}}
-- {{PRECONDITION_2}}
-
-**Postconditions** (implementer guarantees):
-- {{POSTCONDITION_1}}
-- {{POSTCONDITION_2}}
-
-**Error Semantics**:
-
-| Exception Type | Trigger Condition | Caller Should |
-| --- | --- | --- |
-| `{{EXCEPTION_TYPE}}` | {{CONDITION}} | {{CALLER_ACTION}} |
-
-**Idempotency**: {{YES_NO_AND_DETAILS}}
-
-### Known Implementations
-
-| Adapter | Location | Purpose |
-| --- | --- | --- |
-| `{{ADAPTER_NAME}}` | `{{LOCATION}}` | {{PURPOSE}} |
-
----
-
-## 3. Cross-Port Invariants
-
-- {{INVARIANT_1}}
-- {{INVARIANT_2}}
-- New ports must be defined in `domain/ports`; adapters go in `infrastructure/`.
-- Each port needs one clear owner and at least one real caller. Avoid speculative ports without a concrete adapter or testability need.
-
----
-
-> **Note**: The current ports.md is a template. Replace `{{...}}` placeholders with your project's domain details. Refer to `Harness/data-flow.md` to understand how ports are orchestrated.

package/templates/common/docs/features/_template.md

@@ -1,177 +0,0 @@
-# {{FEATURE_NAME}}
-
-> **When to use**: Every PRD scope item in `Harness/research/PRD.md` Section 2 must have a feature doc — either a new one from this template, or an iteration on an existing one. Do not code a PRD scope item without a corresponding features doc.
->
-> **New vs iterate**: If the scope item has ≥85% overlap with an existing feature doc, iterate the existing doc (bump `Version`, add a `## Changelog` entry). If overlap is below 85%, create a new file from this template. When in doubt, ask the user.
-
-> **Status**: Draft / In Progress / Blocked / Done
-> **Created**: {{YYYY-MM-DD}}
-> **Version**: 1
-> **Owner**: {{OWNER_OR_AGENT}}
-> **Related Docs**: {{PRD_OR_ARCH_DOC_LINKS}}
-
----
-
-## 1. Requirements
-
-### 1.1 Background
-
-{{WHY_THIS_FEATURE_EXISTS}}
-
-### 1.2 Goals
-
-- {{GOAL_1}}
-- {{GOAL_2}}
-
-### 1.3 Non-Goals
-
-- {{NON_GOAL_1}}
-- {{NON_GOAL_2}}
-
-### 1.4 Acceptance Criteria
-
-- [ ] {{ACCEPTANCE_CRITERION_1}}
-- [ ] {{ACCEPTANCE_CRITERION_2}}
-- [ ] {{ACCEPTANCE_CRITERION_3}}
-
-### 1.5 Optimistic UI Rollback
-
-If any UI mutation happens before an async operation completes (DOM replacement,
-state update, visual feedback), list the rollback path for when the operation fails:
-
-| Mutation | Failure Recovery |
-|----------|-----------------|
-| {{MUTATION_1}} | {{ROLLBACK_1}} |
-| Not applicable — no optimistic mutations are used. | |
-
-### 1.6 UI Automation Hooks
-
-For TS/React or browser workflows, define required stable accessible labels/roles and stable test hooks such as `data-testid` before implementation. These selectors must cover critical UI controls and states so CDP, Playwright, and manual verification can target inputs, buttons, filters, rows, empty/error/loading states, dialogs, navigation, and submitted/saved/error feedback without brittle DOM paths.
-
-| Element / State | Accessible Role / Label | `data-testid` | Verification Target |
-| --- | --- | --- | --- |
-| {{INPUT_OR_CONTROL}} | {{ROLE_OR_LABEL}} | {{DATA_TESTID}} | {{PLAYWRIGHT_OR_MANUAL_CHECK}} |
-| {{EMPTY_ERROR_LOADING_OR_ROW_STATE}} | {{ROLE_OR_LABEL}} | {{DATA_TESTID}} | {{PLAYWRIGHT_OR_MANUAL_CHECK}} |
-| Not UI-facing | N/A | N/A | N/A |
-
----
-
-## 2. Design
-
-### 2.1 Impact Scope
-
-| Area | Impacted? | Notes |
-| --- | --- | --- |
-| `Harness/architecture.md` | {{YES_NO}} | {{NOTE}} |
-| `Harness/domain/ports.md` | {{YES_NO}} | {{NOTE}} |
-| `Harness/data-flow.md` | {{YES_NO}} | {{NOTE}} |
-| `Harness/state-machines.md` | {{YES_NO}} | {{NOTE}} |
-| tests | {{YES_NO}} | {{NOTE}} |
-
-### 2.2 Allowed Write Set
-
-- `{{PATH_OR_GLOB_1}}`
-- `{{PATH_OR_GLOB_2}}`
-
-### 2.3 Forbidden Scope
-
-- `{{PATH_OR_BEHAVIOR_1}}`
-- `{{PATH_OR_BEHAVIOR_2}}`
-
-### 2.4 Approach
-
-#### Candidate Approaches
-
-| Approach | Pros | Cons | Decision |
-| --- | --- | --- | --- |
-| {{OPTION_A}} | {{PROS_A}} | {{CONS_A}} | {{ACCEPT_REJECT}} |
-| {{OPTION_B}} | {{PROS_B}} | {{CONS_B}} | {{ACCEPT_REJECT}} |
-
-#### Rationale
-
-{{SELECTED_DESIGN_AND_RATIONALE}}
-
-### 2.5 Edge Cases
-
-- {{EDGE_CASE_1}} -> {{EXPECTED_BEHAVIOR_1}}
-- {{EDGE_CASE_2}} -> {{EXPECTED_BEHAVIOR_2}}
-
----
-
-## 3. Tasks
-
-> Every task must have a verification method. When a subagent is needed, define its role and write set first.
-
-| # | Task | Owner | Write Set | Verify |
-| --- | --- | --- | --- | --- |
-| 1 | {{WRITE_FAILING_TEST_OR_DOC_CHECK}} | {{OWNER}} | `{{PATH}}` | `{{COMMAND_OR_CHECK}}` |
-| 2 | {{IMPLEMENT_MINIMAL_CHANGE}} | {{OWNER}} | `{{PATH}}` | `{{COMMAND_OR_CHECK}}` |
-| 3 | {{SYNC_DOCS_OR_BOUNDARIES}} | {{OWNER}} | `{{PATH}}` | `{{COMMAND_OR_CHECK}}` |
-
-### Subagent Plan (required — justify if all No)
-
-Estimate the context budget for this feature. If the main agent would need to read >5 files or modify >3 files, subagents are mandatory per `.claude/rules/ecc/common.md`.
-
-| Agent / Pass | Required? | Mode | Read Boundary | Write Set | Verify |
-| --- | --- | --- | --- | --- | --- |
-| Planner | {{YES_NO}} | Parallel Read | `{{SCOPE}}` | none | `{{CHECK}}` |
-| Researcher / Docs Researcher | {{YES_NO}} | Parallel Read | `{{SCOPE}}` | none | `{{CHECK}}` |
-| Architect | {{YES_NO}} | Parallel Read | `{{SCOPE}}` | none | `{{CHECK}}` |
-| Explorer Pass | {{YES_NO}} | Parallel Read | `{{SCOPE}}` | none | `{{CHECK}}` |
-| Test Writer | {{YES_NO}} | Serial Write | `{{SCOPE}}` | `{{PATH}}` | `{{COMMAND}}` |
-| Implementer / Debugger | {{YES_NO}} | Serial Write | `{{SCOPE}}` | `{{PATH}}` | `{{COMMAND}}` |
-| Reviewer | {{YES_NO}} | Parallel Read | `{{SCOPE}}` | none | `{{CHECK}}` |
-| Verifier | {{YES_NO}} | Parallel Read | `{{SCOPE}}` | none | `{{COMMANDS}}` |
-
-**If all roles are No, justify:** {{WHY_MAIN_AGENT_CAN_HANDLE_ALONE}}
-
----
-
-## 4. Verification
-
-### 4.1 Test Results
-
-| Command | Result | Notes |
-| --- | --- | --- |
-| `{{TEST_COMMAND}}` | {{PASS_FAIL_NOT_RUN}} | {{NOTES}} |
-| `{{OTHER_COMMAND}}` | {{PASS_FAIL_NOT_RUN}} | {{NOTES}} |
-
-### 4.2 Review Findings
-
-- {{FINDING_OR_NONE}}
-
-### 4.3 Docs Sync
-
-- [ ] `Harness/architecture.md`
-- [ ] `Harness/domain/ports.md`
-- [ ] `Harness/data-flow.md`
-- [ ] `Harness/state-machines.md`
-- [ ] `Harness/research/research-results.md`
-- [ ] Not needed because {{REASON}}
-
-### 4.4 Decision Log
-
-| Date | Decision | Reason |
-| --- | --- | --- |
-| {{YYYY-MM-DD}} | {{DECISION}} | {{REASON}} |
-
-### 4.5 Closeout
-
-- [ ] Acceptance criteria satisfied.
-- [ ] Tests or manual verification recorded.
-- [ ] Boundary impact documented.
-- [ ] Remaining risks listed or explicitly none.
-- [ ] If docs/code/tests conflicted, Decision Log records how it was resolved.
-
-Remaining risks:
-- {{RISK_OR_NONE}}
-
----
-
-## 5. Changelog
-
-> Only populate when iterating an existing feature doc (Version ≥ 2).
-
-| Version | Date | What Changed | Reason |
-| --- | --- | --- | --- |
-| 1 | {{YYYY-MM-DD}} | Initial version | — |

package/templates/common/docs/harness/PLAN.md

@@ -1,52 +0,0 @@
-# PLAN.md — DEPRECATED
-
-Workflow state has moved to task-capsule structure. Do not append new content here.
-
-Active state:
-- `Harness/PROGRESS.md` — global task index and cross-task decisions
-- `Harness/tasks/<task-id>/PROGRESS.md` — per-task progress, phase, heartbeat
-- `Harness/tasks/<task-id>/PLAN.md` — per-task implementation plan, verification evidence
-
-Templates:
-- `Harness/tasks/_template/` — copy this directory to create a new task
-
-## Legacy Content (historical reference only)
-
-The sections below are archived from the monolithic PLAN.md era. Active task data has been migrated to `Harness/tasks/`.
-
----
-
-### Historical: Dogfood Bootstrap
-
-Goal: Dogfood the generated Harness scaffold inside this repository so future agents use root `Harness/` routing instead of stale `docs/harness/` guidance.
-
-**Success Criteria** (all verified):
-- [x] Root `CLAUDE.md` routes through `Harness/MEMORY.md` and `Harness/README.md`
-- [x] Root `MEMORY.md` no longer contains stale `docs/harness/` paths or template placeholders
-- [x] Root `Harness/` and `.claude/` dogfood runtime assets exist
-- [x] Harness strict validation passes
-- [x] Repository tests pass
-
-**Decisions:**
-| Date | Decision | Reason |
-|------|----------|--------|
-| 2026-06-24 | Dogfood root `Harness/` while keeping templates under `templates/` | Separate package source from operating harness |
-| 2026-06-24 | memory-master + context-master added to commonAgents | Global memory and context management |
-
-### Historical: WF Conflict Fix
-
-Goal: Fix WF-mode orphaned files and conflicts: align commands/wf.md, resolve subagent count tension, fix README "may" vs "MUST", add memory-master and context-master agents.
-
-**Subagent Dispatch:**
-| Agent | Mode | Purpose | Status |
-|-------|------|---------|--------|
-| Subagent 1 | Serial Write | Create memory-master.md, context-master.md, update commands/wf.md | Verified |
-| Subagent 2 | Serial Write | Fix agent-workflow.md, dispatch.md, README.md conflicts | Verified |
-| Subagent 3 | Serial Write | Update WF.md, wf-mode/SKILL.md, subagents.md, MEMORY.md, context-loading.md, CLAUDE.md, validate-harness.mjs | Verified |
-| Subagent 4 | Serial Write | Sync template changes to dogfood runtime files | Verified |
-
-**Verification:**
-| Check | Result | Notes |
-|-------|--------|-------|
-| `node Harness/scripts/validate-harness.mjs --strict` | Pass | all invariants preserved |
-| `npm test` | Pass | 58/58 tests passed |

package/templates/common/docs/harness/data-flow.md

@@ -1,59 +0,0 @@
-# Data Flow — {{projectName}}
-
-> **Purpose**: Define the complete lifecycle of each event/request — happy path + all failure branches.
-> **This is the most important runtime-flow file in `Harness/`** — what AI most often invents during implementation is failure-path behavior. Write it clearly and it won't.
->
-> Philosophy source: EventCatalog pattern + arc42 Chapter 6 (Runtime View).
-
----
-
-## 1. Event Catalog
-
-| Event Type | Producer | Consumer | Payload Key Fields | Delivery Semantics | Ordering Requirements |
-| --- | --- | --- | --- | --- | --- |
-| `{{EVENT_1}}` | `{{PRODUCER}}` | `{{CONSUMERS}}` | `{{KEY_FIELDS}}` | {{SEMANTICS}} | {{ORDERING}} |
-
----
-
-## 2. Core Flows
-
-### 2.1 Happy Path
-
-```mermaid
-sequenceDiagram
-    participant Caller
-    participant Runner
-    participant Bus as EventBus/Audit
-    participant Port1 as {{PORT_NAME_1}}
-    participant Port2 as {{PORT_NAME_2}}
-
-    Caller->>Runner: {{ENTRY_POINT}}
-    Runner->>Bus: publish {{START_EVENT}}
-    Runner->>Port1: {{ACTION_1}}
-    Port1-->>Runner: {{RESULT_1}}
-    Runner->>Port2: {{ACTION_2}}
-    Port2-->>Runner: {{RESULT_2}}
-    Runner->>Bus: publish {{END_EVENT}}
-    Runner-->>Caller: {{FINAL_RESULT}}
-```
-
-### 2.2 Failure Paths
-
-Each failure point must clearly document:
-- **Trigger condition**
-- **System behavior**
-- **Event publishing**
-- **Caller perception**
-- **Recovery method**
-
----
-
-## 3. Error Handling Conventions
-
-- **Retryable errors**: {{POLICY}}
-- **Non-retryable errors**: {{POLICY}}
-- **Silent ignore**: {{POLICY}}
-
----
-
-> **Note**: This data-flow.md is currently an empty template. Fill it in according to your project's actual flows. For format reference, see real project examples in the ECC repository.

package/templates/common/docs/harness/state-machines.md

@@ -1,58 +0,0 @@
-# State Machines — {{projectName}}
-
-> **Responsibility**: Define the states, transitions, guard conditions, and boundary behaviors for every stateful component. The majority of bugs in long-running harness pipelines originate from illegal state transitions.
->
-> Philosophical source: UML 2.5.1 Section 15.3.14 + "The transition table is the single most important artifact in the document."
-
----
-
-## State Machine Template
-
-Fill out each stateful component using this format:
-
-Before defining states, name the state owner and persistence level. State that crosses agent handoff, retry, browser session, API workflow, or release boundary must have explicit transitions; temporary derived state should stay local and should not become a new state machine.
-
-### State Ownership
-
-| State Slice | Owner | Persistence | Notes |
-| --- | --- | --- | --- |
-| `{{STATE_SLICE}}` | `{{OWNER}}` | durable / runtime / derived / external | {{NOTES}} |
-
-### State Enumeration
-
-| State | Description | Entry Condition | Exit Condition |
-| --- | --- | --- | --- |
-| `{{STATE_1}}` | {{DESCRIPTION}} | {{CONDITION}} | {{CONDITION}} |
-| `{{STATE_2}}` | {{DESCRIPTION}} | {{CONDITION}} | {{CONDITION}} |
-
-### State Transition Diagram
-
-```mermaid
-stateDiagram-v2
-    [*] --> {{INITIAL_STATE}}
-    {{INITIAL_STATE}} --> {{STATE_2}} : {{TRIGGER}}
-    {{STATE_2}} --> {{INITIAL_STATE}} : {{TRIGGER}}
-```
-
-### Transition Table (Most Important)
-
-| Current State ↓ / Event → | `{{EVENT_1}}` | `{{EVENT_2}}` | `{{EVENT_3}}` |
-| --- | --- | --- | --- |
-| **`{{STATE_1}}`** | {{TARGET}} | {{TARGET}} | {{TARGET}} |
-| **`{{STATE_2}}`** | {{TARGET}} | {{TARGET}} | {{TARGET}} |
-
-### Guard Conditions
-
-| Transition | Guard Condition | Notes |
-| --- | --- | --- |
-| `{{SOURCE}} -> {{TARGET}}` | {{GUARD}} | {{NOTE}} |
-
-### Illegal Transitions
-
-| Transition | Why Illegal |
-| --- | --- |
-| `{{SOURCE}} -> {{TARGET}}` | {{REASON}} |
-
----
-
-> **Note**: The current state-machines.md is an empty template. Please fill it in according to the project's actual stateful components.