From dry Hugo build to first GitHub Pages push: what the agent leaves behind
Affiliate disclosure: Some links are affiliate links. As an Amazon Associate I earn from qualifying purchases. See Disclosure.
This article is part of a local-AI series on 16 GB Apple Silicon. We may earn commissions from links (GitHub Pages, Ollama, hardware) at no extra cost. Your support sustains the research.
The local public/ folder: sandbox only
After completing kit QA and the dry Hugo build (post 11), the public/ directory contains static files waiting for inspection. They are a snapshot of content generated by Ollama on Apple Silicon, often via MLX audio or other local models, but they have zero authority until a human validates them.
The distinction is critical: the local build is for iteration and error-checking; GitHub Pages deployment is the moment of truth. We do not deploy directly from the Hugo-generated public/ folder. Instead, we treat those files as raw material. The agent’s role ends once it compiles static HTML, CSS, and JavaScript. From that point forward, human oversight becomes mandatory. This separation ensures no unverified code or hallucinated data reaches the global edge network.
The _redirects file: manual audit required
Before pushing to GitHub Pages, the _redirects configuration file demands a rigorous human checklist. This file dictates URL mappings between old and new structures, often generated by Hugo’s build process or migration scripts. An agent might suggest a redirect based on pattern matching, but it cannot verify semantic correctness or ensure no SEO equity is lost through misconfiguration.
We manually inspect every entry to confirm the source path matches the intended destination and that the HTTP status code (usually 301) is appropriate. A single erroneous redirect breaks navigation for returning visitors or dilutes domain authority. We also verify that no sensitive parameters are stripped or exposed during the transition. The agent may propose a list of potential redirects, but only a human can confirm the logic holds against the actual site structure and business rules.
Claims worksheets and empty-cite gates as publish blockers
A dry build is not a published article; it is a draft of facts awaiting proof. Before any content leaves the local machine, every factual claim must map to a verifiable source. If an agent generates a statement regarding historical events, scientific data, or financial figures without a corresponding citation, that entry acts as a publish blocker.
We use claims worksheets where each assertion is tagged with a requirement for evidence. An “empty-cite” gate prevents the final build from proceeding if any mandatory reference is missing. This is about integrity. Without these gates, the system risks propagating hallucinations or outdated information into the live environment. The agent can draft the text, but it cannot validate the truth value of the statements within that text.
Which series posts are ready vs desk-only
Not every piece in this local-AI affiliate series is ready for the global stage. Some entries remain “desk-only,” meaning they have been drafted and internally reviewed but lack the final human sign-off required for public distribution. These include pieces relying on proprietary data, ongoing experiments, or complex technical setups requiring further validation by the editorial team.
Conversely, posts marked as ready have passed the full checklist: dry Hugo build completed, _redirects audited, claims verified with sources, and safety protocols confirmed. The agent leaves these “ready” posts in a holding pattern until the human editor gives the final go-ahead. This ensures only fully vetted content reaches the audience, maintaining trust and credibility throughout the series.
What agents leave untouched: payments, UBS, Freqtrade,
Specific domains require an agent to stop entirely, leaving work to the human operator. This includes code or configuration related to financial transactions, such as payment gateway integrations or UBS account handling. Similarly, trading algorithms like Freqtrade require precise, real-time logic that cannot be safely generated by a static text model without risking significant capital loss.
The agent also leaves untouched specific time-sensitive windows, such as the Network security tools like Tailscale are another area where automation is insufficient; setting up secure tunnels requires an understanding of the specific infrastructure topology and security policies only a human can guarantee. These elements remain in the agent’s “do not touch” zone, ensuring high-stakes decisions and complex integrations are handled with full accountability.
The final hand-off: GitHub Pages vs local iteration
The path from a dry Hugo build to a live site on GitHub Pages is not automatic; it is a series of deliberate checks. The agent provides the raw material—the HTML, CSS, JS, and configuration files—but the human provides the authority. By treating the public/ folder as a sandbox and enforcing strict gates on claims and redirects, we ensure the final product is safe, accurate, and reliable.
- Summarizing critical steps before deployment
- Reaffirming the role of human oversight in automated workflows
- Preparing for the final push to GitHub Pages