What-Next Commander Loop: Current Design State

The intended mechanism is a generic, bounded self-improvement loop: human-owned goals feed deterministic evidence gathering; the commander selects one next safe task; work is delegated or verified; evidence updates the domain state; then the next task is re-ranked.

Finite Loop Contract

Observe

Read charter, goals, tasks, app routes, code, staging, API, DB, and prior evidence.

Score

Use the domain scorecard. No evidence means no progress credit.

Decompose

Convert broad goals into small task cards with acceptance criteria.

Select

Pick one highest-value unblocked task. Normal mode stops after one.

Baseline

Capture current screenshots, traces, API responses, DB reads, or tests.

Act

Do read-only work directly or delegate implementation through guarded task flow.

Verify

Use browser, API, DB, code, tests, and human gates based on task risk.

Record

Write run notes and an evidence manifest that maps to acceptance criteria.

Re-rank

Update the generated dashboard and candidate task ordering from evidence.

Stop

Stop on done, blocked, human gate, failed verifier, max limit, or no new evidence.

Generic Domain Shape

Human-Owned Goal State

CHARTER.md
GOALS.yaml
SCORECARD.yaml
RISK_POLICY.md

Direction, priorities, invariants, and risk boundaries. Commanders may propose edits but should not silently rewrite these.

Commander-Owned Work State

TASKS/**/*.yaml
RUNS/**
EVIDENCE/**
DASHBOARD.md

Task cards, run notes, evidence manifests, screenshots, traces, API results, DB checks, and generated summaries.

Standard Task Mechanism

Pact -> Build -> Verify
synexar-task

Implementation should be delegated to the guarded task pipeline, not performed by a free-running commander.

What Makes It a Self Loop

  • The commander reads current domain state before acting.
  • Each task produces durable evidence, not just a narrative.
  • Evidence changes the scorecard/dashboard.
  • The updated state determines the next task.
  • Bounded goal-loop mode can continue with --max-tasks=N, but only while evidence passes.

The loop is deliberately finite. It is designed to improve deterministically without allowing an agent to move goalposts, self-certify, or keep retrying.

What Exists Now

Artifact State
.claude/skills/what-next/SKILL.md Generic skill exists. It defines the loop, invocation patterns, guardrails, done rule, and domain layout.
_shared/WHAT_NEXT_MECHANISM.md Shared operating model exists and is explicitly domain-independent.
_shared/evidence-schema.json Evidence manifest schema exists for task verdicts, browser/API/DB/code/test evidence, and criteria mapping.
_shared/templates Templates exist for new domain charter, goals, run notes, and task cards.
anesthesia/ MVP domain exists with charter, goals, scorecard, dashboard, task cards, runs, and evidence.

What Is Not Yet There

Gap Meaning
Only one real domain No GI, front-office, RCM, research, or platform-security commander folders are instantiated yet.
No deterministic runner The skill describes behavior, but there is not yet a single CLI/script that enforces all loop transitions.
No scheduler/liveness layer This is not yet a cron-backed standing loop with audit liveness checks across domains.
Dashboard is generated by convention There is a mutation rule, but no universal dashboard generator was found in this artifact set.
Bounded loop is designed, not automated run-goal --max-tasks=N is documented, but needs a concrete executor to be reliable.

Risk Gates

Tier A: read-only / observe Tier B: implementation via PR Tier C: human-gated
  • Clinical, billing, legal, auth, RLS, audit, schema, PHI, and production actions stop for human approval.
  • Commanders cannot self-certify work as done.
  • Production mutation is disallowed without explicit approval.

Evidence Model

  • Task ID, goal ID, domain, environment, run ID, actor, verdict.
  • Browser routes, viewports, screenshots, traces, console errors.
  • API checks, database checks, code paths, test commands.
  • Every acceptance criterion maps to evidence and pass/fail state.

Loop Ceilings

  • One next-best task per normal invocation.
  • Max 12 observe/read steps before decision.
  • Max 4 verifier attempts per task.
  • One spawned implementation task per invocation.
  • Stop after repeated no-new-evidence runs.

How to Generalize Beyond Anesthesia

1. Instantiate Domain

Copy the domain templates into synexar-runtime/commanders/gi, front-office, rcm, or research. Human writes charter, goals, scorecard, and risk boundaries.

2. Add Deterministic Verifiers

For each goal, define browser/API/DB/code/test probes. GI should use GIQuIC merged-submission checks; front-office should use DB/RLS/encryption and iPad workflow checks.

3. Add a Real Runner

Build a thin script that enforces the finite state machine: read state, validate task card, run verifiers, write evidence, update dashboard, and stop on gates.

Bottom Line

The design is in the right shape for deterministic self-improvement: fixed domain state, small task cards, evidence manifests, risk gates, and stop conditions. The current implementation is still a documented mechanism plus Anesthesia/AIMS proof of concept. To become the general self-loop you originally wanted, the next engineering step is a deterministic commander runner and the first non-AIMS domain, probably GI or front-office.