create-harness-vibe-coding 0.6.3 → 0.6.5

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.