quest

# quest — one objective, riding the host's own verifier ## What it does & why Some hosts already drive the graph for you. Grok's `/goal` plans acceptance criteria, works across rounds, and only marks the goal complete after an **independent adversarial verifier** reproduces the evidence (defaulting to *refuted* if it can't). A Codex task self-drives an objective to done across rounds. On such a host, generating a separate executor + supervisor + two loops is redundant — you'd pay tokens to re-describe what the harness enforces for free. The quest arm emits **one task-specific objective** marked `octopus.quest-executor/v1`. The runtime skill carries the reusable execution discipline; the compiled objective carries only the goal, reproducible acceptance, run controls, concrete red lines, and owner boundary. ## When to use quest vs loop-graph Use the **quest arm** when *all* hold: - one self-contained goal (no strict-ordered milestones with a non-skippable gate); - the host has a goal command that self-drives to done (**Grok `/goal`**, a **Codex task**); - executor and reviewer live in the **same** run (you're not splitting them across hosts/models); - no owner-only decision sits on the goal's critical path. Use the **[loop-graph arm](../loop-graph)** when *any* hold: multi-milestone phases, executor and supervisor on different hosts/models/cadences, owner red-lines/gates that must stop the run, cross-session durability, or a host that **only loops** and has no goal co...