roi-go

Files (1)

• SKILL.md

SKILL.md (first lines)

# roi:go — implementation driver

This skill turns ROI plans into real code, tests, and verification evidence.
It owns one stage: **read plans → implement actions → run oracles → record
evidence**. It is the **work loop** (edit repo → run gates →
`evidence_record`).

It does **not** replace `roi:drive`, which owns the **ROI loop** (runs,
verify gate, publication markers). `roi:drive` may invoke this skill in the
same session when implementation proof is owed.

**Pairing:** `roi:outline` → **`roi:go`** → `roi:drive`. Do not expect
`run_create` in `mode=local` to implement anything — it only records a stub
prompt. Implementation happens here.

## When invoked from `roi:drive`

When `status_get.summary.next_actions` leads with `roi:go`, treat that as
active scope:

- Use the **same `mission_id`** (and plan id / wave if drive named one).
- Select only plans covered by current planning orientation. Within that
  semantic scope, prefer the lowest-wave plan that lacks substantive
  verification evidence unless the operator named a specific plan.
- After recording evidence, return control to `roi:drive` so verify gate
  and publish can proceed.

### Completion mode (drive-invoked, default)

When `roi:drive` invokes this skill for completion (default unless the
operator said **drive only**), do **not** stop after a single plan:

1. Read state:

   ```bash
   node roi/scripts/lifecycle.mjs status_get '{"mission_id":"<id>"}'
   ```

   Inspect `mission_go_progress` (`total`, `substantive`, `open[]`),
   `latest_run`, and `orientation_get` for the selected plan. Progress fields
   are telemetry only; they do not establish scope or readiness.

2. **Loop** until the semantically declared orientation scope has no open plan
   obligations (or the operator constrained a single plan / wave). Do not infer
   sufficiency from a nonzero count, ratio, percentage, score, or ContextPack
   TTL:

   - Pick the lowest-wave plan still lacking substantive `roi:go`
     verification **and** whose `dependencies` (plan UUIDs) already have
     substantive passes. Use:

     ```bash
     node roi/scripts/lifecycle.mjs plan_list '{"mission_id":"<id>"}'
     node roi/scripts/lifecycle.mjs evidence_list '{"mission_id":"<id>"}'
     ```

   - Implement that plan (actions → oracles → `evidence_record` with proof
     bundle).
   - Emit `→ implemented [plan] (wave N, verification pass|fail)`.
   - On oracle failure: stop with blocking plan id; do not advance to the
     next plan in the loop.

3. Emit a **completion matrix** as telemetry, alongside the semantic scope and
   current checkpoint identity:

   ```
   roi:go progress: {substantive}/{total} substantive passes
   open: [plan_id …] or (none)
   orientation_scope: [owner_seam_id …]
   checkpoint: <orientation checkpoint id/status>
   ```

4. Return control to `roi:drive` — drive will run reconcile (resume paused
   review tasks), reach `verify_gate` (mandatory pause), and the operator
   will run `roi:verify`.

### Strict mode (operator says strict / verified **or** brief policy is strict)

Strict applies when **any** of these hold:

1. Operator says `strict` / `verified` on `roi:drive` or sets `ROI_STRICT_VERIFY=1`.
2. `status_get.summary.verification_policy` is **`strict`** (brief carries
   `verification_policy: strict` or graduation/maturity hints — see
   [`docs/mission-verification-policy.md`](../../docs/mission-verification-policy.md)).

When strict applies, every `evidence_record` with `result: pass` must reach a
**verified trust tier** — either of:

- **`run_oracles: true`** — the helper runs `verification_targets` itself and
  stamps `verified_by: mcp` (legacy stamp name; means **helper-verified**,
  reported as `mcp_verified`). This is the strongest tier.
- **A subagent attestation** — `subagent_verified`, for a clean/external
  verifying entity. See [Subagent verification](#subagent-verification-decision-055-d7)
  below.

Plus, in both cases:

- **`paths_touched`** under `bmo/` or `roi/`.
- Optional **`product_tree: bmo`** or **`roi`** when porcelain cross-check
  is appropriate for the plan slice.

Do not rely on agent-set `oracles_ok` alone in strict mode — the helper
overwrites oracle results when `run_oracles` is true.

**You cannot write `verified_by` yourself.** It is gate-authored: the ingress
strips any caller-supplied value and counts the attempt (decision 055 D2). A
pass carrying a self-typed `verified_by: mcp_verified` degrades to
`agent_claimed` and strict blocks it.

### Subagent verification (decision 055 D7, D8)

A **clean/external subagent is a valid verifying entity.** Its verification is
accepted at tier `subagent_verified`, which satisfies `require_verified_proof`,
**when it verified against a static prompt-doc on the graded surface of the
codified corpus** — rather than against prose generated during the run.

**Being under `docs/prompts/` is not enough (D8).** The corpus also holds
`fixtures/*-variant.md` files titled "Deliberately invalid …", one of whose
bodies reads *"Execute approved units anyway"*. The admitted surface is the part

From instagrim-dev/roir, MIT.

More from instagrim-dev/roir