Annotation · not proposed UISpec ii 4.2 · the take is atomic with activation. The activation-time snapshot executes inside spec i's activation critical section: the snapshot write and the activation commit succeed or fail together. There is no active cycle without a snapshot and no snapshot without its cycle. Version 1 above therefore carries the same timestamp story as the cycle's activation, and it is not a separate user action.

Annotation · not proposed UISpec ii 4.2 · refresh appends, never overwrites. An explicit refresh while the cycle is active appends a NEW version with a monotonic version number per cycle (stakeholdergroupsnapshots: companyId, cycleId, snapshotVersion, takenAt/By, frozen copies of the groups, frozen). Earlier versions, and any confirmation that referenced them, are untouched. Nothing in this surface can edit or delete a version, which is why the version cards carry no Edit or Remove affordance.

Annotation · not proposed UISpec ii 4.2 · renames and deactivations cannot reach backwards. A snapshot stores frozen copies of the groups, not references to the live registry rows, so a rename, a category change, or a deactivation in panel 1 leaves every existing version byte-identical (acceptance case 9.5). Panel 1 shows the current name, panel 2 shows the recorded name, and the two are deliberately allowed to differ. Version 1 above reads "Contract farmers" and the registry reads "Contract growers" for exactly that reason.

Annotation · not proposed UISpec ii 4.2 and 6.6 · what freezing does, and what is drawn where. Freezing happens at lock completion, and lock state complete needs spec iii's factor-library vintage, so in I1 the latest version of a live cycle always stays refreshable. That is why the MAIN screen above draws the enabled control: it is the state this build will actually ship. The frozen state and its refusal are drawn in the gallery below as a forward state, because a reviewer has to understand freezing before signing anything off. The refusal constant is CYCLE_IMMUTABLE, 409, spec i's existing code reused unchanged and listed as such in the spec ii 6.6 error contract, so it is quoted rather than proposed.

Annotation · not proposed UISpec ii 4.2 · freezing is one way, and the spec now says so. No lock transition ever unfreezes a snapshot version. If a completed lock is ever reversed and later re-completed, the re-completion freezes the THEN-latest version, and every version that was already frozen stays frozen. That is why no screen in this wireframe set carries an unfreeze path: there is nothing to draw. A related rule from the same section, drawn nowhere because it has no control: when a cycle's lock is already complete at activation, the activation-time snapshot is born frozen, so there is no window in which a lock-complete cycle holds a refreshable snapshot.

Annotation · question for the PMOne open item, not invented into an answer here. The registry carries a category enum and an engagement mode (gate (c) bone 2B), but neither the spec nor the plan enumerates the permitted values. The values shown in panel 1 are invented placeholders in the shape of a closed server-side list, not a proposal about the category list itself.

Annotation · not proposed UIContract notes. Both endpoints are admin role: /v1/stakeholder-groups (list, create, deactivate) and /v1/reporting-cycles/:id/stakeholder-snapshots (list, refresh). Lookups are tenant-scoped {_id, companyId} with cross-tenant 404, which is what closes the snapshot IDOR surface the review named. The registry is never written by the boot-time seeder, and the qualitative stakeholder narrative in the report is never auto-generated from the stakeholder group registry.