# Canonical profile binding during submitted CV capture

Follow-up to PACKAGE_REVISION_CAPTURE.md. The CV variant guard alone did not bind the canonical profile metadata to the profile used by rendering. A deterministic test used the real CareerProfileService save and CvVariantService render to change the profile during capture; the resulting HTML contained the new name while capture could still publish the previously selected projection.

Capture now rechecks the owner's canonical profile revision/projection after rendering and rejects a changed, created or removed row through the existing revision_conflict path. A genuinely absent legacy profile remains capturable. Canonical save/render ownership, null-as-inherit selections, renderer code/styles and historical packages are unchanged. No new profile store, schema, API field or migration.

RED:one focused test failed with no conflict. GREEN:26 targeted cases passed/no skips across package/controller/export-revision/native SQLite suites;22 overlap the preceding run. Four added cases cover real profile save during render, creation, removal and unchanged absence. Logs and raw/gzip TRX/source receipts are in evidence/package-profile. Build/temp/results used E; no live DB/models/providers, physical PDF or production services were used.

This guards the canonical row/projection used by ordinary writers. It is not proof of a transactionally atomic snapshot across every source, arbitrary direct database mutations, legacy user-only fallback writes, or filesystem races. AttachmentStorage destination ownership remains a separate source-backed/unreproduced concern. Native/MariaDB/browser, full integrated security/recovery and final milestone gates remain open.

Rollback reverts only this follow-up source change and reruns affected package tests; no data repair required. Existing accepted PDF metrics remain historical and source-bound, not newly executed.