Collaborative change requests, review, and conflict resolution

A request is a separate proposed change set

A request holds a numbered, hashed diff. Nothing is written to the live roster until the request is merged. The screen deliberately separates the request’s branch—the isolated copy of proposed edits—from the live record.

Do not confuse a change request with an account join request. Join requests link accounts; change requests propose operational data mutations.

One open request per Cadet

If another edit targets a Cadet who already has an open request, the edit joins that request as a contribution. A transaction prevents simultaneous edits from creating competing open requests.

The folded change set keeps the first previous value for conflict detection while the contribution timeline preserves who proposed each value.

Queue views

Cadet-record requests use calculated authority

Whoever could save the surviving changes directly may apply the request. One qualified approval completes the operation; there is no fixed instructor-only final step.

Contributors may merge when they independently satisfy the live requirement. Helping write a request does not grant the authority to apply it.

Structure, positions, and awards climb a review ladder

Unit-level targets have no target Cadet to measure. They move through occupied review tiers above the author and end at an instructor merge.

The ladder is derived from occupied positions with review authority, so an empty rank tier cannot strand the request.

Field-level decisions

A reviewer may deny or restore individual fields without closing the entire request. Denied fields do not survive into the merge and do not continue to raise the authority requirement.

A materially new proposed value clears the old denial because it is a new decision. Re-proposing the same denied value leaves the decision in place.

Two kinds of conflict

A pending conflict occurs when a contribution proposes a different value for a field already in the open request. The editor shows both proposals and requires a choice.

A merge conflict occurs when live data changed after the request’s base snapshot. The resolver offers the live and proposed values; nothing applies until the conflict is explicitly resolved.

Merge and close outcomes

Merged means the surviving diff was applied to live data and logged. Closed means nothing further will apply; the resolution records whether it was rejected, withdrawn, superseded, or closed for conflict.

Live permission validation runs again at the moment of action. Losing a position while the detail screen is open removes authority rather than trusting a stale page.