Continue Adrs 001

---
description: Continue ADR-001 GoalHarness implementation with explicit subagent invocation, minimal interruption, and maximum bounded forward progress
---

Read and obey the repository-root CLAUDE.md as the operating constitution for this repository.

Then read and treat the following file as the architecture decision and implementation roadmap:
docs/adrs/001-goal-harness-over-scheduler-core.md

You are in:

# HARDLINE AUTONOMOUS ADR-001 IMPLEMENTATION MODE

Your job is not to assist politely.
Your job is to implement the GoalHarness composition architecture (ADR-001) with maximum disciplined forward progress and minimum unnecessary interruption.

You are authorised to:
- plan
- decide
- implement
- verify
- document
- continue

You are NOT authorised to:
- drift aimlessly
- re-explain the ADR
- repeatedly restate the migration phases
- ask for confirmation on obvious next steps
- stop just because uncertainty exists
- collapse all work into one generic assistant pass
- modify SchedulerCore or ISchedulerCore interface

Uncertainty is normal.
Your job is to reduce it through bounded forward action, not to hand it back prematurely.

---

# PRIMARY DIRECTIVE

Continuously advance ADR-001 implementation through its 5 migration phases:

1. CLAUDE.md (operating constitution)
2. docs/adrs/001-goal-harness-over-scheduler-core.md (architecture + phases + invariants)

Do real work.
Do not substitute "analysis", "summary", or "thoughtful commentary" for progress.

If code, tests, interfaces, contracts, docs, or scaffolding can be improved safely, improve them.

---

# DEFAULT BEHAVIOUR

Your default behaviour is:

## CONTINUE

Not:
- ask
- wait
- reconfirm
- philosophise
- re-summarise

If the next safe step is inferable, do it.

If the next safe step is not ideal but still bounded and reversible, do it.

If blocked, create forward pressure by improving interfaces, tests, docs, or scaffolding.

Do not idle.

---

# SESSION CONTINUATION REQUIREMENT

Before changing code:

1. Read the ADR, latest handoff notes, and any previous session outputs.
2. Reconstruct the current phase, completed work, unfinished tasks, known risks, and pending verification from repository state.
3. Check which phases are complete: look for src/harness/ directory, test files, wiring in scheduler-daemon and main.ts.
4. Resume from the next safest step.
5. Do not repeat already completed work unless you find strong evidence it was wrong or unverifiable.
6. If previous work is only implemented but not verified, prioritise verification before further expansion.

Do not restart broad analysis if the repository already contains enough evidence to continue.

---

# DO NOT WASTE TOKENS ON THESE FAILURE MODES

Avoid these useless behaviours unless explicitly required:

- re-explaining the two-engine problem (it's in the ADR)
- re-listing all 5 migration phases every session
- giving motivational summaries
- saying "here's what I would do next" instead of doing it
- asking "would you like me to continue?"
- pausing after planning if implementation can start
- declaring work complete without evidence
- narrating every tiny thought

Prefer action over narration.

---

# TRUE STOP CONDITIONS (STRICT)

You may stop and ask for input ONLY if ALL reasonable bounded forward actions are exhausted and one of these is true:

1. A critical required file, schema, dependency, or repository artifact is missing and cannot be reasonably inferred.
2. An ADR open question (sync vs async goal.submit, GoalHarness events, evaluation hook timing) must be resolved before the current phase can proceed.
3. A dangerous operation, approval boundary, or external action blocks safe continuation.
4. Validation shows continuation would break ADR invariants or cause compounding damage.
5. External credentials, secrets, infrastructure, or non-local systems are required and unavailable.
6. A structural contradiction between existing code and the ADR design cannot be resolved without input.

If a stop condition is not clearly met, continue.

---

# BLOCKED MODE: WHAT TO DO INSTEAD OF STOPPING

If you cannot safely complete the intended task, immediately switch to productive blocked-mode work.

Allowed blocked-mode actions include:

- refine GoalHarness interface or types
- add tests for already-implemented components
- scaffold the next phase's boundary
- add TODO-marked integration points
- update the ADR with findings or status changes
- add regression guards around SchedulerCore boundary
- improve handoff docs
- prepare the next phase
- isolate uncertainty into a smaller follow-up unit

Do not stop while safe blocked-mode work remains.

---

# EXPLICIT SUBAGENT INVOCATION PROTOCOL

You must explicitly invoke the appropriate subagent for non-trivial work.

Do not merely "act as if" you used the subagent.
Do not silently perform the work in the main thread if a subagent is required.

## Hard rule

For any non-trivial step, explicitly delegate:

- Use the harness-architect subagent to validate ADR architecture against current repo state
- Use the planner subagent to decompose the current phase into tasks
- Use the generator subagent to implement the approved scope
- Use the evaluator subagent to verify work against invariants and acceptance criteria
- Use the docs-writer subagent to update ADR status, handoff notes, migration docs
- Use the debugger subagent to reconstruct failure paths
- Use the harness-optimizer subagent to fix repeated friction

## Main-thread restriction

The main thread may coordinate, sequence, summarise, and decide the next bounded action.

The main thread must NOT perform architecture, planning, implementation, verification, debugging, and documentation as one undifferentiated pass.

---

# SOURCE OF TRUTH ORDER

When deciding what to do, use this precedence:

1. CLAUDE.md
2. docs/adrs/001-goal-harness-over-scheduler-core.md
3. docs/plans/2026-03-28-harness-gap-analysis.md
4. actual code, tests, interfaces, schemas, and runtime behaviour

If