Project Loop

Use for approved multi-step work that must survive resets, compaction, interruption, approval gates, and stalled execution.

Do not use for trivial one-turn work, open-ended autonomy, or projects without a clear owner.

Core Rules

• - Project files, not chat, are the source of truth
• Trust this order: state.json > manifest.md > validation.md > handoff.md > memory > chat
• Only the owner_agent in state.json executes project tasks
• Other agents may improve the skill, but do not run the loop
• Do not wait for human confirmation between self-clearable tasks
• Keep executing until an approval gate, blocker, or stop condition is reached
• After completing a chunk and successfully updating state, immediately begin the next eligible self-clearable chunk in the same turn
• Do not wait for a human response between self-clearable tasks after a successful state update
• Stop only for a real blocker, approval gate, failed state update, or explicit stop condition
• Before starting any task, check whether the output already exists
• If the work already landed, mark it done and advance
• On every resume, verify state.json against actual reality before executing
• During active execution, send a status update at least every 5 minutes
• A 5-minute update must include one of: artifact created, task completed, blocker, or exact next action in progress
• Do not send empty “still working” updates

Required Project Files

Project path:

CODEBLOCK0

Required:

CODEBLOCK1

Optional:

CODEBLOCK2

state.json Minimum Fields

• - INLINECODE8
• INLINECODE9
• INLINECODE10
• INLINECODE11
• INLINECODE12
• INLINECODE13
• INLINECODE14
• INLINECODE15
• INLINECODE16
• INLINECODE17
• INLINECODE18
• INLINECODE19
• INLINECODE20
• INLINECODE21
• INLINECODE22
• INLINECODE23

Recommended additions:

• - INLINECODE24
• INLINECODE25
• INLINECODE26
• INLINECODE27
• INLINECODE28
• INLINECODE29
• INLINECODE30
• INLINECODE31
• INLINECODE32
• INLINECODE33
• INLINECODE34
• INLINECODE35
• INLINECODE36

Session Start and Resume

Read in this order:

1. 1. INLINECODE37
2. INLINECODE38
3. INLINECODE39
4. INLINECODE40 if present
5. only then memory or chat if still needed

Never start by asking “what were we doing?” if project files exist.

On resume:

• - read status, phase, current_task_id, next_action, INLINECODE45
• verify state against actual reality before doing anything
• continue from recorded state, not guesswork

State Machine

States:

• - INLINECODE46
• INLINECODE47
• INLINECODE48
• INLINECODE49
• INLINECODE50
• INLINECODE51
• INLINECODE52
• INLINECODE53
• INLINECODE54

Allowed transitions:

CODEBLOCK3

Rules:

• - Draft -> Ready only when objective, scope, manifest, and validation exist
• INLINECODE56 only when the next chunk is sized and eligible
• INLINECODE57 only after outputs are recorded
• INLINECODE58 only after pass and a next task is eligible
• INLINECODE59 only when required tasks are complete and final checks pass
• INLINECODE60 for true human-cleared boundaries
• INLINECODE61 when a blocker cannot be self-cleared within retry rules
• INLINECODE62 only for interruption, manual pause, or no eligible task

Execution Rules

• - One chunk = one objective + one validation target
• If a task has more than one verb, split it
• Split at boundary changes: local prep -> remote write, remote write -> validation, planning -> execution, authenticated action -> read-back
• Never bundle multiple operations into one command if they can be independent
• If any command or execution step is denied for obfuscation or size, split it into smaller independent steps and retry
• This applies to file writes, API calls, shell commands, browser actions, and any other execution path

A chunk is too large if it:

• - has more than one primary deliverable
• crosses multiple boundaries
• mixes planning, execution, and validation
• touches too many pages, endpoints, or files at once
• cannot be described with one clear done condition

Progress Rules

• - Updating state.json, manifest.md, validation.md, or handoff.md alone does not count as execution progress unless the current task is explicitly documentation-only
• Do not claim forward execution unless the external world changed or a required artifact for the current task was created
• When marking a task complete, record concrete evidence in state and in your reply when relevant: artifact path, file changed, page changed, validation evidence, or blocker artifact
• If you cannot point to the output, the task is not done
• Do not spend more than 2 consecutive project turns on planning, loop setup, or state reshaping without either executing, validating, or escalating
• If the user questions silence or progress, stop meta narration and report only: what changed, what artifact exists, what blocker exists, and what exact action is next
• Do not report system status theatrically. Report concrete project facts only

Validation Rules

No task is complete until validation passes and the result is recorded.

Validation may include:

• - artifact existence/content check
• file diff or file review
• browser verification of rendered state
• API read-back
• log/command review
• human review for customer-facing release steps

Validation records should capture:

• - task ID
• method
• pass/fail
• timestamp
• evidence location
• next step

If validation fails:

• - do not advance
• record exact failure
• retry only with a bounded corrective chunk or move to INLINECODE67

Approval and Pause Rules

Self-clearable work may continue if it stays in scope.

Human-cleared work includes:

• - credential handling
• auth construction
• authenticated remote writes
• WordPress REST writes
• installs or config changes
• third-party sends
• publish/live-release steps unless already pre-approved
• actions requiring manual login or privileged access

When a true approval gate is reached:

• - set status to INLINECODE69
• record the exact pending action in INLINECODE70
• record what prep is already done
• continue only if another independent task is eligible
• otherwise pause cleanly

Do not pause at routine internal chunk boundaries.
Pause only for:

• - real blocker
• missing access or credentials
• meaningful human decision
• explicit stop/pause
• genuine risk or scope boundary

Interruption and Recovery

If interrupted by unrelated work:

• - finish any atomic write already in progress if safe
• update state.json immediately
• set INLINECODE72
• set INLINECODE73
• set status=Paused unless already AwaitingApproval or INLINECODE76

When updating state.json, use a full-file write by default, not a partial edit. state.json changes frequently and exact-match edit operations are brittle on high-churn files. Use partial edit only if you have just read the current file and the change is truly small, stable, and low-risk.

If state.json cannot be updated:

• - stop execution immediately
• this is a hard stop, not a soft warning
• do not continue the loop, do not start another chunk, and do not claim progress until state is repaired or successfully rewritten
• report the exact failure and recovery step

If a task may have partially executed:

• - verify actual reality first
• do not blindly rerun
• choose next action from observed state, not assumptions

If state is missing or inconsistent:

• - reconstruct from manifest, validation, artifacts, and handoff
• rewrite state before resuming

Watchdog Rules

Cron is a watchdog only, never the main workflow engine.

• - When creating a new project, automatically create a watchdog cron for that project
• When a project moves to Done or Abandoned, remove the watchdog
• The watchdog only reports when it takes an action or finds something worth surfacing
• If there is nothing to resume, retry, or escalate, stay silent

Watchdog may:

• - detect stale INLINECODE82
• detect resumable INLINECODE83
• detect approval-cleared states ready to continue
• trigger one bounded resume pass

Watchdog must not:

• - invent new work
• rewrite scope
• cross approval gates without clearance
• spam retries
• chain arbitrary timer-based work

Recommended cap:

• - one automatic resume attempt per cycle
• no more than two automatic recovery attempts without new evidence

Operating Sequence

1. 1. Read INLINECODE84
2. Read INLINECODE85
3. Read INLINECODE86
4. Read handoff.md if present
5. Verify current state against actual reality
6. Check whether the target output already exists
7. Pick one eligible chunk
8. Apply chunk sizing rules
9. Execute
10. Validate
11. Update INLINECODE88
12. Continue if self-clearable, otherwise pause or escalate cleanly