I pictured a development loop where I could tell an agent to proceed, review one pull request, and decide whether it should merge. I still wanted to control the direction. I made that boundary explicit: phase gates, one task at a time, and no next task until I said to continue. The first responses then exposed how much had to exist before “proceed” was a complete instruction.
A task title could be too vague to implement. A tool could fail even when the code task was well specified. A repository could lack a durable source of decisions or a small queue of ready work. I used those stoppages to revise the harness rather than pretending that stricter agent instructions alone would solve them. By the end, the direction had become a reusable project template with clearer authority and handoff points. It was a concrete change of scope, not a finished autonomous development platform.
The initial control boundary
The proposed harness could inspect repository and pull-request state, select an eligible task in the active phase, make a branch, edit within the task’s scope, run checks, review its work, and open one pull request. It then stopped for me.
It could not approve or merge its own work, push directly to the protected default branch, silently change phase, or invent missing product rules. A merged PR was evidence of completion, but not automatic permission to start the next task. Each phase ended with a gate review.
That was deliberately different from a continuous autonomous loop. I wanted routine execution to become easier while consequential decisions remained visible.
A task title was not enough
Several pilot reports reached the same kind of barrier: a task was next in the register, but its deliverable, allowed files, validation, or executable definition was missing. Naming and ordering tasks did not tell the harness what it was authorized to do.
When I asked when the process would become self-sustaining, the explanation identified four missing pieces: complete task definitions, a way to derive eligibility, validation of the boundaries, and a bounded way to replenish the queue.
The proposed task record included:
| Field | Why it was needed |
|---|---|
| ID, phase, type, dependencies | Identify the task and whether it can start |
| Authority documents | Tie the work to an approved decision |
| Allowed and forbidden paths | Bound the edit |
| Deliverable and acceptance criteria | Define what completion means |
| Required validation | Specify the checks |
| Stop condition and later-task boundary | Prevent the task from quietly expanding |
The long-range register and the ready-to-execute task definition were therefore different artifacts.
Tool failure was a separate kind of stop
One pasted Phase 2 repair report described an atomic Git-tree write failing with Invalid tree info and HTTP 422. A fresh branch had been created, but the write failed before files, commits, or the branch reference changed. No PR was opened.
That was a tooling failure, not an authority gap and not a completed repair. Keeping those states distinct matters when the next task is derived from repository evidence.
The GitHub-protection work also exposed another boundary: repository settings are not the same thing as a file change that can be delivered in a normal task PR. Some controls required an owner action outside the code workflow.
The change to a generic template
I eventually decided to convert HarnessTest into a reusable template. The owner decision explicitly retired the current Phase 3 pilot sequence instead of pretending it was completed template work. Useful history should be preserved, but copied projects should not inherit the pilot’s old tasks as active authority.
The new startup path was:
Approved project documents
→ Source manifest
→ Roadmap
→ Full task catalog
→ Small executable horizon
→ One-task pull-request loopThe proposed first horizon contained only three to five complete task definitions and a qualifying gate. Later executable tasks would come from the approved catalog, rather than being invented when the queue ran out.
The conversion brief called for generic charter, bootstrap, roadmap, catalog, task-definition, external-control, conversion-register, and pilot-archive documents. It also separated owner-configured GitHub settings from evidence the tools could inspect and checks enforced by repository files.
By the end I was asking for a reusable template and a queue small enough that “proceed” would have a defined target. The pilot had shown why a phase gate alone could stop at the right time and still leave the next action underspecified. It had not yet become a finished shared platform.