Goals and verified missions

Use (goal "OBJECTIVE") for lightweight autonomous work. Use (goal "pause"), (goal "resume") or (goal "clear") to control it. For externally verifiable work, install explicit acceptance policy with (mission "start PLIST"), or evaluate:

(application-mission-start
 *active-application*
 '(:objective "Deliver the accepted build"
   :turn-limit 40 :token-limit 100000 :wall-seconds 3600
   :criteria ((:id "build" :description "The build passes" :gates ("build"))
              (:id "review" :description "The user accepts the result"))
   :gates ((:id "build" :kind :command :command "make check"
            :inputs ("Makefile" "src/main.lisp") :deterministic-p t
            :attempt-limit 3 :timeout-seconds 300))))

Use (mission "run") to begin, (mission "status") to inspect the complete durable state, and (mission "verify") to request harness verification. The model can also call mission.status, mission.verify, mission.stop and mission.invalidate. Only the primary agent may mutate mission policy through these model operations. Configure acceptance criteria yourself; the model cannot weaken them or supply user acceptance.

Each criterion has a unique :id, a :description and optional ordered gate IDs in :gates. Criteria without gates require your explicit evidence:

(mission "accept (\"review\" \"I inspected the artifact and accept the result\")")
(mission "resume")
(mission "verify")

The model's completion marker requests verification. Passing a gate proves only the criteria you explicitly associated with it. Verification requires all gates and all criteria. Inspect the acceptance mapping before beginning work.

The turn allowance counts provider inference calls across the primary agent, children, compaction and recursive inference, including mapped and nested frames. Reported billable tokens use the provider API's usage normalization and exclude known prompt-cache reads. Admissions and settlements are serialized within a mission; provider requests execute concurrently. Each admission reserves a turn and an output ceiling from the unspent, unreserved tokens. The default ceiling divides those tokens among the remaining turns; an explicit provider output cap replaces that division. Reviewer requests reserve from both allowances. Settlement releases the ceiling and charges reported input and output usage, so a request can exhaust the token allowance. Missing usage is recorded as unknown and blocks further inference. Install a new explicit budget to proceed after unknown usage.

The wall-clock deadline includes gate execution, delegated tools, pauses and time away. Work runs under cl-jobpond supervision. Use (goal "pause") and (mission "resume") without resetting any mission budget; use (mission "cancel REASON") to terminate it. Terminal states are verified, exhausted, cancelled and failed. A blocked mission retains the evidence needed to resolve its blocker and resume. Interrupted inference restores as blocked when its usage cannot be recovered. Gate attempts, fingerprints and evidence restore with the conversation and survive compaction independently of model summaries.

Gates run in order, stopping at the first failure. Command gates use the ordinary shell authorization and sandbox boundary. Artifact gates require :path and optionally an expected :sha256. Lisp gates require a :predicate string and run an assertion in the existing isolated Lisp worker. Every gate supports :timeout-seconds and a separate :attempt-limit, defaulting to 60 seconds and three executions. Each gate retains bounded evidence.

For deterministic gates, declare all relevant file paths in :inputs and set :deterministic-p t. File contents and missing-file states form the fingerprint; directory paths are rejected. Unchanged passing gates supply current proof, and unchanged failed gates are withheld while the model works on their relevant inputs. For remote state, omit deterministic policy or invalidate a particular gate explicitly:

(mission "invalidate (\"build\" \"The remote build configuration changed\")")

Invalidation permits another execution without replenishing its attempt budget. Before acceptance, every gate fingerprint is checked again under the workspace mutation lock. Changes from a later gate invalidate earlier passing evidence. Collect terminal results and outstanding inference usage before verifying.

Independent review checkpoints

Attach a reviewer to an active mission with mission-review.configure, or evaluate:

(application-mission-review-configure
 *active-application*
 '(:id "release-review" :phase :final-acceptance
   :inputs ("src/main.lisp" "tests/main-tests.lisp")
   :context "Review the changed behavior and test coverage. Report concrete findings."
   :turn-limit 4 :token-limit 16000 :run-limit 3))

Declare the complete relevant file set. The reviewer receives an independent snapshot and background, returns contracted findings, and has no tools or spawning permission. Reviewer call and token allowances are cumulative across changed snapshots and also count against the mission allowances. :run-limit bounds the number of distinct snapshots reviewed.

Use mission-review.trigger with id to review a checkpoint and mission-review.inspect to read its durable findings, decisions and usage. Unchanged snapshots reuse completed, failed or interrupted runs. Resolve or reject each finding through mission-review.decide with id, finding, decision (resolve or reject) and an evidence-bearing reason. Only the primary agent or local user may configure, trigger and adjudicate reviews.

Final verification runs configured final-acceptance checkpoints. Pending findings and failed or interrupted reviews block acceptance. For before-integration and after-edit-set checkpoints, trigger the named review explicitly at the chosen boundary. Reviewer findings are advisory; mission gates and user acceptance supply harness evidence.

Scheduled mission continuations

Attach explicit wakeups to the current mission with mission-schedule.add. Supply an immutable id, continuation content, and a time policy: at is an absolute Common Lisp universal time, interval is a positive number of seconds, and event names an external event instead of a time policy. For example:

(application-mission-schedule-add
 *active-application* :id "build-followup"
 :content "Check the pending build and continue the mission."
 :at (+ (get-universal-time) 300) :missed-policy :latest)

For recurring wakeups, choose missed-policy latest (the default), all or skip to select the newest missed occurrence, every missed occurrence or none. Use mission-schedule.event with an event name and stable external event id; repeated delivery of that ID is deduplicated. The local daemon listener hosts time wakeups. Due work enters the ordinary primary command queue as a persisted (mission-wakeup "TICKET") command and executes as a mission continuation under the existing turn, token and wall-clock budgets.

Only the primary agent may use the mission-schedule tools. Each wakeup retains its exact mission identity and version, checked at admission and execution; replaced or inactive mission work is cancelled. Use mission-schedule.inspect to read schedules, occurrence IDs and claim tokens, and mission-schedule.cancel with the schedule id to cancel future and pending work.

Interrupted admissions and executions restore as uncertain outcomes. Inspect the external effects before calling mission-schedule.resolve with the readable occurrence ID, current token and action completed, failed or retry. Retry is an explicit decision and is refused while the occurrence is executing. Cancellation retains claim and duplicate history.