Gola

gistfile1.txt

Goal:
Complete the ordered task queue through sequential task agents, preserving one attributable accepted checkpoint per successful implementation and continuing past individually blocked tasks while minimizing coordinator context.

Context:
Tasks, in required order:
1. <TASK 1>
2. <TASK 2>
3. <TASK 3>
...

Each task is an independent bounded slice unless a demonstrated dependency says otherwise.

Constraints:
- Follow the repository AGENTS.md. Do not bypass, weaken, or restate it.
- Run exactly one task agent at a time.
- The coordinator owns scheduling, acceptance, baseline regression decisions, commits, checkpoint integrity, and the compact task ledger.
- The task agent owns repository exploration, implementation, routine debugging, and focused verification for its slice.
- Give the task agent only the current task and directly relevant known evidence. Do not preload completed-task histories.
- The agent determines the invariant, owner/boundary, fresh evidence, and smallest warranted solution.
- Treat the listed mechanism as a candidate, not a requirement.
- Preserve unrelated behavior. Do not combine cleanup, redesign, refactoring, documentation, or adjacent fixes with the task.
- Do not add state, persistence, abstractions, dependencies, migrations, compatibility, retries, or lifecycle behavior unless demonstrated necessary for the invariant.
- COMPLETED, NO CHANGE, and BLOCKED are valid task outcomes.
- BLOCKED does not stop the queue.
- Do not manufacture commits for NO CHANGE or BLOCKED tasks.

Context discipline:
- Keep implementation reasoning inside the task agent.
- The agent should investigate, implement, diagnose ordinary task-owned failures, correct them when warranted, and rerun focused verification before returning.
- Do not send ordinary intermediate test failures or debugging transcripts to the coordinator.
- A successful or NO CHANGE agent result must be at most 180 words.
- A BLOCKED result may use at most 300 words when the blocker requires evidence.
- Return only:
  - status;
  - invariant and owner;
  - files changed, if any;
  - focused verification and result;
  - concise blocker or material uncertainty, if any.
- Do not return raw logs, source excerpts, pasted diffs, command transcripts, exploration history, lists of passing tests, or narrative implementation walkthroughs.
- The coordinator must not repeat repository exploration already completed by a task agent.
- For a routine candidate with settled ownership, bounded scope, passing focused verification, and no material uncertainty, the coordinator must not reopen implementation files merely to reconstruct how the worker implemented it.
- Inspect implementation source or detailed diffs only when acceptance materially depends on it: suspicious scope, conflicting evidence, unexpected overlap, regression, consequential semantics, or unresolved uncertainty.
- Prefer status/diff-stat/file-list inspection for routine scope validation.
- Once a task is accepted, collapse it in active coordinator state to one compact ledger entry:
  `<task> <status> <commit-or-> <blocker-or->`
- Do not carry completed worker reports forward after that point.
- Recover accepted implementation detail from Git when genuinely needed.
- Active coordinator state should contain only:
  - accepted HEAD;
  - current regression baseline fingerprint;
  - compact task ledger;
  - unresolved blockers/dependencies;
  - current queue position.
- If context becomes expensive during a long queue, compact only at an accepted checkpoint and preserve that active state rather than completed implementation narratives.

Verification:
- Task agents run only focused tests/checks relevant to their slice.
- The coordinator runs the canonical/full required suite before the first implementation to establish the baseline.
- Because the canonical suite is quiet, keep full-suite execution with the coordinator; do not create a verifier agent merely for token savings.
- Record baseline only as:
  - accepted commit;
  - failing test identities/groups, if any;
  - minimal distinguishing failure signatures.
- Do not retain successful test output.
- After every implementation candidate, the coordinator runs the canonical/full required suite and compares it with the accepted baseline.
- A red baseline is not itself a blocker.
- Accept an implementation only when:
  - focused verification passes;
  - no new attributable full-suite failure appears;
  - no existing failure materially worsens;
  - remaining failures are equivalent to the accepted baseline.
- If equivalence or causality is materially uncertain, reproduce only the disputed failure against the prior accepted checkpoint in an untouched checkout/worktree.
- If a task intentionally removes a baseline failure, the improved result becomes the new baseline.

For each task:
1. Select the cheapest sufficient GPT-5.6 model and effort for that task.
2. Dispatch one agent for the current task only.
3. Let that agent complete its own bounded inspect → implement/debug → focused-verify loop.
4. Receive the compact final task result.
5. If NO CHANGE:
   - record the compact result;
   - continue without a commit.
6. If BLOCKED:
   - record the exact blocker compactly;
   - discard or restore any unaccepted task changes;
   - verify the repository is back at the last accepted checkpoint;
   - continue.
7. If COMPLETED with implementation:
   - validate scope without rereading routine implementation detail unless a material acceptance question exists;
   - run the canonical/full suite;
   - apply the regression gate.
8. If accepted:
   - create one intentional commit containing only that task;
   - verify HEAD and expected working-tree state;
   - update the accepted baseline;
   - collapse the task to its compact ledger entry;
   - continue.
9. If the implementation fails acceptance:
   - redispatch the same task agent once when the demonstrated failure is task-owned and a bounded correction is appropriate;
   - keep diagnosis/correction inside that agent;
   - if still unresolved, mark BLOCKED, discard unaccepted work, restore the accepted checkpoint, and continue.

Hard gates:
- Never run task agents concurrently.
- Never start task N+1 while task N is unresolved.
- Never start task N+1 after implementation until task N is either accepted and committed or rejected/blocked with the accepted checkpoint restored.
- Never combine accepted tasks into one commit.
- Never commit incomplete or failing implementation.
- Never repair unrelated baseline failures merely to advance the queue.
- Never weaken, delete, skip, quarantine, or rewrite tests to satisfy a gate.
- Never classify a failure as pre-existing without baseline evidence.
- Findings outside the current task may be recorded but not implemented unless necessary for its invariant.

Agent selection:
- Choose model and effort independently for every task.
- Luna: bounded repeatable work with known ownership.
- Terra: investigation, unclear causes, broader context, shared infrastructure, or substantial UI work.
- Sol: consequential ambiguity involving authoritative data, immutable history, isolation, security, official outputs, serious concurrency, or similarly consequential semantics.
- Keep difficult task-local context inside the selected worker rather than escalating the coordinator.
- Do not use Sol merely because the overall queue is long.

Done when:
- Every task has been attempted in order.
- Every task is classified COMPLETED, NO CHANGE, or BLOCKED.
- Every accepted implementation passed focused verification and the coordinator regression gate.
- Every accepted implementation has one attributable commit.
- Every blocked task left no partial changes in accepted history.
- The repository ends at a trustworthy accepted checkpoint.
- The final report reconstructs detail from the compact ledger and Git rather than retained worker transcripts, and reports for each task:
  - status;
  - invariant/owner;
  - accepted commit if any;
  - focused verification;
  - regression result for implemented tasks;
  - blocker or material remaining uncertainty.