Complex-task planning and execution control · Independent project
How can parallel, complex work retain direction, boundaries, task quality and traceable decisions?
Chief is a personal operating method for breaking complex goals into tasks and separating responsibility for planning, execution, review and acceptance.
Project overview
Chief is a human-led governance method for coordinating several AI-assisted projects. When the owner cannot monitor each project continuously, Chief narrows the direction, defines boundaries, writes tasks with testable acceptance criteria and hands implementation to a separate execution window. Facts, inferences, recommendations and decisions remain distinct. An executor cannot approve its own output for production; the result must return to Chief for review.
An automated executor was tested for state control, isolation, write boundaries and rollback. In practice, network access, authentication, sandbox behaviour and process recovery were not reliable enough to operate unattended. The governance method remains in use; automated dispatch is archived. Traceability and recoverability take priority over the degree of automation.
Core mechanism
Four boundaries: planning, execution, review and acceptance.
Planning | Define the objective, dependencies and completion criteria.
Execution | Complete the task within scope without expanding authority.
Review | Examine evidence, risks and omissions.
Acceptance | A task is complete only when its pre-defined criteria are met.
Current boundary
The governance method is public. The automated executor is not in production.
Supporting evidence
The role chain, and why the automated executor was archived.
The material below is the engineering record behind the main account. Each claim can be checked in the public repositories.
Chief writes task briefs, reviews outputs and records decisions. Code changes, tests, commits, merges and deployments are performed by manually started, isolated executors.
Why the automated executor was archived
What the tests supported
- Task, project, lease and state controls worked
- Separate clones and fail-closed write boundaries were feasible
- Writes outside the allow-list could be rejected at the kernel level
- Failures could return to a known safe entry point
Why it did not enter production
- Executor A: network and API access were unstable in isolation
- Executor B: CLI processes depended on desktop and Node environments and could stall
- Executor C: allow-lists, output contracts, process recovery and credential cleanup still had gaps