Prism 0.7.0

Release date: 2026-10-11

Prism 0.7.0 delivers the full lifecycle from intake and specification through separate UI and technical design tracks, development, QA, release and operation. It adds roles to board grants with gated approval in the board, per-app progress, release records with rollback and redeploy, and support for bugs and incident records. It also includes security hardening from the independent reviews. Workspaces from earlier versions must be recreated.

Added

• Six workflow roles on board grants. prism board grant NAME --kind human --write --role po,designer,tech-lead,dev,qa,release gives a writable human grant its roles (--role takes a comma-separated list and may be repeated). Roles are fixed for a grant's life; a change is a new grant plus prism board revoke of the old one. An agent grant holds no role (agent_role_forbidden), a role needs --write (role_requires_write) and a role outside the set, or one listed twice, is invalid_role. A grant identifies a registered token holder and does not verify a person.
• Gated approval. A lifecycle action is gated when the registry names the roles its approver must hold (required_roles: every role in all_of and, when any_of is not empty, one of them). An agent proposes with preview_skill and cannot apply, recover or decline (approval_required). A human who satisfies the predicate approves in the board: the board header's Proposals dialog lists the proposals that wait for them, shows the checks and the writes, and applies with the review revision and an explicit acknowledgement, or declines with a reason. Approval is accepted only over a browser board session (approval_requires_board_session). The log entry names the approver, the roles they held and the proposer. The board checks the role at preview, at apply, on a pending retry and at recovery, together with the current policy (role_required, approval_review_required, stale_approval_review, stale_policy, proposer_revoked, proposal_declined).
• qa-separate-from-dev. The setting in knowledge/wiki/SETTINGS.md makes the board refuse a QA approval, a bug verification or a bug reverification from the grant that produced, recovered or repaired the evidence it verifies. The journal binds each Delivery evidence row and each bug Fix row to the operation that produced it (separation_required, separation_unverifiable, evidence_generation_conflict). It separates grants, not people. A value other than true or false is invalid_policy and invalid-workflow-policy.
• Repair and board state commands. operation-repair adopts the effects of an abandoned operation and finishes its remaining writes under the original action's predicate (repair_invalid). prism board audit export --out FILE writes the grants (without token hashes), previews, operations, events and evidence provenance to a new file, and prism board state reset writes the same export and removes .prism/state/; it is refused while an operation is unresolved (unresolved_operations).
• MCP tool contract 4. 16 tools. list_proposals and decline_proposal serve the proposal list; discover reports the role model, the action registry with each action's required_roles, modes and availability, the workspace policy, the participant's roles and whether the request came through a board session, and the pending proposals; list_skills and get_skill report required_roles and write_tools for every skill.
• Ten statuses, seven owners and per-app progress. The statuses are raw, specified, ready-for-design, in-design, ready-for-dev, in-dev, ready-for-qa, in-qa, ready-for-release and released; the owners are po, designer, tech-lead, dev, qa, release and none. From in-dev on, a feature's status is the minimum over the stages of its active apps, derived from each app's rows in ## Delivery evidence, ## QA verification and ## Release. Acceptance criteria carry stable IDs and the apps that verify them (AC-1 [backend], AC-3 [integration: backend, web]), a revision that QA rows cite, and a criteria-high-water mark so an ID is never reused. Evidence rows record whether they were checked or attested. Wiki lint compares status, owner and rows (feature-status-not-minimum, app-row-missing, app-row-ahead-of-status, app-row-out-of-order, stale-qa-evidence, stale-delivery-evidence).
• Design in two tracks under one owner. The design owner is designer when an active app has a UI (has-ui true or unknown) and tech-lead otherwise. design-tracks (ui, technical) records pending, done or not-applicable with a reason. The skills design-ui-done and tech-design-done settle a track; design-handoff needs both settled and design-reaffirm empty. The technical design page kind (knowledge/wiki/technical-design/F-XXX-slug.md) holds architecture impact per app, data model, security, non-functional needs, risks, decisions and a Test strategy that names every acceptance criterion. The API contract api-contracts/F-XXX.md is created at agreed with the human's confirmation as the agreement, carries a version and a digest, and delivery evidence cites it (contract_binding_stale). A change to a settled track's pages sets the track back to pending; the pages are locked from ready-for-dev on.
• The QA stage and bugs. qa-verify records QA rows per app or per integration against the delivered artifact, the criterion revision, the attempt (qa-<n>) and the environment; its first result opens in-qa. qa-pass passes the apps it names and may carry the QA rows still missing, so a clean run is one approval. qa-fail sends apps back to development and archives their delivery, QA and Release rows in ## Evidence history. qa-return-spec and qa-return-design send the whole feature back. A bug is a current-state page in knowledge/wiki/bugs/, created by a QA action or by ingest, with the lifecycle open, in-fix, fixed, verified, released or closed (wont-fix, duplicate, promoted); bug-update performs triage, scope, start, fixed, verified, reverify, reject, close, defer and reopen under per-action roles. An unresolved bug of an app blocks its pass and its release.
• Returns and reopening. dev-return-spec and dev-return-design send a feature in development back; qa-fail, qa-return-* and release-return-dev send it back from QA and release; reopen-spec, reopen-design and reopen-dev reopen a released feature, reopen-dev only for the apps that change. Each appends one ## Evidence history entry that copies the removed rows verbatim, lowers the requirement pages and the contract it names, and sets the revalidation and app-revalidation domains that need fresh evidence. A feature with a released app cannot go back to specification or design (partial_release_requires_new_feature).
• The release stage and release records. release-done settles the Release rows of the apps it releases (released or failed), ships the verified bugs of those apps and writes one dated record, knowledge/wiki/releases/REL-XXX.md, numbered by the board under its lock. The record lists a Delivery row per feature or bug and app with the target, the version, the attempt and the outcome, and snapshots each cited API contract with its digest. Each app has a delivery target in delivery-targets of SETTINGS.md (deployment, store, artifact or other, with a default for each stack except other). release-return-dev returns a failed delivery to development; release-rollback and release-redeploy add records that bind to the current delivery of an app and target. A dependency on a feature or app is satisfied at released (dependency_not_released, dependency-cycle).
• Operations: incidents, runbooks and the status board. An incident is a dated record in knowledge/wiki/incidents/INC-XXX-slug.md with impact, timeline, cause, mitigation, resolution and follow-up links, written through ingest (there is no incident engine and no incident action). Every generated app ships docs/runbook.md with what its stack makes known and **Unknown:** items for hosting; an app in an external repository may record the https link of its runbook in the manifest field runbook. The status board has three tables: the features (with Design tracks, App stages and Open bugs), the open bugs, and one Operations row per app with its released features, latest release record and outcome, open bugs and open incidents.
• Seven skills. design-ui-done, tech-design-done, qa-verify, qa-pass, qa-fail, release-done and bug-update join the 27 existing skills: 34 canonical skills, 23 with connected writes. feature-reopen, ingest (technical design pages, bugs, incidents), feature-status, prep-sprint, wiki-app, wiki-owner, wiki-blockers, ask and audit-feature cover the new statuses, owners and page kinds.
• The read layer covers the lifecycle. prism wiki owner takes po, designer, tech-lead, dev, qa, release and none and lists the bugs an owner holds; prism wiki search reaches bug pages, incident records and technical design pages through their index lines; prism status reports the app stages of the features in development or later; blockers add feature-status-not-minimum, app-row-missing, stale-qa-evidence, stale-delivery-evidence and open-bug-blocks-qa; the graph and the JSON schemas use the ten statuses; the index lists bugs, technical designs, release records and incidents in their own groups.
• Page kinds and lint. technical-design/, bugs/, releases/ and incidents/ each have a _FORMAT.md. Lint reports the findings of the new kinds (bug-page-invalid, invalid-bug-status-owner, bug-close-reason-required, duplicate-target-invalid, promoted-bug-unreopened, bug-feature-missing, release-record-invalid, release-row-record-mismatch, incident-record-invalid, incident-follow-up-missing, missing-technical-design, technical-design-feature-mismatch, test-strategy-incomplete, design-tracks-missing, design-tracks-invalid, design-track-pending, design-coverage-incomplete, ui-exemption-reason-required, technical-track-required, invalid-delivery-target, invalid-app-runbook, dependency-cycle).
• Docs. The docs describe the roles, the lifecycle, the approval flow, the page kinds, the standard files, every lifecycle error code by stage and the maturity of each lifecycle feature.

