McGuckin.Net Domain Access Decisions¶

v0.1 | Draft | 2026-10-02

Purpose¶

This decision record defines the primary McGuckin.Net website surfaces and their access boundaries.

McGuckin.Net contains sensitive information about the home LAN, Docker services, operational dashboards, and supporting documentation. The public website must therefore remain separate from authenticated operational and documentation surfaces.

Decisions¶

Canonical Model¶

mcguckin.net redirects to www.mcguckin.net.

www.mcguckin.net is the public front door.

ops.mcguckin.net is the operational dashboard surface.

docs.mcguckin.net is the documentation surface.

Public Front Door Build Order¶

The public front door shall be designed last, after the operational portal and documentation surfaces are established and the application model is better understood.

During scaffolding, www.mcguckin.net may remain a minimal public shell. Its header may provide links to:

• ops.mcguckin.net,
• docs.mcguckin.net,
• Todd's personal public site.

Those links are allowed as navigational affordances. They do not authorize public exposure of operational details.

Access Standard¶

ops.mcguckin.net and docs.mcguckin.net shall be protected by the same general access model unless a later decision record explicitly separates them.

The intended protection model is equivalent to the existing protected documentation access boundary for docs.mcguckin.net.

Public Content Boundary¶

The public site may describe McGuckin.Net at a high level, including Apple hardware, UniFi networking, Plex, Docker, backups, automation, and design principles.

The public site shall not publish:

• private IP addresses,
• internal administration URLs,
• sensitive DNS names beyond approved public hostnames,
• credentials, tokens, or recovery material,
• firewall or VPN implementation details,
• live operational status,
• internal topology diagrams that materially increase attack surface.

Operational Portal Boundary¶

ops.mcguckin.net may contain:

• service launch links,
• dashboard links,
• service groupings,
• operational health summaries,
• links to Homepage, Uptime Kuma, Grafana, Dozzle, Portainer, and other approved operational tools,
• app status and deployment-state summaries,
• links to relevant runbooks in docs.mcguckin.net.

ops.mcguckin.net shall not become the authoritative source for standards, runbooks, or implementation records. Those belong in docs.mcguckin.net.

Documentation Boundary¶

docs.mcguckin.net remains the system of record for:

• standards,
• implementation guides,
• runbooks,
• inventories,
• audits,
• decision records,
• recovery documentation,
• controlled design notes.

Documentation may link to operational tools, but operational tools do not replace documented procedures or approved source files.

Rationale¶

This model gives each surface a single job:

• www explains McGuckin.Net without exposing the LAN.
• ops helps operate the home network.
• docs explains how the home network is designed, maintained, and recovered.

The split keeps public presentation, daily operations, and governed documentation from blurring into one surface.

Deferring the full public front-door design prevents the public site from driving premature architecture decisions. The private operations and documentation surfaces should define what the public front door eventually summarizes.

Implementation Notes¶

Before publication, confirm the following:

• mcguckin.net redirects to www.mcguckin.net.
• www.mcguckin.net does not expose private operational details.
• ops.mcguckin.net is protected before operational links or dashboards are published there.
• docs.mcguckin.net remains protected.
• Any cross-links between www, ops, and docs respect the access boundary.

Cloudflare Scaffolding Plan¶

The initial Cloudflare scaffold shall create or retain these deployable surfaces:

The operations portal scaffold may be deployed only with placeholder content until the Cloudflare Access boundary is verified.

The public front door header may link to ops.mcguckin.net and docs.mcguckin.net; those links are acceptable because the destinations remain protected.

Publishing Method¶

Cloudflare shall be the only production publisher for the McGuckin.Net website surfaces.

Cloudflare shall pull from GitHub after approved changes are pushed. Local work prepares, audits, and verifies the project folder. GitHub Actions shall not deploy to Cloudflare.

Direct local Wrangler deployment is not the routine publishing method for www.mcguckin.net, ops.mcguckin.net, or docs.mcguckin.net.

GitHub Actions may run validation only. It shall not publish a competing production copy of the same site to GitHub Pages or Cloudflare.

The required flow is:

1. Work locally in the project folder.
2. Audit and verify locally.
3. Correct and re-verify any issues.
4. Push the verified state to GitHub.
5. Cloudflare pulls from GitHub and publishes.
6. Verify the live Cloudflare route independently.

Execution Rule¶

Work on the McGuckin.Net website surfaces shall follow this order:

1. Document first.
2. Code second.
3. Verify third.

If verification finds issues, correct and verify the issues before updating the documentation to claim completion.

Documentation records the intended change before implementation. Code implements the documented change. Verification confirms the implemented behavior. Completion is not recorded until verification succeeds.

Status¶

Draft decision recorded from owner direction on 2026-10-02.

Cloudflare publishing scaffold updated on 2026-10-02:

• Cloudflare Workers and Pages GitHub App is approved for all repositories under rtm135.
• mcguckin-net-site, mcguckin-net-docs, and mcguckin-net-ops are connected to the rtm135/mcguckin-net repository.
• Each Cloudflare Pages project uses a folder-specific include filter so only changes to its surface trigger that surface's deployment.