restruc

docs/index.md

@@ -10,6 +10,6 @@ Welcome to the documentation for The Biergarten App.
 
 ## Documentation Sections
 
-- **[Architecture](architecture.md)** — System design and components
-- **[Website](website/getting-started.md)** — Backend and frontend documentation
+- **[Architecture](web/architecture.md)** — System design and components
+- **[Website](web/getting-started.md)** — Backend and frontend documentation
 - **[Pipeline](pipeline/README.md)** — Data pipeline and ETL processes

docs/pipeline/README.md

@@ -302,11 +302,11 @@ see ETHICS-AND-KNOWN-ISSUES.md's Names-by-Country Dataset section.
 
 ### Process flow - activity diagram
 
-![An activity diagram](./diagrams/current/output/activity.svg)
+See [Activity diagram](./diagrams/current/activity.md).
 
 ### Architectural overview - class diagram
 
-![A class diagram](./diagrams/current/output/class.svg)
+See [Class diagram](./diagrams/current/class.md).
 
 ---
 

docs/pipeline/diagrams/current/activity.md

@@ -3,5 +3,5 @@
 The only concurrency in the current pipeline is a dedicated log dispatcher thread that drains `log_channel` and forwards entries to spdlog for the entire run (joined during shutdown after `log_channel` closes). `BiergartenPipelineOrchestrator::Run()` itself is synchronous — sampling, enrichment, generation, and export all happen on the main thread.
 
 ```mermaid
---8<-- "diagrams/pipeline/current/activity.mmd"
+--8<-- "pipeline/diagrams/current/activity.mmd"
 ```

docs/pipeline/diagrams/current/class.md

@@ -1,5 +1,5 @@
 # The Biergarten Data Pipeline — Class Diagram (Current)
 
 ```mermaid
---8<-- "diagrams/pipeline/current/class.mmd"
+--8<-- "pipeline/diagrams/current/class.mmd"
 ```

docs/pipeline/diagrams/planned/activity.md

@@ -3,5 +3,5 @@
 Each generation phase runs a producer/consumer trio concurrently: an **Orchestrator** producer feeds a bounded channel, an **LLM Worker** consumes it and generates records (closing its output channel when the input is drained and closed), and a **SQLite Worker** consumes that output channel and commits in batches. The Checkin and Follow phases run in parallel with each other once the user and brewery pools are populated.
 
 ```mermaid
---8<-- "diagrams/pipeline/planned/activity.mmd"
+--8<-- "pipeline/diagrams/planned/activity.mmd"
 ```

docs/pipeline/diagrams/planned/class.md

@@ -1,7 +1,7 @@
 # Biergarten Data Pipeline — Class Diagram (Planned)
 
 ```mermaid
---8<-- "diagrams/pipeline/planned/class.mmd"
+--8<-- "pipeline/diagrams/planned/class.mmd"
 ```
 
 ## Notes

docs/web/architecture.md

@@ -19,27 +19,25 @@ reference.
 
 For visual representations, see:
 
-- [architecture.svg](website/diagrams-out/architecture.svg) - Vertical-slice
-  architecture diagram
-- [deployment.svg](website/diagrams-out/deployment.svg) - Docker deployment
-  diagram
-- [database-schema.svg](website/diagrams-out/database-schema.svg) - Database
-  relationships
+- [Vertical Slice](diagrams/vertical-slice.md) - host wiring and project
+  reference diagrams
+- [Deployment](diagrams/deployment.md) - Docker deployment diagram
+- [Database Schema](diagrams/database-schema.md) - database relationships
 
 Authentication workflow diagrams, one per flow, under
-`website/diagrams-out/auth/`:
+[`diagrams/auth/`](diagrams/auth/):
 
-- [registration.svg](website/diagrams-out/auth/registration.svg)
-- [login.svg](website/diagrams-out/auth/login.svg)
-- [refresh-token.svg](website/diagrams-out/auth/refresh-token.svg)
-- [confirm-user.svg](website/diagrams-out/auth/confirm-user.svg)
-- [resend-confirmation.svg](website/diagrams-out/auth/resend-confirmation.svg)
-- [update-username.svg](website/diagrams-out/auth/update-username.svg)
-- [update-email.svg](website/diagrams-out/auth/update-email.svg)
-- [update-password.svg](website/diagrams-out/auth/update-password.svg)
-- [update-profile.svg](website/diagrams-out/auth/update-profile.svg)
-- [delete-account.svg](website/diagrams-out/auth/delete-account.svg)
-- [error-handling.svg](website/diagrams-out/auth/error-handling.svg) - shared
+- [Registration](diagrams/auth/registration.md)
+- [Login](diagrams/auth/login.md)
+- [Refresh Token](diagrams/auth/refresh-token.md)
+- [Confirm User](diagrams/auth/confirm-user.md)
+- [Resend Confirmation](diagrams/auth/resend-confirmation.md)
+- [Update Username](diagrams/auth/update-username.md)
+- [Update Email](diagrams/auth/update-email.md)
+- [Update Password](diagrams/auth/update-password.md)
+- [Update Profile](diagrams/auth/update-profile.md)
+- [Delete Account](diagrams/auth/delete-account.md)
+- [Error Handling](diagrams/auth/error-handling.md) - shared
   `GlobalExceptionFilter` mapping used by all flows above
 
 ## Backend architecture