Changed

• Release reads and writes use one chronological record validator. Rollback and redeploy bind to the current delivery, retries include a failed delivery of the same item and app and may also ship new items, and malformed reference chains produce diagnostics without recursive traversal. A preview accepts its record only after validating the complete candidate sequence. A verified bug may ship its apps independently, retaining earlier rows and becoming released only when every app succeeds.
• released ends a feature's lifecycle; dev-done ends at ready-for-qa. dev-done records per-app delivery evidence (artifact, contract citation, implementation, tests and basis) and moves a feature to the minimum of its app stages. Shipping is a release record, not the end of development. A Delivery evidence row has the columns App | Artifact | Contract | Implementation | Tests | Basis.
• Every action that advances a status, a design track or an app stage is gated. An ungated write (intake, clarification, ingest, verify-pages, board-review) is applied by any writable grant after the human confirms the preview in the agent host. The direct human actions are po-handoff, design-start and dev-start, plus operation-repair.
• The instruction files are split by topic so each stays on one page. The action registry, the common action protocol and the write scopes are in knowledge/wiki/ACTIONS.md, read by the skills that run a lifecycle action; the format and rules of each page kind are in the _FORMAT.md of its folder; SCHEMA.md lists the kinds. ACTIONS.md is a required wiki file (missing-required-wiki-file, missing-schema-version).
• feature-reopen selects its action from the state of the feature. specified and in-design are returns from implementation, returns from QA or reopens of a released feature; in-dev is valid only from released.
• feature-scope is an ordinary write before ready-for-dev and the action scope-edit from ready-for-dev on, which only removes apps, derives the criteria from the removal and archives the removed app's rows.
• Generated skill layers, the packaged workflow asset and the golden workspace carry the lifecycle. The workflow asset has a new digest, so grants are reissued after prism workflow upgrade.

