feat(goal): add the /goal durable objective ledger and gauntlet loop

.agents/skills/goal/SKILL.md

@@ -0,0 +1,94 @@
+---
+name: goal
+description: >-
+  Take one large objective, hold it durably, and drive it to completion through repeated verified passes of the gauntlet loop.
+  Use when the captain invokes /goal, or asks to set up, run, resume, check, or close a long-running objective that will outlive this session - "make X real", "keep working on X until it is done", "set up a loop for X", "where is X up to".
+  Owns goal creation, gate design, the eight-stage loop, the automation handoff, and the fail-closed completion verdict.
+  Not for ordinary task dispatch: a single change that a worker can finish and land is a backlog item, not a goal.
+user-invocable: true
+metadata:
+  internal: true
+---
+
+# goal
+
+A goal is an objective too large for one task, too long-lived for one session, and too important to be tracked in conversation memory.
+This skill turns such an objective into a durable record that survives restarts, drives itself through repeated verified passes, and refuses to report success until evidence says so.
+
+`bin/fm-goal.sh` owns every command, path, and record format.
+Read its header before the first use in a session; this skill owns the judgement, not the mechanics.
+
+## When this is the right shape
+
+Use a goal when all three hold.
+
+- The objective needs many tasks over many sessions, so no single brief can carry it.
+- "Done" is a verdict that must be computed from evidence, not asserted by whoever finished last.
+- Progress must survive a context reset, a crash, and a change of harness.
+
+Use the backlog instead when a single worker can finish and land the change.
+Adding a goal for ordinary work buys durability nobody needed and costs a second place to look.
+
+## The gauntlet loop
+
+The default stage list is `ingest, verify, interpret, merge, render, evaluate, improve, archive`.
+It is a complete cycle: gather the inputs, check they are trustworthy, understand what they mean, integrate them, produce something, score it, refine it, and record it.
+A loop that skips `verify` or `evaluate` is not a gauntlet, it is a treadmill.
+
+Stages are configurable per goal with `--stages`, because a research goal and a production goal do not have the same shape.
+Keep the list short enough that a full pass is a meaningful unit of progress.
+The loop is deliberately circular: reaching the last stage wraps to the first and journals a completed pass, because a goal that is not yet closed always has another pass to run.
+
+## Gates are the whole point
+
+A gate is an executable check that answers one closed question about the objective with an exit code.
+Gates are what make the completion verdict a fact rather than an opinion, so design them before running the loop, not after.
+
+Every gate must satisfy all of these.
+
+- It answers one question, and its exit code is the whole answer: `0` passes, anything else fails.
+- It is runnable unattended, with no prompt, no network dependency it cannot tolerate losing, and a bounded runtime.
+- It fails closed. A gate that cannot determine the answer must fail, never pass. A gate that passes when its subject is missing is worse than no gate.
+- It reads state and reports; it does not fix, install, push, or merge. A gate that changes the thing it measures cannot measure it.
+- Its output is the evidence a sceptic would want, because that output is what gets captured when it fails.
+
+Register a gate with `gate-add`, which records its exact bytes.
+If those bytes later change, the gate reports `UNBOUND` and refuses to run, and any result recorded against the previous version stops counting.
+That is deliberate: an unattended loop that can quietly rewrite its own success condition is not a verification loop.
+Re-registering a gate is normal and expected; re-proving it afterwards is mandatory.
+
+State the gates in the captain's terms when you propose them, and get agreement on the gate set before spending work against it.
+A goal whose gates were never agreed will finish and satisfy nobody.
+
+## Running a goal
+
+1. **Frame it.** Write the objective to a file and create the goal with `new`, passing that file to `--objective`. The objective text is the contract; keep it specific enough that a stranger could tell whether it was met.
+2. **Design the gates.** Propose the gate set to the captain, then register each one with `gate-add`. A goal with no gates can never pass, by design.
+3. **Run passes.** Do the work for the current stage, record what happened with `note`, then `advance`. Never advance a stage whose work did not happen; a journal that records passes nobody made is worse than an empty one.
+4. **Prove it.** Run `gate-run` at the end of each full pass, and read the failures rather than the summary line. The evidence file for a failing gate is the actual finding.
+5. **Close it.** `close` refuses unless every gate has a current pass. Take the refusal as the answer, never as an obstacle to work around.
+
+## Escalation
+
+Bring the captain in for the gate set before work starts against it, for any gate that has failed the same way across three consecutive passes, and for any objective the evidence shows is unreachable as written.
+A goal that keeps looping without its failing gate moving is not progress, and reporting the loop as activity misrepresents it.
+Routine passes, individual gate runs, and stage advances are not captain-facing events.
+
+## Automation handoff
+
+A goal can be driven by a recurring trigger so it continues without the captain re-asking.
+Before arming anything, inventory the automation that already exists in the target project and say what you found.
+Adding a loop on top of unmapped automation is how two schedulers end up fighting over one repository, and an existing unattended loop that pushes or resets a working tree makes that compounding damage rather than duplicated effort.
+
+The arming rules are narrow on purpose.
+
+- One owner. Exactly one trigger drives one goal. Never arm a second while the first is live.
+- The automated pass runs the loop and the gates, and it may write evidence and journal entries. It does not merge, push to a default branch, discard unlanded work, or answer a decision that was escalated to the captain.
+- A gate that fails is a stop, not a retry. Escalate the failure with its evidence rather than looping on it.
+- Anything destructive, irreversible, or security-sensitive stays with the captain regardless of what the loop concludes.
+
+## Reporting
+
+Report a goal in outcomes: what the objective is, which gates pass, which do not, what the failing evidence says, and what decision is needed next.
+`export-json` gives the machine-readable form for a status page or a dashboard.
+Never present a passing verdict without naming the gate set it passed, because the verdict means exactly as much as the gates do and no more.

