Naming the authoritative destination
The 25 June deployment setup designated the project’s root live-site folder as the Git publishing area. The existing one-page v4 site was retained. Older nested copies were recorded as historical context rather than left as competing candidates for the next release.
The Git history records an initial v4 live-site commit on that date. A commit establishes a repository revision; it is not, by itself, proof of when a hosting platform served that revision to visitors.
Source and delivery have different jobs
Versioned authoring folders preserve the content of a release. The deployment repository is the surface that the hosting workflow consumes. Keeping those roles explicit makes it possible to ask a precise question: which authored version is currently represented in the publishing folder?
The private intranet complicated that relationship in a useful way. A public-site copy operation had to preserve deployment-only private files and access controls. Treating the entire destination as disposable would have been the wrong model.
A runbook reduces hidden knowledge
The deployment notes documented the chosen folder, intended Git and hosting route, and the need to protect the intranet during subsequent releases. Some setup steps still required completion, and the record did not erase those outstanding actions.
The practical gain was not a more elaborate stack. It was a single named destination and a documented path to it. That reduced the chance that a future change would update an old copy while leaving the actual publishing surface untouched.
Evidence for this entry
This account is grounded in project records. Internal research and operational files are not published here.
What the records support
- Root live-site becomes designated deploy repository; historical nested copy no longer authoritative.
- Initial repository revision dated 25 June 2026.