Status: thinking, decision pending

This page documents a Hugo content architecture question I have not yet decided.

Context

The LoveIt theme used by arleo.eu follows the recommended Hugo convention: blog articles go in content/posts/. The home filters where Site.RegularPages Type posts.

But due to Grav migration history, my 16 editorial articles are at the root of content/, not in content/posts/. Hugo by default treats all these folders as Type page, not Type posts. So the LoveIt home filter does not see them, and I have to either override layouts/index.html or filter manually.

The question

Should I migrate the 16 articles to content/posts/ to follow LoveIt convention, or leave them at the root?

Option A: Migrate to content/posts/

Pros:

• Theme conformity, no layout override needed
• Repo readability, instantly see which folders are articles vs reference pages
• Future-proof, if LoveIt evolves with new features on Type posts they apply for free
• Standard mental model for any Hugo dev discovering the repo

Cons:

• URL change. /csp-nonce/ would become /posts/csp-nonce/ by default. Breaks all inbound links.
• Possible mitigation via explicit url in front matter to preserve URLs
• Migration friction, 16 folders to move, 16 files to edit
• Internal links: many articles cite each other, must audit

Option B: Keep the root

Pros:

• Identical URLs without doing anything
• No migration, 0 files touched
• Internal links intact by definition
• layouts/home.html override already in place, 1 line diff

Cons:

• Custom override to maintain if LoveIt evolves
• Repo readability: reference pages and articles mixed at root
• Weird convention, a Hugo dev wonders why no posts folder

SEO considerations

SEO fears URL change. With url override on Option A, no URL change. But then what is the migration’s purpose? Just internal repo readability. Cost vs benefit, probably not worth it.

Hugo MCP considerations

The MCP tools accept a route parameter. With url override, MCP workflow is unchanged for the user.

The provisional decision

Status: ✅ DELIVERED — sprint closed on May 9, 2026

Update May 9, 2026 (end of session): all 10 chantiers delivered in a single marathon session, and all 3 coordinated releases published the same day (hugo-mcp v1.9.0, mcp-oauth-proxy v2.1.0, mcp-installer v1.3.0). Every component of the MCP ecosystem hardened in one day. Full technical recap: MCP security sprint delivered: v1.9.0, 10 chantiers, hardened ecosystem.

This page stays published as an archive — to show the trajectory of an announced sprint, then kept. All original content below is preserved.

Original status (pre-delivery)

This page publicly documented an ongoing hardening sprint on arleo.eu’s MCP infrastructure. For security reasons, specific details of each chantier were not exposed until fixes were delivered (“sec-first” philosophy: don’t publish an attack roadmap).

Why this transparency

I debated whether to publish this page. Arguments for transparency:

• Public commitment = healthy pressure on yourself to deliver
• Documentation of a homelab whose goal is to learn and share
• Honesty with readers consuming other technical articles

Arguments against:

• Attack roadmap: if I precisely list what’s not yet protected, I give clues to a patient attacker
• Artificial pressure: announcing a sprint then not delivering = worse than announcing nothing

Adopted compromise: publish the direction and hardening domains without specifying what’s weak today. Specific technical detail published on delivery.

Sprint scope

The sprint covered 10 chantiers grouped into 4 domains:

1. Application hardening (FastAPI + Pydantic)

Reinforcement of MCP entry layers: strict input validation, unified error handling, no information leak in responses (stack traces, internal paths, lib versions).

2. Authentication and tokens

Refactor of MCP access token management: lifetime, rotation, revocation, hashing in storage. Allow cutting off a compromised client’s access without redeploying the service.

3. Observability and audit

Integration of JSON structured logs ingested in BetterStack via Vector. Each MCP call must produce a traceable event: who, what, when, duration, status. Enables anomaly detection in near real-time.

4. Infrastructure and resilience

TLS for internal traffic between NUC and VM, dedicated ModSec rules on the /mcp path, disaster recovery runbook (token theft, server compromise, data loss).

What was already in place before the sprint

To not create false impressions, here are the layers already in place on infrastructure before the sprint (so out of scope):

• nginx + mandatory TLS 1.3 (Mozilla Modern config)
• Cloudflare WAF + Bot Management + IP whitelist
• ModSecurity + OWASP CRS 4.x on all vhosts
• CrowdSec in WAF mode + Cloudflare bouncer
• systemd hardening at level 1.7 (cf. systemd hardening)
• HMAC validation on webhooks
• Frontmatter Pydantic validation (1 chantier of 4 in the validation category)

The sprint aimed to complete this base, not replace it.

Method

For each chantier:

1. Implemented locally + unit tests
2. Validated on mcp-test-vm (pre-prod VM)
3. Deployed to prod only after passing tests
4. Structured JSON audit log for deployment traceability
5. Post-mortem or technical write-up published after delivery

No direct prod deployment without pre-prod step.

Published releases

Status: 🗂️ BACKLOG — not yet implemented

This page documents an architectural intent to be implemented in a future iteration. The code is not yet in production.

Context

In Strategy 4 (separating MCP / Git), I explained why content/ is in .gitignore on the arleo.eu repo: so that no conflict is possible between MCP writes and Git writes.

Concretely, this means that when I push a new version of layouts/, themes/, static/, hugo.toml, or deploy.sh from VS Code, nothing happens automatically server-side. I have to SSH into the Hugo VM and manually run git pull && hugo --minify && rsync.

Not critical (structure pushes happen ~1× per week), but it’s unnecessary friction. So: GitHub webhook → auto-rebuild.

Target architecture