Prism 0.7.3

Release date: 2026-10-13

Prism 0.7.3 makes the board confirm an applied action only when it shows that operation's result, keeps app-stage lines readable on narrow cards, and requires the release participation wherever a released feature's scope is derived.

Changed

• app_stages_text takes the release participation as a required argument, with _status_row of the board service. A caller can no longer judge a released feature's retired apps from the feature page alone by leaving it out; every caller already passed it.

Fixed

• An app-stage line never breaks inside an app ID or a stage. On a narrow card, backend · ready-for-release wrapped as backen / d. The line now wraps only between the app and its stage, a value wider than the row is cut with an ellipsis and keeps its full text in a title, and the Apps view chip keeps its stage label on one line.
• The applied-view check confirms the operation's own result. After an apply the page accepted any status among a minimum-of-stages action's targets, so a stale refresh could be labelled validated (release-done still at ready-for-release). The applied receipt now carries resulting_features, the status, owner and app stages of each feature page the operation wrote, and the page validates a refresh only when its graph shows them. A partial dev-done that leaves the feature in-dev still validates once its app stage is visible. The receipt also names the graph that first contains the operation (graph_epoch, graph_version: the epoch and version of the snapshot the synchronous refresh after the write produced, stored once and reported by apply, recover and the operation lookup). The page treats a graph of that epoch at or after that version as current, whatever it shows, because a later change may have replaced the result, and a view at an earlier version waits; it never takes a baseline from the view it holds when it inspects an operation. A graph of another epoch (the server restarted after the operation) was built from disk after the operation completed, so it is current at once with no stale label; only a receipt without the pair falls back to resulting_features, and any newer graph ends its wait. Recovery from the Operations dialog confirms the view against the recovered receipt.
• The snapshot a receipt names contains the operation's writes. The graph refresh that follows a write shared the write's read scope, so release-record facts cached before a release-done stayed cached while the graph was rebuilt: the stamped snapshot showed no latest release for the apps and reported false missing-record errors. The refresh now starts without the facts the write computed before it.
• MCP results stay within their size limit with a wide receipt. A release that wrote many features made resulting_features too large for the 48,000-character result limit, and the shaper removed applied_paths without getting under it. The shaper now drops resulting_features entries first (the first ones in feature ID order stay) and marks the receipt resulting_features_truncated: true; the HTTP receipt keeps every feature.