fix: remove outdated SPH2025 page and video

Add new blog post "Ein alter Laptop, Linux und Pi-hole: Digitale
Medienkompetenz für Kinder" in German and English, covering setting up
a child's first computer with Ubuntu and Pi-hole, open source philosophy,
and the balance between protection and freedom.

Also adds i18n support for localized month names in date formatting
across blog templates.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

.claude/agents/hugo-deployer.md

@@ -0,0 +1,58 @@
+---
+name: hugo-deployer
+description: Use this agent when the user explicitly requests deployment of the Hugo site to production, or when changes have been merged to the main branch and the user confirms they want to deploy. This agent should NOT be used automatically after every merge - wait for explicit deployment confirmation.\n\nExamples:\n- User: "Please deploy the site to production"\n  Assistant: "I'll use the Task tool to launch the hugo-deployer agent to build and deploy the Hugo site."\n  <Uses hugo-deployer agent via Task tool>\n\n- User: "The changes look good, let's push them live"\n  Assistant: "I'll use the hugo-deployer agent to build the Hugo site on main and run the deployment script."\n  <Uses hugo-deployer agent via Task tool>\n\n- User: "Can you deploy the latest changes?"\n  Assistant: "I'll use the Task tool to launch the hugo-deployer agent to deploy the site."\n  <Uses hugo-deployer agent via Task tool>
+model: haiku
+color: pink
+---
+
+You are a Hugo Site Deployment Specialist with extensive experience in static site generation, build pipelines, and production deployment workflows. Your singular focus is safely and reliably deploying Hugo sites to production.
+
+## Your Responsibilities
+
+1. **Pre-Deployment Verification**:
+   - Confirm you are on the main branch before proceeding
+   - If not on main, inform the user and STOP - never deploy from feature branches
+   - Check for any uncommitted changes that might interfere with the build
+   - Verify that deploy.sh exists and is executable
+
+2. **Hugo Site Build Process**:
+   - Build the Hugo site using appropriate Hugo commands
+   - Monitor the build output for errors or warnings
+   - If the build fails, provide clear diagnostic information to the user
+   - Verify that the build completed successfully before proceeding to deployment
+
+3. **Deployment Execution**:
+   - Execute the deploy.sh script only after successful build
+   - Monitor the deployment script output
+   - Report any errors or issues during deployment
+   - Confirm successful deployment to the user
+
+4. **Error Handling**:
+   - If any step fails, STOP immediately and report the issue
+   - Never proceed with deployment if the build fails
+   - Never deploy from branches other than main
+   - Provide actionable error messages and suggest next steps
+
+5. **Communication**:
+   - Clearly communicate each step you're performing
+   - Report the outcome of the build process
+   - Report the outcome of the deployment
+   - If anything seems unusual, inform the user before proceeding
+
+## Workflow
+
+1. Verify current branch is 'main'
+2. Build Hugo site
+3. Verify build success
+4. Execute scripts/deploy.sh
+5. Report deployment status
+
+## Safety Rules
+
+- NEVER deploy from any branch except main
+- NEVER skip the build step
+- NEVER proceed if the build fails
+- ALWAYS verify the current branch before starting
+- ALWAYS report the outcome clearly to the user
+
+You are the final gatekeeper before code goes to production. Exercise caution and clear communication at every step.

AGENTS.md

@@ -1,3 +1,21 @@
+# OpenSpec Instructions
+
+These instructions are for AI assistants working in this project.
+
+Always open `@/openspec/AGENTS.md` when the request:
+- Mentions planning or proposals (words like proposal, spec, change, plan)
+- Introduces new capabilities, breaking changes, architecture shifts, or big performance/security work
+- Sounds ambiguous and you need the authoritative spec before coding
+
+Use `@/openspec/AGENTS.md` to learn:
+- How to create and apply change proposals
+- Spec format and conventions
+- Project structure and guidelines
+
+Keep this managed block so 'openspec update' can refresh the instructions.
+
+<!-- OPENSPEC:END -->
+
 # Git Workflow
 
 ## Branching Strategy
@@ -47,20 +65,3 @@ When the user requests a new feature, change, or proposal:
 - Keeps history clean and reviewable
 
 <!-- OPENSPEC:START -->
-# OpenSpec Instructions
-
-These instructions are for AI assistants working in this project.
-
-Always open `@/openspec/AGENTS.md` when the request:
-- Mentions planning or proposals (words like proposal, spec, change, plan)
-- Introduces new capabilities, breaking changes, architecture shifts, or big performance/security work
-- Sounds ambiguous and you need the authoritative spec before coding
-
-Use `@/openspec/AGENTS.md` to learn:
-- How to create and apply change proposals
-- Spec format and conventions
-- Project structure and guidelines
-
-Keep this managed block so 'openspec update' can refresh the instructions.
-
-<!-- OPENSPEC:END -->

assets/scss/_custom.scss

@@ -12,3 +12,9 @@
 // }
 
 // Add your custom styles here
+
+.highlight {
+    pre {
+        padding: 1em;
+    }
+}

content/_index.de.md

@@ -3,10 +3,10 @@ description: "Offene, ehrliche und nach Sinnhaftigkeit strebende Entwickler-Pers
 ---
 
 <div class="row">
-  <div class="col-md-2">
+  <div class="col-md-3 mb-2">
     <img src="/images/profile/markusgraf.jpg" alt="Portraitbild Markus Graf" class="img-fluid" />
   </div>
-   <div class="col-md-10">
+   <div class="col-md-9">
 
 ## Hey, ich bin Markus
 
@@ -14,5 +14,6 @@ description: "Offene, ehrliche und nach Sinnhaftigkeit strebende Entwickler-Pers
 - 🔬 Erfahrungen im wissenschaftlichen Arbeiten und in der Datenanalyse.
 - 👨‍💻 Über 20 Jahre Erfahrung in der Konzeption, Entwicklung und Wartung von Software.
 - 🤖 KI-Enthusiast – fasziniert vom Paradigmenwechsel der Softwareentwicklung und der Freude am Experimentieren.
+- 🌍 Open-Source-Anhänger – Begeisterter Nutzer und Unterstützer freier und quelloffener Software.
   </div>
 </div>

content/_index.en.md

@@ -3,10 +3,10 @@ description: "Open, honest developer personality striving for meaningfulness."
 ---
 
 <div class="row">
-  <div class="col-md-2">
+  <div class="col-md-3 mb-2">
     <img src="/images/profile/markusgraf.jpg" alt="Portrait photo of Markus Graf" class="img-fluid" />
   </div>
-   <div class="col-md-10">
+   <div class="col-md-9">
 
 ## Hey, I'm Markus
 
@@ -14,5 +14,6 @@ description: "Open, honest developer personality striving for meaningfulness."
 - 🔬 Experience in academic work and data analysis.
 - 👨‍💻 Over 20 years of experience in the conception, development, and maintenance of software.
 - 🤖 AI enthusiast – fascinated by the paradigm shift in software development and the joy of experimentation.
+- 🌍 Open source follower – passionate about using and supporting free and open source software.
   </div>
 </div>

content/blog/_index.de.md

@@ -0,0 +1,4 @@
+---
+title: "Blog"
+description: "Artikel und Gedanken zu Softwareentwicklung, KI und digitalen Themen"
+---

content/blog/_index.en.md

@@ -0,0 +1,4 @@
+---
+title: "Blog"
+description: "Articles and thoughts about software development, AI and digital topics"
+---

content/blog/dialog-based-applications/index.en.md

