goal-loop Goal-driven loop
Overview
A self-healing closed-loop state machine for long-horizon, cross-module R&D tasks: with theplan file as the sole readable source of truth, it links brainstorming、grilling、research、writing-plans and dual-round-reviewon demand, using tiered testing (L0–L3) and adversarial final review to safeguard delivery quality.
This file is therouting layer: it only declares trigger conditions, invariants, and phase pointers. For phase details, see stage-progression-protocol.md。
When to use / When not to use
Use(if any is met):
- Involves more than 2 files or modules, or changes a public contract/data model;
- Expected to take more than about 10 minutes;
- Requires cross-session/interruption recovery, or has many steps prone to context rot;
- Requires high-fidelity delivery and tiered testing protection.
Do not use: pure copy tweaks, single-line constant changes, direct read-only Q&A retrieval.
Iron Rules (Invariants)
- The plan file is the sole human-readable source of truth. Progress, checkboxes, and checkpoints are written to the plan header; machine state is written to the host's native goal primitive,do not create parallel state files(
scripts/goal-state-tracker.shonly does derived read/write). - Read the checkpoint before acting. When entering a new phase or resuming a session, the first action is to read the
Active Checkpointanchor in the plan header. - Without explicit user approval (User Nod), do not write code or write an implementation plan(P-1 gate).
- If the selection decision is not complete, do not enter the P1 plan(P0.5 gate); prefer reusing mature solutions, and any in-house development must be defended in writing.
- Before P3 starts, confirm the execution backend with the user: host-native subagent /
agyheadless process / inline in the current session. - Test at the adjudicated level, red first then green: the level is governed by the Test Strategy Adjudication in the plan, and an Exit Code of 0 is required before an atomic commit is allowed.
- Branch isolation: work on a feature branch, do not write code directly on
main/master. - Before delivery, there must be a Zero Blockers adjudication by an independent subagent: the Heavy Track goes through full two-round adversarial review; the Fast-Track goes through targeted single-round red-team review, and is escalated to full two-round review when it touches a public contract or core path.
- Retries are capped: a single error fix is capped at 3 attempts (the 2nd triggers micro-investigation, the 3rd triggers circuit-breaker escalation); smaller scene-level caps (such as 2 compile failures, 2 refactor-induced test breakages) take priority and trigger their corresponding actions; Delta Re-Loop iterations are capped at 5.
- Facts are persisted immediately: after every 2 read-only investigations, write the conclusion into
.goal-loop/scratchpad.mdor a checkpoint anchor. - After writing, Read-Modify-Verify: use
git diff, read back key lines, or use test/compile exit codes to confirm the change took effect. - Do not execute destructive Git commands(
reset/rebase/revert/restore/clean -fd/force push).
When higher-confidence details are needed, read the corresponding file under
references/; do not copy the detailed rules back into this file.
Phase Routing
| Phase | Goal | External Skill | Artifact / Pointer |
|---|---|---|---|
| P-1 | Intent Alignment | brainstorming |
2–3 alternatives; gate see stage-progression-protocol.md |
| P0 | Solution Stress Testing | grilling |
Requirements Confirmation Document = docs/proposals/RFC-{NNNN}-{slug}.md(convergence exit, In Review); for ledger paragraphs see RFC Standard Template §6; legacy engineering assessment optional evaluation-report-template.md |
| P0.5 | Research and Open-Source Selection | research / find-docs |
research-spike-template.md |
| P1 | Planning and Test Tiering | writing-plans |
goal-plan-template.md + testing-decision-matrix.md |
| P2 | Atomic Task Breakdown | — | atomic-task-template.md |
| P3 | TDD Loop Implementation | Host Execution Backend (ask the user before starting) | host-adapters.md |
| P3.5 | Integration Verification | Frontend Deliverable Acceptance:frontend-qa-gate(design tasks additionally attach taste-driven-designer) |
stage-progression-protocol.md |
| P4 | Adversarial Final Review | dual-round-review |
stage-progression-protocol.md |
| P5 | Document Archiving | doc-governance(optional) |
documentation-sync-matrix.md |
Track Tailoring:
- Fast-Track (Agile Lightweight): exempt P-1 / P0 / P0.5 and go directly to the P1 lightweight plan and P3;
- Maintenance-Patch (Legacy Maintenance): exempt P-1 / P0 / P0.5 / P2; retain the P1 minimal plan (symptoms/reproduction/root cause hypothesis/fix scope/regression tests), P3 localization and regression tests, P3.5 L2 localized regression, and P4 targeted single-round red team review.Mandatorily retain the 3-Tries circuit breaker, reproduce before fixing, fixes must include regression tests, and Diff scope locking; once a public contract must be changed, escalate to Heavy Track.
For decision thresholds, the full Track C procedure, and misclassification downgrade rules see stage-progression-protocol.md the execution track tiering decision matrix.
Exception Recovery
If the same error remains unresolved for 3 consecutive times, trigger the circuit breaker (STOP → RECORD → RESEARCH → ESCALATE), generate a structured arbitration report, and pause pending human adjudication. For the full failure matrix and report template see failure-recovery-protocol.md。
Auxiliary State Script (optional)
scripts/goal-state-tracker.sh provides a breakpoint dashboard and phase switching. The skill directory depends on the installation method (source repository is usually skills/goal-loop, after installation usually .agents/skills/goal-loop):
SKILL_DIR="<goal-loop 技能实际所在目录>"
bash "$SKILL_DIR/scripts/goal-state-tracker.sh" init "目标名称" "计划文件路径"
bash "$SKILL_DIR/scripts/goal-state-tracker.sh" status
bash "$SKILL_DIR/scripts/goal-state-tracker.sh" set-phase P3
bash "$SKILL_DIR/scripts/goal-state-tracker.sh" complete-task "p3-1"
The plan file is always the single readable source of truth; this script serves only as a derived view.
Reference Navigation
- host-adapters.md — capability contract, user selection, and downgrade rules for the P3 execution backend
- stage-progression-protocol.md — P-1 to P5 execution details, triage matrix, and gates
- testing-decision-matrix.md — decision rules from change characteristics to L0~L3
- context-engineering.md — 2-Action Rule, read/write decision matrix, and checkpoint specification
- failure-recovery-protocol.md — failure matrix and 3-Tries circuit breaker
- documentation-sync-matrix.md — P5 document linkage review checklist
- Template Suite:
templates/the four templates under: plan, atomic task, research, and assessment