Removed

• The done feature status and its owner. released and the owner none replace them for features; requirements, advisory reviews and plans keep their own done.
• ## Post-ship notes, ## Reopen history and the Release column of Delivery evidence. ## Evidence history records what a return or reopen archives, the Basis column records whether evidence was checked or attested, and a Release row records the delivery.
• The design: not-applicable and design-exemption-reason front matter fields. The design tracks and their reasons replace them (unsupported-feature-field).
• Delivery attestation by attested by <Name>: and the codes release_evidence_required, delivery_evidence_not_archived and reopen_artifact_missing. The Basis cell and the Evidence history checks replace them.
• MCP tool contract 3, and any board state without role support. A state database created before roles is refused with unsupported_board_state; run prism board state reset and issue the grants again. Workspaces and wiki pages written for an earlier status model are recreated.

Security

• Roles and approval are enforced by the board, not by the skills. A gated action is applied only by a writable human grant that satisfies its role predicate, in a browser board session with a review revision and an acknowledgement. The predicate is checked again on a pending retry, on recovery and on repair, with the current policy; an agent cannot apply, recover, decline or repair a gated operation.
• The limits are documented. A grant identifies a registered token holder; a role records what whoever ran prism board grant assigned; session-only approval keeps the approval out of tool calls and does not protect a leaked human token; local filesystem access can mint a grant; qa-separate-from-dev separates grants. SECURITY.md states each.
• Board state is exported and reset in one safe path. prism board audit export never overwrites a file and omits token hashes; prism board state reset exports first and refuses while an operation is unresolved, because deleting .prism/state/ loses recovery and separation provenance.
• One section parser. The write-scope checks and the evidence readers find a ## heading the same way: a line that starts with ## in column zero, outside fenced code. An indented or repeated ## Delivery evidence, ## QA verification, ## Release or ## Evidence history heading is refused at preview (ambiguous_lifecycle_section) and reported by wiki lint (ambiguous-lifecycle-section), and a question skill (ask, the clarify skills) cannot change those sections (lifecycle_evidence_changed). A proposal can no longer hide evidence from the scope check that a reader would take as authoritative.
• Separation holds through repairs. With qa-separate-from-dev, the grants excluded from verifying evidence include the approver and every recoverer of each operation-repair linked to the producing operation, a repair of a repair included.
• A repair binds the files it adopts. The repair preview records the current digest of every file the abandoned operation already wrote. An edit of one after the review stops the approval (stale_approval_review, stale_preview), and a recovery of the repair stops with recovery_source_changed. Recovery rechecks the lint of the pages the repair leaves behind.
• Release records are validated before they carry authority. A page in releases/ counts for the current delivery, the next number, a retry or a rollback only when it is a valid record: file name and ID agree, no duplicate ID, required front matter, parseable rows, and a valid retry-of or rollback-of chain. An invalid page blocks release-done (release_record_invalid, naming the file) until it is fixed, and wiki lint names it.
• The approval view shows what is approved. The Proposals dialog renders the before and after text of every write, the folder moves and the review obligations, escaped, before the acknowledgement can be given, and reports success only for an applied receipt. A conflict keeps the operation ID, the completed writes and the recovery controls in view.
• Evidence history is dated by the preview. The heading of an archiving write is checked against the day the operation was previewed, stored with it, on apply, recovery and repair. A recovery on a later day no longer fails on the date.