AGENTS.md

@@ -486,6 +486,9 @@ Unresolved decisions discovered by investigations or visual reviews follow `deci
 Update the backlog on every dispatch, completion, and decision for a work item.
 Re-evaluate queued work after every teardown and heartbeat, dispatching items only when dependencies and time gates have cleared.
 
+An objective too large for one work item and too long-lived for one session is a goal rather than a backlog entry.
+Load the `goal` skill when the captain invokes `/goal`, or asks to set up, run, resume, check, or close such an objective; the backlog still holds the individual work items that goal spawns.
+
 `.tasks.toml`, `docs/configuration.md`, and current `tasks-axi --help` own the backlog schema, compatibility, retention, and routine command syntax.
 Use compatible `tasks-axi` when the configured backend selects it and the documented manual path otherwise; keep only the configured recent Done entries.
 `secondmate-provisioning` and `bin/fm-backlog-handoff.sh` own cross-home handoff safety.

README.md

@@ -174,6 +174,7 @@ Claude and grok use the slash form shown here; codex uses the same names with `$
 | `/afk`             | Enter away-mode supervision: the sub-supervisor self-handles routine notifications in bash, escalates captain-relevant events and bounded declared-external-wait rechecks as batched digests, and actively alerts if delivery gets stuck while you step away |
 | `/ahoy`            | Recap visible session events since the prior real captain message plus visibly unanswered captain decisions, then guide the captain through any open decisions one at a time in agent-judged impact order; fall back to Bearings when invoked as the session's first real captain message |
 | `/bearings`        | Generate a concise four-section chat digest from bounded local fleet and registered-secondmate state; use `/bearings file` to also replace today's dated report in `data/`, and add `include PRs` when live PR enrichment is wanted |
+| `/goal`            | Hold one long-running objective in a durable ledger and drive it through repeated verified passes of the gauntlet loop, with content-bound gates that decide completion from evidence rather than assertion |
 | `/updatefirstmate` | Self-update the running firstmate and its secondmates to the latest from origin with fast-forward-only pulls, then re-read instructions and nudge secondmates |
 | `/stow`            | Sweep the session for uncaptured durable knowledge, persist the open work records this session knows are unfiled or now wrong, curate tiered startup memory with decay and cold archival, enforce each home's budget or surface the required decision, cascade to registered second mates, and report what is safe to reset |