fix(cv): protect revisions and measure rendering readiness

This commit is contained in:
cesnimda
2026-10-07 07:56:35 +02:00
parent ac6d78289d
commit 046dc304aa
175 changed files with 16252 additions and 41 deletions
+6 -2
View File
@@ -49,14 +49,18 @@ Blocks P5-08b section/application/document restructuring, related CV tailoring c
## G-CV-REV — server revision safety before broad CV migration
F01/audit D01 remains open. Current `CvVariantService.SaveAsync(owner,id,name,settings,source,ct)` owner-loads and increments `Version`; it has no expected-revision parameter/comparison. Restore calls Save. The browser queue serializes one mounted editor only. B02 account identity, stale-record conflicts and creation idempotency are three separate contracts.
Successor: [P5-09 readiness](p5-09-readiness/README.md#revision-defect-boundary-and-recovery) protects CV save/restore with an expected version and atomic EF concurrency token on the existing column, with cross-client rejection and draft recovery evidence. **CV revision gate satisfied locally; related canonical-profile/job lost-update contracts remain separate.** G-CV-RENDER still blocks P5-09–14. No B07 or schema migration.
Missing proof: two independent same-account clients load vN; A saves vN+1; B's stale save/restore cannot overwrite A; deterministic conflict/reload/review handling preserves B's unsaved work; canonical-source edits and variant resets have explicit version semantics; legitimate retry/reload/history/undo succeed. Owner isolation must continue to hold. Relevant job/profile lost-update semantics must be resolved before **changing their persistence**, not silently rebuilt by a UI slice.
Original planning state: `CvVariantService.SaveAsync(owner,id,name,settings,source,ct)` owner-loaded and incremented `Version` without an expected-revision comparison. Restore called Save. The browser queue serialized one mounted editor only. B02 account identity, stale-record conflicts and creation idempotency remain three separate contracts.
Required CV proof, now supplied by the successor: two independent same-account clients load vN; A saves vN+1; B's stale save/restore cannot overwrite A; deterministic conflict/reload/review handling preserves B's unsaved work; canonical-source edits and variant resets have explicit version semantics; legitimate retry/reload/history/undo succeed. Owner isolation must continue to hold. Relevant job/profile lost-update semantics remain separate and must be resolved before **changing their persistence**, not silently rebuilt by a UI slice.
This is separate integrity work, not authorization to start B07 or implement a concurrency framework. Any schema requirement invokes existing restore/rollback readiness first. Serialize all edits to `CvBuilderEditor` with that work. Blocks P5-09–14. Shell-only route entry and the existing isolated preview keyboard protection can remain in use meanwhile.
## G-CV-RENDER — geometry, templates and real output
Successor: [P5-09 native corpus and measured results](p5-09-readiness/README.md#measured-corpus-and-results). Three bounded CSS/export/margin corrections restore the intended template/physical-page rules. **10/16 fixtures pass implemented measurements; six long-document fixtures fail materially. G-CV-RENDER remains open; P5-09 is NO-GO.** Native acquisition passing is not fidelity passing. A separate pagination repair and the remaining font/photo/wrapping qualifications are required; no renderer replacement is implicitly authorised.
The renderer is shared, but preview is not a byte-for-byte PDF rendering: `CvBuilderEditor.previewDocumentHtml` injects page padding, a pagination script and per-page transforms into server HTML. `CvCustomizeTab`, normalized settings and `ThemedCvRenderer` also influence layout. P4-03 proved keyboard access, not margin accuracy or document-theme fidelity.
Before P5-09–14, obtain a dedicated rendering checkpoint, with corrections separately authorized if needed: