Publish Deploy

Generated

This page is generated from qa/operations/specs/publish-deploy.md — the source of truth. Edit the spec, not this page.

Last run: not yet recorded (run the replay suite to populate status).

Overview

Once rules are approved, the operator publishes a new ruleset version. Publish is the terminal cockpit UI action and is deliberately irreversible-feeling: the Publish tab stages the approved changes, and confirming requires typing the exact phrase publish vN before the publish proceeds. Version history is folded into the Publish tab (no longer a separate tab) — the published versions list links to each version’s Ruleset Card and release notes. The legacy /publication/history/:id deep link redirects into the Publish tab so old links keep working.

The draft panel still offers a direct publish path that lands on a confirmation. Deployment itself is API-driven (the operator POST /operator/worlds/{id}/deploy-version route, not a cockpit affordance), so it is exercised at the API/smoke level (D5), not the browser; the browser specs here end at the publish confirmation.

Preconditions

• Signed in as the seeded operator.
• A world with at least one enshrined rule.

Scenarios

1. Publish a version from the draft panel

• Open the publication draft panel for the world
• Trigger Publish version
• Expected: A publication confirmation is shown (the new version + released-at + request id).

2. Enshrinement preview degrades gracefully when unavailable

• Open the draft panel when the enshrinements preview read is unavailable (the backend route is not yet built)
• Expected: A “preview unavailable” notice is shown and the Publish control remains enabled (the backend validates the deployable set) — the panel is not wedged.

3. Version history is folded into the Publish tab

• Open the Publish tab for the world (the version-history inspector deep link redirects here)
• Expected: The published version(s) are listed inline on the Publish tab, each showing its version and released-at; the live version reads its Proceed state. Each version row also carries its decisions-served read and its added/changed/removed change counts vs the prior version (an em-dash when those reads are not yet populated).

3b. The Publish tab stages the next-version change summary

• Open the Publish tab for a published world
• Expected: A staged-changes summary shows the live-to-next version arrow (e.g. v1 → v2) and the added / changed / removed staged-rule counts (an em-dash with a “counting…” note when the staged-diff read is unavailable).

4. Reach a Ruleset Card from version history

• From a published version on the Publish tab, follow the “Ruleset Card” link
• Expected: The version-addressed Ruleset Card renders.

5. Type-to-confirm gates the publish action

• On the Publish tab, open the publish confirmation
• Expected: The confirm button stays disabled until the exact publish vN phrase is typed; the dialog states that publishing is permanent and emits version-published events.

6. Author and revise release notes

• Create release notes for a draft version, then revise the narrative
• Expected: The draft notes are created and the revision is saved.

7. Release notes lock once the version is published

• Attempt to revise release notes whose parent version is published
• Expected: The editor reflects the locked state (the revision is rejected with a locked indication).

Test Data

Label	Value	Notes
Release narrative	Initial filing-threshold rules.	Draft notes body