snappy-go (outcome-gate spec)

Historical eval bucket for the directive-tick cron driver. The live invocation skill is state/skills/go.md (the multi-agent /snappy-go command). This page owns the per-tick outcome-gate that scores every directive tick and the audit trail behind it.

Originally reclaimed as a dormant ghost by state/bin/orphan-audit/fix.ts on 2026-04-18 (20 historical rows had no doc). Resurrected the same day by Pod X to anchor the outcome-gate fix to Pod K's audit (commit ae19fee).

Why this page exists

Pod K's audit found that every directive tick was scoring 1.0 in state/log/evals.ndjson simply because claude -p exited 0 - a participation trophy. A tick that ran for 20 minutes producing nothing got the same score as a tick that closed three p0 frictions and shipped two commits. The eval log was lying to the PID loop.

The fix is in state/bin/agents/tick.sh. This page is the spec.

Eval

Shape-gate at invocation lives in state/skills/go.md (verb: "set"). That gate validates the agent file was created correctly. Unchanged.

Outcome-gate per tick is implemented in state/bin/agents/tick.sh around the claude -p call (verb: "tick", skill: "agent-<id>"). For every tick the driver:

1. Snapshots git rev-parse HEAD and the count of distinct OPEN p0/p1

areas in state/log/breakage-report.ndjson (latest-row-per-area wins, status == "open", sev ∈ {p0, p1}) before the tick.

1. Runs the claude -p subprocess with the directive prompt.
2. Re-snapshots both values after the subprocess returns.
3. Scores the row using:

COMMITS is the delta of git rev-list --count HEAD across the tick (positive = HEAD advanced). OPEN_DELTA is OPEN_BEFORE - OPEN_AFTER (positive = frictions closed).

Each eval row carries the full forensic payload so the PID loop and any auditor can re-derive the score:

{"ts":"...","skill":"agent-default","verb":"tick","score":1,
 "tick":15,"max_ticks":40,"dur_secs":207,"exit":0,
 "commits":2,"open_before":7,"open_after":5,"open_delta":2,
 "head_before":"a4b4d2f","head_after":"c1a84c3","note":"progress"}

A run of tick-no-op rows for the same agent is the load-bearing signal that the directive is stale (verify-only, agent has nothing to do); the PID loop should retire the agent rather than keep firing it.

Actor != auditor

The set verb's actor is state/bin/agents/go.sh; its auditor is the shape-check in go.md. The tick verb's actor is state/bin/agents/tick.sh running claude -p; its auditor is the deterministic git rev-list / jq snapshot pair surrounding the call. Two different mechanisms, per program.md's rule.

Dormancy note

This skill page does not have its own runnable command - invocation is handled by /snappy-go (see state/skills/go.md). The page exists to document the outcome-gate spec and to give historical eval rows a catalog home so structural lint stops flagging them as ghosts.

Rubric

criteria:
  - name: eval_row_format_and_fields
    kind: deterministic
    check: "Each 'verb: tick' row in 'evals.ndjson' must contain 'ts', 'skill', 'verb', 'score', 'tick', 'max_ticks', 'dur_secs', 'exit', 'commits', 'open_before', 'open_after', 'open_delta', 'head_before', 'head_after', and 'note' fields."
  - name: score_correctness_exit_code
    kind: deterministic
    check: "If 'exit' is not 0, then 'score' must be 0 and 'note' must be 'tick-failed'."
  - name: score_correctness_progress
    kind: deterministic
    check: "If 'exit' is 0 AND ('commits' > 0 OR 'open_delta' > 0), then 'score' must be 1 and 'note' must be 'progress'."
  - name: score_correctness_no_op
    kind: deterministic
    check: "If 'exit' is 0 AND ('commits' is 0 AND 'open_delta' is 0), then 'score' must be 0 and 'note' must be 'tick-no-op'."
  - name: open_delta_calculation
    kind: deterministic
    check: "'open_delta' must equal 'open_before' minus 'open_after' for all 'verb: tick' rows."

snappy-go-outcome-gate - loader (dormant)

Full reference: state/skills/snappy-go-outcome-gate/SKILL.md. This skill is dormant; new runs are not expected.

Critical Rules

• NEVER treat a dormant skill as runnable without reviving its spec
• ALWAYS prefer an existing active skill over resurrecting a dormant one

Commands

| ui dashboard | state/skills/snappy-go-outcome-gate/resources/ui.openui | |full spec: state/skills/snappy-go-outcome-gate/SKILL.md |eval log: state/log/evals.ndjson (skill: "snappy-go" - historical only)

OpenUI Resource

• Skill-owned OpenUI Lang resource: state/skills/snappy-go-outcome-gate/resources/ui.openui. Read it before rendering or editing this skill's generated component surface.
• Treat this resource as a first-class artifact of the skill, not a generic chat response. Improve it when the skill's user-facing output needs to become richer.
• System resources compose OpenUI primitives and inherit SnappyChat tokens. Use ui_contract: branded in SKILL.md only for deliberate platform or client visuals.

Known Pitfalls

_(reclaimed ghost - no failures recorded in the new catalog yet.)_

Self-Test

1. [ ] Is this skill truly needed, or should I use an active neighbor?

<!-- kernel-ok: historical attribution for the PID-loader pattern. -->

Self-correcting loader (PID feedback)

This is the rule that makes loaders learn. Ported from snappy-kernel, where it demonstrably worked: the snappy-dom-cartographer skill mapped Skool admin UI once, every later ship-agent inherited the full map for free.

Before you finish, do two things:

1. Fix gaps (P - proportional). MANDATORY. If this loader didn't cover your case - if you had to read another file, run an undocumented command, work around a wrong selector, or discover a quirk - you MUST attempt an Edit to this AGENTS.md before you log.

• Default action: edit this file. Surgical. Add the missing line, table

row, or code example where it belongs. No restructuring.

• Only LOGGED is allowed when: the fix needs >10 lines, spans multiple

files, or requires a structural rewrite. In that case the state/regen/drain.sh queue picks it up asynchronously.

• "I didn't have time" / "it's minor" / "the next agent will figure it out"

are NOT valid reasons. Minor gaps compound - that's the whole point of this loop.

• Concrete example of a valid P-fix: discover agent-browser screenshot

takes path positionally not as --output <path>. One line in a table. Edit it in. Do not just log it.

• The goal: the next agent never has to leave the loader.

2. Log the result.

echo "[$(date -u +%FT%TZ)] snappy-go-outcome-gate: <what was missing or fixed> [FIXED|LOGGED]" >> state/log/loader-feedback.log

• FIXED = you patched this loader inline (P-fix).
• LOGGED = too large for inline; the PostToolUse enqueue + Stop-hook drain

will rewrite the loader from scratch on next session-end.

Do not skip this. Every agent run must leave the system better than it found it. The loader is the setpoint; you are the sensor; the gap is the error signal; closing the gap is the correction.