| REQ-LC-001 |
Every document version shall be in exactly one of the states DRAFT, IN_REVIEW, RELEASED, REVOKED, CANCELLED; no other states shall exist. |
STR-001; ADR-0003, ADR-0024 |
| REQ-LC-002 |
State transitions shall be limited to: submit (DRAFT→IN_REVIEW), reject (IN_REVIEW→DRAFT), withdraw (IN_REVIEW→DRAFT, by the author side — REQ-LC-020), release (IN_REVIEW→RELEASED, only when the review policy is satisfied), revoke (RELEASED→REVOKED), new version (RELEASED→new DRAFT version), cancel (DRAFT→CANCELLED, IN_REVIEW→CANCELLED). (withdraw added by ADR-0066) |
STR-001; ADR-0003, ADR-0024, ADR-0066 |
| REQ-LC-003 |
A review policy shall be configurable per scope and document type, defining approval requirements, the four-eyes flag, transition permissions, and the release mode. (a release-flow axis STANDARD/DIRECT is added by REQ-LC-027 — orthogonal to the AUTOMATIC/EXPLICIT release mode of REQ-LC-007; ADR-0091.) |
STR-002; ADR-0003, ADR-0091 |
| REQ-LC-004 |
Approval requirements shall be expressible as a set of (role, minimum count) pairs that must all be satisfied before release. |
STR-002; ADR-0003, ADR-0004 |
| REQ-LC-005 |
~~The four-eyes rule shall be enforced by default: the author of a version shall not count as one of its approvers; relaxing it shall require an explicit, audit-visible configuration.~~ Superseded by REQ-LC-016 (ADR-0047): creator-based exclusion replaced by attester-based. |
STR-002; ADR-0003, ADR-0047 |
| REQ-LC-006 |
Each transition shall be executable only by users holding a role permitted for that transition in the applicable review policy. |
STR-002, STR-003; ADR-0003 |
| REQ-LC-007 |
The release mode shall be configurable as automatic (on last required approval) or explicit (separate release step by an authorized role). |
STR-002; ADR-0003 |
| REQ-LC-008 |
Every approval shall be recorded with user, the role in which they approved, and timestamp, permanently attached to the approved version. |
STR-009; ADR-0003 |
| REQ-LC-009 |
Review comments shall be attachable to the version under review and shall be preserved with it. (realized and extended by REQ-LC-022..026; ADR-0067) |
STR-001; ADR-0003, ADR-0067 |
| REQ-LC-010 |
A released version shall remain unchanged and effective until a newer version of the same document is released or it is revoked. (effectivity refined by REQ-EFF-002) |
STR-001, STR-009; ADR-0003 |
| REQ-LC-011 |
All life-cycle rules shall be enforced server-side; clients shall not be able to bypass them via any interface. |
STR-003, STR-014; ADR-0007 |
| REQ-LC-012 |
Revocation (RELEASED → REVOKED) shall be terminal for a version; a revoked version shall not return to RELEASED. To put a withdrawn document back in force, a new version is released. |
STR-001; ADR-0003 |
| REQ-LC-013 |
Revoking a document that is a derivation source shall notify scopes holding derivations of it, and shall not change those derivations. |
STR-005; ADR-0002 |
| REQ-LC-014 |
Revocation shall be gated by transition permission and may, per the review policy, require approval and/or an electronic signature (meaning REVOKED); it shall always be audited. |
STR-002, STR-009; ADR-0003, ADR-0014 |
| REQ-LC-015 |
Cancellation shall be terminal and gated by transition permission; a cancelled version shall never be effective and shall not be reopened (a new version/draft is started instead); cancelled versions are retained, not deleted, and the cancellation is audited. |
STR-001; ADR-0024, REQ-AUD-001 |
| REQ-LC-016 |
The four-eyes rule shall be enforced by default: the user who submitted the current review round — thereby freezing and attesting its content — shall not count as one of its approvers, so at least two distinct persons demonstrably act on every release (their identities recoverable from the audit trail); relaxing it shall require an explicit, audit-visible configuration. (Supersedes REQ-LC-005 per ADR-0047; accepted residual: a version's creator may approve content another person submitted.) |
STR-002, STR-009; ADR-0003, ADR-0047 |
| REQ-LC-017 |
Each document shall carry three workflow role-group bindings — AUTHOR, REVIEWER (each entry with a minimum-approver count ≥ 1), and RELEASER — copied from the applicable (scope, type) review policy's submit/approve/release role sets (with matching min-counts) at draft creation; from then on the document's own bindings shall be authoritative for that document's workflow, while the type policy remains the template for future documents and keeps governing the non-workflow transitions (REVOKE, CANCEL, PERIODIC_REVIEW). |
STR-002, STR-003; ADR-0064, REQ-LC-004 |
| REQ-LC-018 |
Workflow-role bindings shall be editable while the version is DRAFT by holders of the document edit permission — every change audited (before/after shape) — and frozen at SUBMIT together with the content and policy snapshot; changing reviewers during a review round shall be possible only by rejecting or withdrawing and resubmitting. |
STR-002, STR-009; ADR-0064, ADR-0030 |
| REQ-LC-019 |
SUBMIT shall require all three workflow groups to be non-empty (otherwise rejected with a clear message) and shall block any transition whose required group's roles have zero ACTIVE holders effective in the document's scope, with no fallback to bare scope permissions (a fallback would be the non-enforcement being replaced): AUTHOR roles gate SUBMIT, REVIEWER roles gate APPROVE (honouring the per-entry minimum counts), RELEASER roles gate RELEASE. Four-eyes (REQ-LC-016) applies on top unchanged, and the review inbox shall route approval tasks by the document's REVIEWER bindings. |
STR-002, STR-003; ADR-0064, ADR-0054, REQ-LC-016 |
| REQ-LC-020 |
The author side shall be able to WITHDRAW a version from review (IN_REVIEW→DRAFT): permitted for any holder of the document's AUTHOR group (not only the original submitter) at any point while IN_REVIEW, including after partial approvals. A withdraw shall close the review round, VOID already-given approvals, cancel open approval-required tasks, return the frozen content to the draft working area, and unlock the workflow-role bindings; it shall be audited as WITHDRAWN (actor, optional comment) and visible in version history. Resubmission shall start a fresh round with a fresh content + workflow-role pin, four-eyes evaluated against the new round's submitter. |
STR-001, STR-002; ADR-0066, ADR-0064 |
| REQ-LC-021 |
Content mutation shall be confined to the AUTHOR-side roles while the version is DRAFT; reviewers shall act only through comments and verdicts (reject/approve), never by directly editing the version under review — so the approved artefact is exactly the submitted artefact (freeze integrity), four-eyes cannot be collapsed by self-fixing, and authorship attribution stays unambiguous (ISO 13485 §4.2.3). |
STR-002; ADR-0066, ADR-0067 |
| REQ-LC-022 |
A review comment shall belong to a document version and may carry an anchor into the version's content tree — a block reference plus the quoted excerpt captured at creation and the character offset within that block; anchor resolution shall be block-scoped and exact-at-offset (never a global text search), so a repeated excerpt resolves to the commented occurrence. While DRAFT, editor markers shall follow edits and re-persist position only (quote and body stay immutable); while IN_REVIEW the frozen content keeps anchors stable; if the version later changes, a stale anchor shall degrade to a quote-only display — honest, never dangling. |
STR-001, STR-002; ADR-0067, ADR-0057 |
| REQ-LC-023 |
Holders of the document's AUTHOR, REVIEWER, or RELEASER workflow roles may comment while the version is DRAFT or IN_REVIEW; a scope member without a workflow role shall be refused (403), and commenting shall be refused (409) once the version leaves the DRAFT/IN_REVIEW window. Reading comments shall follow normal version visibility (RLS scope), so base readers of released content never see draft-round discussions. AUTHOR-group holders shall be notified when another participant comments on their IN_REVIEW version (a notification, not a task; the commenter is never self-notified). |
STR-002, STR-003, STR-023; ADR-0067, ADR-0019 |
| REQ-LC-024 |
Review comments shall be immutable records: create, one-level reply, and resolve/unresolve (resolver + timestamp recorded); no edit. Deletion shall exist only in one narrow form — the comment's own author may delete it while the version is still DRAFT and it has no replies — and shall be audited (COMMENT_DELETED: actor + comment id); anything that entered a review round or was answered stays, and the reply foreign key never cascades. Bodies are plain text (no HTML surface). Disposal shall sever comment bodies and quoted excerpts with the version's content (REQ-DPR-005); derive/copy shall not carry review discussions; a revision shall keep prior-version comments on the prior version. |
STR-002, STR-009, STR-021; ADR-0067, ADR-0025 |
| REQ-LC-025 |
A per-(scope, type) review-policy flag requireCommentsResolved (default ON, the four-eyes configurability pattern) shall block RELEASE while any unresolved root comment exists on the version, guarding every path into RELEASED — under an automatic release policy the auto-release is deferred (the version stays IN_REVIEW until a releaser releases explicitly after resolution), and resolving a comment shall never release as a side effect. An unresolved reply shall not block release (only root comments count). Resolve rights stay participant-wide (a bulldozed comment is visible, audited misconduct, not a prevented action); the blocked action shall be surfaced with its reason and the unresolved count. |
STR-002; ADR-0067, REQ-LC-016 |
| REQ-LC-026 |
Comment visibility shall be state-bound: while DRAFT/IN_REVIEW the layer is visible to every version reader except that resolved comments lose their inline markers (moving to a collapsed panel section); once the version leaves the working states (RELEASED, superseded, revoked) the layer shall be hidden by default and a reveal toggle shall appear only for the document's workflow-group holders and holders of CONFIGURE_REVIEW_POLICY effective in the scope. The hiding shall be enforced server-side — the comments query returns nothing to an unauthorized caller on post-working states, not merely a hidden UI. |
STR-002, STR-003, STR-009; ADR-0067 |
| REQ-LC-027 |
The per-(scope, type) review policy shall carry a release flow — STANDARD (submit → approve → release, as today) or DIRECT — where DIRECT permits an authorized RELEASER-role holder to release a version straight from DRAFT (DRAFT→RELEASED, a policy-permitted transition that adds no new lifecycle state). DIRECT shall be configurable ONLY for RECORD-category types (enforced server-side and in the schema; PRESCRIPTIVE and TEMPLATE types are refused), and a DIRECT policy shall name at least one RELEASE role so the single-person release stays an attributed, role-held act (never a bare permission, never a deadlock). DIRECT permits, never forbids: a document on a DIRECT-configured type may still be routed through the full submit→approve→release flow by choice. The direct path shall preserve the guardrails — an attributed, audited RELEASED event with change info; the comments-resolved gate (REQ-LC-025) and the training-questionnaire gate (REQ-TRN-007) still evaluate; the approvals gate and the ADR-0064 empty-workflow-group block (REQ-LC-019) do not apply, there being no review round; a non-releaser is refused (403); and the getVersion action reflection exposes the direct-release affordance honestly. |
STR-002, STR-009; ADR-0091, ADR-0049, ADR-0064 |