# openspec/changes/wf-incident-to-policy/proposal.md

## Why

Postmortems produce lessons that nobody enforces, so the same error comes back. Each incident makes the next one less likely, and you can show which lessons have a check behind them.

## What Changes

- Add the `incident-to-policy` workflow to the PromptReports workflow library, run by the workflow runner as an agent acting for a person.
- RepoOps: Open a lesson candidate from the incident (today: Built).
- RepoOps: File it for review (propose_brain_entry) (today: Built).
- PromptCompute: Propose the policy change the lesson implies (today: Planned).
- ContextFile: Publish a new context version with the lesson (today: Built).
- PromptCompute: Run the new rule in a shadow test first (today: Built).
- PromptCompute: A person promotes the lesson (today: Built).
- Gate `memory.lesson.promote`, `memory.agentmd.publish` through PromptCompute approvals; each gated step runs only after `verifyResume` passes, with `final_args`.
- Write a signed record at the end of each run and count one workflow request.

## Impact

- Products: RepoOps, PromptCompute, ContextFile.
- Outside the family: GitHub.
- State: Partly built. A bad outcome already starts a lesson. Lessons that propose a policy change are still to build.
- Plan row: LDG-2276.

# openspec/changes/wf-incident-to-policy/tasks.md

## 1. Connect and authorize

- [ ] 1.1 Confirm the org has a connection for each of: RepoOps, PromptCompute, ContextFile. Stop and tell the user which is missing.
- [ ] 1.2 Get a PromptReports ID agent token for each product the run calls (RFC 8693 exchange). Where a product does not accept ID tokens yet, use its connect key.
- [ ] 1.3 Register policy for `memory.lesson.promote`, `memory.agentmd.publish` with `require_approval` as the default.

## 2. Build the steps

- [ ] 2.1 RepoOps: Open a lesson candidate from the incident.
- [ ] 2.2 RepoOps: File it for review (propose_brain_entry).
- [ ] 2.3 PromptCompute: Propose the policy change the lesson implies. Blocked: this part is Planned; until it ships, record the step's evidence as `missing` and continue.
- [ ] 2.4 ContextFile: Publish a new context version with the lesson.
- [ ] 2.5 PromptCompute: Run the new rule in a shadow test first.
- [ ] 2.6 PromptCompute: A person promotes the lesson.

## 3. Verify and record

- [ ] 3.1 Run a dry run with the user's inputs: Incident = INC-311; Repo = northwind/api.
- [ ] 3.2 Run it once for real; approve each gate as the user.
- [ ] 3.3 Measure the outcomes: Lessons with a check (PromptCompute's own brain: 16 of 21 on 2026-11-07); Errors that came back after a lesson; Days from incident to enforced policy.
- [ ] 3.4 Confirm the run left a signed record with a task id and one workflow request counted.

# openspec/changes/wf-incident-to-policy/specs/workflow-incident-to-policy/spec.md

## ADDED Requirements

### Requirement: A lesson is tested before agents read it

The workflow SHALL run a proposed rule in a shadow test before a person can promote it.

#### Scenario: A lesson is tested before agents read it

- **WHEN** the shadow test would have blocked a request that later succeeded
- **THEN** the run shows the false block on the approval card

### Requirement: Evidence stays honest

Each step SHALL report what it saw as measured, inferred or missing, and SHALL never report missing as measured.

#### Scenario: A product part is not built

- **WHEN** a step depends on a part that is Planned or Proposed
- **THEN** the step records `missing`, names the part, and the approval card shows the gap

### Requirement: One run is one workflow request

The runner SHALL count one workflow request when the first step starts, and SHALL NOT count retries, resumes or dry runs.

#### Scenario: A gated step resumes after two days

- **WHEN** a person approves a step and the run resumes
- **THEN** the org's usage does not change