Goal Exec

---
name: goal-exec
description: Convert an explicit user request into a Codex goal and pass its chosen coder, Lev, omo/omp, SDD, or Fable execution flags to $coder.
---

# Goal Exec

Use this only before `create_goal` when the user explicitly asks to set or run a
goal. The goal describes the domain outcome. Load `skill://coder`; `$coder` owns
execution mechanics. For `--lev`, also load `skill://exec` and resolve the flow
as `lev://exec/<flow>` rather than treating the skill pointer as a runtime URI.

## Flags

```text
$goal-exec [--coder] [--lev] [--sdd[=checkpoint|pair]] [--omo|--omp] [--fable]
```

| Flag | Contract |
|---|---|
| `--coder` | Load `$coder`; use its direct single-worker mode unless another topology flag is present. |
| `--lev` | Pass `--lev`; execution must use `lev exec` and project FlowMind/profile policy. |
| `--sdd` | Pass `--sdd=checkpoint`. |
| `--sdd=checkpoint|pair` | Pass the exact SDD mode. Reject other values. |
| `--omo`/`--omp` | Pass through; use the pi-family worker in `$coder`. |
| `--fable` | Pass through; prefer the configured Fable reviewer profile. |

`--coder` selects the execution owner. The remaining flags refine `$coder` and
must be copied unchanged into the goal's `Tools:` clause. `--sdd`, `--omo`, `--omp`,
or `--fable` imply `--coder`. `--fable` requires SDD because it selects the
reviewer, never the coder. Reject contradictions instead of silently dropping
or substituting flags.

## Long-Horizon Goal Navigation

When the user explicitly creates a long-horizon or multi-session goal, read
[long-running guidance](references/long-running.md) before composing the prompt.
It owns outcome fidelity, acceptance mapping, continuation and completion audit.
Use [recursive wayfinding](../lev/references/recursive.md) when the route or
dependencies need reshaping, not as a mandatory restart of a settled plan.
Prefer native goal continuation. Create a navigation heartbeat only for an
explicit watch/schedule request or existing authorized policy that needs one;
never when scheduling is prohibited. An optional timer is not a goal prerequisite.
When authorized and no cadence is supplied, use 30 minutes or project policy.

For tracked long-horizon work, bind the existing navigation state below. Timer
fields apply only when scheduling is authorized; otherwise mark them not applicable.

```yaml
goal_ref: <stable goal identity; finalize after create_goal>
outcome_ref: <stable outcome>
outcome_map_ref: <durable outcome map>
workstream_ref: <durable workstream>
tracker_binding: <one configured backend and identity>
policy_provenance: <source refs and digest or revision>
tick_policy: outcome_navigation
heartbeat_idempotency_key: <derive from goal_ref + tick_policy>
rolling_horizon_ref: <current projection>
allowed_effects: []
stop_conditions:
  - goal_paused
  - goal_cancelled
  - outcome_confirmed_complete
  - budget_exhausted
  - blocker_requires_human_or_external_change
```

If tracked work requires a tracker and none is configured, ask once among the mechanically supported
Markdown, Beads, and GitHub choices, then persist the selection. Resume reuses
that binding. An unavailable backend blocks tracker effects; it never causes a
write to another backend. Do not create the goal until this required choice is
resolved.

Only when a heartbeat is required, confirm the host exposes its callable
automation surface. After goal creation succeeds, finalize `goal_ref`, derive a
stable automation idempotency key from `goal_ref + tick_policy`, then inspect
existing automations by that key. Update the matching heartbeat when present or
create one when absent. Never use a display name alone as identity. If the host
cannot create or update a heartbeat, report that capability gap; never invent
an automation ID or claim scheduling succeeded.

Deduplicate timer and worker-return wakes so only one tick can advance a given
navigation revision. Pause, cancellation, and confirmed completion disable the
heartbeat through the same host surface. Repeated unchanged blocked or
live-worker states stay quiet; surface only a changed failure, a required
decision, or a meaningful route update.

Use this heartbeat meta-prompt with the resolved packet injected by the host.
The heartbeat must consume the packet; it does not look up project config:

