create-harness-vibe-coding 0.8.19 → 0.9.3

package/templates/common/Harness/specs/runtime/command-surface.json

@@ -224,6 +224,34 @@
         "codexSkill": true,
         "helpRow": true
       }
+    },
+    {
+      "id": "wf-init",
+      "classification": "direct",
+      "aliases": ["/wf-init", "$wf-init", "/skills wf-init"],
+      "entersWf": false,
+      "taskCapsulePolicy": "none",
+      "surfaces": {
+        "claudeCommand": true,
+        "opencodeCommand": true,
+        "claudeSkill": true,
+        "codexSkill": true,
+        "helpRow": true
+      }
+    },
+    {
+      "id": "wf-search",
+      "classification": "direct",
+      "aliases": ["/wf-search", "$wf-search", "/skills wf-search"],
+      "entersWf": false,
+      "taskCapsulePolicy": "none",
+      "surfaces": {
+        "claudeCommand": true,
+        "opencodeCommand": true,
+        "claudeSkill": true,
+        "codexSkill": true,
+        "helpRow": true
+      }
     }
   ]
 }

package/templates/common/Harness/specs/runtime/context-loading.md

@@ -31,6 +31,12 @@ files, contracts, tests, or evidence to stay under budget.
 
 After the tier is selected, load other docs only by trigger.
 
+## Task Context Pack and Research Gate
+
+Use `task-context.mjs pack/show` for bounded role packs/pointers. Run
+`research-policy.mjs decide` before web/GitHub/HF lookup; record source/adoption
+evidence. Never preload full logs; structural, not semantic proof.
+
 Escalation rule: when unsure whether a file is required, prefer targeted
 keyword search or a one-file read over guessing from memory. Escalate from a
 smaller profile to the next targeted profile only when the new file directly

package/templates/common/Harness/specs/runtime/dispatch.md

@@ -4,8 +4,16 @@ Purpose: coordinate a small set of subagents without building a scheduler.
 
 Use [subagents.md](subagents.md) for orchestration strategy. Use this file for the dispatch table, handoff format, and status protocol.
 
