Revive the product promises registry as forge project items #92

Closed AtlantisPleb opened this 23h ago 1 comment

Outcome

Represent public product promises as canonical forge issues viewed through a project with machine-readable LIVE, GATED, and WITHDRAWN states.

Current behavior

The former promises registry reconciled claims with evidence, but the current forge has no structured promise record. Roadmap cards, episode claims, changelog entries, and implementation issues can drift without one item that states what was promised and what evidence supports its state.

Source: docs/episode-triage.md, episodes 234 and 251 and the claim station.

Contract

Use one canonical issue per promise with a stable promise ID.
Record problem, claim, scope, acceptance criteria, success metrics, owner, target, state, last verification time, and evidence links.
Add a project field with LIVE, GATED, and WITHDRAWN options.
Require an accepted-outcome receipt before LIVE.
Require the missing gate, owner, and next review before GATED.
Require a reason, replacement path, and date before WITHDRAWN.
Expose the registry through the existing Projects and Issues APIs.
Let verified gaps become bounty candidates without duplicating the promise issue.

Acceptance criteria

A person or agent can list every promise and its evidence through the forge API.
State changes are actor-attributed and preserve history.
A promise cannot become LIVE from a narrative comment alone.
WITHDRAWN promises remain discoverable and explain what replaced them.
Private roadmap material cannot leak through public promise items or evidence links.

Verification

Backfill a small reviewed set from docs/episode-triage.md, test state gates and authorization, and compare API and web projections. Run mix precommit.

Dependencies

Depends on #60, project 3 accepted-outcome receipts, and project 8 stored-field board work.

AtlantisPleb opened this issue 23h ago
A AtlantisPleb Author 18h ago

Fixed in c0a0451 on main.

The registry is a Projects V2 project with one promise_state field (LIVE, GATED, WITHDRAWN), one canonical issue per promise, and the promise record stored in the item's values["promise"] with a stable ID. LIVE requires a readable accepted_outcome evidence entry naming an accepted Compensation.OutcomeDecision receipt, so a promise cannot self-certify through a narrative comment; issue, changelog, receipt, and link entries remain supporting evidence. GATED requires the missing gate, owner, and next review, and a gated promise with a missing gate is reported as a bounty candidate. WITHDRAWN requires the reason, replacement, and date, and stays visible.

Every create, update, and state change writes an actor-attributed row to an append-only project_item_events log that PostgreSQL refuses to rewrite and that outlives the project it describes. Reads are paginated at GET /api/v3/repos/:owner/:repo/projectsV2/:project_number/items/:item_id/events, and item lists accept promise_state and bounty_candidate filters. Evidence pointing at a repository or issue the reader cannot read is redacted from the item, promise, and event projections, and the project board renders the three states with the same data.

mix openagents.promises.backfill loads the reviewed set in priv/promises/curated.json, is idempotent, and skips a promise whose gate does not hold in the target database rather than downgrading its state. One note on that set: promises_registry_v1 is recorded as GATED, not LIVE, because the registry launch has no accepted-outcome receipt yet. See docs/product-promises-registry.md and PROMISE-001 and PROMISE-002 in INVARIANTS.md.
closed this as completed 18h ago