fix(risks): cs-727 deploy-review fixes (acceptance race, approval drift baseline, error surfacing)

[github-actions]

Follow-up to #3493 (CS-727): fixes the cubic findings raised on the main→release deploy PR #3496. 13 of 16 findings fixed here; 3 rebutted on their threads (cascade-delete of acceptance history — settled on #3493, published RTP snapshots + AuditLog preserve the trail; the submit-gate TOCTOU — would require serializing every Risk/Vendor write against ISMS submits for an advisory gate; openapi.json regeneration — four-PR precedent, spec pipeline reads main).

Correctness

• Acceptance race: createForRisk/createForVendor now run in a transaction that takes a FOR UPDATE row-lock on the subject, so a concurrent residual PATCH serializes with the read→freeze→insert sequence — a fresh acceptance can no longer be recorded against an already-superseded rating (and can never be born stale).
• Approval drift baseline: approve() used to collect the platform snapshot before its transaction while the published rows were loaded inside it — a concurrent edit in that window made a just-approved document immediately show "may be out of date". collectPlatformData gained an optional transaction client and the approval flow collects the baseline under the document lock, in the same transaction as the frozen rows.

UX / client

• useAcceptances surfaces ApiResponse.error (the useApiSWR fetcher never throws on API failures, so swr.error alone missed forbidden/failed responses); the acceptance card now renders an explicit "Couldn't load the acceptance history" + Retry state instead of misreporting a failed load as "No acceptance recorded yet".
• The acceptance dialog only preselects the owner when they are actually in the selectable member list (a deactivated owner previously submitted and failed server-side).
• The RTP page keeps "Submit for approval" blocked while readiness data is loading or failed, instead of letting the dialog complete into the server-side completeness error.

Documents / docs

• The methodology's matrix intro misstated the bands (it attributed the raw-product ranges to the normalized score). It now states both: score bands (Very low 1-2 … Very high 9-10) and their raw-product equivalents (1-5 … 21-25). Same correction in the in-app matrix preview caption.
• Acceptance response schemas document authType/authenticatedUser (which the controllers actually return) and a 500 response, matching the sibling risk schemas.
• Comment fixes: the PDF column-sizing note says 10 columns; the defaults header attributes the treatment-option names to ISO 27001 (not 27002).

Structure

• The RTP readiness queries moved out of the oversized isms.service.ts into documents/risk-treatment-readiness.ts; the service keeps only the thin submit-gate and page-payload wrappers.

Verification

• 664 API tests + 214 app tests green (new regression test asserts the create path row-locks and writes through one transaction; the approve spec asserts the baseline is collected in-tx).
• Both typechecks clean apart from the documented pre-existing sets; bun run --filter '@trycompai/app' build green.

[linear]

CS-727

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
app	Ready	Preview, Comment	Jul 24, 2026 4:21am
comp-framework-editor	Ready	Preview, Comment	Jul 24, 2026 4:21am

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
portal	Skipped		Jul 24, 2026 4:21am

[cubic-dev-ai]

cubic analysis

2 issues found across 15 files

Confidence score: 3/5

• In apps/api/src/isms/documents/data-source.ts, the RTP stale-check runs in a transaction that can see different snapshots under READ COMMITTED, so a just-approved Risk Treatment Plan may be marked stale immediately and trigger incorrect workflow/state transitions — use a single consistent-read strategy (e.g., stronger isolation or locking/statement structure that guarantees one snapshot for the check).
• In apps/api/src/risks/schemas/risk-acceptances.responses.ts, the new 500 schema entries are not connected to the controller decorators, so Swagger omits internal-server-error responses and clients won’t see accurate failure contracts — wire [500] into both risk-acceptance decorators to expose the intended API docs.

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="apps/api/src/isms/documents/data-source.ts">

<violation number="1" location="apps/api/src/isms/documents/data-source.ts:32">
P2: A just-approved Risk Treatment Plan can be marked stale immediately: this transaction client does not guarantee one consistent read snapshot under the repository's default READ COMMITTED isolation, and the RTP rows are read again later in the same transaction. Configuring a repeatable-read/serializable transaction for approval, or otherwise locking the rendered risk/vendor rows, would keep `riskTreatmentFingerprint` aligned with the frozen RTP.</violation>
</file>

<file name="apps/api/src/risks/schemas/risk-acceptances.responses.ts">

<violation number="1" location="apps/api/src/risks/schemas/risk-acceptances.responses.ts:173">
P3: The new 500 response definitions are unreachable from the controller decorators, so Swagger still omits the documented internal-server-error response. Wiring `[500]` into both risk acceptance decorators (and the vendor equivalents) would make this addition effective.</violation>
</file>

Linked issue analysis

Linked issue: CS-727: [Feature] - Risks module updates

Status	Acceptance criteria	Notes
✅	Row-lock acceptance creation so a fresh acceptance cannot be recorded against an already-superseded residual rating	createForRisk/createForVendor run inside db.$transaction and take a FOR UPDATE row lock before reading and inserting; tests assert the transaction and the FOR UPDATE query.
✅	Collect the approval drift baseline inside the approval transaction so a just-approved document cannot immediately show as stale	collectPlatformData accepts an optional transaction client and approve() now calls it inside the document-lock transaction; unit spec asserts client threading.
✅	Surface acceptance-history loading errors in the UI (don’t show a failed load as 'Awaiting acceptance') and offer a Retry	useAcceptances now converts ApiResponse.error into an error for callers; ResidualAcceptanceCard renders an explicit error + Retry instead of treating failure as empty history.
✅	Acceptance dialog only preselects the owner when they are actually selectable/active	RecordAcceptanceDialog computes a valid default and uses it; prevents silently submitting a deactivated owner.
✅	Keep 'Submit for approval' blocked while RTP readiness data is loading or failed (so the dialog cannot be completed into a server-side completeness error)	RiskTreatmentPlanClient sets a blockedReason when readiness is loading or errored, rather than allowing the submit dialog to proceed.
✅	Correct the Risk Assessment Methodology matrix text and preview so score bands and raw-product equivalents are stated consistently	Methodology narrative updated to state normalized score calculation and band mappings; preview text updated to match.
✅	Extract RTP readiness queries into a focused loader and use it where readiness is checked (refactor to support tx-client usage)	Readiness logic moved to documents/risk-treatment-readiness.ts and isms.service now uses the loader (including tx client) for completeness checks and approval gating.

<sub>Tip: instead of fixing issues one by one fix them all with cubic

Re-trigger cubic</sub>

[cubic-dev-ai]

All reported issues were addressed across 7 files (changes from recent commits).

<sub>Reply with feedback, questions, or to request a fix.

Fix all with cubic | Re-trigger cubic</sub>

[claudfuen]

🎉 This PR is included in version 3.108.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