+WF/WF-MAX: [context pack/research gate](context-loading.md#Task Context Pack and Research Gate).
+
 Use when work needs parallel reading, independent review, cross-layer analysis, or more than one bounded implementation pass.
 
+## Runtime model capability declarations
+
+Native catalogs are authoritative. See [capability fallback](../../scripts/README.md#runtime-capability-declarations)
+for exact operator config and HTTP rejection; fallback declarations are not
+provider measurement.
+
 ## Principles
 
 - Main agent owns the final decision, integration, and verification.
@@ -13,7 +21,7 @@ Use when work needs parallel reading, independent review, cross-layer analysis,
 - Important assumptions, decisions, blockers, evidence, and handoffs must be written to `Harness/tasks/<task-id>/PROGRESS.md` and `Harness/tasks/<task-id>/PLAN.md`, the current feature doc, `Harness/MEMORY.md`, or `Harness/memory/*` as appropriate.
 - Resumable state is governed by [WF-STATE.md](../workflows/WF-STATE.md). On session start, the controller reads STATE.json before building a fresh dispatch table.
 - PRD-derived Acceptance Criteria are the source of truth. Dispatch packets must carry the relevant AC IDs and contracts.
-- Agent count: default (non-WF) <=3 active agents; `/wf` selects a tier dynamically per [WF-KERNEL.md](../workflows/WF-KERNEL.md) (Light/Standard/Full); `/wf-max` inherits the selected tier and adds maximum safe fan-out (WF-Max-Useful default; WF-Max-Strict explicit only), removing the Harness default cap through the span formula. WF-MAX must attempt native subagent fan-out and record `fanoutAttempted: true` before any solo fallback. Real concurrency is still bounded by runtime thread budget, config, billing, and local resources. Use current runtime subagents first, close completed agents, then peer-CLI overflow (`claude -p`, `codex exec`, or `opencode run --agent <role> --dir .`). Do not scaffold Codex scalar `[agents]` capacity fields into project `.codex/config.toml`; probe the installed runtime and manage Codex caps through the dispatch ledger unless the installed version accepts the config shape. Generated OpenCode config defaults to `subagent_depth = 2` for manager -> worker nesting. See [WF.md](../workflows/WF.md) and [WF-MAX.md](../workflows/WF-MAX.md).
+- Agent count: non-WF <=3; `/wf` selects tier; `/wf-max` defaults to Useful suppression with rationale, while explicit Strict attempts the span formula within runtime capacity; see [WF-MAX.md](../workflows/WF-MAX.md).
 - Read-only agents may run in parallel.
 - Writing agents run serially unless write sets are disjoint.
 - Use a worktree when two agents may touch overlapping files or long-running branches.

package/templates/common/Harness/specs/runtime/subagents.md

@@ -9,6 +9,21 @@ Cache-first discipline: subagent context packs follow
 docs and selected files, keep dispatch fields in deterministic order, defer
 unused skill/tool schemas, and return bounded summaries instead of transcripts.
 
+For WF and WF-MAX dispatch, the controller first creates a bounded pack with
+`node Harness/scripts/task-context.mjs pack <task-id> --project <absolutePath> --role <role>
+--budget-bytes <n> --json`. The dispatch packet references the resulting hash,
+budget, role/work-item filter, omitted sections, and evidence pointers. A
+resumed agent consumes a new pack; it does not receive the full task transcript.
+Pack structure is not semantic proof, so validators still run the behavior
+checks required by the acceptance criteria.
+
+External lookup is conditional. Run
+`node Harness/scripts/research-policy.mjs decide --trigger <trigger>
+--task-type <type> --json` only when a capability gap, volatile API, explicit
+request, repeated failure, or benchmark gap is present. If search is allowed,
+the assigned agent reads the source body and records URL, title, version,
+license, date, and adopt/adapt/reject rationale; otherwise reuse local evidence.
+
 project files are the only durable communication channel; chat/subagent transcript state is non-authoritative. Important assumptions, decisions, blockers, evidence, and handoffs must be written to `Harness/tasks/<task-id>/PROGRESS.md` and `Harness/tasks/<task-id>/PLAN.md`, the current feature doc, `Harness/MEMORY.md`, or `Harness/memory/*` as appropriate.
 
 Subagent work is acceptance-driven. Use [AGENT_ISOLATION.md](../protocols/AGENT_ISOLATION.md)
@@ -202,11 +217,11 @@ matrix from running behavior and evidence, not from the implementer's summary.
 If either reviewer finds issues, the implementer or debugger fixes them and the same gate runs again. Do not move to final acceptance with open critical/high findings or without reflector PASS.
 
 For `/wf-review`, use the installed `reviewer` role before inventing any
-ad hoc review prompt. If no peer CLI is available, dispatch `reviewer` as an
-independent same-runtime subagent context; for broad WF-MAX review, dispatch
-`review-manager` when the runtime supports nested reviewer fan-out. Reviewer
-agents report suggestions only. The controller accepts, rejects, or escalates
-each finding and owns the final decision.
+ad hoc review prompt. Dispatch it as an independent clean native subagent
+context; peer CLIs are forbidden for this command. For broad reviews, dispatch
+`review-manager` only when the runtime supports bounded native nested fan-out.
+Reviewer agents report suggestions only. The controller accepts, rejects, or
+escalates each finding and owns the final decision.
 
 ### OpenCode Reviewer Caveat
 

package/templates/common/Harness/specs/workflows/WF-AUTO-SPARK.md

@@ -20,6 +20,25 @@ But perpetual search without direction = drift. The **Roadmap** is the anchor.
 
 ## Inherited Execution Chain
 
+### Context and Conditional Research
+
+Spark discovery starts from the bounded role-scoped task pack:
+
+```text
+node Harness/scripts/task-context.mjs pack <task-id> --project <absolutePath> --role <role> --budget-bytes <n> --json
+```
+
+Workers and resumed cycles consume a fresh `show`/`pack`, not the full task
+log. Before a spark search, ask:
+
+```text
+node Harness/scripts/research-policy.mjs decide --trigger <trigger> --task-type <type> --json
+```
+
+Search results must be read from the source body and recorded with URL, title,
+version, license, date, and an adopt/adapt/reject rationale. This policy keeps
+spark search conditional and does not require network access for every cycle.
+
 WF-AUTO-SPARK is a `/wf` variant layered on WF-AUTO: it inherits the WF-KERNEL contract via WF-AUTO and WF constraints, and does not define an independent heavy process. External spark search replaces discovery only; it does not replace acceptance, implementation, review, verification, reflection, or evidence.
 
 Accepted spark candidates re-enter the standard W2-W5 gates per [WF-KERNEL.md](WF-KERNEL.md): implementer (one file_claim, ≤3 files, ≤50 lines), verifier, reviewer(s), reflector. Spark searchers are read-only. Any implementation must use the dispatch packet from `Harness/specs/runtime/dispatch.md` with explicit write set, forbidden truth files, AC IDs, and verification commands. A candidate with no verifier evidence or no reflector PASS is not accepted, even if the idea is valuable.

package/templates/common/Harness/specs/workflows/WF-AUTO.md

@@ -17,6 +17,27 @@ This fills the gap between:
 
 ## Organization Model
 
+### Context and Conditional Research
+
+Each bounded auto cycle uses a role-scoped task context pack for the controller,
+probe, and worker inputs:
+
+```text
+node Harness/scripts/task-context.mjs pack <task-id> --project <absolutePath> --role <role> --budget-bytes <n> --json
+```
+
+Checkpoint and recovery consume `show`/`pack` rather than the complete cycle
+log. External lookup begins only after:
+
+```text
+node Harness/scripts/research-policy.mjs decide --trigger <trigger> --task-type <type> --json
+```
+
+When `search: true`, record each source's URL, title, version, license, date,
+and adopt/adapt/reject rationale. Auto cycles remain reuse-first when no
+capability-gap, volatile-API, explicit-request, repeated-failure, or
+benchmark-gap trigger exists.
+
 WF-AUTO uses the same acceptance-driven mother flow per cycle. Each selected
 optimization becomes a Mini PRD with AC IDs, a test/validation plan, bounded
 implementation, independent validation, review, debug if needed, and memory.

package/templates/common/Harness/specs/workflows/WF-KERNEL.md

@@ -181,8 +181,10 @@ Delta from `/wf`:
 - Each write-unit = one file_claim = one implementer Worker
 - Managers coordinate per-domain fan-out (explore, architect, implement, review)
 - CEO/controller never writes source; delegates all production edits to Workers
-- WF-Max-Useful (default): fan-out only where writeSets are meaningfully independent
-- WF-Max-Strict (explicit `--strict`): unconditional fan-out per span formula
+- WF-Max-Useful (default): fan-out only for independent writeSets/acceptance;
+  persist `fanoutSuppressed` with reason/capacity evidence on suppression.
+- WF-Max-Strict (explicit `--strict`, `strict wf-max`, or `strict mode`): attempt
+  the span formula within runtime capacity.
 - Disjoint writeSets → parallel; overlapping → serial wave or worktree isolation
 - task-scribe continuously maintains dispatch ledger and heartbeat
 - `idleWorker -> nextReady` queue: dispatch immediately when a slot opens

package/templates/common/Harness/specs/workflows/WF-MAX.md

@@ -16,27 +16,54 @@ WF-MAX is **explicit only**. Enter ONLY when the user explicitly types `/wf-max`
 | State | Controller or task-scribe | task-scribe continuously maintains dispatch ledger |
 | Source edits | Implementer writes | Workers write ONLY dispatch.writeSet; CEO never writes source |
 
+The manager ranges above describe available role shapes, not a fixed headcount.
+WF-Max-Useful chooses no spawn or a cheap role pass when dependency, acceptance,
+coordination, budget, or runtime evidence makes fan-out uneconomic.
+
 ## Fan-Out Modes
 
-**WF-Max-Useful** (default): fan-out only where writeSets or review lenses are meaningfully independent. Overhead > 0.30 degrades a wave to flat role pass. This does not authorize CEO source edits: source implementation still goes through an implementer/Worker role, or the run records an honest downgrade before editing.
+**WF-Max-Useful** (default): the CEO makes an evidence-based spawn decision
+from dependency shape, independent acceptance, expected coordination benefit,
+token/time budget, and actual runtime capacity. A dependency chain, no
+independent acceptance, or coordination cost without measurable benefit is a
+valid no-spawn outcome. Persist `fanoutSuppressed: true`, the reason, and the
+budget/capacity evidence in the task ledger. This does not authorize CEO source edits;
+required production changes still go through a Worker.
+
+**WF-Max-Strict** (explicit `--strict`, `strict wf-max`, or `strict mode`):
+unconditional fan-out per the span formula, bounded by real runtime capacity.
+Strict mode attempts native fan-out first; on a failure record
+`fanoutAttempted: true`, runtime/channel, requested roles, limits, failure, and
+fallback in task state. Strict mode is never inferred from task size.
 
-**WF-Max-Strict** (explicit `--strict`, `strict wf-max`, or `strict mode`): unconditional fan-out per span formula. Every file gets a Worker.
+## Mandatory Fan-Out Contract (Strict mode only)
 
-## Mandatory Fan-Out Contract
+The mandatory portion of this contract applies only after an explicit
+`--strict`, `strict wf-max`, or `strict mode` request. In that mode the
+controller MUST attempt native subagent fan-out before implementation planning
+is considered complete, bounded by the real runtime capacity. Useful mode may
+record a no-spawn decision and does not inherit this requirement.
 
-`/wf-max` MUST attempt native subagent fan-out before implementation planning is considered complete. A solo controller path is allowed only after an explicit degradation record.
+## Context and Research Contract
 
-Minimum W0 attempt:
+Before planning or dispatch, generate the bounded task input:
 
-- Start `task-scribe` when available to maintain task state and the dispatch ledger.
-- Start at least one independent read-only planning/exploration/review lane. For real multi-domain tasks, prefer `explore-manager` plus scoped researchers or codebase explorers.
-- Record `fanoutAttempted: true`, runtime, channel tried, agents requested, configured/runtime limit facts, result, and degradation reason in the task PLAN or PROGRESS.
+```text
+node Harness/scripts/task-context.mjs pack <task-id> --project <absolutePath> --role <role> --budget-bytes <n> --json
+```
 
-Mode interaction:
+The controller passes the role/work-item pack to each Worker. Resume consumes a
+new `show`/`pack` instead of the full task log; `--input` is optional for pack.
+Before any external lookup, run:
+
+```text
+node Harness/scripts/research-policy.mjs decide --trigger <trigger> --task-type <type> --json
+```
 
-- WF-Max-Useful may shrink the fan-out after the first native attempt when write sets or review lenses are not meaningfully independent. It may not silently skip the attempt.
-- WF-Max-Strict continues through the span formula until the Harness caps, runtime caps, user budget, or safety gates stop dispatch.
-- If native manager fan-out is unavailable, the controller dispatches leaf agents directly with exact WF-MAX dispatch packets; if no independent channel exists, stop honestly and ask the user.
+Search current web, GitHub, or Hugging Face primary sources only when the result
+has `search: true`. Record URL, title, version, license, checked date, and an
+`adopt`, `adapt`, or `reject` rationale. Reuse local evidence when no trigger
+exists; do not force network research or full-memory loading.
 
 OpenCode-specific requirement: project `opencode.json` must set `subagent_depth >= 2` for manager -> worker nesting, and WF-MAX manager agents must expose `permission.task` allowlists for their child agents. Without those two settings, OpenCode may accept `/wf-max` but fail to fan out from manager subagents.
 

package/templates/common/Harness/specs/workflows/WF-STATE.md

@@ -10,9 +10,23 @@ manager, async runtime, or graph framework.
 |------|------|
 | `Harness/PROGRESS.md` | Derived global active pointer and Task Index |
 | `Harness/tasks/<task-id>/STATE.json` | Canonical machine-readable resume truth |
+| `Harness/tasks/INDEX.json` | Generated machine route for project/group/status/date queries |
+| `Harness/tasks/INDEX.md` | Generated human route for the same task collection |
 | `Harness/tasks/<task-id>/PROGRESS.md` | Human-readable summary |
 | `Harness/tasks/<task-id>/PLAN.md` | Plan, decisions, scope context |
 
+## Task Context Packs
+
+`STATE.json.context` is optional for legacy capsules. When present it contains
+only `intent` (with immutable `original`, `current`, and append-only `changes`),
+`constraints`, `facts`, `assumptions`, `decisions`, `evidence`, `attempts`, and
+`handoff`. The root `STATE.json.nextAction` is the only next-action field.
+Use `node Harness/scripts/task-context.mjs update|show|pack <task-id>` for
+bounded context updates and role/work-item packs. Packs include evidence paths
+or URLs and claims, never the body of a raw log; UTF-8 byte budgets fail
+explicitly when mandatory intent, constraints, unresolved items, or nextAction
+cannot fit. Legacy context is reconstructed from PLAN/STATE for read-only use.
+
 Task id convention: new task capsules MUST use
 `task-<verb>-<noun>[-detail]` (kebab-case, 2-5 words after the prefix), for
 example `task-fix-login-flow`. Do not create bare task names such as
@@ -22,9 +36,12 @@ example `task-fix-login-flow`. Do not create bare task names such as
 
 ### status
 
-`active`, `blocked`, `in_progress`, `running`, `pending`,
+`active`, `blocked`, `closed`
+
+Legacy repositories may still contain `in_progress`, `running`, `pending`,
 `needs-user-decision`, `complete`, `verified`, `archived`, `abandoned`,
-`obsolete`, `done`, `closed`, `closeout`, `skipped`, `failed`
+`obsolete`, `done`, `closeout`, `skipped`, or `failed`. `task-state.mjs` reads
+those values and normalizes them to the three lifecycle statuses on new writes.
 
 ### phase
 
@@ -44,6 +61,11 @@ Legacy aliases such as `Implementation`, `Validation`, and
 `direct`, `wf`, `wf-max`, `wf-auto`, `wf-auto-spark`, `wf-review`,
 `wf-browser`
 
+Only `wf` and `wf-max` own the durable task lifecycle. The auto/spark modes
+use their separate continuous capsule; review/browser are capability modes.
+They remain valid explicit mode values for compatibility, but do not promote a
+normal task into cross-session WF management.
+
 ### tier
 
 `none`, `light`, `standard`, `full`, `max-useful`, `max-strict`
@@ -65,12 +87,18 @@ Legacy aliases such as `Implementation`, `Validation`, and
    not.**
 7. **If STATE.json conflicts with PLAN/PROGRESS, controller stops and reconciles
    before continuing.**
+8. **Durable WF ownership is creation-time opt-in.** A task in `wf` or
+   `wf-max` remains WF-managed for its whole lifetime; its mode cannot be
+   downgraded or exited. `closed` is terminal for that capsule. Start the
+   next unit of work in a new capsule with an explicit mode.
 
 ## CLI Contract
 
 Use `Harness/scripts/task-state.mjs` as the deterministic state writer:
 
 - `node Harness/scripts/task-state.mjs list --json`
+- `node Harness/scripts/task-state.mjs index`
+- `node Harness/scripts/task-state.mjs query <keyword> --project <project> --json`
 - `node Harness/scripts/task-state.mjs validate --json`
 - `node Harness/scripts/task-state.mjs reconcile --dry-run --json`
 - `node Harness/scripts/task-state.mjs reconcile --apply`
@@ -79,8 +107,9 @@ Use `Harness/scripts/task-state.mjs` as the deterministic state writer:
 - `node Harness/scripts/task-state.mjs archive --keep 5 --dry-run --json`
 - `node Harness/scripts/task-state.mjs archive --keep 5 --apply`
 
-Do not rely on prompt instructions alone to keep active task, task `STATE.json`,
-task `PROGRESS.md`, and root `Harness/PROGRESS.md` synchronized.
+Do not rely on prompt instructions alone to keep task `STATE.json`, task
+`PROGRESS.md`, the generated task route, and root `Harness/PROGRESS.md`
+synchronized.
 
 ## Links (Cross-Task Dependencies)
 
@@ -121,13 +150,15 @@ subagent dispatches.
 
 ## Open Tasks
 
-"Open tasks" are non-archived task capsules with status one of:
-`active`, `in_progress`, `running`, `pending`, `blocked`,
-`needs-user-decision`.
+"Open tasks" are task capsules with lifecycle status `active` or `blocked`.
+Legacy open values are accepted while an old repository is being migrated.
 
-The active pointer (`Harness/PROGRESS.md`) marks the single task the agent
-should resume. Other open tasks remain visible in the Task Index but are not
-automatically loaded.
+The active pointer (`Harness/PROGRESS.md`) is a focus/resume pointer, not a
+lock. Multiple open tasks are valid and remain visible in `INDEX.json`,
+`INDEX.md`, and `list --by-group`; `set-active` only changes which open WF task
+is loaded first on resume while a managed WF task is open. It cannot replace
+that focus with a direct task. A direct task may coexist, but it never acquires
+WF lifecycle ownership.
 
 ## Queue Entry Normalization
 
@@ -161,12 +192,16 @@ New window / session start:
      blocked (needs resolution), done.
    - nextAction (what to do next).
    - **links.dependsOn**: if non-empty, check whether any dependency tasks are
-     still open (their STATE.json has a non-archived status). Report blocked
-     dependencies to the user.
+     still open (their STATE.json status is `active` or `blocked`, after legacy
+     normalization). Report blocked dependencies to the user.
    - **workItems[]**: if non-empty, inspect items with status `running` or
      `ready` for parallel dispatch candidates.
-4. Do NOT bulk-read `Harness/tasks/` to find context. Use the active pointer.
-5. Direct simple tasks may skip STATE/PLAN/PROGRESS unless the user says
+4. Do NOT bulk-read `Harness/tasks/` to find context. Use the active pointer
+   and `Harness/tasks/INDEX.json` for deterministic project/group lookup.
+5. If the active pointer targets an open `wf`/`wf-max` task, automatically
+   resume WF mode from that capsule even when the user does not repeat `/wf`.
+   If it targets a direct or capability-mode task, do not enter WF.
+6. Direct simple tasks may skip STATE/PLAN/PROGRESS unless the user says
    "continue"/"resume".
 
 ## State Transitions
@@ -181,6 +216,19 @@ intake -> clarify -> requirements -> prd -> acceptance -> plan
 Any phase may transition to `blocked` if a dependency, user decision, or external
 input is required.
 
+Task lifecycle is deliberately smaller than phase state:
+
+```text
+direct ------------------------------> closed
+wf / wf-max (immutable ownership) ---> closed
+active <-----------------------------> blocked
+```
+
+An open managed task may move between `active` and `blocked`, then only to
+`closed`. It cannot return from `closed`, change to `direct`, or be reused as a
+new task. Multiple capsules may be open at once; the active pointer selects
+one managed focus without collapsing the collection.
+
 ## Dispatch Ledger
 
 Every dispatch packet MUST have an `id`. On return, controller or task-scribe

package/templates/common/Harness/specs/workflows/WF.md

@@ -32,6 +32,28 @@ These are NOT WF triggers:
 - Multi-step work, multi-file changes, complexity, uncertainty, architecture scope, browser/API behavior, repeated failure
 - Those may need planning, subagents, or tests — but not WF
 
+### Durable Task Lifecycle
+
+The task lifecycle is separate from workflow capability routing:
+
+- `/wf` or `/wf-max` explicitly creates or enters a task with durable WF
+  ownership. Its `STATE.json.mode` is immutable for the lifetime of that task.
+- An open `wf`/`wf-max` task is automatically resumed by Harness on the next
+  session from `Harness/PROGRESS.md` plus `STATE.json`; repeating the trigger is
+  optional.
+- A task that never explicitly used `/wf` or `/wf-max` remains outside the WF
+  lifecycle forever. Complexity, project membership, `wf-auto`, `wf-review`,
+  and UI activity do not promote it.
+- Closing is terminal. To continue with a new WF unit, close the current task
+  and create a new capsule with an explicit WF trigger. Multiple task capsules
+  can remain open, but only a managed WF capsule can own the Harness resume
+  focus while one is active.
+
+`wf-auto` and `wf-auto-spark` retain their explicit continuous workflows and
+their `Harness/tasks/continuous/` capsule; they do not adopt ordinary task
+capsules. `wf-review` remains native review capability and never invokes an
+external CLI or recursively starts another review.
+
 ## Memory Preflight
 
 1. Load `CLAUDE.md`, `Harness/MEMORY.md` index only, then `Harness/README.md`.
@@ -45,6 +67,16 @@ listed router/workflow loads in stable order, load only routed skills/tools, and
 append task state, current runtime facts, and latest tool output after the
 stable docs. Do not bulk-load skill bodies, tool schemas, or `Harness/`.
 
+## Bounded Context and Conditional Research
+
+The controller creates a role-scoped pack with
+`task-context.mjs pack <task-id> --project <absolutePath> --role <role> --budget-bytes <n>
+--json`; it carries intent, constraints, unresolved handoff, and filtered
+evidence. Dispatch and resume consume `show`/`pack`, not the full task log.
+Before lookup, ask `research-policy.mjs decide`; only `search: true` permits
+current web/GitHub/Hugging Face reads with source metadata and an
+adopt/adapt/reject rationale. No trigger means reuse-first.
+
 ## Standard Orchestration Loop
 
 The `/wf` kernel follows a dependency-driven ready-queue, NOT a fixed serial phase list.

package/templates/common/Harness/tasks/INDEX.json

@@ -0,0 +1,7 @@
+{
+  "schemaVersion": 1,
+  "generatedAt": null,
+  "sourceOfTruth": "Harness/tasks/*/STATE.json",
+  "projects": {},
+  "tasks": []
+}

package/templates/common/Harness/tasks/INDEX.md

@@ -0,0 +1,12 @@
+# Task Index (generated)
+
+Generated: not yet generated
+
+This file is derived from task STATE.json files. Do not edit it directly.
+
+| Task | Project | Status | Phase | Created | Updated |
+|------|---------|--------|-------|---------|---------|
+
+## Projects
+
+- (none)

package/templates/common/Harness/tasks/_template/PLAN.md

@@ -30,6 +30,12 @@ Expanded evidence required when triggered by high-risk changes, broad cross-file
 
 - Add Given/When/Then, selector contracts, migration notes, or release evidence only when the task risk requires it.
 
+## Context Contract
+
+- Keep the original intent immutable; record later changes under `STATE.json.context.intent.changes`.
+- Store only compact constraints, facts, assumptions, decisions, evidence pointers, attempts, and handoff items. Keep raw logs outside `STATE.json`.
+- The canonical next action lives at the root `STATE.json.nextAction`; context packs must reference it rather than add another next-action field.
+
 ## Risks
 
 | Risk | Mitigation | Status |

package/templates/common/Harness/tasks/_template/PROGRESS.md

@@ -14,6 +14,11 @@ Phase heartbeat. Update on transitions, blockers, verification. Keep under 20 li
 
 - [ ] verification command
 
+## Context
+
+- Context is loaded from canonical `STATE.json`; evidence entries are pointers, not log bodies.
+- Record unresolved handoff items in `STATE.json.context.handoff.unresolved`.
+
 ## Log
 
 | Date | Phase | Note |

package/templates/common/Harness/tasks/_template/STATE.json

@@ -6,9 +6,31 @@
   "tier": "none",
   "phase": "intake",
   "gate": null,
+  "project": "default",
+  "tags": [],
+  "createdAt": "2026-07-16T00:00:00.000Z",
+  "startedAt": null,
+  "closedAt": null,
   "updatedAt": "2026-07-16T00:00:00.000Z",
   "activeQuestion": null,
   "nextAction": "Define goal and acceptance criteria",
+  "context": {
+    "intent": {
+      "original": "",
+      "current": "",
+      "changes": []
+    },
+    "constraints": [],
+    "facts": [],
+    "assumptions": [],
+    "decisions": [],
+    "evidence": [],
+    "attempts": [],
+    "handoff": {
+      "summary": "",
+      "unresolved": []
+    }
+  },
   "acceptance": [],
   "links": {
     "dependsOn": [],

package/templates/common/Harness/templates/TEST_PLAN.template.md

@@ -2,13 +2,14 @@
 
 | AC ID | Test Level | File/Command | Evidence |
 | --- | --- | --- | --- |
-| AC-001 | Playwright + CDP | `npx playwright test {{SPEC_FILE}} --trace on` | trace + screenshot |
+| AC-001 | wf-browser control run + fallback Playwright/CDP when needed | `Harness/wf-browser/runs/<runId>/...` or `npx playwright test {{SPEC_FILE}} --trace on` | run manifest, action log, screenshot, UI tree, logs, network, trace |
 
 Required checks:
 
 - unit tests for pure logic
 - API/integration tests for API contracts
-- Playwright for user-visible paths
-- CDP/network assertions for frontend-backend side effects
-- screenshot/trace/video on browser validation failure
+- `wf-browser` control loop for browser-visible paths when the page can load the Harness Bridge
+- fallback Playwright/CDP for third-party pages, native browser capabilities, or bridge gaps
+- screenshot, UI tree, log, state, network, trace, or video artifact paths for browser validation
+- multi-window/subagent lease evidence when validating concurrent UI work
 - syntax-only checks, shallow renders, imports, typecheck, lint, and build success do not satisfy browser-visible ACs

package/templates/common/Harness/templates/UI_CONTRACT.template.md

@@ -1,11 +1,13 @@
 # UI Contract: {{FEATURE_NAME}}
 
-| Element | data-testid | Accessible Role/Label | States | AC IDs |
-| --- | --- | --- | --- | --- |
-| {{ELEMENT}} | `{{TEST_ID}}` | {{ROLE_OR_LABEL}} | default, loading, error, disabled | AC-001 |
+| Element | Capability ID | data-testid | Accessible Role/Label | Actions | Captures | States | AC IDs |
+| --- | --- | --- | --- | --- | --- | --- | --- |
+| {{ELEMENT}} | `{{CAPABILITY_ID}}` | `{{TEST_ID}}` | {{ROLE_OR_LABEL}} | `act.click`, `act.intent({{CAPABILITY_ID}})` | screenshot, ui-tree, state, logs | default, loading, error, disabled | AC-001 |
 
 Rules:
 
 - Prefer `data-testid` for critical automation selectors.
-- Accessible role/label may supplement but must not be unstable.
-- Cover inputs, buttons, rows/items, empty state, loading state, and error state.
+- Use stable accessible labels/roles for controls and icon-only buttons.
+- Add capability ids for first-party route, component, form, table, graph, canvas, and element targets.
+- Declare supported `act.*` operations and `observe.*` captures for complex widgets.
+- Cover inputs, buttons, filters, rows/items, empty state, loading state, and error state.

package/templates/common/Harness/wf-browser/README.md

@@ -0,0 +1,69 @@
+# wf-browser Runtime Artifacts
+
+`Harness/wf-browser/` stores browser debug/control evidence created by
+`wf-browser`, the Harness Bridge, and fallback browser drivers. Keep high-volume
+runtime data here instead of in chat, task state, or long markdown logs.
+
+## Layout
+
+```text
+Harness/wf-browser/
+  README.md
+  runs/
+    <runId>/
+      manifest.json
+      timeline.jsonl
+      sessions.json
+      windows/
+        <windowId>/
+          browser-launches.json
+          actions.jsonl
+          screenshots/
+          ui-tree/
+          state/
+          logs/
+          network/
+          ast/
+          replay/
+          analysis/
+  tmp/
+  cache/
+```
+
+## Rules
+
+- Partition artifacts by `runId`, `sessionId`, `windowId`, and `agentId`.
+- Store full screenshots, UI trees, app state, logs, network summaries, AST
+  dumps, replay data, and videos as files. WebSocket messages should carry only
+  bounded metadata, paths, hashes, sizes, and short summaries.
+- A write/control lease is exclusive per window. Multiple subagents may run at
+  the same time only when they own different windows or hold explicit read-only
+  observation leases.
+- `browser-allocate-many` creates one run with multiple window/lease/launch URL
+  assignments for concurrent subagent dispatch.
+- `browser-open --context isolated` opens a visible Chrome/Edge/Chromium window
+  with a per-run/window profile under `tmp/browser-profiles/` and stores launch
+  metadata under the window `analysis/` artifacts and `browser-launches.json`.
+- `browser-launches` lists recorded launches with process liveness, and
+  `browser-close --remove-profile true` closes selected launches and removes
+  their isolated profiles.
+- `browser-wait` waits for the requested run/window/agent frontend to register
+  before a subagent dispatches `observe.*`, `act.*`, or snapshot commands.
+- `browser-snapshot` captures the standard connected-window handoff bundle:
+  route, capabilities, UI tree, state, logs, network, replay, and diff.
+- `actions.jsonl` records every `act.*` command, target resolution, before/after
+  observation ids, status, and artifact paths.
+- `timeline.jsonl` records command lifecycle, route changes, console/runtime
+  errors, network events, mixed-control collisions, and cleanup.
+- Default local debugging is trusted and open. Do not redact artifacts unless
+  project policy or user instruction asks for redaction.
+
+## Cleanup
+
+Default retention is latest 20 runs or 7 days. Do not delete runs referenced by
+an active task. `tmp/browser-profiles/` is per-window launch scratch data; keep
+it only while the run is useful. Use
+`node Harness/scripts/wf-ui-control.mjs browser-close --remove-profile true` for
+per-window closeout, then `node Harness/scripts/wf-ui-control.mjs
+browser-cleanup` to preview run cleanup. Add `--apply true` only when the
+eligible run list is correct.