Two audiences, two surfaces
The private workspace was added and expanded into a multi-page intranet on 25 June. It brought together a dashboard, review routes, a document centre and operational guidance. The purpose was to help an authorised reviewer move through evidence without turning internal material into public website content.
The public site and private workspace shared a deployment context, so separation had to be enforced in the request path, not merely suggested by navigation labels.
Protection belongs at the edge
The implementation included Cloudflare Pages middleware for the intranet route and private-response headers. Authentication configuration remained a deployment requirement in the session notes. A static local server did not execute that middleware, so a successful local page load could not prove that the production login worked.
The distinction between local preview and production protection was explicitly recorded. Testing an interface and testing access control answer different questions; neither result should be used as a substitute for the other.
The workspace is not a public archive
Full manuscript texts were deliberately kept out of the web deployment. The existence of a private review interface did not automatically authorise putting all research files behind it.
This boundary also matters during redesigns. Replacing a public homepage must preserve the private routes, access controls and necessary supporting files. The intranet is part of the operational system, not disposable material that a website cleanup can remove without review.
Evidence for this entry
This account is grounded in project records. Internal research and operational files are not published here.
What the records support
- Private multipage workspace, middleware and headers; configuration/production verification still needed in contemporaneous note.
- Git revision records the added private workspace on 25 June; not used alone as proof of public authentication.