create_task now pins upstream files by content hash and carries the
source task, source thread, verified facts, open questions and
acceptance criteria into the assignee's prompt.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Two c_suite tools in agent-goal-tools: company_status reports every goal
with real-work task counts (wake tasks and review checkpoints stay out),
work in flight, recent completions, and team headcount, so progress
answers come from the board instead of the model's memory; update_goal
rewrites an active goal's title/description when the founder redirects
the company, audited, CEO-or-owner gated. Both route through the sync
dispatcher; complete_goal now shares the same permission helper.
Adopted from studying Claude Code's /goal (completion judged by a fresh
model, never the one doing the work) and pi-goal-x's auditor (isolated
session, read-only tools, explicit approval marker, rejects scaffold-only
and proxy-metric completions).
complete_goal no longer closes a goal on the caller's word:
- It now takes a required `evidence` claim, and permission/argument gates
run before any audit spend.
- The audit is an isolated tool-turn loop: fresh conversation (the auditor
never sees the executor's transcript), read-only workspace tools (no
run_command), strict auditor instructions, at most 6 iterations.
- Only an explicit <approved/> closes the goal (recorded with the audit
verdict). <disapproved/>, no marker, or an exhausted budget all leave the
goal active and hand the decisive gap back to the caller as the tool
result.
- The handler moved from the sync dispatcher into the run loop's async
routing because it needs provider access; the goal-review prompt warns
that substanceless claims will bounce.
AGENTS.md documents both this and the web-access contract.
The board draining to 280/280 done left the company idle under a
still-active goal, with 24 markdown files and zero code as its life's work.
Two structural gaps caused it: goals had no lifecycle (status was written
once as 'active' and never read again — nothing re-engages anyone when the
last task closes), and nothing anywhere distinguished plans from product,
so every "engineering" objective closed on documents.
The loop, closed:
- tasks.origin (migration 055) records provenance: chat_wake for mention
vehicles (backfilled from their runs), goal_review for checkpoints, null
for real work. Chatter and checkpoints can therefore never count as
progress.
- spawnGoalReviews (each worker tick): an active goal with zero open tasks
and real progress since the last review gets ONE review task for the goal
owner. The review demands evidence — list the workspace, read the code,
run the tests; documents are how work starts, not proof it happened — and
must end in exactly one of: complete_goal, or the next wave of tasks with
requires_filesystem engineering. A review closed with neither spawns
nothing: termination is structural, not a counter.
- complete_goal (CEO or goal owner) finally lets someone say a goal is
achieved, audited.
- CEO and department-head voices now state the doctrine: a goal that
promises software closes on code that builds and passes tests in the
workspace, and implementation is delegated with requires_filesystem: true.
On the live profile this arms one review: the active platform goal has 0
open tasks and 21 real completed ones, so the CEO gets the checkpoint on
next launch and the company starts building instead of stopping.
ZacharyZhang-NYandClaude Opus 5.5