loop-contract

Scaffolding an agent loop with persistent task state requires creating on-disk operating contract files like SPEC, WORKFLOW, TASKS, and RUNLOG to store goals and evidence requirements outside chat context. This approach prevents false completion by keeping truth in files that survive compaction and crashes.

A repo-OS operating contract is a set of persistent on-disk files that define an agent loop's goals, workflow rules, and task state. You need it when turning an architecture decision into a verifiable loop workspace that remains auditable across runtime changes and context compaction.

Bootstrapping a verifiable agent loop from an ADR involves initializing workspace files including SPEC, WORKFLOW, TASKS, and RUNLOG, then recording an iteration-zero pre-execution review. The process wires terminal states and approval gates to keep the loop auditable before any implementation changes begin.

Yes, you can extend an existing agent loop workspace by re-scaffolding its operating contract with clearer criteria, evidence rules, and machine-readable state. The process applies YAML frontmatter and deterministic file templates to update SPEC, WORKFLOW, TASKS, and .loop state files.

Yes, agent loop scaffolding records an iteration-zero pre-execution review and captures explicit approval gates. It enumerates terminal states and prepares verify-fast and verify-full skeletons so success criteria can be checked deterministically throughout the workflow.

Agent loops lose task state and claim false completion when goals and evidence requirements are stored only in chat context. Scaffolding a persistent on-disk operating contract with TASKS and RUNLOG files forces the loop to store truth in files that survive compaction, preventing false completion.