# openspec/changes/wf-roadmap-to-revenue/proposal.md

## Why

The roadmap follows whoever spoke last. Nobody can say which deals wait on which feature, or which deals moved after a feature shipped. It turns a roadmap argument into a list with pipeline next to each item, and it stops shipped work from going untold.

## What Changes

- Add the `roadmap-to-revenue` workflow to the PromptReports workflow library, run by the workflow runner as an agent acting for a person.
- Sales as Code: Read the capability each deal waits on (today: Built).
- CommitOps: Read those deals into the ledger (today: Switching on).
- CommitOps: Rank capabilities by blocked pipeline (today: Planned).
- RepoOps: Find shipped work per capability (today: Built).
- CommitOps: Report the deals each shipped capability moved (today: Planned).
- PromptCompute: A person approves telling each waiting customer (today: Built).
- Gate `commitops.customer.notify`, `crm.deal.update` 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: Sales as Code, CommitOps, RepoOps.
- Outside the family: HubSpot, Salesforce or Attio, GitHub.
- State: Partly built. Sales as Code deals name the capability they wait on, sent once CommitOps reads them. Two parts to go.
- Plan row: LDG-2273.

# openspec/changes/wf-roadmap-to-revenue/tasks.md

## 1. Connect and authorize

- [ ] 1.1 Confirm the org has a connection for each of: Sales as Code, CommitOps, RepoOps. 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 `commitops.customer.notify`, `crm.deal.update` with `require_approval` as the default.

## 2. Build the steps

- [ ] 2.1 Sales as Code: Read the capability each deal waits on.
- [ ] 2.2 CommitOps: Read those deals into the ledger.
- [ ] 2.3 CommitOps: Rank capabilities by blocked pipeline. Blocked: this part is Planned; until it ships, record the step's evidence as `missing` and continue.
- [ ] 2.4 RepoOps: Find shipped work per capability.
- [ ] 2.5 CommitOps: Report the deals each shipped capability moved. Blocked: this part is Planned; until it ships, record the step's evidence as `missing` and continue.
- [ ] 2.6 PromptCompute: A person approves telling each waiting customer.

## 3. Verify and record

- [ ] 3.1 Run a dry run with the user's inputs: Pipeline = Open deals this quarter; Capability list = From CommitOps.
- [ ] 3.2 Run it once for real; approve each gate as the user.
- [ ] 3.3 Measure the outcomes: Open pipeline attached to each capability; Deals that moved within 30 days of the capability shipping; Shipped promises not yet told to the customer: target 0 after 7 days.
- [ ] 3.4 Confirm the run left a signed record with a task id and one workflow request counted.

# openspec/changes/wf-roadmap-to-revenue/specs/workflow-roadmap-to-revenue/spec.md

## ADDED Requirements

### Requirement: Demand is ranked by pipeline

The ranking step SHALL order capabilities by the distinct open pipeline that waits on them.

#### Scenario: Demand is ranked by pipeline

- **WHEN** two deals at one company wait on the same capability
- **THEN** the ranking counts the company's pipeline once

### Requirement: Shipped work gets told

The workflow SHALL list each customer whose promised capability shipped and who was not told.

#### Scenario: Shipped work gets told

- **WHEN** a capability ships
- **THEN** shipped_not_told lists its waiting customers, oldest first, for approval

### 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