The complete sequence matters
On 16 July, v5’s contact, about and editorial-standards work was released. The same day, the public deployment was restored to the earlier v4 state at the owner’s request so further refinements could be made. Both parts of that sequence appear in the session records and Git history.
Describing only the release would leave an incorrect impression of the public site. Describing only the rollback would conceal the completed work that remained available locally.
Revert the release, retain the candidate
The rollback used reversible Git commits. The recorded check compared the restored deployment with the prior v4 revision. Meanwhile, the v5 source remained in its versioned folder as a held candidate.
That separation is valuable. Reversing a public change does not require deleting the design or pretending the release never happened. It requires an identifiable previous state, a controlled restoration and an accurate record of what is now live.
Verification is specific to a state
The earlier release checks established that particular pages were reachable with their intended content at the time of verification. They did not make the design permanently approved. A later owner decision changed the desired public state, and the records needed to reflect that change.
The lesson is to keep technical checks, editorial acceptance and production state separate. A candidate can be functional, remain worth developing and still be the wrong thing to leave live. Reliable release history makes that a manageable decision rather than an unexplained disappearance.
Evidence for this entry
This account is grounded in project records. Internal research and operational files are not published here.
What the records support
- Same-day release and user-requested rollback; v5 authoring retained; v4 comparison verified.
- Release and reversible rollback on 16 July 2026.