Prism 0.7.4

Release date: 2026-10-13

Prism 0.7.4 shows a product's bugs, release history and incidents on the board as clearly as its features: a bug board by status, a release timeline with kinds, outcomes, chains and live deliveries, and incidents by status, each with its own panel and linked to the features and apps it touches.

Added

• The board page shows the bugs, the release history and the incidents. Three views follow Apps: Bugs (a board with a column per status, severity, blocking, deferred and regression badges, the apps, the owner, the feature as a link and a closed bug's disposition; the invalid column of pages without a known status comes first, and the count reads "12 bugs, 2 invalid"; filters by app and blocking only, which counts and shows the open blocking bugs, the number on the Open bugs tile), Releases (the highest record number first, as the release validator orders them, with the kind, outcome and current badges, the features and bugs as links, retry of and rollback of links and each delivery as an item, app, target, version and outcome row, the item as a link; filters by app and target) and Incidents (by status, with the severity, the impact, "cause unknown" and links to the releases and follow-ups). A record opens a panel with its summary, fix, verification and release rows, its deliveries and chain, or its impact and timeline, and a link between records opens the other panel. A card opens exactly its own record, found by its kind and source path, so the second of two BUG-003 pages opens its own panel. A link resolves within the kind its field names, by ID, to the first valid page of that kind: the Apps view's open bugs only to bugs, its open incidents only to incidents, its released features only to features and its latest release only to a release, a bug's feature only to a feature and a release's bugs only to bugs, so an open bug that declares F-001 or an ID such as custom opens its own panel and a page that declares another kind's ID never takes a link. A field that can name a bug or a feature (an incident's follow-ups, a delivery row's item) tries the kind its ID prefix names first and then the other. Closing a panel puts focus back on the card that opened it, also after a live update replaced the card, and on its column or the view when the record is gone. A digit typed in a filter does not switch the view, and a list of IDs in the Apps view that is cut ends with "+N more". A feature's panel lists its bugs and the release records that name it, the Apps view links each app's open bugs, open incidents and latest release, and the header shows Open bugs (with the blocking count) and Open incidents, each opening its view. A page that fails lint shows with a warning instead of being hidden, and a view without records says so. The views are read-only and appear on the connected board, the legacy dashboard and the static export.
• The graph envelope carries the bug, release and incident records. facts.bugs, facts.releases and facts.incidents list every bug page, release record and incident, each sorted by its record number, for the board's record views. A bug entry has its status, owner, severity, blocking flag, apps, feature, where it was found, its disposition if closed, a summary and its Fix, Verification and Release rows. A release entry has its date, kind (release, retry, rollback or redeploy, from the chronological release validator that lint and the status board use), outcome, features and bugs, the record it retries or rolls back, a summary, its Delivery rows and whether it is current: the latest record of an app and target, and it released there, as in the Operations row, so a record rolled back without a redeploy is not current. An incident entry has its date, status, severity, apps, releases, follow-ups, an impact summary, whether the cause is known and its Timeline (the last 20 lines when it is longer, with timeline_truncated). Text is plain and bounded: a summary or impact is its first paragraph cut to 240 characters at a word boundary, a timeline line to 200. A record that lint marks invalid is still listed, with valid: false. The values come from the readers lint and the status board use, and the graph reads each page once for these lists and for the Operations rows. The graph schema describes the three lists, and docs/wiki-visualization.md lists the facts.

Fixed

• An ID with thousands of digits no longer stops lint, the status board or the graph. A bug, incident or release record whose ID ends in a number too long to convert (5,000 digits) made the graph builder, the live board, the static export and the Operations rows raise. Records now sort by the length and the digits of their number. A bug, incident, feature or release record whose ID has a number of more than 18 digits is an invalid ID: lint reports it (bug-page-invalid, incident-record-invalid, invalid-feature-id, release-record-invalid), the record stays listed with valid: false, it takes no part in release chronology, current deliveries, numbering or the retry-of and rollback-of checks, and a board write that creates one is refused. Within 18 digits every surface orders records by their number.
• Page text with thousands of digits no longer raises. Every conversion of digits read from a page into an integer goes through one bounded function: an acceptance-criterion ID, a criterion reference or an attempt (qa-N, release-N) of an evidence row, a contract binding version, a Test strategy criterion, an open-question number, wiki-stale-after-days and a minimum CLI version of the manifest. A value of more than 18 digits is reported by the diagnostic that already reports a malformed value (criterion-id-required, invalid-evidence-row, invalid_open_question, invalid-wiki-stale-after-days, invalid-min-prism-cli-version), in lint, the graph and a board preview alike.
• An integer from front matter is checked by its value, and an ID takes the digits 0 to 9 only. YAML reads hexadecimal and octal integers of any size, so an API contract with version: 0x and thousands of f made the citation raise in lint, the graph and read_workspace. One function now accepts a front matter integer only when it is a whole number from 0 to 999999999999999999, compared by value and never turned into text: the version of an API contract, criteria-high-water, schema-version, wiki-stale-after-days and the manifest schema_version. Any other value gets the field's own malformed-value diagnostic (invalid-api-contract-version, for a contract version). A contract version has one range, 1 to 999999999999999999, for contract lint, the board's contract checks, the citation and the Delivery row that cites it. Every reader of page or manifest YAML also refuses an integer outside that range anywhere in the front matter, whatever the field: lint reports the page as malformed (malformed-frontmatter, malformed-page, invalid-workspace-manifest-yaml) with "front matter holds an integer outside the supported range", a board preview refuses it as invalid_frontmatter, and no later formatting of a value can raise. So a contract with a longer version is invalid at its source, has no citation, and no Delivery row can cite it. Every ID grammar (F-, BUG-, INC-, REL-, AC-, qa-, release- and question numbers) matches the digits 0 to 9, so an ID written with other Unicode digits is an invalid ID of its kind and never valid.