From c0bccfbcc67dc47ffd17d7affc6173056ffc1633 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?R=7BAI=7Df=20D=2E=20M=C3=BCller?= Date: Sat, 14 Mar 2026 14:18:56 +0100 Subject: [PATCH] =?UTF-8?q?feat:=20replace=20Font=20Awesome=20anchor=20ico?= =?UTF-8?q?n=20with=20=E2=9A=93=20emoji?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Use the ⚓ emoji instead of Font Awesome's fa-anchor icon to mark Semantic Anchors in the workflow documentation. The emoji is copyable and renders correctly in any target system without requiring Font Awesome. Co-Authored-By: Claude Opus 4.6 (1M context) --- docs/spec-driven-workflow.de.html | 48 +++++++++++++++---------------- docs/spec-driven-workflow.html | 46 ++++++++++++++--------------- 2 files changed, 47 insertions(+), 47 deletions(-) diff --git a/docs/spec-driven-workflow.de.html b/docs/spec-driven-workflow.de.html index 0f7da0d..25a9d09 100644 --- a/docs/spec-driven-workflow.de.html +++ b/docs/spec-driven-workflow.de.html @@ -544,7 +544,7 @@

Einleitung

-

Semantic Anchors sind im Dokument mit gekennzeichnet. +

Semantic Anchors sind im Dokument mit ⚓ gekennzeichnet. Ein Klick auf einen Anker führt zur vollständigen Definition auf der Semantic Anchors Website.

@@ -613,16 +613,16 @@

Querschnittsthemen

-
Plain English nach Strunk & White
+
⚓ Plain English nach Strunk & White

Alle Dokumentation verwendet kurze Sätze, aktive Sprache und keine überflüssigen Wörter. -Für deutschsprachige Dokumentation gilt analog Gutes Deutsch nach Wolf Schneider.

+Für deutschsprachige Dokumentation gilt analog ⚓ Gutes Deutsch nach Wolf Schneider.

-
Conventional Commits
+
⚓ Conventional Commits

Alle Commits folgen einem standardisierten Format für eine saubere, maschinenlesbare Git-History.

-
Docs-as-Code nach Ralf D. Müller
+
⚓ Docs-as-Code nach Ralf D. Müller

Dokumentation lebt im Repository als AsciiDoc, gebaut von docToolchain. Docs-as-Code behandelt Dokumentation wie Quellcode: versioniert, reviewt und automatisch gebaut.

@@ -647,7 +647,7 @@

Voraussetzungen