```text
Reconcile current evidence against the bound outcome. Retrieve relevant prior
learning. If the selected step is vague or its assumptions failed, run the
recursive wayfinding procedure. Refresh the rolling horizon after material
changes, keeping steps 1-3 actionable and steps 4-10 appropriately coarse.
Select one eligible tick and resume at most one coherent unit within the
supplied authority. Do not duplicate a live worker or infer release, publishing,
or marketing permission. If waiting remains correct, stay quiet. Stop when the
goal is paused, cancelled, or confirmed complete.
```

The heartbeat is a navigation wake, not a second worker. It reconciles evidence
before choosing one deterministic tick: required review, wayfind/research,
authorized execution, due hygiene, or separately authorized release/publish.
It must not rediscover arbitrary config, rewrite an unchanged plan, or treat no
eligible work as completion.

## Pre-create Gate

Before calling `create_goal`, display the complete goal prompt and, for a
long-horizon goal, its resolved navigation packet. Together they must contain:

1. `Hard refs:` exact absolute paths to governing plans/specs.
2. `Outcome:` the stable observable domain result.
3. `Plan:` the ordered execution sequence; for long-horizon work, the outcome-map
   reference and at most ten stable-ID rolling-horizon steps with unresolved fog.
4. `Acceptance:` hard-cut observable completion criteria.
5. `Batch gates:` controller checks after each applicable batch.
6. `Stop rules:` blockers, review, timeout, identity/session, and dirty-work protections.

Do not create a goal, dispatch a worker, or modify code while one is absent.
Create a goal only with explicit user authorization and set a token budget only
when the user supplies one.

Inspect current goal state before creation; do not duplicate an unfinished goal
or fake completion to replace it. Display the complete proposed objective in a
Markdown code block, then save it when creation is authorized and supported.

Pass the displayed goal prompt **VERBATIM** to `create_goal.objective`, preserving
its wording, formatting and line breaks. If the prompt changes, display the
complete revised prompt first, then submit that exact text. Verify the returned
objective matches the displayed prompt before continuing.

For long-horizon work, the stable objective may reference the displayed durable
navigation packet rather than repeat its evolving horizon. Do not invent
acceptance criteria or replace exact references with conversation shorthand.

For SDD, carry the selected `$coder` topology into the packet: PR-sized batches,
controller gates before review, one reviewer covering spec and code quality,
timeout/no-result handling, and scoped staging with the authorized commit/push
policy. Do not review partial diffs unless diagnosis is explicitly requested.

Keep scope, exclusions, source refs and other tasks' ownership explicit. Use
first-principles analysis, premortems or expert lenses only for unresolved
choices or material risk; architectural patterns come from the task or repo.

## Goal Prompt

Keep workflow out of the objective and place the resolved flags in one short
tools clause:

```text
Outcome: <domain outcome>.
Tools: $coder <resolved flags> as the bounded execution surface.

Hard refs: <absolute paths>.
Plan: <ordered sequence or durable navigation packet and rolling horizon>.
Acceptance: <observable hard cuts>.
Batch gates: <commands and runtime checks>.
Continuation: after each verified milestone, execute the next authorized ready
step; an isolated helper or fixture does not complete the integrated outcome.
Stop rules: repair failed gates within scope under coder's bounded recovery
policy. Escalate real authority/product choices, exhausted recovery, unavailable
required identity, or conflicting dirty work; follow host blocked-state rules.
Completion: audit every accepted requirement against current evidence before
marking the entire goal complete. No silent scope reduction or fixture-only claims.
```

Source coding standards from the nearest project instructions, DNA/rules,
docs, and `.lev/validation-gates.yaml`. Model selection belongs to the selected
project execution profile or FlowMind binding. The goal may name a model only
for an explicit current-run user override.

Before emitting `--lev`, inspect `lev exec --help`, the selected task
`execution.yaml`, FlowMind file, and project `.lev/exec-profiles/`. Prefer a
declared `--flow` or `--profile`; never guess current flags or model aliases.