@@ -370,7 +368,7 @@ method that registers its repository and slice-internal services
 - Application focuses on orchestration; the database enforces integrity via
   keys, `CHECK` constraints, and cascades
 
-See [Database](website/database.md) for the schema and the app's SQL
+See [Database](database.md) for the schema and the app's SQL
 error-handling approach in more detail.
 
 ## Frontend architecture
@@ -504,7 +502,7 @@ reference. Product and engineering documentation points to `web/frontend`.
 ## Database architecture
 
 For the table-by-table schema and the custom SQL error code scheme, see
-[Database](website/database.md).
+[Database](database.md).
 
 ### SQL-first philosophy
 
@@ -555,7 +553,7 @@ tracking stays valid.
 **Purpose**: Populate development/test databases with realistic data
 
 **Implementation**: `Database.Seed` project, using data produced by the C++
-pipeline under `tooling/pipeline/` (see [Pipeline README](pipeline/README.md))
+pipeline under `tooling/pipeline/` (see [Pipeline README](../pipeline/README.md))
 
 **Seed Data**:
 
@@ -590,7 +588,7 @@ Tables that exist in the schema but have no repository yet (`UserAvatar`,
 - Testing (`docker-compose.test.yaml`)
 - Production (`docker-compose.prod.yaml`)
 
-For details, see [Docker Guide](website/docker.md).
+For details, see [Docker Guide](docker.md).
 
 ### Health checks
 
@@ -626,4 +624,4 @@ flowchart TB
 - Mock external dependencies
 - Test database for integration tests
 
-For details, see [Testing Guide](website/testing.md).
+For details, see [Testing Guide](testing.md).

docs/web/database.md

@@ -11,7 +11,7 @@ tags:
 
 SQL Server 2022 schema, migration approach, and the app's SQL error-handling
 convention. For the vertical-slice code that talks to this schema, see
-[Architecture](../architecture.md).
+[Architecture](architecture.md).
 
 ## Schema
 
@@ -42,7 +42,7 @@ script per table.
 
 Each script is run in order by `Database.Migrations` (DbUp) on startup. Each
 table is queried directly by the owning feature slice's repository (see
-[Direct SQL via Dapper/ADO.NET](../architecture.md#direct-sql-via-dapperadonet)).
+[Direct SQL via Dapper/ADO.NET](architecture.md#direct-sql-via-dapperadonet)).
 
 A generated DBML copy of the schema (for import into a diagramming tool such as
 dbdiagram.io) lives at `web/backend/Database/Database.Migrations/schema.dbml`.

docs/web/diagrams/auth/confirm-user.md

@@ -1,5 +1,5 @@
 # User Authentication Flow — Confirm User
 
 ```mermaid
---8<-- "diagrams/website/auth/confirm-user.mmd"
+--8<-- "web/diagrams/auth/confirm-user.mmd"
 ```

docs/web/diagrams/auth/delete-account.md

@@ -1,5 +1,5 @@
 # User Authentication Flow — Delete Account
 
 ```mermaid
---8<-- "diagrams/website/auth/delete-account.mmd"
+--8<-- "web/diagrams/auth/delete-account.mmd"
 ```

docs/web/diagrams/auth/error-handling.md

@@ -3,5 +3,5 @@
 Global exception mapping performed by `API.Core`'s `GlobalExceptionFilter`. Applies uniformly across every authentication endpoint (registration, login, refresh, confirm, resend, update-username/email/password/profile, delete-account) — see the per-flow diagrams for where each exception type is thrown.
 
 ```mermaid
---8<-- "diagrams/website/auth/error-handling.mmd"
+--8<-- "web/diagrams/auth/error-handling.mmd"
 ```

docs/web/diagrams/auth/login.md

@@ -1,5 +1,5 @@
 # User Authentication Flow — Login
 
 ```mermaid
---8<-- "diagrams/website/auth/login.mmd"
+--8<-- "web/diagrams/auth/login.mmd"
 ```

docs/web/diagrams/auth/refresh-token.md

@@ -1,5 +1,5 @@
 # User Authentication Flow — Refresh Token
 
 ```mermaid
---8<-- "diagrams/website/auth/refresh-token.mmd"
+--8<-- "web/diagrams/auth/refresh-token.mmd"
 ```

docs/web/diagrams/auth/registration.md

@@ -1,5 +1,5 @@
 # User Authentication Flow — Registration
 
 ```mermaid
---8<-- "diagrams/website/auth/registration.mmd"
+--8<-- "web/diagrams/auth/registration.mmd"
 ```

docs/web/diagrams/auth/resend-confirmation.md

@@ -1,5 +1,5 @@
 # User Authentication Flow — Resend Confirmation Email
 
 ```mermaid
---8<-- "diagrams/website/auth/resend-confirmation.mmd"
+--8<-- "web/diagrams/auth/resend-confirmation.mmd"
 ```

docs/web/diagrams/auth/update-email.md

@@ -1,5 +1,5 @@
 # User Authentication Flow — Update Email
 
 ```mermaid
---8<-- "diagrams/website/auth/update-email.mmd"
+--8<-- "web/diagrams/auth/update-email.mmd"
 ```

docs/web/diagrams/auth/update-password.md

@@ -1,5 +1,5 @@
 # User Authentication Flow — Update Password
 
 ```mermaid
---8<-- "diagrams/website/auth/update-password.mmd"
+--8<-- "web/diagrams/auth/update-password.mmd"
 ```

docs/web/diagrams/auth/update-profile.md

@@ -1,5 +1,5 @@
 # User Authentication Flow — Update Profile
 
 ```mermaid
---8<-- "diagrams/website/auth/update-profile.mmd"
+--8<-- "web/diagrams/auth/update-profile.mmd"
 ```

docs/web/diagrams/auth/update-username.md

@@ -1,5 +1,5 @@
 # User Authentication Flow — Update Username
 
 ```mermaid
---8<-- "diagrams/website/auth/update-username.mmd"
+--8<-- "web/diagrams/auth/update-username.mmd"
 ```

docs/web/diagrams/database-schema.md

@@ -3,5 +3,5 @@
 Every table also has a `RowVersion ROWVERSION` column (optimistic concurrency), omitted below for brevity. Tables marked `(*)` have no repository/feature slice yet.
 
 ```mermaid
---8<-- "diagrams/website/database-schema.mmd"
+--8<-- "web/diagrams/database-schema.mmd"
 ```

docs/web/diagrams/deployment.md

@@ -1,7 +1,7 @@
 # Docker Deployment Architecture
 
 ```mermaid
---8<-- "diagrams/website/deployment.mmd"
+--8<-- "web/diagrams/deployment.mmd"
 ```
 
 ## Notes

docs/web/diagrams/vertical-slice.md

@@ -11,7 +11,7 @@ assemblies to register — there's no shared bootstrap. `Database.Migrations`
 doesn't wire up any slice; it applies schema directly.
 
 ```mermaid
---8<-- "diagrams/website/architecture/host-wiring.mmd"
+--8<-- "web/diagrams/vertical-slice/host-wiring.mmd"
 ```
 
 ## Project reference dependencies
@@ -25,7 +25,7 @@ foundation projects (`Shared.Contracts`, `Domain.Entities`,
 see the notes for what else each of those foundation projects pulls in.
 
 ```mermaid
---8<-- "diagrams/website/architecture/project-references.mmd"
+--8<-- "web/diagrams/vertical-slice/project-references.mmd"
 ```
 
 ## Notes

docs/web/docker.md

@@ -21,7 +21,7 @@ The project uses Docker Compose to orchestrate multiple services:
 - React Router website (SSR frontend)
 - Test runners
 
-See the [deployment diagram](diagrams-out/deployment.svg) for visual
+See the [deployment diagram](diagrams/deployment.md) for visual
 representation.
 
 ## Docker Compose environments

docs/web/getting-started.md

@@ -159,6 +159,6 @@ reference; it is not part of the running stack.
 
 ## Next steps
 
-- Review [Architecture](../architecture.md)
+- Review [Architecture](architecture.md)
 - Run backend and frontend checks from [Testing](testing.md)
 - Use [Docker Guide](docker.md) for container troubleshooting