Git-Repository initialisieren

  • -

    docToolchain installieren und das arc42-Template herunterladen

    +

    docToolchain installieren und das ⚓ arc42-Template herunterladen

  • KI-Coding-Umgebung mit einer AGENTS.md konfigurieren (oder toolspezifisches Äquivalent wie CLAUDE.md)

    @@ -761,7 +761,7 @@

    Schritt 1: Vision beschreiben

    Schritt 2: Anforderungen mit der Sokratischen Methode klären

    -

    Die KI auffordern, die Sokratische Methode zur Klärung der Anforderungen zu nutzen.

    +

    Die KI auffordern, die ⚓ Sokratische Methode zur Klärung der Anforderungen zu nutzen.

    @@ -783,7 +783,7 @@

    Schritt 2

    -

    MECE (Mutually Exclusive, Collectively Exhaustive) stellt sicher, dass die Fragen alle Bereiche überlappungsfrei abdecken.

    +

    ⚓ MECE (Mutually Exclusive, Collectively Exhaustive) stellt sicher, dass die Fragen alle Bereiche überlappungsfrei abdecken.

    Den Dialog fortführen, bis man mit der KI zufrieden ist, dass die Anforderungen klar sind.

    @@ -817,7 +817,7 @@

    Schritt 4: Detaillierte

    -

    Gherkin (Given/When/Then) liefert Akzeptanzkriterien, die sowohl für Menschen lesbar als auch maschinell testbar sind. +

    ⚓ Gherkin (Given/When/Then) liefert Akzeptanzkriterien, die sowohl für Menschen lesbar als auch maschinell testbar sind. Diese Kriterien werden später die Grundlage für TDD.

    @@ -842,21 +842,21 @@

    Schritt 5: arc42-Ar

    • -

    arc42 bietet 12 Abschnitte, die alles von Kontextabgrenzung bis Deployment abdecken. +

    ⚓ arc42 bietet 12 Abschnitte, die alles von Kontextabgrenzung bis Deployment abdecken. Die KI kennt die Template-Struktur und füllt sie passend.

    -

    C4 Diagrams kombiniert mit PlantUML ermöglichen textbasierte Architektur-Visualisierung auf vier Ebenen: Context, Container, Component, Code. +

    ⚓ C4 Diagrams kombiniert mit PlantUML ermöglichen textbasierte Architektur-Visualisierung auf vier Ebenen: Context, Container, Component, Code. Die KI kann diese Diagramme ohne grafische Tools erstellen und ändern.

    Architecture Decision Records

    -

    Architekturentscheidungen werden als ADRs nach Nygard dokumentiert. +

    Architekturentscheidungen werden als ⚓ ADRs nach Nygard dokumentiert. Jedes ADR folgt der Struktur: Titel, Status, Kontext, Entscheidung, Konsequenzen.

    -

    Für jede Entscheidung wird eine Pugh-Matrix mit 3-Punkt-Skala (-1, 0, +1) erstellt, um Alternativen gegen Qualitätskriterien zu bewerten.

    +

    Für jede Entscheidung wird eine ⚓ Pugh-Matrix mit 3-Punkt-Skala (-1, 0, +1) erstellt, um Alternativen gegen Qualitätskriterien zu bewerten.

    @@ -878,7 +878,7 @@

    Architecture Decision Records

    Schritt 6: Architektur-Review (ATAM)

    -

    Ein Architektur-Review mit der Architecture Tradeoff Analysis Method (ATAM) durchführen:

    +

    Ein Architektur-Review mit der ⚓ Architecture Tradeoff Analysis Method (ATAM) durchführen:

    @@ -912,10 +912,10 @@

    Schritt 7: Backlog erstellen

    -

    INVEST stellt sicher, dass User Stories Independent, Negotiable, Valuable, Estimable, Small und Testable sind.

    +

    ⚓ INVEST stellt sicher, dass User Stories Independent, Negotiable, Valuable, Estimable, Small und Testable sind.

    -

    MoSCoW (Must have, Should have, Could have, Won’t have) liefert klare Priorisierung.

    +

    ⚓ MoSCoW (Must have, Should have, Could have, Won’t have) liefert klare Priorisierung.

    Die initiale Backlog-Reihenfolge folgt der EPIC-Sequenz. @@ -969,15 +969,15 @@

    Schritt 8: Issue für Issue

    -

    TDD (Test-Driven Development) gibt es in zwei Schulen:

    +

    ⚓ TDD (Test-Driven Development) gibt es in zwei Schulen:

    • -

      London School (Mockist): Unit Under Test isolieren, Abhängigkeiten mocken. Gut für interaktionslastigen Code.

      +

      ⚓ London School (Mockist): Unit Under Test isolieren, Abhängigkeiten mocken. Gut für interaktionslastigen Code.

    • -

      Chicago School (Classicist): Verhalten über die öffentliche API testen, echte Kollaborateure nutzen. Gut für zustandsbasierte Logik.

      +

      ⚓ Chicago School (Classicist): Verhalten über die öffentliche API testen, echte Kollaborateure nutzen. Gut für zustandsbasierte Logik.

    @@ -990,16 +990,16 @@

    Schritt 8: Issue für Issue
    • -

      DRY (Don’t Repeat Yourself)

      +

      ⚓ DRY (Don’t Repeat Yourself)

    • -

      SOLID-Prinzipien

      +

      ⚓ SOLID-Prinzipien

    • -

      KISS (Keep It Simple, Stupid)

      +

      ⚓ KISS (Keep It Simple, Stupid)

    • -

      Ubiquitous Language aus Domain-Driven Design: dieselben Begriffe im Code wie in der Spezifikation

      +

      ⚓ Ubiquitous Language aus Domain-Driven Design: dieselben Begriffe im Code wie in der Spezifikation

    @@ -1084,7 +1084,7 @@

    Schritt 10: Security Review

    -

    OWASP Top 10 deckt die kritischsten Sicherheitsrisiken für Webanwendungen ab. +

    ⚓ OWASP Top 10 deckt die kritischsten Sicherheitsrisiken für Webanwendungen ab. Auch für CLI-Tools oder Libraries identifiziert die Methodik gängige Schwachstellenmuster.

    diff --git a/docs/spec-driven-workflow.html b/docs/spec-driven-workflow.html index 44c8f97..99967b7 100644 --- a/docs/spec-driven-workflow.html +++ b/docs/spec-driven-workflow.html @@ -544,7 +544,7 @@

    Introduction

    -

    Semantic Anchors marked with are highlighted throughout this document. +

    Semantic Anchors marked with ⚓ are highlighted throughout this document. Click on any anchor to see its full definition on the Semantic Anchors website.

    @@ -613,15 +613,15 @@

    Cross-Cutting Concerns

    -
    Plain English according to Strunk & White
    +
    ⚓ Plain English according to Strunk & White

    All documentation uses short sentences, active voice, and no unnecessary words.

    -
    Conventional Commits
    +
    ⚓ Conventional Commits

    All commits follow a standardized format for a clean, parseable git history.

    -
    Docs-as-Code according to Ralf D. Müller
    +
    ⚓ Docs-as-Code according to Ralf D. Müller

    Documentation lives in the repository as AsciiDoc, built by docToolchain. Docs-as-Code treats documentation like source code: version-controlled, peer-reviewed, and built automatically.

    @@ -646,7 +646,7 @@

    Prerequisites

    Initialize a git repository

  • -

    Install docToolchain and download the arc42 template

    +

    Install docToolchain and download the ⚓ arc42 template

  • Configure your AI coding environment with an AGENTS.md (or tool-specific equivalent like CLAUDE.md)

    @@ -760,7 +760,7 @@

    Step 1: Describe Your Vision

    Step 2: Clarify Requirements with the Socratic Method

    -

    Prompt the AI to use the Socratic Method to clarify requirements.

    +

    Prompt the AI to use the ⚓ Socratic Method to clarify requirements.

    @@ -782,7 +782,7 @@

    Step 2: Clarify R

    -

    MECE (Mutually Exclusive, Collectively Exhaustive) ensures questions cover all areas without overlap.

    +

    ⚓ MECE (Mutually Exclusive, Collectively Exhaustive) ensures questions cover all areas without overlap.

    Continue the dialogue until both you and the AI are satisfied that the requirements are clear.

    @@ -816,7 +816,7 @@

    Step 4: Create Detailed Specifica

    -

    Gherkin (Given/When/Then) provides acceptance criteria that are both human-readable and machine-testable. +

    ⚓ Gherkin (Given/When/Then) provides acceptance criteria that are both human-readable and machine-testable. These criteria become the foundation for TDD later.

    @@ -841,21 +841,21 @@

    Step 5: Create arc42 Ar

    • -

    arc42 provides 12 sections covering everything from context to deployment. +

    ⚓ arc42 provides 12 sections covering everything from context to deployment. The AI knows the template structure and fills it appropriately.

    -

    C4 Diagrams combined with PlantUML provide text-based architecture visualization at four levels: Context, Container, Component, Code. +

    ⚓ C4 Diagrams combined with PlantUML provide text-based architecture visualization at four levels: Context, Container, Component, Code. The AI can create and modify these diagrams without graphical tools.

    Architecture Decision Records

    -

    Architecture decisions are documented as ADRs according to Nygard. +

    Architecture decisions are documented as ⚓ ADRs according to Nygard. Each ADR follows the structure: Title, Status, Context, Decision, Consequences.

    -

    For each decision, create a Pugh Matrix with a 3-point scale (-1, 0, +1) to evaluate alternatives against quality criteria.

    +

    For each decision, create a ⚓ Pugh Matrix with a 3-point scale (-1, 0, +1) to evaluate alternatives against quality criteria.

    @@ -877,7 +877,7 @@

    Architecture Decision Records

    Step 6: Architecture Review (ATAM)

    -

    Conduct an architecture review using the Architecture Tradeoff Analysis Method (ATAM):

    +

    Conduct an architecture review using the ⚓ Architecture Tradeoff Analysis Method (ATAM):

    @@ -911,10 +911,10 @@

    Step 7: Create Backlog

    -

    INVEST ensures User Stories are Independent, Negotiable, Valuable, Estimable, Small, and Testable.

    +

    ⚓ INVEST ensures User Stories are Independent, Negotiable, Valuable, Estimable, Small, and Testable.

    -

    MoSCoW (Must have, Should have, Could have, Won’t have) provides clear prioritization.

    +

    ⚓ MoSCoW (Must have, Should have, Could have, Won’t have) provides clear prioritization.

    The initial backlog order follows the EPIC sequence. @@ -968,15 +968,15 @@

    Step 8: Implement Issue by Issue

    -

    TDD (Test-Driven Development) comes in two schools:

    +

    ⚓ TDD (Test-Driven Development) comes in two schools:

    • -

      London School (mockist): isolate the unit under test, mock dependencies. Good for interaction-heavy code.

      +

      ⚓ London School (mockist): isolate the unit under test, mock dependencies. Good for interaction-heavy code.

    • -

      Chicago School (classicist): test behavior through the public API, use real collaborators. Good for state-based logic.

      +

      ⚓ Chicago School (classicist): test behavior through the public API, use real collaborators. Good for state-based logic.

    @@ -989,16 +989,16 @@

    Step 8: Implement Issue by Issue

    • -

      DRY (Don’t Repeat Yourself)

      +

      ⚓ DRY (Don’t Repeat Yourself)

    • -

      SOLID principles

      +

      ⚓ SOLID principles

    • -

      KISS (Keep It Simple, Stupid)

      +

      ⚓ KISS (Keep It Simple, Stupid)

    • -

      Ubiquitous Language from Domain-Driven Design: use the same terms in code as in the specification

      +

      ⚓ Ubiquitous Language from Domain-Driven Design: use the same terms in code as in the specification

    @@ -1083,7 +1083,7 @@

    Step 10: Security Review

    -

    OWASP Top 10 covers the most critical web application security risks. +

    ⚓ OWASP Top 10 covers the most critical web application security risks. Even for CLI tools or libraries, the methodology identifies common vulnerability patterns.