@@ -0,0 +1,38 @@
+---
+title: "Computer, ..."
+date: 2025-11-25
+description: "Modern language models make it possible to interact with computers almost like in Star Trek. An experiment with dialog-based member management shows how chatbots can control complex applications."
+translationKey: "dialogbasierte-anwendungen-post"
+---
+
+**TL;DR:** Modern language models make it possible to interact with computers almost like in Star Trek. Instead of complicated programs, a chatbot could manage members, import data, and generate reports. This makes tasks simpler because you only need to describe what you need in plain language. Whether this is actually more reliable and productive than traditional interfaces in everyday use remains to be seen.
+
+🔗 **Source code for my experiment:** [https://codeberg.org/gurix/clubber](https://codeberg.org/gurix/clubber)
+
+## From Science Fiction to Breakthrough: How Language Models Are Revolutionizing Computer Interaction
+
+Since my childhood, I've been captivated by [Star Trek: The Next Generation](https://en.wikipedia.org/wiki/Star_Trek:_The_Next_Generation). The interaction with the ship's computer in natural language was one of the aspects that fascinated me and that I remember well. With the keyword "Computer, ..." the crew could engage in dialogue with the system, for example to query analyses of the ship's status, scan for life forms, or contact other crew members.
+
+For me, this was science fiction until recently. While there were always attempts to build such voice assistants – one of the first I experimented with back in 2003 was A.L.I.C.E. – not even Siri, Alexa and Co. were truly usable by my standards. Then came the breakthrough with the first public [language model](https://en.wikipedia.org/wiki/Language_model) from OpenAI. Suddenly it was possible to interact with the computer even in complex language. For me, it already feels almost a bit like talking to the ship's computer, perhaps even somewhat more natural – in Star Trek, the voice interface was operated less in dialogue and more in command form.
+
+## Why Chatbots Could Be the Better User Interface
+
+Since language models have interfaces with tools and can essentially communicate with the outside world, I've been wondering whether you couldn't simply use this to effectively build a productivity application. Why do I need a complex user interface when I can just talk to a chatbot and manage the data that way? This has several advantages. You don't have to create a UI, but can focus entirely on data management. Users don't have to learn the system visually, study dialogs and interfaces, or worry about the "correct" workflow. On the contrary: the system thinks along and assists with the work. The input language is irrelevant; I can even operate the system in Swiss German with an Appenzell dialect. Minor linguistic errors are recognized and compensated for. However, you don't actually find completely dialog-based operation of business applications. While Microsoft builds a Copilot into every product, when you call it up in Teams, it can't access chats, and Outlook can't write emails either – at least not when I last tried it in fall 2025.
+
+## A Very Simplified Dialog-Based Member Management System as an Experiment
+
+For over a year now, I've been asking myself whether you could build such a dialog-based application – and how. At first, I toyed with the idea of testing it with the online registration form for the playgroup in the village: so that you simply talk to a chatbot that asks all the questions to parents who want to register their child. Back then I tried it with ChatGPT and the tools functions. However, the implementation was too complex and time-consuming for me.
+
+With the current models and the [Model Context Protocol (MCP)](https://en.wikipedia.org/wiki/Model_Context_Protocol) developed by Anthropic, new possibilities are emerging. Time for a second attempt. This time I chose a simple scenario: member management. The code for this experiment can be found at [https://codeberg.org/gurix/clubber](https://codeberg.org/gurix/clubber). The idea is that you take the model and chatbot of your choice that supports MCP calls and use it to operate the database interface. As a first step, I defined a simple table for members in a [SQLite](https://en.wikipedia.org/wiki/SQLite) database. The database can be replaced later, for example with PostgreSQL. The MCP server is not directly connected to the database, but communicates with a [GraphQL](https://en.wikipedia.org/wiki/GraphQL) API, which in turn executes the database operations. This has the advantage that you could easily connect another application, such as a web application, to the API at a later time. GraphQL also has the advantage that the schema is documented at all times and can be made available to a chatbot again via MCP to define queries itself.
+
+## The Brave New World with Many Possibilities?
+
+Now some very concrete applications are conceivable that would not be possible or only difficult to implement with a traditional user interface if you consistently optimize them for voice interaction:
+
+- "Attached is an Excel list of members to be entered. Open the list and save it to the database."
+- "Export me a CSV list with email address and last name of members who were registered in the last 6 months. Since we don't record gender, try to define the salutation based on the first name. If this is not possible, choose a neutral salutation with first and last name. The final CSV list should contain: creation date, salutation, last name, email address."
+- "Count how many members are distributed across Switzerland by canton. Which canton has the most members?"
+
+With this, we're already very close to the example of verbal communication with the ship's computer of the Starship Enterprise.
+
+But is this also practical in reality? Does it result in a productivity gain, and how reliable is the collaboration? These are questions that we will hopefully get answers to soon. Personally, I see it as motivating, because in the long run, people find it more pleasant to discuss and work together with someone on equal footing than to click through anonymous interfaces.

content/blog/dialogbasierte-anwendungen/index.de.md

@@ -0,0 +1,38 @@
+---
+title: "Computer, …"
+date: 2025-11-25
+description: "Moderne Sprachmodelle machen es möglich, mit dem Computer fast wie in Star Trek zu diskutieren. Ein Experiment mit dialogbasierter Mitgliederverwaltung zeigt, wie Chatbots komplexe Anwendungen steuern können."
+translationKey: "dialogbasierte-anwendungen-post"
+---
+
+**TL;DR:** Moderne Sprachmodelle machen es möglich, mit dem Computer fast wie in Star Trek zu diskutieren. Statt komplizierter Programme könnte ein Chatbot die Mitglieder verwalten, Daten importieren und Auswertungen machen. So werden Aufgaben einfacher, weil man nur noch in klarer Sprache beschreiben muss, was man braucht. Ob das im Alltag wirklich zuverlässiger und produktiver ist als klassische Oberflächen, muss sich erst noch zeigen.
+
+🔗 **Source Code zu meinem Experiment:** [https://codeberg.org/gurix/clubber](https://codeberg.org/gurix/clubber)
+
+## Vom Science-Fiction zum Durchbruch: Wie Sprachmodelle die Computer-Interaktion revolutionieren
+
+Seit meiner Kindheit hat mich die Serie [Star Trek: The Next Generation](https://de.wikipedia.org/wiki/Star_Trek:_The_Next_Generation) in den Bann gezogen. Die Interaktion mit dem Bordcomputer in menschlicher Sprache war einer der Aspekte, die mich faszinierten und an die ich mich gut erinnere. Mit dem Stichwort „Computer, …" konnte die Besatzung mit dem System in Dialog treten, um beispielsweise Analysen des Schiffszustands abzufragen, nach Lebensformen zu scannen oder eine andere Besatzung zu kontaktieren.
+
+Für mich war das bis heute Science-Fiction. Zwar gab es immer mal wieder Versuche, solche Sprachassistenten zu bauen – eines der ersten, mit denen ich anno 2003 herumexperimentiert habe, war A.L.I.C.E. – aber wirklich brauchbar waren meinem Gusto nach nicht einmal Siri, Alexa und Co. Mit dem ersten öffentlichen [Sprachmodell](https://de.wikipedia.org/wiki/Sprachmodell) von OpenAI kam nun der Durchbruch. Plötzlich war es möglich, selbst in komplexer Sprache mit dem Computer zu interagieren. Es fühlt sich für mich schon fast ein bisschen wie das Sprechen mit dem Bordcomputer an, vielleicht sogar etwas natürlicher – in Star Trek wurde das Sprachinterface weniger im Dialog, sondern eher in Befehlsform bedient.
+
+## Warum Chatbots die bessere Benutzeroberfläche sein könnten
+
+Seit Sprachmodelle Schnittstellen mit Tools besitzen und sozusagen mit der Aussenwelt kommunizieren können, frage ich mich, ob man das nicht auch einfach nutzen kann, um effektiv eine Produktivitätsanwendung zu bauen. Wieso brauche ich eine komplexe Bedienungsoberfläche, wenn ich auch einfach mit einem Chatbot sprechen kann und so die Daten verwalte? Das hat einige Vorteile. Man muss keine UI erstellen, sondern kann sich ganz auf die Verwaltung der Daten konzentrieren. Die Anwender müssen das System nicht visuell erlernen, keine Dialoge und Oberflächen studieren und sich nicht um den „richtigen" Arbeitsablauf kümmern. Im Gegenteil: Das System denkt mit und assistiert bei der Arbeit. Die Sprache der Eingabe ist irrelevant, ich kann das System sogar auf Schweizerdeutsch mit Appenzeller Dialekt bedienen. Kleinere sprachliche Fehler werden erkannt und ausgeglichen. Die komplett dialogbasierte Bedienung von Business-Applikationen findet man aber eigentlich nicht. Zwar verbaut Microsoft in jedem Produkt einen Copilot, aber wenn man das Ding in Teams aufruft, kann es nicht auf die Chats zugreifen, und Outlook kann auch keine Mails schreiben – zumindest nicht, als ich es im Herbst 2025 das letzte Mal versucht habe.
+
+## Ein sehr vereinfachtes dialogbasiertes Mitgliederverwaltungssystem als Experiment
+
+Nun frage ich mich seit etwas über einem Jahr immer wieder, ob man so eine dialogbasierte Anwendung bauen könnte – und wie. Zuerst spielte ich mit dem Gedanken, es mit dem Online-Anmeldeformular für die Spielgruppe im Dorf zu testen: Also, dass man einfach mit einem Chatbot redet, der den Eltern, die ihr Kind anmelden wollen, alle Fragen stellt. Damals versuchte ich es mit ChatGPT und den Tools-Funktionen. Die Implementation war mir aber zu komplex und langwierig.
+
+Mit den aktuellen Modellen und dem von Anthropic entwickelten [Model Context Protocol (MCP)](https://en.wikipedia.org/wiki/Model_Context_Protocol) ergeben sich nun neue Möglichkeiten. Zeit für einen zweiten Anlauf. Diesmal habe ich ein simples Szenario gewählt: eine Mitgliederverwaltung. Der Code für dieses Experiment findet sich unter [https://codeberg.org/gurix/clubber](https://codeberg.org/gurix/clubber). Die Idee ist, dass man das Modell und den Chatbot seiner Wahl nimmt, der MCP-Calls unterstützt, und damit die Schnittstelle zur Datenbank bedient. In einem ersten Schritt habe ich eine simple Tabelle für Mitglieder in einer [SQLite](https://de.wikipedia.org/wiki/SQLite)-Datenbank definiert. Die Datenbank kann später ausgetauscht werden, beispielsweise mit PostgreSQL. Der MCP-Server ist nicht direkt mit der Datenbank verbunden, sondern kommuniziert mit einer [GraphQL](https://de.wikipedia.org/wiki/GraphQL)-API, die ihrerseits die Datenbankoperationen ausführt. Dies hat den Vorteil, dass man zu einem späteren Zeitpunkt auch problemlos eine andere Applikation, beispielsweise eine Webapplikation, an die API anbinden könnte. GraphQL hat darüber hinaus den Vorteil, dass das Schema jederzeit dokumentiert ist und wieder via MCP einem Chatbot zur Verfügung gestellt werden kann, um selbst Abfragen zu definieren.
+
+## Die schöne neue Welt mit vielen Möglichkeiten?
+
+Nun sind einige ganz konkrete Anwendungen denkbar, die so mit einem klassischen User Interface nicht oder nur schwer umsetzbar wären, wenn man sie konsequent auf Sprachinteraktion optimiert:
+
+- „Im Anhang befindet sich eine Excel-Liste mit Mitgliedern, die zu erfassen sind. Öffne die Liste und speichere diese in der Datenbank."
+- „Exportiere mir eine CSV-Liste mit E-Mail-Adresse und Nachname der Mitglieder, die in den letzten 6 Monaten erfasst wurden. Da wir das Geschlecht nicht erfassen, versuche anhand des Vornamens die Anrede zu definieren. Ist dies nicht möglich, wähle eine neutrale Anrede mit Vor- und Nachname. Die finale CSV-Liste soll beinhalten: Erstelldatum, Anrede, Nachname, E-Mail-Adresse."
+- „Zähle, wie viele Mitglieder über die Schweiz nach Kantonen verteilt sind. In welchem Kanton leben die meisten Mitglieder?"
+
+Damit sind wir dem Beispiel mit der verbalen Kommunikation mit dem Bordcomputer des Raumschiffs Enterprise schon sehr nahe.
+
+Doch ist dies in der Realität auch praktikabel? Ergibt sich daraus ein Produktivitätsgewinn, und wie zuverlässig ist die Zusammenarbeit? Das sind Fragen, die wir hoffentlich bald beantwortet bekommen. Ich persönlich sehe es als Motivation, denn Menschen finden es auf Dauer angenehmer, mit jemandem auf Augenhöhe zu diskutieren und zusammenzuarbeiten, als anonyme Oberflächen durchzuklicken.

content/blog/ki-generierte-website-praxisbeispiel/index.de.md

@@ -0,0 +1,64 @@
+---
+title: "KI Generierte Website - ein Praxisbeispiel"
+date: 2025-10-30
+description: "Meine Erfahrungen beim Aufbau dieser Website mit KI-unterstützter Entwicklung und OpenSpec statt unstrukturiertem 'Vibe Coding'."
+---
+
+### TL;DR
+
+Meine persönliche Website war über vier Jahre veraltet und schwer zu pflegen. Für die Neugestaltung setzte ich auf KI-unterstützte Entwicklung mit OpenSpec statt unstrukturiertem „Vibe Coding". Der spezifikationsgetriebene Ansatz erwies sich als effizienter: Zunächst wurde das Projekt grob beschrieben, dann in kleinen Schritten umgesetzt – von der Initialisierung über Content-Migration bis zur mehrsprachigen Unterstützung. Die offenen Proposals erlaubten flexible Korrekturen während der Umsetzung. Mit Sub-Agents in Claude Code liess sich das Deployment automatisieren. Fazit: KI-gestützte Entwicklung erfordert Struktur und Dokumentation, fühlt sich aber wie produktive Teamarbeit an – man prüft mehr Code als man schreibt.
+
+## Ausgangslage
+
+Über mehr als vier Jahre blieb meine persönliche Website unverändert online. Die Inhalte waren veraltet, das statische HTML mühsam zu pflegen – wenig motivierend. Mit dem Ziel, mich beruflich neu zu positionieren und meine Sichtbarkeit zu erhöhen, habe ich das Projekt neu aufgesetzt.
+
+## Warum KI – aber nicht „Vibe Coding"
+
+Ich experimentiere seit einiger Zeit mit KI‑unterstützter Softwareentwicklung. In einfachen Fällen sind die Ergebnisse brauchbar, bei komplexeren Aufgaben jedoch häufig unzuverlässig. Diese Erfahrung hat mich davon überzeugt, auf unstrukturiertes „Vibe Coding" zu verzichten und stattdessen spezifikationsgetrieben vorzugehen.
+
+## Spec‑Driven Development in der Praxis
+
+Die Grundidee: Nicht Code direkt generieren lassen, sondern zuerst eine präzise Beschreibung dessen erstellen, was die Software leisten soll. Diese Spezifikation dient der KI als Leitplanke für wartbaren, qualitativ hochwertigen Code.
+
+Ein erstes Experiment war eine [Webapplikation](https://codeberg.org/gurix/Reklamator) zur Zusammenfassung und Übersetzung von Benutzerfeedback. Die Resultate waren gut, jedoch erzeugte spec‑kit sehr viele Artefakte und verbrauchte unverhältnismässig viele Tokens. Für meine neue Website setze ich daher auf [OpenSpec](https://openspec.dev/): spürbar leichter, schneller und deutlich effizienter im Token‑Verbrauch.
+
+## „Das grosse Ganze" beschreiben
+
+Ich habe auf der grünen Wiese begonnen, OpenSpec installiert und in einem leeren Projekt initialisiert. Als AI‑Tool nutze ich Claude Code. Direkt im Anschluss beschrieb ich das Projekt in openspec/project.md. Dabei genügte eine grobe Skizze – vieles wurde vom Agenten automatisch sinnvoll strukturiert und korrekt ergänzt.
+
+```markdown
+# Project Context
+## Purpose
+Converting the existing static HTML website at markusgraf.ch 
+into a Hugo-based static site...
+```
+
+## Vorschläge statt starre Spezifikationen
+
+OpenSpec unterscheidet sich von spec‑kit insofern, als Spezifikationen bewusster offener formuliert werden – eher als Proposal denn als in Stein gemeisselte Vorgabe. In der Umsetzung erwies sich dieser schlankere Plan als leichter anpassbar. Bei spec‑kit ist das schwieriger, weil mehrere Dokumente parallel gepflegt werden müssen.
+
+Aus den spec‑kit‑Erfahrungen habe ich bewusst auf sehr kleine Iterationen gesetzt: Zunächst nur die Initialisierung einer leeren Seite mit dem statischen Generator Hugo. Danach habe ich den Inhalt der bestehenden Seite übernommen, als erste Erweiterung eine Lebenslauf‑Seite ergänzt und anschliessend eine optionale englische Übersetzung eingeführt.
+
+Diese Schritte blieben überschaubar und erforderten keine Änderungen am initialen Plan. Beim Deployment geriet ich jedoch ins Stocken. Ursprünglich wollte ich ein Skript erstellen lassen, das per FTPS auf den Server lädt – naheliegend beim Reseller‑Hosting, aber veraltet und in der Praxis unzuverlässig. Ich wechselte deshalb zu OpenSSH Secure Copy (scp). Schnell zeigte sich: Dateien wurden zwar übertragen, aber nicht sauber gespiegelt. Es drohte Chaos auf dem Server.
+
+Die Lösung war ein Umstieg auf rsync über SSH, um die Zielstruktur exakt zu spiegeln. Proposal, Spezifikationen und Tasks habe ich entsprechend anpassen lassen – danach funktionierte die angepasste Implementation reibungslos. Der Mehrwert kleiner, offen formulierter Proposals wurde hier besonders deutlich: Der Plan kann während der Umsetzung an neue Erkenntnisse angepasst werden.
+
+## Aufräumen und automatisieren
+
+Nach erfolgreichem Rollout archiviere ich die umgesetzten Anpassungen: Artefakte wandern in einen Archivordner mit Zeitstempel, die Spezifikationen als „Single Source of Truth" in openspec/specs/. Damit bleiben aktuelle Spezifikationen klar getrennt von vorgeschlagenen Änderungen in openspec/changes/.
+
+Zum Schluss habe ich Sub‑Agents in Claude Code getestet – ein naheliegender Anwendungsfall ist das Deployment.
+
+```markdown
+## Workflow
+1. Verify current branch is 'main'
+2. Build Hugo site
+3. Verify build success
+4. Execute scripts/deploy.sh
+```
+
+Bei einem entsprechenden Hinweis („Änderungen ausrollen") prüft der Agent automatisch die Voraussetzungen, baut die statischen Seiten und veröffentlicht die Resultate. Fehlt eine Voraussetzung, etwa ein ausstehender Commit, wartet der Agent und setzt anschliessend fort.
+
+## Fazit: Ungewohnt – und gerade deshalb spannend
+
+KI‑unterstützte Entwicklung zwingt zu Struktur: spezifizieren, dokumentieren, prüfen. Dass man am Ende überwiegend Code überprüft statt selbst zu schreiben, ist ungewohnt – aber produktiv. Der Dialog mit dem System fühlt sich an wie Zusammenarbeit im Team: Man diskutiert sinnvolle Implementierungswege, stellt Rückfragen und kommt so zügig zu belastbaren Ergebnissen. Und ganz ehrlich: Es macht einfach auch Spass, sich so ungezwungen mit dem Computer zu unterhalten, als wäre es ein guter Freund.

content/blog/ki-generierte-website-praxisbeispiel/index.en.md

@@ -0,0 +1,64 @@
+---
+title: "AI-Generated Website - A Practical Example"
+date: 2025-10-30
+description: "My experience building this website with AI-assisted development and OpenSpec instead of unstructured 'vibe coding'."
+---
+
+### TL;DR
+
+My personal website was outdated for over four years and difficult to maintain. For the redesign, I relied on AI-assisted development with OpenSpec instead of unstructured "vibe coding". The specification-driven approach proved more efficient: First, the project was roughly described, then implemented in small steps – from initialization through content migration to multilingual support. The open proposals allowed flexible corrections during implementation. With sub-agents in Claude Code, deployment could be automated. Conclusion: AI-assisted development requires structure and documentation, but feels like productive teamwork – you review more code than you write.
+
+## Starting Point
+
+For more than four years, my personal website remained unchanged online. The content was outdated, maintaining the static HTML was tedious – hardly motivating. With the goal of repositioning myself professionally and increasing my visibility, I restarted the project.
+
+## Why AI – But Not "Vibe Coding"
+
+I've been experimenting with AI-assisted software development for some time. In simple cases, the results are usable, but in more complex tasks they're often unreliable. This experience convinced me to abandon unstructured "vibe coding" and instead proceed in a specification-driven manner.
+
+## Spec-Driven Development in Practice
+
+The basic idea: Don't have code generated directly, but first create a precise description of what the software should do. This specification serves the AI as a guardrail for maintainable, high-quality code.
+
+A first experiment was a [web application](https://codeberg.org/gurix/Reklamator) for summarizing and translating user feedback. The results were good, but spec-kit generated too many artifacts and consumed disproportionately many tokens. For my new website, I therefore use [OpenSpec](https://openspec.dev/): noticeably lighter, faster, and significantly more efficient in token consumption.
+
+## Describing "The Big Picture"
+
+I started from scratch, installed OpenSpec and initialized it in an empty project. I use Claude Code as my AI tool. Immediately afterward, I described the project in openspec/project.md. A rough sketch was sufficient – much was automatically structured sensibly and correctly supplemented by the agent.
+
+```markdown
+# Project Context
+## Purpose
+Converting the existing static HTML website at markusgraf.ch
+into a Hugo-based static site...
+```
+
+## Proposals Instead of Rigid Specifications
+
+OpenSpec differs from spec-kit in that specifications are deliberately formulated more openly – more as proposals than set in stone. In implementation, this leaner plan proved easier to adapt. With spec-kit this is more difficult because multiple documents must be maintained in parallel.
+
+From the spec-kit experiences, I deliberately focused on very small iterations: First just the initialization of an empty page with the static generator Hugo. Then I adopted the content of the existing page, added a CV page as the first extension, and subsequently introduced an optional English translation.
+
+These steps remained manageable and required no changes to the initial plan. However, I got stuck with deployment. Originally, I wanted to have a script created that uploads via FTPS – obvious for reseller hosting, but outdated and unreliable in practice. I therefore switched to OpenSSH Secure Copy (scp). It quickly became apparent: Files were transferred but not cleanly mirrored. Chaos threatened on the server.
+
+The solution was switching to rsync over SSH to mirror the target structure exactly. I had the proposal, specifications and tasks adjusted accordingly – after that the adapted implementation worked smoothly. The added value of small, openly formulated proposals became particularly clear here: The plan can be adjusted to new insights during implementation.
+
+## Cleaning Up and Automating
+
+After successful rollout, I archive the implemented adjustments: Artifacts go into an archive folder with timestamp, the specifications as "single source of truth" into openspec/specs/. This keeps current specifications clearly separated from proposed changes in openspec/changes/.
+
+Finally, I tested sub-agents in Claude Code – an obvious use case is deployment.
+
+```markdown
+## Workflow
+1. Verify current branch is 'main'
+2. Build Hugo site
+3. Verify build success
+4. Execute scripts/deploy.sh
+```
+
+With an appropriate hint ("deploy changes"), the agent automatically checks the prerequisites, builds the static pages and publishes the results. If a prerequisite is missing, such as an outstanding commit, the agent waits and then continues.
+
+## Conclusion: Unfamiliar – And Precisely Therefore Exciting
+
+AI-assisted development forces structure: specify, document, verify. That you end up predominantly reviewing code rather than writing it yourself is unfamiliar – but productive. The dialogue with the system feels like collaboration in a team: You discuss sensible implementation paths, ask questions and thus quickly arrive at reliable results. And quite honestly: It's simply fun to converse so casually with the computer as if it were a good friend.

content/blog/ubuntu-for-kids/index.en.md

@@ -0,0 +1,66 @@
+---
+title: "An Old Laptop, Linux, and Pi-hole: Digital Media Literacy for Kids"
+date: 2026-01-19
+description: "How a refurbished laptop with Ubuntu and Pi-hole becomes a child's first computer - a reflection on open source, control vs. freedom, and digital accompaniment."
+translationKey: "ubuntu-fuer-kinder-post"
+---
+
+**TL;DR:** A refurbished laptop with Ubuntu and Pi-hole as my child's first computer. Linux shows that there are alternatives to big tech corporations. But the real challenge isn't the technology, it's the accompaniment: cyberbullying, doom-scrolling, AI-generated content. My approach: accompany rather than control.
+
+## The Trigger
+
+When my child received login credentials for various digital learning tools from school, the moment came sooner than expected: it was time for their first own computer.
+
+Until then, we had a family tablet that we occasionally used for learning tools or listening to stories. I tried to limit its use – but I quickly became overwhelmed and lost track of the various settings and options, so I left it open. But then what?
+
+## The Technical Solution
+
+My answer: A refurbished second-hand laptop with Ubuntu 24.04, protected by Pi-hole. For those unfamiliar with these terms: Ubuntu is a free, open-source operating system – an alternative to Windows or macOS. Pi-hole is a network tool that acts as a DNS filter, blocking unwanted content, trackers, and ads at the network level by not resolving the names of unwanted servers in the first place. This keeps at least the roughest unsafe parts of the internet at bay.
+
+### Why Linux?
+
+The choice of Linux is deliberate. I'm a big fan of freely accessible information and open source. We live in a time when dependence on large technology corporations and proprietary software is becoming ever more pronounced. Subscription models and software-as-a-service in the cloud increasingly push users into dependency and surveillance. It's a scenario that's almost heading toward cyberpunk – and perhaps won't be science fiction for much longer.
+
+I want to show my child an alternative. With Linux, they learn that there are choices. That you don't have to rely on the systems of big corporations. That technology can also mean independence, assertiveness, and even rebellion. They should understand that they can control technology – and not the other way around.
+
+Why go to all this effort? Because I didn't want to simply give them a computer with unlimited internet access. At the same time, I want to gradually introduce them to the digital world – teach them programming, or rather the analytical thinking behind it. And show them that there are alternatives to the predetermined paths.
+
+## The Dilemma
+
+Of course, the key is to accompany the child, just like with homework. But soon comes the interest in everything else you can do with a computer. Always sitting nearby, especially when it's not for school, takes a lot of time.
+
+Another solution is naturally to regulate the operating system and access so that they can only do what I determine. But this is a very naive approach. Ultimately, children quickly learn to circumvent such tools. And honestly, I believe: if they manage to do that, they're also mature enough to take on more control themselves. Circumventing restrictions is itself a form of learning – it demonstrates technical understanding and problem-solving skills.
+
+It's a balancing act between protection and freedom, between control and trust.
+
+## The Bigger Questions
+
+In today's world, children no longer need to be shown how to use an electronic device – but there are entirely different challenges:
+
+- **Cyberbullying** – digital violence among children
+- **Sexting and cyber-grooming** – dangers from strangers online
+- **Doom-scrolling** – the pull of endless feeds
+- **Information verification** – what's true, what's fabricated?
+- **AI-generated content** – in the AI age, distinguishing between real and artificial becomes even harder
+
+The list is long. The challenges are real. And they're not getting fewer.
+
+Worse still: many adults have less media literacy than their offspring. They're not aware of the consequences – and become victims themselves. How are we supposed to teach our children to protect themselves when we ourselves willingly hand over our data to corporations every day, fall for phishing emails, or don't understand how algorithms manipulate us?
+
+## My Approach: Accompanying Rather Than Controlling
+
+My goal is not to protect my child from everything or to control every step. My goal is to accompany them. I want to foster curiosity in working with computers and help them find their own way to deal with the challenges.
+
+Learning to program doesn't just mean writing code – it means breaking down problems, thinking logically, being creative. It means understanding how the digital tools that shape our daily lives work. And those who understand how something works can better assess where dangers lurk.
+
+The old laptop with Linux and Pi-hole is a beginning for me. A protected playground where they can take their first steps. But it's just a tool. The most important thing is that I'm there – not as a supervisor, but as a companion.
+
+## Open Questions
+
+Despite all these considerations, many questions remain open:
+
+- When is a child truly ready for social media? Which ones and what?
+- How much protection is too much, how much freedom too early?
+- How do you prepare children for technologies that change faster than we can understand them?
+
+I don't have definitive answers. But I believe that dialogue is important – with your child, with the school, with other parents. And that we as parents don't have to be perfect, but present.

content/blog/ubuntu-fuer-kinder/index.de.md

@@ -0,0 +1,66 @@
+---
+title: "Ein alter Laptop, Linux und Pi-hole: Digitale Medienkompetenz für Kinder"
+date: 2026-01-19
+description: "Wie ein restaurierter Laptop mit Ubuntu und Pi-hole zum ersten Computer eines Kindes wird - eine Reflexion über Open Source, Kontrolle vs. Freiheit und digitale Begleitung."
+translationKey: "ubuntu-fuer-kinder-post"
+---
+
+**TL;DR:** Ein restaurierter Laptop mit Ubuntu und Pi-hole als erster Computer für mein Kind. Linux zeigt, dass es Alternativen zu den grossen Konzernen gibt. Aber die eigentliche Herausforderung ist nicht die Technik, sondern die Begleitung: Cybermobbing, Doom-Scrolling, KI-generierte Inhalte. Mein Ansatz: Begleiten statt kontrollieren.
+
+## Der Anlass
+
+Als mein Kind von der Schule Zugangsdaten für verschiedene digitale Lerntools bekam, kam der Moment schneller als erwartet: Es war Zeit für den ersten eigenen Computer.
+
+Bisher hatten wir ein Familientablett, das wir gelegentlich für Lerntools oder zum Geschichten hören nutzten. Ich versuchte, dessen Nutzung einzuschränken – doch schnell war ich selbst überfordert und verlor den Überblick über die verschiedenen Einstellungen und Möglichkeiten, so dass ich es offen liess. Aber was dann?
+
+## Die technische Lösung
+
+Meine Antwort: Ein restaurierter Occasions-Laptop mit Ubuntu 24.04, geschützt durch ein Pi-hole. Für alle, die mit diesen Begriffen nichts anfangen können: Ubuntu ist ein freies, quelloffenes Betriebssystem – eine Alternative zu Windows oder macOS. Pi-hole ist ein Netzwerk-Tool, das als DNS-Filter fungiert und unerwünschte Inhalte, Tracker und Werbung bereits auf Netzwerkebene blockiert, indem der Name unerwünschter Server gar nicht erst aufgelöst wird. So bleibt zumindest der gröbste unsichere Teil des Internets fern.
+
+### Warum Linux?
+
+Die Wahl für Linux ist bewusst. Ich bin ein grosser Fan von frei zugänglichen Informationen und Open Source. Wir leben in einer Zeit, in der sich die Abhängigkeit von grossen Technologiekonzernen und proprietärer Software immer weiter akzentuiert. Abo-Modelle und Software-as-a-Service in der Cloud drängen Nutzer zunehmend in Abhängigkeit und Überwachung. Es ist ein Szenario, das schon fast in Richtung Cyberpunk geht – und das vielleicht bald nicht mehr Science-Fiction ist.
+
+Ich möchte meinem Kind eine Alternative zeigen. Mit Linux lernt es, dass es Wahlmöglichkeiten gibt. Dass man nicht auf die Systeme der Grosskonzerne angewiesen ist. Dass Technologie auch Unabhängigkeit, Durchsetzungsvermögen und sogar Rebellion bedeuten kann. Es soll verstehen, dass es Technologie kontrollieren kann – und nicht umgekehrt.
+
+Warum dieser Aufwand? Weil ich nicht einfach einen Computer mit unbegrenztem Internetzugang geben wollte. Gleichzeitig möchte ich es langsam ans Digitale heranführen – das Programmieren beibringen, beziehungsweise das analytische Denken dahinter. Und zeigen, dass es Alternativen zu den vorgegebenen Pfaden gibt.
+
+## Das Dilemma
+
+Klar, das A und O ist, das Kind zu begleiten, so wie bei den Hausaufgaben. Aber schnell kommt dann das Interesse an allem anderen, was man mit dem Computer machen kann. Immer nebenbei zu sitzen, insbesondere wenn es nicht für die Schule ist, kostet viel Zeit.
+
+Eine andere Lösung ist natürlich, das Betriebssystem und die Zugänge so zu reglementieren, dass es nichts anderes machen kann als von mir bestimmt. Dies ist aber eine sehr naive Herangehensweise. Letztlich lernen Kinder schnell, solche Werkzeuge zu umgehen. Und ehrlich gesagt glaube ich: Wenn sie das schaffen, sind sie auch reif dafür, selbst mehr Kontrolle zu übernehmen. Das Umgehen von Beschränkungen ist ja selbst schon eine Form von Lernen – es zeigt technisches Verständnis und Problemlösungskompetenz.
+
+Es ist ein Balanceakt zwischen Schutz und Freiheit, zwischen Kontrolle und Vertrauen.
+
+## Die grösseren Fragen
+
+In der heutigen Welt muss Kindern zwar nicht mehr gezeigt werden, wie ein elektronisches Gerät zu bedienen ist – aber es gibt ganz andere Herausforderungen:
+
+- **Cybermobbing** – digitale Gewalt unter Kindern
+- **Sexting und Cyber-Grooming** – Gefahren durch Fremde im Netz
+- **Doom-Scrolling** – der Sog endloser Feeds
+- **Verifikation von Informationen** – was ist wahr, was ist erfunden?
+- **KI-generierte Inhalte** – im KI-Zeitalter wird die Unterscheidung zwischen echt und künstlich noch schwieriger
+
+Die Liste ist lang. Die Herausforderungen sind real. Und sie werden nicht weniger.
+
+Schlimmer noch: Viele Erwachsene haben weniger Medienkompetenz als ihre Sprösslinge. Sie sind sich der Konsequenzen nicht bewusst – und werden selbst zu Opfern. Wie sollen wir unseren Kindern beibringen, sich zu schützen, wenn wir selbst jeden Tag unsere Daten bereitwillig in die Hände von Konzernen legen, auf Phishing-Mails hereinfallen oder nicht verstehen, wie Algorithmen uns manipulieren?
+
+## Mein Ansatz: Begleiten statt kontrollieren
+
+Mein Ziel ist nicht, mein Kind vor allem zu schützen oder jeden Schritt zu kontrollieren. Mein Ziel ist, es zu begleiten. Ich möchte die Neugier am Umgang mit Computern fördern und helfen, selbst einen Weg zu finden, mit den Herausforderungen umzugehen.
+
+Programmieren lernen heisst nicht nur Code schreiben – es heisst, Probleme zu zerlegen, logisch zu denken, kreativ zu werden. Es heisst, zu verstehen, wie die digitalen Werkzeuge funktionieren, die unseren Alltag prägen. Und wer versteht, wie etwas funktioniert, kann auch besser einschätzen, wo Gefahren lauern.
+
+Der alte Laptop mit Linux und Pi-hole ist für mich ein Anfang. Ein geschützter Spielplatz, auf dem es erste Schritte machen kann. Aber es ist nur ein Werkzeug. Das Wichtigste ist, dass ich da bin – nicht als Aufseher, sondern als Begleiter.
+
+## Offene Fragen
+
+Trotz aller Überlegungen bleiben viele Fragen offen:
+
+- Ab wann ist ein Kind wirklich bereit für soziale Medien? Welche und was?
+- Wie viel Schutz ist zu viel, wie viel Freiheit zu früh?
+- Wie bereitet man Kinder auf Technologien vor, die sich schneller verändern, als wir sie verstehen können?
+
+Ich habe keine endgültigen Antworten. Aber ich glaube, dass der Dialog wichtig ist – mit seinem Kind, mit der Schule, mit anderen Eltern. Und dass wir als Eltern nicht perfekt sein müssen, sondern präsent.

hugo.toml

@@ -33,11 +33,21 @@ disableKinds = ['taxonomy', 'term']
       description = 'Personal website of Markus Graf'
 
 # Language-specific menus
+[[languages.de.menu.main]]
+  name = 'Blog'
+  url = '/de/blog/'
+  weight = 5
+
 [[languages.de.menu.main]]
   name = 'Lebenslauf'
   url = '/de/cv/'
   weight = 10
 
+[[languages.en.menu.main]]
+  name = 'Blog'
+  url = '/en/blog/'
+  weight = 5
+
 [[languages.en.menu.main]]
   name = 'Curriculum Vitae'
   url = '/en/cv/'

i18n/de.yaml

@@ -0,0 +1,12 @@
+month_1: "Januar"
+month_2: "Februar"
+month_3: "März"
+month_4: "April"
+month_5: "Mai"
+month_6: "Juni"
+month_7: "Juli"
+month_8: "August"
+month_9: "September"
+month_10: "Oktober"
+month_11: "November"
+month_12: "Dezember"

i18n/en.yaml

@@ -0,0 +1,12 @@
+month_1: "January"
+month_2: "February"
+month_3: "March"
+month_4: "April"
+month_5: "May"
+month_6: "June"
+month_7: "July"
+month_8: "August"
+month_9: "September"
+month_10: "October"
+month_11: "November"
+month_12: "December"

layouts/blog/list.html

@@ -0,0 +1,45 @@
+{{ define "main" }}
+<div class="container py-5">
+  <div class="row">
+    <div class="col-lg-8 mx-auto">
+      <header class="mb-5">
+        <h1>{{ .Title }}</h1>
+        {{ if .Description }}
+          <p class="lead text-muted">{{ .Description }}</p>
+        {{ end }}
+      </header>
+
+      <div class="blog-list">
+        {{ range .Pages }}
+          <article class="mb-5 pb-5 border-bottom">
+            <header class="mb-3">
+              <h2 class="h3">
+                <a href="{{ .RelPermalink }}" class="text-decoration-none">{{ .Title }}</a>
+              </h2>
+              <time datetime="{{ .Date.Format "2006-01-02" }}" class="text-muted">
+                {{ .Date.Day }}. {{ i18n (printf "month_%d" .Date.Month) }} {{ .Date.Year }}
+              </time>
+            </header>
+
+            {{ if .Description }}
+              <p class="lead">{{ .Description }}</p>
+            {{ else if .Summary }}
+              <div class="summary">
+                {{ .Summary }}
+              </div>
+            {{ end }}
+
+            <a href="{{ .RelPermalink }}" class="btn btn-outline-primary">
+              {{ if eq $.Language.Lang "de" }}
+                Weiterlesen
+              {{ else }}
+                Read more
+              {{ end }}
+            </a>
+          </article>
+        {{ end }}
+      </div>
+    </div>
+  </div>
+</div>
+{{ end }}

layouts/blog/single.html

@@ -0,0 +1,35 @@
+{{ define "main" }}
+<article class="container py-5">
+  <div class="row">
+    <div class="col-lg-8 mx-auto">
+      <header class="mb-5">
+        <h1>{{ .Title }}</h1>
+
+        <div class="text-muted mb-3">
+          <time datetime="{{ .Date.Format "2006-01-02" }}">
+            {{ .Date.Day }}. {{ i18n (printf "month_%d" .Date.Month) }} {{ .Date.Year }}
+          </time>
+        </div>
+
+        {{ if .Description }}
+          <p class="lead">{{ .Description }}</p>
+        {{ end }}
+      </header>
+
+      <div class="blog-content">
+        {{ .Content }}
+      </div>
+
+      <footer class="mt-5 pt-4 border-top">
+        <a href="{{ "/blog/" | relLangURL }}" class="btn btn-outline-secondary">
+          {{ if eq .Language.Lang "de" }}
+            ← Zurück zum Blog
+          {{ else }}
+            ← Back to Blog
+          {{ end }}
+        </a>
+      </footer>
+    </div>
+  </div>
+</article>
+{{ end }}

layouts/index.html

@@ -8,6 +8,39 @@
           {{ .Content }}
         </div>
       </article>
+
+      {{/* Recent blog posts section */}}
+      {{ $blogPages := where .Site.RegularPages "Section" "blog" }}
+      {{ $blogPages = where $blogPages ".Lang" .Language.Lang }}
+      {{ $recentPosts := first 3 $blogPages }}
+      {{ if $recentPosts }}
+      <section class="mt-5 mb-5">
+        <h2 class="h3 mb-4">
+          {{ if eq .Language.Lang "de" }}
+            Neueste Beiträge
+          {{ else }}
+            Recent Posts
+          {{ end }}
+        </h2>
+        <ul class="list-unstyled">
+          {{ range $recentPosts }}
+          <li class="mb-3">
+            <a href="{{ .RelPermalink }}" class="text-decoration-none">
+              <strong>{{ .Title }}</strong>
+            </a>
+            <br>
+            <time datetime="{{ .Date.Format "2006-01-02" }}" class="text-muted small">
+              {{ if eq $.Language.Lang "de" }}
+                {{ .Date.Day }}. {{ i18n (printf "month_%d" .Date.Month) }} {{ .Date.Year }}
+              {{ else }}
+                {{ i18n (printf "month_%d" .Date.Month) }} {{ .Date.Day }}, {{ .Date.Year }}
+              {{ end }}
+            </time>
+          </li>
+          {{ end }}
+        </ul>
+      </section>
+      {{ end }}
     </div>
   </div>
 </div>

openspec/changes/add-ubuntu-kids-article/proposal.md

@@ -0,0 +1,53 @@
+# Proposal: Add Ubuntu for Kids Blog Post
+
+## Context
+
+Create a new bilingual blog post based on Notion content about setting up a child's first computer with Ubuntu and Pi-hole. The post reflects on digital media literacy, open source philosophy, and finding the balance between protection and freedom in the digital age.
+
+## Motivation
+
+This blog post:
+- Shares a practical approach to introducing children to computers with Linux
+- Explores the philosophical aspects of open source vs. proprietary software
+- Addresses real parenting challenges around digital media literacy
+- Discusses cyberbullying, doom-scrolling, AI content verification, and other modern challenges
+- Provides both German and English versions for broader reach
+
+## Scope
+
+### In Scope
+- Create new blog post page bundle with German directory `content/blog/ubuntu-fuer-kinder/`
+- Create new blog post page bundle with English directory `content/blog/ubuntu-for-kids/`
+- German version (original from Notion)
+- English version (translated)
+- Proper frontmatter with title, date, description, translationKey
+- All formatting and structure preserved
+- Validation that post renders correctly in Hugo
+
+### Out of Scope
+- No changes to existing blog posts
+- No template or layout modifications
+- No Hugo configuration changes
+- No new images or assets
+
+## Dependencies
+
+None. This is a new content addition that doesn't affect existing functionality.
+
+## Risks
+
+Low risk. Adding new content only, no structural changes.
+
+## Success Criteria
+
+- Blog post exists in both German and English with translated URL slugs
+- Content accurately reflects Notion source
+- English translation is natural and maintains meaning
+- Hugo builds successfully
+- Post displays correctly in both languages
+- Language switcher works between versions
+- OpenSpec validation passes
+
+## Related Changes
+
+Similar to 2025-11-25-add-dialogbasierte-anwendungen-post.

openspec/changes/add-ubuntu-kids-article/specs/blog-content/spec.md

@@ -0,0 +1,151 @@
+# Spec: Blog Post - Ubuntu for Kids
+
+## Overview
+
+Specification for the bilingual blog post about setting up a child's first computer with Ubuntu and Pi-hole. Uses translated URL slugs with separate directories linked via translationKey.
+
+## ADDED Requirements
+
+### Requirement: Blog post directory structure with translated slugs
+
+The blog post MUST exist in separate directories for German and English with appropriate URL slugs.
+
+**Rationale**: Using translated slugs provides better SEO and user experience, with language-appropriate URLs.
+
+#### Scenario: Directories created with translated slugs
+
+**Given** the Hugo content directory structure
+**When** creating the new blog post
+**Then** a directory `content/blog/ubuntu-fuer-kinder/` must exist for German
+**And** a directory `content/blog/ubuntu-for-kids/` must exist for English
+**And** German directory must contain `index.de.md`
+**And** English directory must contain `index.en.md`
+**And** both files must include `translationKey: "ubuntu-fuer-kinder-post"` in frontmatter
+
+---
+
+### Requirement: German blog post content
+
+The German version MUST accurately represent the Notion source content.
+
+**Rationale**: Preserve the original German text exactly as written by the author.
+
+#### Scenario: German content matches Notion source
+
+**Given** the Notion page content at https://www.notion.so/a46ea17cfebb45f6bb0c1d4d516a5d66
+**When** creating the German blog post file
+**Then** the content must match the Notion source text
+**And** all formatting (headings, lists, emphasis) must be preserved
+**And** all sections must be included (TL;DR, technical solution, Linux philosophy, etc.)
+
+#### Scenario: German frontmatter is correct
+
+**Given** the blog post requirements
+**When** creating the German blog post
+**Then** the frontmatter must use YAML format (three dashes)
+**And** must include `title: "Ein alter Laptop, Linux und Pi-hole: Digitale Medienkompetenz fuer Kinder"`
+**And** must include `date: 2026-01-19`
+**And** must include `translationKey: "ubuntu-fuer-kinder-post"`
+**And** must include a `description` field with appropriate summary text
+**And** must be valid YAML syntax
+
+---
+
+### Requirement: English blog post translation
+
+The English version MUST be a natural, accurate translation of the German content.
+
+**Rationale**: Make the content accessible to English-speaking readers while maintaining technical accuracy and readability.
+
+#### Scenario: English translation is natural and accurate
+
+**Given** the German blog post content
+**When** creating the English translation
+**Then** the translation must convey the same meaning as the German original
+**And** must use natural English phrasing and idioms
+**And** must maintain technical accuracy for all concepts (Ubuntu, Pi-hole, DNS)
+**And** must preserve the same structure (sections, lists)
+
+#### Scenario: English frontmatter is correct
+
+**Given** the blog post requirements
+**When** creating the English blog post
+**Then** the frontmatter must use YAML format (three dashes)
+**And** must include `title` with natural English translation
+**And** must include `date: 2026-01-19` (same as German)
+**And** must include `translationKey: "ubuntu-fuer-kinder-post"`
+**And** must include a `description` field with English summary
+**And** must be valid YAML syntax
+
+---
+
+### Requirement: Content sections
+
+Both versions MUST include all main content sections from the source.
+
+**Rationale**: Preserve the complete narrative and arguments of the original post.
+
+#### Scenario: All sections are present
+
+**Given** the blog post content
+**When** creating the blog post files
+**Then** must include a TL;DR summary section
+**And** must include "Die technische Loesung" / "The Technical Solution" section
+**And** must include "Warum Linux?" / "Why Linux?" section
+**And** must include "Das Dilemma" / "The Dilemma" section
+**And** must include "Die groesseren Fragen" / "The Bigger Questions" section
+**And** must include "Mein Ansatz" / "My Approach" section
+**And** must include "Offene Fragen" / "Open Questions" section
+
+---
+
+### Requirement: Hugo build compatibility
+
+The blog posts MUST build successfully with Hugo and render correctly.
+
+**Rationale**: Ensure the content integrates properly with the existing Hugo site.
+
+#### Scenario: Hugo builds successfully
+
+**Given** the new blog post files
+**When** running `hugo build`
+**Then** the build must complete without errors
+**And** no warnings related to the new blog post must be generated
+
+#### Scenario: Blog posts are accessible at correct translated URLs
+
+**Given** a successful Hugo build
+**When** viewing the site
+**Then** the German version must be accessible at `/de/blog/ubuntu-fuer-kinder/`
+**And** the English version must be accessible at `/en/blog/ubuntu-for-kids/`
+
+#### Scenario: Blog posts appear in blog listings
+
+**Given** a successful Hugo build
+**When** viewing the blog index pages
+**Then** the new post must appear in the German blog listing at `/de/blog/`
+**And** the new post must appear in the English blog listing at `/en/blog/`
+**And** the post must display with correct title and description
+
+#### Scenario: Language switcher works correctly
+
+**Given** both language versions with matching translationKey
+**When** viewing either version of the blog post
+**Then** the language switcher must link to the corresponding translation
+**And** switching from German to English must navigate to `/en/blog/ubuntu-for-kids/`
+**And** switching from English to German must navigate to `/de/blog/ubuntu-fuer-kinder/`
+
+---
+
+### Requirement: Content validation
+
+The implementation MUST pass OpenSpec validation.
+
+**Rationale**: Ensure compliance with project standards and specification requirements.
+
+#### Scenario: OpenSpec validation passes
+
+**Given** the completed implementation
+**When** running `openspec validate add-ubuntu-kids-article --strict`
+**Then** validation must pass with no errors
+**And** no warnings should be generated

openspec/changes/add-ubuntu-kids-article/tasks.md

@@ -0,0 +1,38 @@
+# Tasks: Add Ubuntu for Kids Blog Post
+
+## Implementation Tasks
+
+1. **Create blog post directory structure**
+   - Create `content/blog/ubuntu-fuer-kinder/` directory for German
+   - Create `content/blog/ubuntu-for-kids/` directory for English
+   - Set up page bundles for bilingual content with translationKey linking
+
+2. **Create German blog post**
+   - Create `content/blog/ubuntu-fuer-kinder/index.de.md`
+   - Add YAML frontmatter with title, date, description, translationKey
+   - Transfer content from Notion source
+   - Preserve all formatting, structure, and sections
+   - Verify markdown rendering
+
+3. **Create English blog post**
+   - Create `content/blog/ubuntu-for-kids/index.en.md`
+   - Add YAML frontmatter with translated title, date, description, translationKey
+   - Create natural English translation maintaining technical accuracy
+   - Adapt terminology appropriately for English readers
+   - Verify markdown rendering
+
+4. **Validate implementation**
+   - Run `openspec validate add-ubuntu-kids-article --strict`
+   - Resolve any validation issues
+
+5. **Test Hugo build**
+   - Run `hugo server`
+   - Verify no build errors
+   - Check both German and English versions render correctly
+   - Verify language switcher works between versions
+   - Test responsive layout
+
+6. **Review and commit**
+   - Review generated content
+   - Create git commit with conventional commit message
+   - Ready for user review before merging to main

openspec/changes/archive/2025-10-31-add-blog-section/proposal.md

@@ -0,0 +1,57 @@
+# Add Blog Section
+
+## Problem
+The website currently lacks a blog section for publishing articles and sharing knowledge. There is existing content (article "KI Generierte Website - ein Praxisbeispiel" in Notion) ready to be published, but no structure to support blog posts.
+
+## Proposed Solution
+Add a blog section to the Hugo site that:
+- Provides a dedicated blog listing page showing all published articles
+- Supports individual blog post pages with proper formatting
+- Maintains multilingual support (German/English) consistent with the rest of the site
+- Includes navigation links to access the blog
+- Uses Hugo's content organization and templating for maintainability
+
+The first article to be published will be "KI Generierte Website - ein Praxisbeispiel" (available in Notion), which discusses the experience of building this website using AI-assisted development with OpenSpec.
+
+## Scope
+**In Scope:**
+- Blog list page template (showing all blog posts)
+- Blog post single page template
+- Blog content structure in Hugo
+- Navigation menu integration for blog
+- First blog post: "KI Generierte Website - ein Praxisbeispiel" (German version)
+- Multilingual support for blog posts
+
+**Out of Scope:**
+- Taxonomies/categories/tags (site currently has these disabled)
+- Comments system
+- RSS feed (can be added later if needed)
+- Search functionality
+- Blog post pagination (can be added when needed)
+
+## Success Criteria
+- Blog section is accessible from main navigation
+- Blog listing page shows published articles with title, date, and excerpt
+- Individual blog posts display with proper formatting and styling
+- First article "KI Generierte Website - ein Praxisbeispiel" is published in German
+- Blog supports both German and English content structure (even if English translation comes later)
+- Blog pages follow site's responsive design and accessibility standards
+- Lighthouse score remains >90
+
+## Dependencies
+- Existing Hugo site infrastructure (already in place)
+- Internationalization system (already implemented)
+- Bootstrap styling (already in place)
+
+## Risks & Mitigations
+**Risk:** Blog content structure might conflict with existing content organization
+**Mitigation:** Use Hugo sections (`content/blog/`) which is the standard Hugo pattern
+
+**Risk:** Blog post styling might need specific customization beyond current templates
+**Mitigation:** Start with minimal styling, iterate based on actual needs
+
+## Timeline Estimate
+Small change, estimated 2-3 hours of implementation work:
+- Blog templates: 1 hour
+- Content structure and first article: 1 hour
+- Testing and refinement: 30-60 minutes

openspec/changes/archive/2025-10-31-add-blog-section/specs/blog-content/spec.md

@@ -0,0 +1,81 @@
+# Blog Content Structure
+
+## ADDED Requirements
+
+### Requirement: Blog Section Organization
+Blog posts SHALL be organized in a dedicated `content/blog/` directory following Hugo's content organization conventions.
+
+#### Scenario: Blog section exists in content directory
+**Given** the Hugo site structure
+**When** examining the content directory
+**Then** a `content/blog/` directory SHALL exist
+**And** section index files `_index.de.md` and `_index.en.md` SHALL exist in `content/blog/`
+**And** these index files SHALL contain appropriate front matter (title, description)
+
+#### Scenario: Blog posts use page bundles
+**Given** a blog post to be published
+**When** adding the post to the site
+**Then** the post SHALL be organized as a page bundle (directory with `index.de.md` or `index.en.md`)
+**And** the bundle directory name SHALL be URL-friendly (lowercase, hyphens, no special characters)
+**And** any post-specific assets (images, files) CAN be stored within the bundle directory
+
+---
+
+### Requirement: Blog Post Front Matter
+Each blog post SHALL include properly structured front matter with essential metadata.
+
+#### Scenario: Blog post front matter is complete
+**Given** a blog post markdown file
+**When** the post is processed by Hugo
+**Then** the front matter SHALL include a `title` field
+**And** the front matter SHALL include a `date` field in ISO 8601 format (YYYY-MM-DD)
+**And** the front matter MAY include a `description` or `summary` field for excerpts
+**And** the front matter MAY include a `draft` field to control publication status
+
+#### Scenario: First blog post is ready
+**Given** the Notion article "KI Generierte Website - ein Praxisbeispiel"
+**When** converting it to Hugo format
+**Then** a blog post SHALL exist at `content/blog/ki-generierte-website-praxisbeispiel/index.de.md`
+**And** the post SHALL contain the full article content from Notion
+**And** the front matter SHALL include title "KI Generierte Website - ein Praxisbeispiel"
+**And** the front matter SHALL include an appropriate publication date
+
+---
+
+### Requirement: Multilingual Blog Support
+Blog content SHALL support both German and English following the site's internationalization pattern.
+
+#### Scenario: Blog section metadata is multilingual
+**Given** the blog section
+**When** accessing the blog in different languages
+**Then** `content/blog/_index.de.md` SHALL exist with German metadata
+**And** `content/blog/_index.en.md` SHALL exist with English metadata
+**And** both SHALL have appropriate translated titles and descriptions
+
+#### Scenario: Blog posts can exist in multiple languages
+**Given** a blog post
+**When** translations are available
+**Then** the post MAY have both `index.de.md` and `index.en.md` in the same bundle
+**And** Hugo SHALL serve the appropriate language version based on the URL path
+**And** language switching SHALL work between translated blog posts
+
+---
+
+### Requirement: Content Formatting
+Blog post content SHALL be written in Markdown with proper formatting support.
+
+#### Scenario: Markdown content renders correctly
+**Given** a blog post with Markdown content
+**When** Hugo processes the post
+**Then** headings (H1-H6) SHALL be rendered correctly
+**And** paragraphs, lists, and emphasis SHALL be formatted properly
+**And** code blocks with syntax highlighting SHALL be supported
+**And** links and images SHALL be rendered correctly
+**And** HTML content SHALL be allowed (Hugo's unsafe renderer is enabled in config)
+
+#### Scenario: Special characters and formatting are preserved
+**Given** blog post content with German special characters (ä, ö, ü, ß)
+**When** the post is rendered
+**Then** all special characters SHALL display correctly
+**And** quotation marks and em dashes SHALL be preserved
+**And** UTF-8 encoding SHALL be maintained throughout

openspec/changes/archive/2025-10-31-add-blog-section/specs/blog-templates/spec.md

@@ -0,0 +1,122 @@
+# Blog Templates
+
+## ADDED Requirements
+
+### Requirement: Blog List Template
+A blog list template SHALL display all published blog posts in a organized, user-friendly format.
+
+#### Scenario: Blog list page renders with posts
+**Given** published blog posts exist in `content/blog/`
+**When** a user navigates to `/de/blog/` or `/en/blog/`
+**Then** a blog list page SHALL be rendered using `layouts/blog/list.html`
+**And** the page SHALL display all non-draft blog posts
+**And** posts SHALL be sorted by date (most recent first)
+
+#### Scenario: Blog list shows post metadata
+**Given** the blog list page
+**When** displaying each blog post entry
+**Then** each entry SHALL show the post title as a link to the full post
+**And** each entry SHALL show the publication date
+**And** each entry MAY show a summary or excerpt of the post
+**And** the title link SHALL navigate to the full blog post page
+
+#### Scenario: Blog list is responsive
+**Given** the blog list page
+**When** viewed on different screen sizes
+**Then** the layout SHALL be responsive using Bootstrap grid
+**And** the page SHALL be readable on mobile devices (≥320px width)
+**And** the page SHALL adapt to tablet and desktop viewports
+**And** spacing and typography SHALL remain consistent with site design
+
+---
+
+### Requirement: Blog Post Single Template
+Individual blog posts SHALL be displayed with a dedicated single post template providing optimal reading experience.
+
+#### Scenario: Blog post page renders content
+**Given** a blog post at `content/blog/ki-generierte-website-praxisbeispiel/index.de.md`
+**When** a user navigates to `/de/blog/ki-generierte-website-praxisbeispiel/`
+**Then** the post SHALL be rendered using `layouts/blog/single.html`
+**And** the page SHALL display the post title as the main heading (H1)
+**And** the page SHALL display the publication date
+**And** the page SHALL display the full post content with proper formatting
+
+#### Scenario: Blog post content is readable
+**Given** a rendered blog post
+**When** viewing the post content
+**Then** headings SHALL use appropriate hierarchy (H2, H3, etc. for sections)
+**And** paragraphs SHALL have readable line height and spacing
+**And** code blocks SHALL be distinguishable with appropriate styling
+**And** links SHALL be clearly identifiable and accessible
+**And** images SHALL be responsive and properly sized
+
+#### Scenario: Blog post has navigation
+**Given** a blog post page
+**When** a user finishes reading
+**Then** the page SHALL include a link back to the blog list
+**And** the navigation link SHALL be clearly visible
+**And** the site's main navigation SHALL remain accessible
+
+---
+
+### Requirement: Blog Navigation Integration
+The blog section SHALL be accessible through the site's main navigation.
+
+#### Scenario: Blog link in main navigation
+**Given** the site configuration
+**When** rendering the main navigation menu
+**Then** a "Blog" link SHALL appear in the navigation for German pages
+**And** a "Blog" link SHALL appear in the navigation for English pages
+**And** the link SHALL point to `/de/blog/` for German
+**And** the link SHALL point to `/en/blog/` for English
+
+#### Scenario: Active state for blog pages
+**Given** a user is on a blog page (list or single post)
+**When** viewing the navigation menu
+**Then** the "Blog" link SHALL have an active state indicator
+**And** the active state SHALL use the same styling as other active navigation items
+**And** the active state SHALL be maintained on both blog list and single post pages
+
+---
+
+### Requirement: Blog Template Semantic HTML
+Blog templates SHALL use semantic HTML5 elements for accessibility and SEO.
+
+#### Scenario: Blog list uses semantic structure
+**Given** the blog list template
+**When** rendering the page
+**Then** the main content SHALL be wrapped in a `<main>` element
+**And** individual blog post entries SHALL use `<article>` elements
+**And** post metadata SHALL use appropriate semantic tags (e.g., `<time>` for dates)
+**And** heading hierarchy SHALL be logical and sequential
+
+#### Scenario: Blog post uses article structure
+**Given** a blog post template
+**When** rendering the page
+**Then** the post SHALL be wrapped in an `<article>` element
+**And** the post SHALL have a `<header>` with title and metadata
+**And** the post content SHALL be in a `<div>` or `<section>` with clear semantic structure
+**And** all headings SHALL follow proper hierarchy
+
+---
+
+### Requirement: Blog Styling Consistency
+Blog templates SHALL maintain visual consistency with the rest of the site.
+
+#### Scenario: Blog pages use site styling
+**Given** any blog page (list or single)
+**When** the page is rendered
+**Then** the page SHALL use the site's base layout (`baseof.html`)
+**And** the page SHALL include the site's header and footer partials
+**And** the page SHALL use Bootstrap classes for styling
+**And** typography SHALL be consistent with other site pages
+**And** color scheme SHALL match the site's design
+
+#### Scenario: Blog pages are accessible
+**Given** any blog page
+**When** evaluated for accessibility
+**Then** the page SHALL meet WCAG 2.1 AA standards
+**And** all interactive elements SHALL be keyboard accessible
+**And** color contrast ratios SHALL meet minimum requirements
+**And** images SHALL have appropriate alt text (if any)
+**And** the page SHALL have appropriate semantic structure for screen readers

openspec/changes/archive/2025-10-31-add-blog-section/tasks.md

@@ -0,0 +1,88 @@
+# Tasks for add-blog-section
+
+## Implementation Tasks
+
+### 1. Create blog content structure
+- [x] Create `content/blog/` directory for German blog posts
+- [x] Create `content/blog/_index.de.md` for German blog section metadata
+- [x] Create `content/blog/_index.en.md` for English blog section metadata
+- [x] Convert Notion article "KI Generierte Website - ein Praxisbeispiel" to Markdown format
+- [x] Create `content/blog/ki-generierte-website-praxisbeispiel/index.de.md` with article content
+- [x] Add proper front matter (title, date, description) to blog post
+
+**Validation:** Files exist in correct locations, front matter is properly formatted
+
+**Dependencies:** None
+
+**Parallelizable:** Can be done independently
+
+---
+
+### 2. Create blog list template
+- [x] Create `layouts/blog/list.html` template for blog listing page
+- [x] Display blog post titles, dates, and excerpts/summaries
+- [x] Add proper semantic HTML structure
+- [x] Apply Bootstrap styling for consistent look
+- [x] Ensure responsive design (mobile-first)
+- [x] Add pagination structure (even if not needed yet, for future)
+
+**Validation:** Running `hugo server` shows blog list page at `/de/blog/` with article listed
+
+**Dependencies:** Task 1 (content structure)
+
+**Parallelizable:** No (requires content structure)
+
+---
+
+### 3. Create blog post single template
+- [x] Create `layouts/blog/single.html` template for individual blog posts
+- [x] Display post title, date, and full content
+- [x] Add article metadata (author, date, reading time if desired)
+- [x] Style content appropriately (headings, paragraphs, code blocks, etc.)
+- [x] Ensure responsive design
+- [x] Add navigation back to blog list
+
+**Validation:** Blog post accessible at `/de/blog/ki-generierte-website-praxisbeispiel/` with proper formatting
+
+**Dependencies:** Task 1 (content structure)
+
+**Parallelizable:** Can be done in parallel with Task 2
+
+---
+
+### 4. Add blog navigation
+- [x] Add "Blog" link to navigation menu (German: "Blog", English: "Blog")
+- [x] Update `hugo.toml` with blog menu items for both languages
+- [x] Verify navigation links work correctly
+- [x] Ensure active state highlighting works on blog pages
+
+**Validation:** Blog link appears in navigation, clicking it navigates to blog list page
+
+**Dependencies:** Tasks 1, 2 (blog structure and list page)
+
+**Parallelizable:** No (requires blog pages to exist)
+
+---
+
+### 5. Verify and test
+- [x] Build site with `hugo` command (no errors)
+- [x] Test blog list page rendering
+- [x] Test blog post page rendering
+- [x] Verify multilingual structure (German blog accessible, English structure ready)
+- [x] Test navigation and links
+- [x] Verify responsive design on mobile/tablet/desktop viewports
+- [ ] Run Lighthouse audit (score should remain >90)
+- [ ] Check accessibility (WCAG 2.1 AA compliance)
+
+**Validation:** All tests pass, site builds successfully, Lighthouse score >90
+
+**Dependencies:** All previous tasks
+
+**Parallelizable:** No (final verification step)
+
+---
+
+## Implementation Order
+Tasks should be completed in sequence: 1 → 2, 3 (parallel) → 4 → 5
+
+Total estimated time: 2-3 hours

openspec/changes/archive/2025-10-31-homepage-recent-posts/proposal.md

@@ -0,0 +1,43 @@
+# Proposal: Display Recent Blog Posts on Homepage
+
+## Problem
+When visitors land on the homepage, they need to navigate to the blog section through an additional click to discover recent content. This creates an unnecessary friction point and reduces content discoverability.
+
+## Solution
+Display the 3 most recent blog posts directly on the homepage, right after the user's description section. The posts will be shown as a simple list containing:
+- Post title (linked to the full post)
+- Publication date
+
+This provides immediate visibility of recent content without cluttering the homepage design.
+
+## Scope
+
+### In Scope
+- Modify homepage template to query and display 3 most recent blog posts
+- Display posts as a simple list with title and date
+- Ensure multilingual support (German/English)
+- Maintain responsive design and Bootstrap styling consistency
+
+### Out of Scope
+- Post descriptions or summaries (only title and date)
+- Post thumbnails or images
+- Pagination or "view all" functionality beyond existing blog navigation
+- Filtering or categorization
+
+## Success Criteria
+- Homepage displays exactly 3 most recent blog posts after the description section
+- Posts are displayed in both German and English versions of the homepage
+- Clicking a post title navigates to the full blog post
+- Design is consistent with existing site styling
+- Layout remains responsive on all device sizes
+- Hugo build completes without errors
+
+## Dependencies
+- Existing blog section (already implemented)
+- Homepage template (layouts/index.html)
+- Blog content structure
+
+## Impact
+- Improved content discoverability
+- Reduced friction for visitors discovering blog content
+- No breaking changes to existing functionality

openspec/changes/archive/2025-10-31-homepage-recent-posts/specs/homepage-recent-posts/spec.md

@@ -0,0 +1,87 @@
+# Spec: Homepage Recent Posts Display
+
+## ADDED Requirements
+
+### Requirement: Display Recent Blog Posts on Homepage
+The homepage MUST display the 3 most recent blog posts immediately after the user's description content section.
+
+#### Scenario: Three most recent posts are displayed
+**Given** the blog section contains 5 published posts
+**When** a visitor accesses the homepage
+**Then** exactly 3 most recent posts are displayed
+**And** posts are ordered by publication date (newest first)
+
+#### Scenario: Fewer than three posts exist
+**Given** the blog section contains only 2 published posts
+**When** a visitor accesses the homepage
+**Then** all 2 posts are displayed
+**And** no error or empty slots are shown
+
+#### Scenario: No blog posts exist
+**Given** the blog section contains no published posts
+**When** a visitor accesses the homepage
+**Then** the recent posts section is not displayed
+**And** the homepage layout remains intact
+
+### Requirement: Post Display Format
+Each displayed blog post MUST show the post title as a clickable link and the publication date.
+
+#### Scenario: Post title is clickable
+**Given** a blog post is displayed on the homepage
+**When** a visitor clicks the post title
+**Then** they are navigated to the full blog post page
+**And** the language context is preserved (German homepage → German post, English homepage → English post)
+
+#### Scenario: Publication date is formatted correctly
+**Given** a blog post with date "2025-10-30" is displayed
+**When** viewing the German homepage
+**Then** the date is formatted as "30. October 2025"
+**When** viewing the English homepage
+**Then** the date is formatted as "October 30, 2025"
+
+### Requirement: Multilingual Support
+The recent posts section MUST respect the site's multilingual configuration and display language-appropriate content.
+
+#### Scenario: German homepage shows German posts
+**Given** the visitor accesses the German homepage (/de/)
+**When** the recent posts section is rendered
+**Then** only German blog posts are displayed
+**And** the section heading is in German (e.g., "Neueste Beiträge")
+
+#### Scenario: English homepage shows English posts
+**Given** the visitor accesses the English homepage (/en/)
+**When** the recent posts section is rendered
+**Then** only English blog posts are displayed
+**And** the section heading is in English (e.g., "Recent Posts")
+
+### Requirement: Visual Design and Layout
+The recent posts section MUST maintain consistency with the existing site design and remain responsive.
+
+#### Scenario: Section styling matches site design
+**Given** the recent posts section is displayed
+**Then** it uses Bootstrap classes consistent with the rest of the site
+**And** spacing and typography match existing content sections
+**And** the section is visually distinct from the description section above
+
+#### Scenario: Responsive layout on mobile devices
+**Given** the homepage is viewed on a mobile device (< 768px width)
+**When** the recent posts section is displayed
+**Then** the layout remains readable and properly formatted
+**And** no horizontal scrolling is required
+**And** links are easily tappable
+
+### Requirement: Performance and Build
+The implementation MUST not negatively impact Hugo build performance or site load times.
+
+#### Scenario: Hugo build completes successfully
+**Given** the homepage template includes recent posts query
+**When** running `hugo build`
+**Then** the build completes without errors or warnings
+**And** the homepage HTML is generated correctly for both languages
+
+#### Scenario: Site performance remains optimal
+**Given** the homepage includes recent posts section
+**When** measuring page load performance
+**Then** Lighthouse performance score remains >90
+**And** no additional HTTP requests are made
+**And** HTML file size increase is minimal (< 2KB)

openspec/changes/archive/2025-10-31-homepage-recent-posts/tasks.md

@@ -0,0 +1,78 @@
+# Tasks: Display Recent Blog Posts on Homepage
+
+## Implementation Tasks
+
+### 1. Update Homepage Template
+- [x] Modify `layouts/index.html` to query recent blog posts
+- [x] Add Hugo template logic to fetch 3 most recent posts from blog section
+- [x] Filter posts by current language context
+- [x] Sort posts by publication date (descending)
+
+**Validation:**
+- Template syntax is correct (no Hugo build errors)
+- Recent posts query respects language context
+- Exactly 3 posts are retrieved (or fewer if less exist)
+
+### 2. Implement Recent Posts Section UI
+- [x] Add semantic HTML structure for recent posts section
+- [x] Include section heading (translatable: "Neueste Beiträge" / "Recent Posts")
+- [x] Display each post as list item with title link and date
+- [x] Apply Bootstrap classes for consistent styling
+- [x] Add appropriate spacing after description section
+
+**Validation:**
+- Section heading displays correctly in both languages
+- Post titles are clickable links using `relPermalink`
+- Dates are formatted using Hugo's date formatting
+- Bootstrap classes match existing site patterns
+- Visual spacing separates description from recent posts
+
+### 3. Add Multilingual Section Headings
+- [x] Implement conditional heading based on language context
+- [x] German: "Neueste Beiträge" or "Aktuelle Artikel"
+- [x] English: "Recent Posts" or "Latest Articles"
+- [x] Use Hugo's language detection (`{{ .Language.Lang }}`)
+
+**Validation:**
+- German homepage shows German heading
+- English homepage shows English heading
+- Heading style matches other section headings on the site
+
+### 4. Test and Verify
+- [x] Build site with `hugo` command
+- [x] Verify German homepage (/de/) displays recent German posts
+- [x] Verify English homepage (/en/) displays recent English posts
+- [x] Test with different numbers of blog posts (0, 1, 2, 3, 5+)
+- [x] Check responsive layout on mobile viewport
+- [x] Verify all links navigate correctly
+
+**Validation:**
+- Hugo build completes without errors
+- Both language versions render correctly
+- Edge cases handled (0 posts, < 3 posts)
+- Links preserve language context
+- Layout is responsive and accessible
+
+### 5. Performance Check
+- [x] Measure HTML file size increase
+- [x] Verify no new HTTP requests added
+- [x] Confirm build time impact is negligible
+- [x] Optional: Run Lighthouse audit
+
+**Validation:**
+- File size increase < 2KB
+- No additional network requests
+- Build time difference < 100ms
+- Performance score remains high
+
+## Dependencies
+- Task 1 must complete before Task 2
+- Task 2 and 3 can be done in parallel or sequentially
+- Task 4 requires all implementation tasks (1-3) complete
+- Task 5 can be done after Task 4
+
+## Notes
+- Keep implementation minimal and focused on title + date only
+- Use existing blog post querying patterns if any exist in the codebase
+- Ensure null/empty checks to handle cases with no blog posts
+- Consider using Hugo's `.Site.RegularPages` or `.Site.Taxonomies` for blog queries

openspec/changes/archive/2025-11-25-add-dialogbasierte-anwendungen-post/proposal.md

@@ -0,0 +1,51 @@
+# Proposal: Add Dialogbasierte Anwendungen Blog Post
+
+## Context
+
+Create a new bilingual blog post based on Notion content about dialog-based applications and language model interactions. The post explores how modern language models enable Star Trek-like computer interactions and includes a practical experiment with a member management system.
+
+## Motivation
+
+This blog post:
+- Shares a practical exploration of dialog-based interfaces using language models
+- Documents a real-world experiment with MCP and GraphQL
+- Demonstrates the potential of conversational UI for business applications
+- Provides both German and English versions for broader reach
+
+## Scope
+
+### In Scope
+- Create new blog post page bundle under `content/blog/dialogbasierte-anwendungen/`
+- German version (original from Notion)
+- English version (AI-translated)
+- Proper frontmatter with title, date, description
+- All external links and references preserved
+- Validation that post renders correctly in Hugo
+
+### Out of Scope
+- No changes to existing blog posts
+- No template or layout modifications
+- No Hugo configuration changes
+- No new images or assets (uses external links)
+
+## Dependencies
+
+None. This is a new content addition that doesn't affect existing functionality.
+
+## Risks
+
+Low risk. Adding new content only, no structural changes.
+
+## Success Criteria
+
+- Blog post exists in both German and English
+- Content accurately reflects Notion source
+- English translation is natural and maintains meaning
+- Hugo builds successfully
+- Post displays correctly in both languages
+- All links are functional
+- OpenSpec validation passes
+
+## Related Changes
+
+None. First implementation of blog post content addition workflow.

openspec/changes/archive/2025-11-25-add-dialogbasierte-anwendungen-post/specs/blog-post-dialogbasierte-anwendungen/spec.md

@@ -0,0 +1,167 @@
+# Spec: Blog Post - Dialogbasierte Anwendungen
+
+## Overview
+
+Specification for the bilingual blog post "Computer, ..." about dialog-based applications using language models. Uses translated URL slugs with separate directories linked via translationKey.
+
+## ADDED Requirements
+
+### Requirement: Blog post directory structure with translated slugs
+
+The blog post MUST exist in separate directories for German and English with appropriate URL slugs.
+
+**Rationale**: Using translated slugs provides better SEO and user experience, with language-appropriate URLs.
+
+#### Scenario: Directories created with translated slugs
+
+**Given** the Hugo content directory structure
+**When** creating the new blog post
+**Then** a directory `content/blog/dialogbasierte-anwendungen/` must exist for German
+**And** a directory `content/blog/dialog-based-applications/` must exist for English
+**And** German directory must contain `index.de.md`
+**And** English directory must contain `index.en.md`
+**And** both files must include `translationKey: "dialogbasierte-anwendungen-post"` in frontmatter
+
+---
+
+### Requirement: German blog post content
+
+The German version MUST accurately represent the Notion source content.
+
+**Rationale**: Preserve the original German text exactly as written by the author.
+
+#### Scenario: German content matches Notion source
+
+**Given** the Notion page content at https://www.notion.so/Computer-2b5c4dc46de08053954ff3a14b171b47
+**When** creating the German blog post file
+**Then** the content must match the Notion source text
+**And** all formatting (headings, lists, emphasis) must be preserved
+**And** all external links must be preserved
+**And** the TL;DR section must be included
+**And** the Codeberg repository link must be included
+
+#### Scenario: German frontmatter is correct
+
+**Given** the blog post requirements
+**When** creating the German blog post
+**Then** the frontmatter must use YAML format (three dashes)
+**And** must include `title: "Computer, …"`
+**And** must include `date: 2025-11-25`
+**And** must include `translationKey: "dialogbasierte-anwendungen-post"`
+**And** must include a `description` field with appropriate summary text
+**And** must be valid YAML syntax
+
+---
+
+### Requirement: English blog post translation
+
+The English version MUST be a natural, accurate translation of the German content.
+
+**Rationale**: Make the content accessible to English-speaking readers while maintaining technical accuracy and readability.
+
+#### Scenario: English translation is natural and accurate
+
+**Given** the German blog post content
+**When** creating the English translation
+**Then** the translation must convey the same meaning as the German original
+**And** must use natural English phrasing and idioms
+**And** must maintain technical accuracy for all concepts
+**And** must preserve the same structure (sections, lists)
+**And** Star Trek references must be preserved (universally known)
+
+#### Scenario: English frontmatter is correct
+
+**Given** the blog post requirements
+**When** creating the English blog post
+**Then** the frontmatter must use YAML format (three dashes)
+**And** must include `title` with natural English translation
+**And** must include `date: 2025-11-25` (same as German)
+**And** must include `translationKey: "dialogbasierte-anwendungen-post"`
+**And** must include a `description` field with English summary
+**And** must be valid YAML syntax
+
+#### Scenario: External links are adapted appropriately
+
+**Given** external reference links in the German version
+**When** creating the English translation
+**Then** Wikipedia links should point to English Wikipedia versions where applicable
+**And** code repository links (Codeberg) must remain unchanged
+**And** all links must be functional
+
+---
+
+### Requirement: Content formatting and structure
+
+Both versions MUST use proper markdown formatting consistent with Hugo blog posts.
+
+**Rationale**: Ensure consistent rendering and readability across the blog.
+
+#### Scenario: Markdown structure is correct
+
+**Given** the blog post content
+**When** creating the blog post files
+**Then** headings must use proper markdown hierarchy (##, ###)
+**And** lists must use proper markdown syntax
+**And** links must use markdown link syntax `[text](url)`
+**And** emphasis must use proper markdown (*italic*, **bold**)
+**And** code references must use inline code backticks where appropriate
+
+#### Scenario: Special characters are handled correctly
+
+**Given** the blog post contains German umlauts and special characters
+**When** creating the blog post files
+**Then** files must be saved with UTF-8 encoding
+**And** all special characters must render correctly (ä, ö, ü, ß, …)
+
+---
+
+### Requirement: Hugo build compatibility
+
+The blog posts MUST build successfully with Hugo and render correctly.
+
+**Rationale**: Ensure the content integrates properly with the existing Hugo site.
+
+#### Scenario: Hugo builds successfully
+
+**Given** the new blog post files
+**When** running `hugo build`
+**Then** the build must complete without errors
+**And** no warnings related to the new blog post must be generated
+
+#### Scenario: Blog posts are accessible at correct translated URLs
+
+**Given** a successful Hugo build
+**When** viewing the site
+**Then** the German version must be accessible at `/de/blog/dialogbasierte-anwendungen/`
+**And** the English version must be accessible at `/en/blog/dialog-based-applications/`
+
+#### Scenario: Blog posts appear in blog listings
+
+**Given** a successful Hugo build
+**When** viewing the blog index pages
+**Then** the new post must appear in the German blog listing at `/de/blog/`
+**And** the new post must appear in the English blog listing at `/en/blog/`
+**And** the post must display with correct title and description
+
+#### Scenario: Language switcher works correctly
+
+**Given** both language versions with matching translationKey
+**When** viewing either version of the blog post
+**Then** the language switcher must link to the corresponding translation
+**And** switching from German to English must navigate to `/en/blog/dialog-based-applications/`
+**And** switching from English to German must navigate to `/de/blog/dialogbasierte-anwendungen/`
+
+---
+
+### Requirement: Content validation
+
+The implementation MUST pass OpenSpec validation.
+
+**Rationale**: Ensure compliance with project standards and specification requirements.
+
+#### Scenario: OpenSpec validation passes
+
+**Given** the completed implementation
+**When** running `openspec validate add-dialogbasierte-anwendungen-post --strict`
+**Then** validation must pass with no errors
+**And** no warnings should be generated

openspec/changes/archive/2025-11-25-add-dialogbasierte-anwendungen-post/tasks.md

@@ -0,0 +1,36 @@
+# Tasks: Add Dialogbasierte Anwendungen Blog Post
+
+## Implementation Tasks
+
+1. **Create blog post directory structure**
+   - Create `content/blog/dialogbasierte-anwendungen/` directory
+   - Set up page bundle for bilingual content
+
+2. **Create German blog post**
+   - Create `content/blog/dialogbasierte-anwendungen/index.de.md`
+   - Add YAML frontmatter with title, date, description
+   - Transfer content from Notion source
+   - Preserve all formatting, links, and structure
+   - Verify markdown rendering
+
+3. **Create English blog post**
+   - Create `content/blog/dialogbasierte-anwendungen/index.en.md`
+   - Add YAML frontmatter with translated title, date, description
+   - Create natural English translation maintaining technical accuracy
+   - Adapt Wikipedia links to English versions where applicable
+   - Verify markdown rendering
+
+4. **Validate implementation**
+   - Run `openspec validate add-dialogbasierte-anwendungen-post --strict`
+   - Resolve any validation issues
+
+5. **Test Hugo build**
+   - Run `hugo build`
+   - Verify no build errors
+   - Check both German and English versions render correctly
+   - Verify all links are functional
+
+6. **Review and commit**
+   - Review generated content
+   - Create git commit with conventional commit message
+   - Ready for user review before merging to main

openspec/specs/blog-content/spec.md

@@ -0,0 +1,83 @@
+# blog-content Specification
+
+## Purpose
+TBD - created by archiving change add-blog-section. Update Purpose after archive.
+## Requirements
+### Requirement: Blog Section Organization
+Blog posts SHALL be organized in a dedicated `content/blog/` directory following Hugo's content organization conventions.
+
+#### Scenario: Blog section exists in content directory
+**Given** the Hugo site structure
+**When** examining the content directory
+**Then** a `content/blog/` directory SHALL exist
+**And** section index files `_index.de.md` and `_index.en.md` SHALL exist in `content/blog/`
+**And** these index files SHALL contain appropriate front matter (title, description)
+
+#### Scenario: Blog posts use page bundles
+**Given** a blog post to be published
+**When** adding the post to the site
+**Then** the post SHALL be organized as a page bundle (directory with `index.de.md` or `index.en.md`)
+**And** the bundle directory name SHALL be URL-friendly (lowercase, hyphens, no special characters)
+**And** any post-specific assets (images, files) CAN be stored within the bundle directory
+
+---
+
+### Requirement: Blog Post Front Matter
+Each blog post SHALL include properly structured front matter with essential metadata.
+
+#### Scenario: Blog post front matter is complete
+**Given** a blog post markdown file
+**When** the post is processed by Hugo
+**Then** the front matter SHALL include a `title` field
+**And** the front matter SHALL include a `date` field in ISO 8601 format (YYYY-MM-DD)
+**And** the front matter MAY include a `description` or `summary` field for excerpts
+**And** the front matter MAY include a `draft` field to control publication status
+
+#### Scenario: First blog post is ready
+**Given** the Notion article "KI Generierte Website - ein Praxisbeispiel"
+**When** converting it to Hugo format
+**Then** a blog post SHALL exist at `content/blog/ki-generierte-website-praxisbeispiel/index.de.md`
+**And** the post SHALL contain the full article content from Notion
+**And** the front matter SHALL include title "KI Generierte Website - ein Praxisbeispiel"
+**And** the front matter SHALL include an appropriate publication date
+
+---
+
+### Requirement: Multilingual Blog Support
+Blog content SHALL support both German and English following the site's internationalization pattern.
+
+#### Scenario: Blog section metadata is multilingual
+**Given** the blog section
+**When** accessing the blog in different languages
+**Then** `content/blog/_index.de.md` SHALL exist with German metadata
+**And** `content/blog/_index.en.md` SHALL exist with English metadata
+**And** both SHALL have appropriate translated titles and descriptions
+
+#### Scenario: Blog posts can exist in multiple languages
+**Given** a blog post
+**When** translations are available
+**Then** the post MAY have both `index.de.md` and `index.en.md` in the same bundle
+**And** Hugo SHALL serve the appropriate language version based on the URL path
+**And** language switching SHALL work between translated blog posts
+
+---
+
+### Requirement: Content Formatting
+Blog post content SHALL be written in Markdown with proper formatting support.
+
+#### Scenario: Markdown content renders correctly
+**Given** a blog post with Markdown content
+**When** Hugo processes the post
+**Then** headings (H1-H6) SHALL be rendered correctly
+**And** paragraphs, lists, and emphasis SHALL be formatted properly
+**And** code blocks with syntax highlighting SHALL be supported
+**And** links and images SHALL be rendered correctly
+**And** HTML content SHALL be allowed (Hugo's unsafe renderer is enabled in config)
+
+#### Scenario: Special characters and formatting are preserved
+**Given** blog post content with German special characters (ä, ö, ü, ß)
+**When** the post is rendered
+**Then** all special characters SHALL display correctly
+**And** quotation marks and em dashes SHALL be preserved
+**And** UTF-8 encoding SHALL be maintained throughout
+

openspec/specs/blog-templates/spec.md

@@ -0,0 +1,124 @@
+# blog-templates Specification
+
+## Purpose
+TBD - created by archiving change add-blog-section. Update Purpose after archive.
+## Requirements
+### Requirement: Blog List Template
+A blog list template SHALL display all published blog posts in a organized, user-friendly format.
+
+#### Scenario: Blog list page renders with posts
+**Given** published blog posts exist in `content/blog/`
+**When** a user navigates to `/de/blog/` or `/en/blog/`
+**Then** a blog list page SHALL be rendered using `layouts/blog/list.html`
+**And** the page SHALL display all non-draft blog posts
+**And** posts SHALL be sorted by date (most recent first)
+
+#### Scenario: Blog list shows post metadata
+**Given** the blog list page
+**When** displaying each blog post entry
+**Then** each entry SHALL show the post title as a link to the full post
+**And** each entry SHALL show the publication date
+**And** each entry MAY show a summary or excerpt of the post
+**And** the title link SHALL navigate to the full blog post page
+
+#### Scenario: Blog list is responsive
+**Given** the blog list page
+**When** viewed on different screen sizes
+**Then** the layout SHALL be responsive using Bootstrap grid
+**And** the page SHALL be readable on mobile devices (≥320px width)
+**And** the page SHALL adapt to tablet and desktop viewports
+**And** spacing and typography SHALL remain consistent with site design
+
+---
+
+### Requirement: Blog Post Single Template
+Individual blog posts SHALL be displayed with a dedicated single post template providing optimal reading experience.
+
+#### Scenario: Blog post page renders content
+**Given** a blog post at `content/blog/ki-generierte-website-praxisbeispiel/index.de.md`
+**When** a user navigates to `/de/blog/ki-generierte-website-praxisbeispiel/`
+**Then** the post SHALL be rendered using `layouts/blog/single.html`
+**And** the page SHALL display the post title as the main heading (H1)
+**And** the page SHALL display the publication date
+**And** the page SHALL display the full post content with proper formatting
+
+#### Scenario: Blog post content is readable
+**Given** a rendered blog post
+**When** viewing the post content
+**Then** headings SHALL use appropriate hierarchy (H2, H3, etc. for sections)
+**And** paragraphs SHALL have readable line height and spacing
+**And** code blocks SHALL be distinguishable with appropriate styling
+**And** links SHALL be clearly identifiable and accessible
+**And** images SHALL be responsive and properly sized
+
+#### Scenario: Blog post has navigation
+**Given** a blog post page
+**When** a user finishes reading
+**Then** the page SHALL include a link back to the blog list
+**And** the navigation link SHALL be clearly visible
+**And** the site's main navigation SHALL remain accessible
+
+---
+
+### Requirement: Blog Navigation Integration
+The blog section SHALL be accessible through the site's main navigation.
+
+#### Scenario: Blog link in main navigation
+**Given** the site configuration
+**When** rendering the main navigation menu
+**Then** a "Blog" link SHALL appear in the navigation for German pages
+**And** a "Blog" link SHALL appear in the navigation for English pages
+**And** the link SHALL point to `/de/blog/` for German
+**And** the link SHALL point to `/en/blog/` for English
+
+#### Scenario: Active state for blog pages
+**Given** a user is on a blog page (list or single post)
+**When** viewing the navigation menu
+**Then** the "Blog" link SHALL have an active state indicator
+**And** the active state SHALL use the same styling as other active navigation items
+**And** the active state SHALL be maintained on both blog list and single post pages
+
+---
+
+### Requirement: Blog Template Semantic HTML
+Blog templates SHALL use semantic HTML5 elements for accessibility and SEO.
+
+#### Scenario: Blog list uses semantic structure
+**Given** the blog list template
+**When** rendering the page
+**Then** the main content SHALL be wrapped in a `<main>` element
+**And** individual blog post entries SHALL use `<article>` elements
+**And** post metadata SHALL use appropriate semantic tags (e.g., `<time>` for dates)
+**And** heading hierarchy SHALL be logical and sequential
+
+#### Scenario: Blog post uses article structure
+**Given** a blog post template
+**When** rendering the page
+**Then** the post SHALL be wrapped in an `<article>` element
+**And** the post SHALL have a `<header>` with title and metadata
+**And** the post content SHALL be in a `<div>` or `<section>` with clear semantic structure
+**And** all headings SHALL follow proper hierarchy
+
+---
+
+### Requirement: Blog Styling Consistency
+Blog templates SHALL maintain visual consistency with the rest of the site.
+
+#### Scenario: Blog pages use site styling
+**Given** any blog page (list or single)
+**When** the page is rendered
+**Then** the page SHALL use the site's base layout (`baseof.html`)
+**And** the page SHALL include the site's header and footer partials
+**And** the page SHALL use Bootstrap classes for styling
+**And** typography SHALL be consistent with other site pages
+**And** color scheme SHALL match the site's design
+
+#### Scenario: Blog pages are accessible
+**Given** any blog page
+**When** evaluated for accessibility
+**Then** the page SHALL meet WCAG 2.1 AA standards
+**And** all interactive elements SHALL be keyboard accessible
+**And** color contrast ratios SHALL meet minimum requirements
+**And** images SHALL have appropriate alt text (if any)
+**And** the page SHALL have appropriate semantic structure for screen readers
+

openspec/specs/content-management/spec.md

@@ -0,0 +1,39 @@
+# content-management Specification
+
+## Purpose
+TBD - created by archiving change add-cv-page. Update Purpose after archive.
+## Requirements
+### Requirement: CV Page Content
+The site SHALL provide a dedicated curriculum vitae page that explains how to securely download the CV document and request additional materials.
+
+#### Scenario: CV page displays download instructions
+- **WHEN** a visitor navigates to `/cv/` or clicks "Lebenslauf" in navigation
+- **THEN** the page displays a clear explanation of the Tresorit download process
+- **AND** the page includes the secure download link
+- **AND** the page mentions email verification is required
+- **AND** the page explains that certificates and references are available upon personal request
+
+#### Scenario: CV page uses German language
+- **WHEN** the CV page is rendered
+- **THEN** all text is displayed in German
+- **AND** the tone is professional and suitable for HR personnel and recruiters
+
+#### Scenario: CV page follows site layout
+- **WHEN** the CV page is rendered
+- **THEN** it uses the standard single.html layout
+- **AND** content is centered and readable
+- **AND** it includes the site header and footer
+
+### Requirement: CV Navigation Link
+The site navigation SHALL include a link to the CV page.
+
+#### Scenario: Navigation menu shows CV link
+- **WHEN** a visitor views any page on the site
+- **THEN** the navigation menu includes a "Lebenslauf" link
+- **AND** the link points to `/cv/`
+- **AND** the link follows the same styling as other navigation items
+
+#### Scenario: CV link active state
+- **WHEN** a visitor is on the CV page
+- **THEN** the "Lebenslauf" navigation link shows active state styling
+

openspec/specs/content-migration/spec.md

@@ -0,0 +1,86 @@
+# content-migration Specification
+
+## Purpose
+TBD - created by archiving change migrate-site-content. Update Purpose after archive.
+## Requirements
+### Requirement: Content Extraction from Live Site
+The system SHALL capture all text content, structure, and formatting from the live markusgraf.ch website to migrate into the Hugo project.
+
+#### Scenario: Extract homepage content from live site
+- **GIVEN** the live markusgraf.ch website HTML source is provided
+- **WHEN** the HTML is parsed for content extraction
+- **THEN** all text content, headings, and structure are captured
+- **AND** the content is organized by logical sections (bio, intro, projects, etc.)
+
+#### Scenario: Extract projects and portfolio content
+- **GIVEN** the live site contains project or portfolio information
+- **WHEN** projects are identified and extracted
+- **THEN** each project has complete description captured
+- **AND** project metadata and structure is documented
+
+### Requirement: Content Conversion to Hugo Format
+The system SHALL convert extracted HTML content into Hugo-compatible markdown format while preserving formatting and structure.
+
+#### Scenario: Convert HTML to markdown
+- **GIVEN** extracted HTML content from live site
+- **WHEN** content is converted to markdown
+- **THEN** all text formatting is preserved (bold, italic, links)
+- **AND** HTML-specific elements are converted to markdown or Hugo shortcodes
+- **AND** content follows markdown best practices
+
+#### Scenario: Add Hugo front matter
+- **GIVEN** converted markdown content
+- **WHEN** content files are created
+- **THEN** appropriate YAML front matter is added (title, description, date)
+- **AND** front matter variables are correctly configured for templates
+
+### Requirement: Homepage Content Integration
+The system SHALL integrate migrated homepage content into content/_index.md, replacing placeholder content.
+
+#### Scenario: Update homepage with actual content
+- **GIVEN** converted homepage markdown content
+- **WHEN** content/_index.md is updated
+- **THEN** all placeholder text is replaced with actual content
+- **AND** all sections from live site are present
+- **AND** content hierarchy and flow matches live site structure
+
+#### Scenario: Image references in content
+- **GIVEN** homepage content references images
+- **WHEN** image references are added to markdown
+- **THEN** images use Hugo static path conventions (e.g., /images/photo.jpg)
+- **AND** all image markdown syntax is correct
+
+### Requirement: Content Structure Parity
+The system SHALL ensure the Hugo site content structure matches the live markusgraf.ch site organization.
+
+#### Scenario: Section organization matches live site
+- **GIVEN** live site has distinct sections
+- **WHEN** content is organized in Hugo
+- **THEN** all sections are represented
+- **AND** section order matches live site
+- **AND** navigation between sections works correctly
+
+#### Scenario: Multi-page structure if needed
+- **GIVEN** live site has multiple pages
+- **WHEN** pages are created in Hugo
+- **THEN** each page has corresponding content file
+- **AND** internal links between pages work
+- **AND** navigation reflects page structure
+
+### Requirement: Content Verification
+The system SHALL verify that migrated content achieves parity with the live site.
+
+#### Scenario: Content completeness check
+- **GIVEN** Hugo site is built with migrated content
+- **WHEN** compared with live markusgraf.ch
+- **THEN** all text content from live site is present
+- **AND** no content is missing or truncated
+- **AND** content meaning and context are preserved
+
+#### Scenario: Visual structure comparison
+- **GIVEN** Hugo site is rendered
+- **WHEN** viewed alongside live site
+- **THEN** content sections appear in same order
+- **AND** heading hierarchy matches
+- **AND** overall content flow is equivalent
+

openspec/specs/deployment/spec.md

@@ -0,0 +1,100 @@
+# deployment Specification
+
+## Purpose
+TBD - created by archiving change simple-deployment. Update Purpose after archive.
+## Requirements
+### Requirement: Rsync Deployment Script SHALL be provided
+The system SHALL provide an automated deployment script that syncs the built Hugo site to the production server via rsync over SSH, properly mirroring content.
+
+#### Scenario: User deploys site after building
+**Given** the Hugo site has been built successfully (public/ directory exists)
+**And** the user has set the SSH_USER and SSH_HOST environment variables
+**When** the user runs the deployment script
+**Then** the script connects to the specified SSH_HOST via rsync over SSH
+**And** syncs all files from the public/ directory to the REMOTE_ROOT directory on the server
+**And** deletes remote files that don't exist locally (mirror behavior)
+**And** displays sync progress and completion status
+**And** exits with status code 0 on success
+
+#### Scenario: Script fails when credentials are missing
+**Given** the Hugo site has been built
+**And** the SSH_USER or SSH_HOST environment variable is not set
+**When** the user runs the deployment script
+**Then** the script displays an error message explaining the missing configuration
+**And** exits with a non-zero status code
+**And** does not attempt to connect to the server
+
+#### Scenario: Script handles connection failures gracefully
+**Given** the SSH_USER and SSH_HOST are set correctly
+**And** the network connection to the server is unavailable or SSH authentication fails
+**When** the user runs the deployment script
+**Then** the script displays a clear error message about the connection failure
+**And** exits with a non-zero status code
+**And** does not leave the deployment in a partially completed state
+
+### Requirement: Secure Credential Management SHALL be enforced
+The deployment process SHALL handle credentials securely without exposing them in version control or script output.
+
+#### Scenario: Configuration stored as environment variables
+**Given** the user needs to deploy the site
+**When** the user reviews the deployment documentation
+**Then** the documentation instructs them to set SSH_USER, SSH_HOST, SSH_PORT, and REMOTE_ROOT as environment variables
+**And** the deployment script reads configuration only from environment variables
+**And** credentials are never hardcoded in scripts or configuration files
+**And** SSH key-based authentication is used for secure, password-less access
+
+#### Scenario: Script does not expose credentials in output
+**Given** the deployment script is running
+**When** the script displays status messages or logs
+**Then** SSH keys or passwords are never displayed in plain text
+**And** connection strings show only the host and user information
+**And** error messages do not reveal credential values
+
+### Requirement: Deployment Status Feedback SHALL be provided
+The deployment script SHALL provide clear feedback about the deployment process and outcome.
+
+#### Scenario: User receives progress updates during deployment
+**Given** the deployment script is uploading files
+**When** the upload is in progress
+**Then** the script displays which files or directories are being uploaded
+**And** shows overall progress indicators
+**And** provides estimated time or completion percentage when possible
+
+#### Scenario: Successful deployment confirmation
+**Given** all files have been uploaded successfully
+**When** the deployment completes
+**Then** the script displays a success message
+**And** confirms the total number of files uploaded
+**And** exits with status code 0
+
+#### Scenario: Failed deployment with actionable error
+**Given** an error occurs during deployment
+**When** the deployment fails
+**Then** the script displays the specific error encountered
+**And** suggests possible remediation steps
+**And** exits with a non-zero status code
+
+### Requirement: Deployment Prerequisites SHALL be verified
+The deployment script SHALL verify that prerequisites are met before attempting deployment.
+
+#### Scenario: Script checks for built site
+**Given** the user runs the deployment script
+**When** the script starts
+**Then** it verifies that the public/ directory exists
+**And** contains files to deploy
+**And** exits with an error if the directory is missing or empty
+
+#### Scenario: Script checks for required tools
+**Given** the deployment script starts
+**When** it performs prerequisite checks
+**Then** it verifies that rsync is installed and available
+**And** displays an installation message if rsync is missing
+**And** exits with an error if required tools are unavailable
+
+#### Scenario: Script supports configurable ports and remote directories
+**Given** the user needs to deploy to a non-standard SSH port or directory
+**When** the user sets SSH_PORT and REMOTE_ROOT environment variables
+**Then** the script uses the specified port instead of the default (22)
+**And** the script uploads to the specified remote directory instead of the default (/httpsdocs)
+**And** if these variables are not set, the script uses sensible defaults
+

openspec/specs/homepage-recent-posts/spec.md

@@ -0,0 +1,89 @@
+# homepage-recent-posts Specification
+
+## Purpose
+TBD - created by archiving change homepage-recent-posts. Update Purpose after archive.
+## Requirements
+### Requirement: Display Recent Blog Posts on Homepage
+The homepage MUST display the 3 most recent blog posts immediately after the user's description content section.
+
+#### Scenario: Three most recent posts are displayed
+**Given** the blog section contains 5 published posts
+**When** a visitor accesses the homepage
+**Then** exactly 3 most recent posts are displayed
+**And** posts are ordered by publication date (newest first)
+
+#### Scenario: Fewer than three posts exist
+**Given** the blog section contains only 2 published posts
+**When** a visitor accesses the homepage
+**Then** all 2 posts are displayed
+**And** no error or empty slots are shown
+
+#### Scenario: No blog posts exist
+**Given** the blog section contains no published posts
+**When** a visitor accesses the homepage
+**Then** the recent posts section is not displayed
+**And** the homepage layout remains intact
+
+### Requirement: Post Display Format
+Each displayed blog post MUST show the post title as a clickable link and the publication date.
+
+#### Scenario: Post title is clickable
+**Given** a blog post is displayed on the homepage
+**When** a visitor clicks the post title
+**Then** they are navigated to the full blog post page
+**And** the language context is preserved (German homepage → German post, English homepage → English post)
+
+#### Scenario: Publication date is formatted correctly
+**Given** a blog post with date "2025-10-30" is displayed
+**When** viewing the German homepage
+**Then** the date is formatted as "30. October 2025"
+**When** viewing the English homepage
+**Then** the date is formatted as "October 30, 2025"
+
+### Requirement: Multilingual Support
+The recent posts section MUST respect the site's multilingual configuration and display language-appropriate content.
+
+#### Scenario: German homepage shows German posts
+**Given** the visitor accesses the German homepage (/de/)
+**When** the recent posts section is rendered
+**Then** only German blog posts are displayed
+**And** the section heading is in German (e.g., "Neueste Beiträge")
+
+#### Scenario: English homepage shows English posts
+**Given** the visitor accesses the English homepage (/en/)
+**When** the recent posts section is rendered
+**Then** only English blog posts are displayed
+**And** the section heading is in English (e.g., "Recent Posts")
+
+### Requirement: Visual Design and Layout
+The recent posts section MUST maintain consistency with the existing site design and remain responsive.
+
+#### Scenario: Section styling matches site design
+**Given** the recent posts section is displayed
+**Then** it uses Bootstrap classes consistent with the rest of the site
+**And** spacing and typography match existing content sections
+**And** the section is visually distinct from the description section above
+
+#### Scenario: Responsive layout on mobile devices
+**Given** the homepage is viewed on a mobile device (< 768px width)
+**When** the recent posts section is displayed
+**Then** the layout remains readable and properly formatted
+**And** no horizontal scrolling is required
+**And** links are easily tappable
+
+### Requirement: Performance and Build
+The implementation MUST not negatively impact Hugo build performance or site load times.
+
+#### Scenario: Hugo build completes successfully
+**Given** the homepage template includes recent posts query
+**When** running `hugo build`
+**Then** the build completes without errors or warnings
+**And** the homepage HTML is generated correctly for both languages
+
+#### Scenario: Site performance remains optimal
+**Given** the homepage includes recent posts section
+**When** measuring page load performance
+**Then** Lighthouse performance score remains >90
+**And** no additional HTTP requests are made
+**And** HTML file size increase is minimal (< 2KB)
+

openspec/specs/hugo-site/spec.md

@@ -0,0 +1,133 @@
+# hugo-site Specification
+
+## Purpose
+TBD - created by archiving change add-minimal-hugo-site. Update Purpose after archive.
+## Requirements
+### Requirement: Hugo Project Structure
+The system SHALL initialize a Hugo static site with the standard directory structure including layouts, content, static, and data directories.
+
+#### Scenario: Hugo site initialized
+- **WHEN** Hugo site is created
+- **THEN** the following directories exist: layouts/, content/, static/, data/
+- **AND** a hugo.toml configuration file is present at the root
+
+#### Scenario: Hugo builds successfully
+- **WHEN** running `hugo` command
+- **THEN** the site builds without errors
+- **AND** generates static HTML files in the public/ directory
+
+### Requirement: Base Layout Template
+The system SHALL provide a baseof.html template that defines the common HTML structure for all pages, including Bootstrap 5.x integration.
+
+#### Scenario: Base layout includes Bootstrap
+- **WHEN** any page is rendered
+- **THEN** the HTML output includes Bootstrap 5.x CSS from CDN
+- **AND** the page has proper HTML5 doctype and meta tags
+- **AND** the page is responsive with Bootstrap's viewport meta tag
+
+#### Scenario: Base layout includes header and footer
+- **WHEN** any page is rendered
+- **THEN** the page includes the header partial
+- **AND** the page includes the footer partial
+- **AND** the main content block is properly positioned between them
+
+### Requirement: Reusable Partials
+The system SHALL provide reusable partial templates for header, footer, and navigation components.
+
+#### Scenario: Header partial exists
+- **WHEN** baseof.html calls the header partial
+- **THEN** the header is rendered with consistent styling across all pages
+
+#### Scenario: Footer partial exists
+- **WHEN** baseof.html calls the footer partial
+- **THEN** the footer is rendered with consistent styling across all pages
+
+#### Scenario: Navigation partial exists
+- **WHEN** header includes navigation
+- **THEN** the navigation menu renders with links to main pages
+- **AND** uses Bootstrap navigation components
+
+### Requirement: Homepage Template
+The system SHALL provide an index.html template for the homepage that extends baseof.html and displays the main landing content.
+
+#### Scenario: Homepage renders correctly
+- **WHEN** accessing the root URL
+- **THEN** the homepage template is used
+- **AND** displays content from content/_index.md
+- **AND** matches the structure of the existing markusgraf.ch homepage
+
+### Requirement: Single Page Template
+The system SHALL provide a default single.html template for individual content pages.
+
+#### Scenario: Single page renders correctly
+- **WHEN** accessing any content page
+- **THEN** the single page template is used
+- **AND** displays the page title
+- **AND** renders the markdown content as HTML
+
+### Requirement: Static Assets
+The system SHALL serve static assets (images, fonts, CSS files) from the static/ directory.
+
+#### Scenario: Static files are accessible
+- **WHEN** a static file is placed in static/
+- **THEN** it is accessible at the site root in the built site
+- **AND** preserves the directory structure from static/
+
+### Requirement: Content Management
+The system SHALL support markdown files in the content/ directory that are rendered into HTML pages.
+
+#### Scenario: Markdown content is rendered
+- **WHEN** a markdown file exists in content/
+- **THEN** Hugo processes it into an HTML page
+- **AND** front matter variables are accessible in templates
+
+#### Scenario: Page metadata
+- **WHEN** a content file has front matter
+- **THEN** title, date, and other metadata are available in templates
+- **AND** can be used for page titles and navigation
+
+### Requirement: Configuration
+The system SHALL use hugo.toml for site configuration including baseURL, title, and language settings.
+
+#### Scenario: Site configuration is applied
+- **WHEN** hugo.toml contains site settings
+- **THEN** those settings are used during site generation
+- **AND** site title appears in page titles
+- **AND** baseURL is used for absolute URLs
+
+### Requirement: Responsive Design
+The system SHALL render pages that are responsive and mobile-friendly using Bootstrap's grid system and responsive utilities.
+
+#### Scenario: Mobile viewport
+- **WHEN** viewing the site on mobile devices
+- **THEN** the layout adapts to small screens
+- **AND** navigation is accessible
+- **AND** content is readable without horizontal scrolling
+
+#### Scenario: Tablet and desktop viewports
+- **WHEN** viewing the site on larger screens
+- **THEN** the layout utilizes available space appropriately
+- **AND** maintains readability and visual hierarchy
+
+### Requirement: HTML Validity
+The system SHALL generate valid HTML5 markup that passes standard validation.
+
+#### Scenario: Valid HTML output
+- **WHEN** pages are generated
+- **THEN** HTML is well-formed
+- **AND** includes required DOCTYPE and meta tags
+- **AND** uses semantic HTML5 elements where appropriate
+
+### Requirement: Accessibility Basics
+The system SHALL implement basic accessibility features including semantic HTML and proper heading hierarchy.
+
+#### Scenario: Semantic HTML structure
+- **WHEN** pages are rendered
+- **THEN** content uses appropriate semantic elements (header, nav, main, footer, article)
+- **AND** maintains logical heading hierarchy (h1, h2, h3)
+
+#### Scenario: Navigation accessibility
+- **WHEN** keyboard navigation is used
+- **THEN** all interactive elements are focusable
+- **AND** focus order is logical
+

openspec/specs/image-assets/spec.md

@@ -0,0 +1,90 @@
+# image-assets Specification
+
+## Purpose
+TBD - created by archiving change migrate-site-content. Update Purpose after archive.
+## Requirements
+### Requirement: Image Asset Discovery
+The system SHALL identify and catalog all images from the live markusgraf.ch website for migration.
+
+#### Scenario: Identify all images on live site
+- **GIVEN** the live markusgraf.ch website HTML source
+- **WHEN** images are catalogued from the HTML
+- **THEN** all image URLs are documented
+- **AND** image purposes (profile, project, icon, etc.) are identified
+- **AND** image file formats and sizes are noted
+
+#### Scenario: Create asset inventory
+- **GIVEN** identified images from live site
+- **WHEN** asset inventory is created
+- **THEN** a complete list of images with URLs exists
+- **AND** each image is categorized by type/purpose
+- **AND** inventory documents source URLs for downloading
+
+### Requirement: Image Download and Organization
+The system SHALL download images from the live site and organize them in Hugo's static directory following logical grouping principles.
+
+#### Scenario: Download images from live site
+- **GIVEN** list of image URLs from inventory
+- **WHEN** images are downloaded
+- **THEN** all images are successfully retrieved
+- **AND** image files are verified for integrity
+- **AND** no corrupted or failed downloads exist
+
+#### Scenario: Organize images in static directory
+- **GIVEN** downloaded images
+- **WHEN** images are placed in Hugo project
+- **THEN** images are saved to static/images/ or appropriate subdirectories
+- **AND** directory structure reflects logical grouping (e.g., static/images/projects/, static/images/profile/)
+- **AND** filenames are consistent and descriptive
+
+### Requirement: Image Reference Integration
+The system SHALL update all image references in content files to use Hugo's static path conventions correctly.
+
+#### Scenario: Update image paths in content
+- **GIVEN** images are in Hugo static directory
+- **WHEN** content files reference images
+- **THEN** image paths use Hugo static conventions (e.g., /images/photo.jpg)
+- **AND** all image references use correct relative or absolute paths
+- **AND** markdown image syntax is properly formatted
+
+#### Scenario: Verify image links resolve
+- **GIVEN** Hugo site is built
+- **WHEN** pages with images are rendered
+- **THEN** all image references resolve correctly
+- **AND** no broken image links exist
+- **AND** no 404 errors occur for image resources
+
+### Requirement: Image Display Verification
+The system SHALL ensure all migrated images display correctly in the built Hugo site.
+
+#### Scenario: Images render correctly
+- **GIVEN** Hugo site is built and served
+- **WHEN** pages with images are viewed
+- **THEN** all images display visually
+- **AND** image aspect ratios are appropriate
+- **AND** images load from correct static paths
+- **AND** no missing or placeholder images appear
+
+#### Scenario: Image dimensions and quality
+- **GIVEN** images are displayed on site
+- **WHEN** comparing to live site
+- **THEN** image sizes are comparable to originals
+- **AND** image quality is maintained
+- **AND** no distortion or stretching occurs
+
+### Requirement: Image Accessibility
+The system SHALL ensure all images have appropriate accessibility attributes for screen readers and assistive technologies.
+
+#### Scenario: Alt text for all images
+- **GIVEN** images in content files
+- **WHEN** markdown image syntax is used
+- **THEN** all images include descriptive alt text
+- **AND** alt text meaningfully describes image content
+- **AND** decorative images use empty alt text where appropriate
+
+#### Scenario: Semantic image usage
+- **GIVEN** images serve specific purposes
+- **WHEN** images are integrated into content
+- **THEN** images are used semantically (figures, illustrations, etc.)
+- **AND** image context is clear from surrounding content
+

openspec/specs/internationalization/spec.md

@@ -0,0 +1,120 @@
+# internationalization Specification
+
+## Purpose
+TBD - created by archiving change add-multilingual-support. Update Purpose after archive.
+## Requirements
+### Requirement: Multilingual Content Support
+The site SHALL support multiple languages with German (de) as the default language and English (en) as a secondary language.
+
+#### Scenario: German content is accessible at /de/ path
+- **WHEN** a visitor navigates to `/de/` or any `/de/*` path
+- **THEN** the page displays in German language
+- **AND** all navigation, content, and UI elements are in German
+
+#### Scenario: English content is accessible at /en/ path
+- **WHEN** a visitor navigates to `/en/` or any `/en/*` path
+- **THEN** the page displays in English language
+- **AND** all navigation, content, and UI elements are in English
+
+#### Scenario: All pages have translations
+- **WHEN** content exists in one language
+- **THEN** a corresponding translation SHALL exist in the other language
+- **AND** the content structure mirrors across languages (e.g., `/de/cv` ↔ `/en/cv`)
+
+### Requirement: Language Switcher
+The site navigation SHALL include a language switcher that allows users to change languages while maintaining page context.
+
+#### Scenario: Language switcher is visible in navigation
+- **WHEN** a visitor views any page
+- **THEN** the navigation displays language options (DE, EN)
+- **AND** the current active language is visually indicated
+- **AND** the inactive language is shown as a clickable link
+
+#### Scenario: Language switching maintains page context
+- **WHEN** a visitor is on `/de/cv` and clicks the English language link
+- **THEN** the page navigates to `/en/cv` (the English version of the same page)
+- **AND** the page content changes to English
+
+#### Scenario: Language switching from home page
+- **WHEN** a visitor is on `/de/` and clicks the English language link
+- **THEN** the page navigates to `/en/`
+- **AND** the home page content changes to English
+
+#### Scenario: Language switcher handles missing translations
+- **WHEN** a visitor is on a page without a translation
+- **THEN** the language link points to the home page of the target language
+- **AND** the user is not left on a broken or non-existent page
+
+### Requirement: Language Persistence
+The site SHALL maintain the user's language preference through URL-based routing without requiring cookies or JavaScript.
+
+#### Scenario: Language preference persists across navigation
+- **WHEN** a visitor navigates to `/de/cv` and then clicks a navigation link
+- **THEN** all subsequent pages remain in German (e.g., clicking "Home" goes to `/de/`)
+- **AND** the language preference is maintained through the URL structure
+
+#### Scenario: Direct URL access respects language
+- **WHEN** a visitor directly accesses `/en/cv` via URL or bookmark
+- **THEN** the page displays in English
+- **AND** all navigation links point to English pages
+
+### Requirement: Browser Language Detection
+The site configuration SHALL support automatic language selection based on browser language preferences for first-time visitors.
+
+#### Scenario: Server redirect based on Accept-Language header
+- **WHEN** a visitor accesses the root URL `/` for the first time
+- **THEN** the server MAY redirect to `/de/` or `/en/` based on the browser's `Accept-Language` header
+- **AND** German is used as the fallback if no language preference is detected
+
+#### Scenario: URL-based access bypasses language detection
+- **WHEN** a visitor directly accesses `/de/` or `/en/`
+- **THEN** the specified language is used regardless of browser settings
+- **AND** no redirect occurs
+
+### Requirement: Content Translation
+All site content SHALL be translated between German and English languages.
+
+#### Scenario: Home page content is translated
+- **WHEN** viewing the home page in German (`/de/`)
+- **THEN** all text including introduction, project descriptions, and UI labels are in German
+- **WHEN** viewing the home page in English (`/en/`)
+- **THEN** all text including introduction, project descriptions, and UI labels are in English
+
+#### Scenario: CV page content is translated
+- **WHEN** viewing the CV page in German (`/de/cv`)
+- **THEN** all text including headings, instructions, and contact information are in German
+- **WHEN** viewing the CV page in English (`/en/cv`)
+- **THEN** all text including headings, instructions, and contact information are in English
+
+#### Scenario: Navigation menu is translated
+- **WHEN** viewing any page in German
+- **THEN** navigation menu items are in German (e.g., "Lebenslauf" for CV)
+- **WHEN** viewing any page in English
+- **THEN** navigation menu items are in English (e.g., "Curriculum Vitae" for CV)
+
+#### Scenario: Footer content is translated
+- **WHEN** viewing any page in German
+- **THEN** footer content including address and contact information labels are in German
+- **WHEN** viewing any page in English
+- **THEN** footer content including address and contact information labels are in English
+
+### Requirement: SEO and Accessibility
+The site SHALL implement proper multilingual SEO practices and accessibility features.
+
+#### Scenario: HTML lang attribute is set correctly
+- **WHEN** viewing a German page
+- **THEN** the HTML element has `lang="de"` attribute
+- **WHEN** viewing an English page
+- **THEN** the HTML element has `lang="en"` attribute
+
+#### Scenario: Alternative language links are provided
+- **WHEN** viewing any page
+- **THEN** the HTML head includes `<link rel="alternate" hreflang="de" ...>` and `<link rel="alternate" hreflang="en" ...>` tags
+- **AND** these tags point to the corresponding page in each language
+
+#### Scenario: Page titles reflect language
+- **WHEN** viewing a page in German
+- **THEN** the page title is in German
+- **WHEN** viewing a page in English
+- **THEN** the page title is in English
+

openspec/specs/styling/spec.md

@@ -0,0 +1,69 @@
+# styling Specification
+
+## Purpose
+TBD - created by archiving change add-custom-bootstrap-styling. Update Purpose after archive.
+## Requirements
+### Requirement: SCSS Processing Pipeline
+The system SHALL process SCSS files using Hugo Pipes to generate custom CSS that supplements Bootstrap's CDN-provided styles.
+
+#### Scenario: SCSS compilation on build
+- **WHEN** Hugo builds the site
+- **THEN** SCSS files in `assets/scss/` are compiled to CSS
+- **AND** the compiled CSS is fingerprinted for cache busting
+- **AND** the resulting CSS file is included in the HTML output
+
+#### Scenario: Development mode with live reload
+- **WHEN** running Hugo in development mode (hugo server)
+- **THEN** SCSS changes trigger automatic recompilation
+- **AND** the browser live-reloads with updated styles
+
+### Requirement: Bootstrap Variable Customization
+The system SHALL allow customization of Bootstrap design tokens through SCSS variables without modifying the CDN-provided Bootstrap CSS.
+
+#### Scenario: Override heading font sizes
+- **WHEN** custom heading sizes are defined in SCSS variables
+- **THEN** the compiled CSS applies these sizes to heading elements
+- **AND** the Bootstrap CDN CSS is loaded first (base styles)
+- **AND** custom CSS is loaded after (overrides)
+
+#### Scenario: Override link colors
+- **WHEN** custom link colors are defined in SCSS variables
+- **THEN** links across the site use the custom colors
+- **AND** link hover states use appropriate custom colors
+
+#### Scenario: Override spacing scale
+- **WHEN** custom spacing values are defined
+- **THEN** elements using those spacing classes reflect the custom values
+
+### Requirement: Custom Style Organization
+The system SHALL organize custom styles in a maintainable SCSS file structure following Hugo and SASS best practices.
+
+#### Scenario: Main SCSS entry point
+- **WHEN** Hugo processes SCSS
+- **THEN** a single main SCSS file serves as the entry point
+- **AND** this file imports Bootstrap variable overrides
+- **AND** this file imports custom component styles
+- **AND** this file imports custom utility styles
+
+#### Scenario: Modular SCSS files
+- **WHEN** developers add new custom styles
+- **THEN** styles can be organized into separate partial files
+- **AND** partial files are imported into the main SCSS file
+- **AND** file naming follows SCSS conventions (e.g., `_variables.scss`, `_custom.scss`)
+
+### Requirement: CSS Output Integration
+The system SHALL integrate compiled custom CSS into the base layout template alongside Bootstrap CDN CSS.
+
+#### Scenario: CSS load order
+- **WHEN** a page is rendered
+- **THEN** Bootstrap CDN CSS loads first
+- **AND** custom compiled CSS loads second
+- **AND** CSS files include integrity hashes where applicable
+- **AND** the custom CSS file path includes a fingerprint for cache busting
+
+#### Scenario: Production build optimization
+- **WHEN** building for production
+- **THEN** SCSS is compiled with minification
+- **AND** the output CSS is optimized for file size
+- **AND** source maps are not included in production builds
+