outcome-run

Outcome Run

Run one action for one outcome folder. An action is one concrete step on a lever, whether a rep of a proven recipe or a fix to something in the path. The run folder records work references and learning; Superdense records durable sessions, artifacts, externalization targets, and reward snapshots.

Read references/outcome-loop.md and references/preflight.md before starting.

Workflow

1. Locate the outcome folder and read goal.md, run.md, and gate.md. If any are missing, stop and use outcome-setup to repair the folder contract.
2. Start with the bounded reward preflight. references/preflight.md is the full job specification:
   • Spawn a bounded subagent when the runtime supports it and the invocation permits subagents.
   • Prefer a lower-cost or lower-reasoning subagent only when it is still capable of correct, bounded maintenance.
   • If subagents are unavailable, run the same preflight locally.
3. Run the preflight per references/preflight.md, filling in <outcome-folder>. It plans the maintenance pipeline with one superdense reward next --project <id> --items 10 call, advances each returned step in one bounded batch up to the budgeted item count, and returns a compact evidence packet. reward next retires matured targets itself (linked and non-located) and returns the project name and roots, so no separate retire call is needed. It stays on already-external active targets and the current run; it does not drain the internal backlog.
4. Refresh the lever portfolio in run.md from the evidence packet when the evidence clearly changes pull count, reward summary, uncertainty, last-pulled, status, or Pareto-best dimension. Do not flatten multidimensional reward into one scalar.
5. Render due experiment verdicts with superdense experiment verdict <id> when target reps are met and the reward window is mature. Surface refuted hypotheses with superdense hypothesis list --project <project-id> --status refuted as "what not to try" before choosing a new action.
6. Surface comparable cohorts and version chains yourself — this is the run agent's job, not the preflight's. Start with superdense cohort list --project <project-id> --by type and inspect relevant version chains; keep it compact and project-scoped. Use them to inform the next action.
7. Use goal.md, run.md, gate.md, open hypotheses/experiments, refuted hypotheses, cohort/chain comparison, and the evidence packet to choose exactly one action unless the user explicitly asks for exploration only. First set Mode: explore or Mode: exploit from the Selection Policy.
8. For explore, record a structured falsifiable hypothesis with superdense hypothesis record unless an open suitable hypothesis already exists. Open or extend an experiment with superdense experiment open and later superdense experiment add-member. For exploit, cite the supported hypothesis and experiment that justify the proven lever.
9. Create runs/<run-id>/ using a stable date-plus-slug id. Use the ## Run Record Template in run.md as the source of truth. Write:
   • work.md
   • learnings.md
10. Execute the action in the correct surface:
    • for content outcomes, the run folder may contain drafts or final copy,
    • for product outcomes, edit the target repo and record branch, PR, deploy, event names, and session IDs in work.md.
11. After the shipped artifact exists or the run has a stable artifact id, attach the run/artifact to the experiment with superdense experiment add-member. Record Mode, Hypothesis id, and Experiment id in work.md.
12. Before completion, apply gate.md: