diff --git a/.github/copilot-instructions.md b/.github/copilot-instructions.md
index 9c793d3..1d68ea0 100644
--- a/.github/copilot-instructions.md
+++ b/.github/copilot-instructions.md
@@ -377,6 +377,18 @@ Diese Regeln gelten für alle Repositories in diesem Workspace. Projektspezifisc
 - Änderungen an dieser Regel erfordern ein gemeinsames Update in `constitution.md`, `.specify/memory/constitution.md`, `AGENTS.md`, `CLAUDE.md`, `GEMINI.md` und `.github/copilot-instructions.md`.
 
 *AI-generated and human-written software architecture MUST follow secure-architecture principles. Authoritative rules: `constitution.md`, Principle XIII. Core principles: trust boundaries (validate all input at system boundaries), defense in depth (at least two independent security layers), least privilege (minimum required permissions), fail-safe defaults (deny by default), attack surface reduction (disable unused features), separation of concerns (auth/logging/validation as cross-cutting concerns), secure configuration (secrets in secret stores, never in code or Git), supply-chain security (verified registries, lock files, no known-vulnerable dependencies). Principles XII + XIII together form the complete secure-development approach: XII = tactical code-level security, XIII = strategic architecture-level security. Changes require a joint update across `constitution.md`, `.specify/memory/constitution.md`, and all four agent guidance files.*
+
+## Allgemeine Software-Architektur / General Software Architecture (iSAQB / arc42)
+
+- Software-Architektur MUSS als explizites Design-Artefakt behandelt werden, wenn Änderungen Struktur, Schnittstellen, Quality Attributes, Laufzeitverhalten, Deployment oder technische Schulden berühren.
+- Verbindliche Regeln und Evidenzpfade: siehe `constitution.md`, Prinzip XX.
+- Architekturarbeit SOLL iSAQB/CPSA-F-Methodik und leichtgewichtige arc42-kompatible Dokumentation verwenden.
+- Architekturrelevante Entscheidungen MÜSSEN als ADRs dokumentiert werden; allgemeine ADRs standardmäßig in `docs/architecture/adr/`.
+- Systemkontext, Building Blocks, Runtime-Sichten, Deployment-Zwänge, Qualitäts-Szenarien sowie Architektur-Risiken oder akzeptierte Trade-offs MÜSSEN dokumentiert werden, wenn sie das Design materiell beeinflussen.
+- Allgemeine Architektur-Evidenz liegt standardmäßig unter `docs/architecture/`; Sicherheitsarchitektur verbleibt unter `docs/security/`.
+- Änderungen an dieser Regel erfordern ein gemeinsames Update in `constitution.md`, `.specify/memory/constitution.md`, `AGENTS.md`, `CLAUDE.md`, `GEMINI.md` und `.github/copilot-instructions.md`.
+
+*Software architecture MUST be treated as an explicit design artefact whenever changes affect structure, interfaces, quality attributes, runtime behavior, deployment, or technical debt. Authoritative rules: `constitution.md`, Principle XX. Architecture work SHOULD use iSAQB/CPSA-F discipline and lightweight arc42-compatible documentation. Architecturally significant decisions MUST be recorded as ADRs, defaulting to `docs/architecture/adr/`. Context, building blocks, runtime/deployment views, quality scenarios, and architecture risks or trade-offs MUST be documented when they materially affect the design. General architecture evidence defaults to `docs/architecture/`; security architecture remains under `docs/security/`. Changes require a joint update across `constitution.md`, `.specify/memory/constitution.md`, and all four agent guidance files.*
 ## Sicherheitsdokumentation / Security Documentation (XII–XVIII Extensions)
 
 - Jedes Level-2-Projekt MUSS die folgenden Sicherheitsdokumente pflegen, basierend auf den Templates in `.specify/templates/`:
@@ -417,6 +429,16 @@ Diese Regeln gelten für alle Repositories in diesem Workspace. Projektspezifisc
 
 *Capture the applicable standards and the evidence path in `spec.md`, `plan.md`, and `tasks.md`. Use `STRIDE` as the base for threat modeling and add relevant `CAPEC` patterns for the highest-risk flows. For web/API work, record the chosen `ASVS` level and verification scope in `docs/security/` or equivalent project documentation. For release and artefact work, plan `SBOM`, `VEX`, provenance/SLSA evidence, and `OpenSSF Scorecard` review where applicable. For architectural changes, evaluate `Zero Trust`; for long-lived projects, consider `OWASP SAMM` follow-up actions. The default evidence path is `docs/security/asvs-verification.md`, `docs/security/supply-chain-evidence.md`, `docs/security/zero-trust-applicability.md`, and `docs/security/samm-assessment.md`, unless the repository documents a justified equivalent location.*
 
+## Agentischer Architektur-Workflow / Agentic Architecture Workflow
+
+- In `spec.md`, `plan.md` und `tasks.md` festhalten, ob Systemkontext, Schnittstellen, Building Blocks, Laufzeitverhalten, Deployment oder technische Schulden betroffen sind.
+- Bei architekturrelevanten Änderungen passende Evidenz unter `docs/architecture/` planen und pflegen: Context View, Building-Block View, Runtime View, Deployment View, Quality Scenarios, ADRs sowie Architektur-Risiken.
+- Für architekturell signifikante Entscheidungen ADRs in `docs/architecture/adr/` anlegen oder aktualisieren.
+- Qualitätsanforderungen als konkrete Szenarien formulieren statt als unscharfe Adjektive.
+- Wenn Sicherheitsarchitektur betroffen ist, die Evidenzpfade unter `docs/security/` zusätzlich gemeinsam mit der allgemeinen Architektur-Evidenz aktualisieren.
+
+*In `spec.md`, `plan.md`, and `tasks.md`, record whether system context, interfaces, building blocks, runtime behavior, deployment, or technical debt are affected. For architecture-relevant changes, plan and maintain the matching evidence under `docs/architecture/`: context, building-block, runtime, deployment, quality-scenario, ADR, and architecture-risk artefacts. Create or update ADRs in `docs/architecture/adr/` for significant decisions. Express quality requirements as concrete scenarios rather than vague adjectives. If security architecture is affected, update the `docs/security/` evidence path together with the general architecture evidence.*
+
 <!-- SPECKIT START -->
 For additional context about technologies to be used, project structure,
 shell commands, and other important information, read the current plan
diff --git a/.specify/memory/constitution.md b/.specify/memory/constitution.md
index aa8216e..f40db45 100644
--- a/.specify/memory/constitution.md
+++ b/.specify/memory/constitution.md
@@ -1,16 +1,21 @@
 <!--
 Sync Impact Report
-Version change: 1.11.0 -> 1.12.0
+Version change: 1.12.0 -> 1.13.0
 Modified principles:
 - None (purely additive)
 Added sections:
-- None
+- XX. General Architecture Governance (iSAQB / arc42)
 Removed sections:
 - None
 Templates requiring updates:
 - ✅ .specify/templates/plan-template.md
 - ✅ .specify/templates/spec-template.md
 - ✅ .specify/templates/tasks-template.md
+- ✅ .specify/templates/commands/checklist.md
+- ✅ .specify/templates/commands/constitution.md
+- ✅ .specify/templates/commands/plan.md
+- ✅ .specify/templates/commands/spec.md
+- ✅ .specify/templates/commands/tasks.md
 - ✅ .specify/templates/asvs-verification-template.md
 - ✅ .specify/templates/supply-chain-evidence-template.md
 - ✅ .specify/templates/zero-trust-applicability-template.md
@@ -722,6 +727,43 @@ software placed on the EU market. Recording CRA applicability and aligning
 practices proactively reduces legal and reputational risk and builds on the
 security work already required by Principles XII–XVIII.
 
+### XX. General Architecture Governance (iSAQB / arc42)
+
+Software architecture MUST be treated as an explicit design artefact whenever
+changes affect structure, interfaces, quality attributes, runtime behavior,
+deployment, or long-term maintainability. Implementation work without visible
+architecture reasoning creates hidden coupling and unreviewed technical debt.
+
+Mandatory rules:
+- Architecture work SHOULD follow iSAQB/CPSA-F method discipline and use
+  lightweight arc42-compatible documentation where useful.
+- Architecturally significant decisions MUST be documented as Architecture
+  Decision Records (ADRs).
+- Quality attributes MUST be expressed as concrete scenarios, not only as
+  generic claims such as "fast", "maintainable", or "scalable".
+- System context, building blocks, runtime behavior, and deployment
+  constraints MUST be documented when they materially affect the design.
+- Architecture risks, accepted trade-offs, and technical debt MUST be
+  recorded with owner, impact, mitigation or repayment plan, and review
+  trigger.
+- Architecture documentation MUST stay proportional: enough to support
+  review, maintenance, onboarding, and later change decisions.
+- This principle covers general software architecture. Security-specific
+  architecture concerns such as trust boundaries, threat modeling,
+  STRIDE/CAPEC, Zero Trust, S-ADRs, and OWASP SAMM remain governed by
+  Principles XIII and XVII-XVIII and SHOULD be applied together when
+  security is in scope.
+- General architecture evidence defaults to `docs/architecture/`.
+  ADRs default to `docs/architecture/adr/`.
+- `N/A` decisions for architecture evidence MUST be documented with a
+  short rationale; silent omission is not allowed.
+
+**Rationale**: The secure-architecture principles already govern how systems
+must protect assets, but the newly integrated iSAQB/arc42 preset also requires
+an explicit general architecture work product layer. Making this separate
+layer constitutional keeps structure, quality attributes, ADRs, and technical
+debt visible instead of leaving them implicit in implementation diffs.
+
 ## Level-2 Project Environment Registry / Level-2-Projektumgebungsregister
 
 This registry consolidates the constitution-relevant Level-2 project facts
@@ -812,7 +854,7 @@ allowed path.
 `.github/copilot-instructions.md` for per-agent operational guidance. This
 constitution is the authoritative policy layer above all agent-specific files.
 
-**Version**: 1.12.0 | **Ratified**: 2026-03-31 | **Last Amended**: 2026-04-24
+**Version**: 1.13.0 | **Ratified**: 2026-03-31 | **Last Amended**: 2026-05-05
 
 <!-- EN: constitution.md placeholder
 [DE-Zusammenfassung: constitution.md beschreibt die Prinzipien und Standards für alle home-baseline Workspaces.]
diff --git a/.specify/templates/commands/checklist.md b/.specify/templates/commands/checklist.md
index 4858568..6a3a35b 100644
--- a/.specify/templates/commands/checklist.md
+++ b/.specify/templates/commands/checklist.md
@@ -8,6 +8,7 @@ Use this command to generate review checklists for a feature or release.
 2. Include governance checks for:
    - branch/PR compliance
    - constitution gate compliance
+   - architecture evidence completeness (`docs/architecture/`, ADRs, risks, quality scenarios when applicable)
    - test evidence completeness
    - coverage evidence (`>=70%` minimum, `>=80%` target tracking)
    - .NET 10 + C# 14.0 toolchain alignment
diff --git a/.specify/templates/commands/constitution.md b/.specify/templates/commands/constitution.md
index ddc57e8..818e89c 100644
--- a/.specify/templates/commands/constitution.md
+++ b/.specify/templates/commands/constitution.md
@@ -10,6 +10,7 @@ Use this command when governance or project rules change.
    - `.specify/templates/plan-template.md`
    - `.specify/templates/spec-template.md`
    - `.specify/templates/tasks-template.md`
+   - relevant files in `.specify/templates/commands/`
 4. Reconcile runtime guidance:
    - `AGENTS.md`
    - `CLAUDE.md`
@@ -20,6 +21,7 @@ Use this command when governance or project rules change.
    - `.NET 10` + `C# 14.0`
    - coverage gate `>=70%` with target `>=80%`
    - NuGet packages tracked against latest stable versions
+   - architecture evidence expectations under `docs/architecture/` and ADR usage when architecture rules changed
 
 ## Validation Checklist
 
@@ -28,3 +30,4 @@ Use this command when governance or project rules change.
 - Principles are declarative and auditable.
 - `main` protection workflow is respected (new branch + PR).
 - Toolchain/coverage/dependency rules are reflected in templates and guidance files.
+- Architecture governance expectations are reflected in templates and guidance files when applicable.
diff --git a/.specify/templates/commands/plan.md b/.specify/templates/commands/plan.md
index a105577..b0a8d31 100644
--- a/.specify/templates/commands/plan.md
+++ b/.specify/templates/commands/plan.md
@@ -8,6 +8,7 @@ Use this command to produce an implementation plan from an approved specificatio
 2. Execute the Constitution Check gates explicitly:
    - branching and PR flow
    - .NET 10 + C# 14.0 toolchain alignment
+   - general architecture evidence scope (`docs/architecture/`, ADRs, quality scenarios, risks/trade-offs)
    - architecture/layer boundaries
    - bilingual CEFR B2 documentation scope
    - XML documentation + DocFX regeneration scope
@@ -22,3 +23,4 @@ Use this command to produce an implementation plan from an approved specificatio
 
 - No gate is left unresolved without rationale.
 - Test, coverage, dependency, and documentation impacts are planned before implementation.
+- Architecture evidence impacts are planned before implementation.
diff --git a/.specify/templates/commands/spec.md b/.specify/templates/commands/spec.md
index cb1a719..7cdff9f 100644
--- a/.specify/templates/commands/spec.md
+++ b/.specify/templates/commands/spec.md
@@ -7,7 +7,8 @@ Use this command to create or update a feature specification.
 1. Create a branch for the feature (never work directly on `main`).
 2. Fill `spec.md` with prioritized, independently testable user stories.
 3. Define measurable outcomes and explicit edge cases.
-4. Fill the Constitution Alignment section with concrete impacts:
+4. Fill the Constitution Requirements and applicability sections with concrete impacts:
+   - general architecture evidence impact (`docs/architecture/`, ADRs, quality scenarios, risks/trade-offs)
    - .NET 10 + C# 14.0 toolchain impact
    - NuGet dependency currency impact
    - coverage thresholds (`>=70%`, target `>=80%`)
@@ -23,3 +24,4 @@ Use this command to create or update a feature specification.
 - Requirements are implementation-agnostic.
 - Constitution alignment items are complete and non-empty.
 - Toolchain/dependency/coverage constraints are explicit and measurable.
+- Architecture applicability and evidence expectations are explicit when the feature affects design structure.
diff --git a/.specify/templates/commands/tasks.md b/.specify/templates/commands/tasks.md
index 030b29b..cf673e1 100644
--- a/.specify/templates/commands/tasks.md
+++ b/.specify/templates/commands/tasks.md
@@ -6,14 +6,19 @@ Use this command to generate an executable task list from `plan.md` and `spec.md
 
 1. Organize tasks by user story for independent delivery.
 2. Include Red-Green-Refactor test tasks before implementation tasks.
-3. Include documentation tasks:
+3. Include architecture evidence tasks when the feature affects structure, interfaces, runtime behavior, deployment, or quality attributes:
+   - `docs/architecture/` updates
+   - ADRs in `docs/architecture/adr/`
+   - quality-scenario validation
+   - architecture risks / technical debt review
+4. Include documentation tasks:
    - bilingual updates (German block first, then English)
    - XML documentation completeness
    - `docfx docfx.json` run when API/XML docs changed
-4. Include coverage and dependency tasks:
+5. Include coverage and dependency tasks:
    - coverage evidence for `>=70%` minimum and `>=80%` target tracking
    - `dotnet list package --outdated` review and update tasks
-5. Include PR preparation task (purpose, touched projects, test evidence, config/API impact).
+6. Include PR preparation task (purpose, touched projects, test evidence, config/API impact).
 
 ## Validation Checklist
 
@@ -21,3 +26,4 @@ Use this command to generate an executable task list from `plan.md` and `spec.md
 - Documentation and governance tasks are present.
 - Task ordering supports incremental, verifiable delivery.
 - Coverage and dependency currency tasks are explicitly scheduled.
+- Architecture evidence tasks are explicitly scheduled when architecture is in scope.
diff --git a/.specify/templates/plan-template.md b/.specify/templates/plan-template.md
index c5e2aea..33be8a3 100644
--- a/.specify/templates/plan-template.md
+++ b/.specify/templates/plan-template.md
@@ -37,6 +37,11 @@
   MUST cite the matching row from the Level-2 Project Environment Registry in
   `constitution.md` and use its runtime, build/test, docs/A11Y, statistics, and
   agent-surface baselines.
+- **General architecture governance**: If this feature affects structure,
+  interfaces, building blocks, runtime behavior, deployment, quality
+  attributes, or technical debt, the plan MUST state which evidence under
+  `docs/architecture/` will be created or updated, whether ADRs are needed,
+  and how architecture risks or trade-offs will be tracked.
 - **Memory-safe languages (MSL)**: State the primary implementation language
   and confirm it is on the MSL allow-list in `constitution.md`, Principle XI.
   If the primary language is not an MSL (e.g. C, C++, Assembly, `cc65`), cite
@@ -78,6 +83,10 @@
   and which manual/Thorsten-Solo baseline applies.
 - **Agent guidance parity**: State whether `AGENTS.md`, `CLAUDE.md`,
   `GEMINI.md`, and `.github/copilot-instructions.md` are affected together.
+- **Architecture evidence**: Prefer `docs/architecture/` for context,
+  building-block, runtime, deployment, quality-scenario, ADR, and
+  architecture-risk evidence. If an equivalent location is used, state it
+  explicitly and justify the deviation.
 
 ## Project Structure
 
diff --git a/.specify/templates/spec-template.md b/.specify/templates/spec-template.md
index 44340f5..0418591 100644
--- a/.specify/templates/spec-template.md
+++ b/.specify/templates/spec-template.md
@@ -106,23 +106,27 @@
   EN-second unless a synchronized `.EN.md` companion is explicitly chosen.
 - **CR-004**: The feature MUST state whether statistics and AI-agent guidance
   files require synchronized updates.
-- **CR-005**: The feature MUST name its primary implementation language and
+- **CR-005**: The feature MUST state whether it affects system context,
+  interfaces, building blocks, runtime behavior, deployment, quality
+  attributes, or technical debt, and whether evidence under
+  `docs/architecture/` or ADRs in `docs/architecture/adr/` are required.
+- **CR-006**: The feature MUST name its primary implementation language and
   either confirm it is on the MSL allow-list (`constitution.md`, Principle XI)
   or cite the documented non-MSL justification from the Level-2
   `constitution.md`.
-- **CR-006**: The feature MUST determine the applicable security standards from
+- **CR-007**: The feature MUST determine the applicable security standards from
   `constitution.md`, Principles XIV-XVIII, and mark non-applicable standards
   as `N/A` with justification. `NIST SSDF` and `CWE Top 25` are mandatory for
   all Level-2 work.
-- **CR-007**: If the feature includes web/API/HTTP/auth-bearing services, it
+- **CR-008**: If the feature includes web/API/HTTP/auth-bearing services, it
   MUST declare the selected `OWASP ASVS` level and verification scope.
-- **CR-008**: If the feature creates releasable or distributable artefacts, it
+- **CR-009**: If the feature creates releasable or distributable artefacts, it
   MUST declare the intended `SBOM` / `VEX` evidence path and any required
   provenance / `SLSA` considerations.
-- **CR-009**: If the feature changes trust boundaries, externally reachable
+- **CR-010**: If the feature changes trust boundaries, externally reachable
   flows, or distributed/service architecture, it MUST state how `CAPEC` and
   `Zero Trust` applicability will be handled.
-- **CR-010**: The feature MUST state whether it uses the default evidence files
+- **CR-011**: The feature MUST state whether it uses the default evidence files
   in `docs/security/` (`asvs-verification.md`, `supply-chain-evidence.md`,
   `zero-trust-applicability.md`, `samm-assessment.md`) or an explicitly
   justified equivalent governance location.
diff --git a/.specify/templates/tasks-template.md b/.specify/templates/tasks-template.md
index 74b6471..e82d1fa 100644
--- a/.specify/templates/tasks-template.md
+++ b/.specify/templates/tasks-template.md
@@ -152,6 +152,10 @@ Examples of foundational tasks (adjust based on your project):
 
 - [ ] TXXX [P] Documentation updates in docs/
 - [ ] TXXX [P] Verify the implementation against the matching Level-2 Project Environment Registry row in `constitution.md`
+- [ ] TXXX [P] Update the relevant architecture evidence in `docs/architecture/` when system context, interfaces, building blocks, runtime behavior, deployment, or quality attributes changed
+- [ ] TXXX [P] Create or update ADRs in `docs/architecture/adr/` for architecturally significant decisions, trade-offs, or boundary changes
+- [ ] TXXX [P] Define and validate concrete architecture quality scenarios when non-functional requirements materially drive the design
+- [ ] TXXX [P] Record architecture risks, accepted trade-offs, and technical debt with owner and review trigger
 - [ ] TXXX [P] Verify primary implementation language against the MSL allow-list in `constitution.md`, Principle XI; cite the Level-2 non-MSL justification if applicable
 - [ ] TXXX [P] Run the required A11Y/text-first review path for affected user-facing artefacts
 - [ ] TXXX [P] Update `docs/project-statistics.md` when the feature changes statistics-relevant artefacts or delivery evidence
@@ -171,6 +175,7 @@ Examples of foundational tasks (adjust based on your project):
 - [ ] TXXX [P] If threat boundaries or externally reachable flows changed, update STRIDE threat modeling and add relevant `CAPEC` references for the highest-risk attack paths
 - [ ] TXXX [P] If the system is distributed, service-based, cloud, or remotely managed, document `Zero Trust` applicability; if the project is long-lived, note any `OWASP SAMM` follow-up actions
 - [ ] TXXX [P] Prefer the default evidence files `docs/security/asvs-verification.md`, `docs/security/supply-chain-evidence.md`, `docs/security/zero-trust-applicability.md`, and `docs/security/samm-assessment.md`; document and justify any equivalent governance location
+- [ ] TXXX [P] Run a final architecture consistency review across `spec.md`, `plan.md`, `tasks.md`, and the updated evidence in `docs/architecture/`
 - [ ] TXXX Run quickstart.md validation
 - [ ] TXXX Lastenheft umbenennen / Rename Lastenheft: `bash scripts/rename-lastenheft.sh <LH-Datei> <branch-name>` (macOS/Linux) . `pwsh scripts/rename-lastenheft.ps1 -File <LH-Datei> -BranchName <branch-name>` (Windows) - stamps the feature branch name onto the filename to mark it as archived
 
diff --git a/AGENTS.md b/AGENTS.md
index bb4a868..1d18c5d 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -296,6 +296,18 @@ Activation records use three reserved cells: Static Link, Dynamic Link, Return A
 - Änderungen an dieser Regel erfordern ein gemeinsames Update in `constitution.md`, `.specify/memory/constitution.md`, `AGENTS.md`, `CLAUDE.md`, `GEMINI.md` und `.github/copilot-instructions.md`.
 
 *AI-generated and human-written software architecture MUST follow secure-architecture principles. Authoritative rules: `constitution.md`, Principle XIII. Core principles: trust boundaries (validate all input at system boundaries), defense in depth (at least two independent security layers), least privilege (minimum required permissions), fail-safe defaults (deny by default), attack surface reduction (disable unused features), separation of concerns (auth/logging/validation as cross-cutting concerns), secure configuration (secrets in secret stores, never in code or Git), supply-chain security (verified registries, lock files, no known-vulnerable dependencies). Principles XII + XIII together form the complete secure-development approach: XII = tactical code-level security, XIII = strategic architecture-level security. Changes require a joint update across `constitution.md`, `.specify/memory/constitution.md`, and all four agent guidance files.*
+
+## Allgemeine Software-Architektur / General Software Architecture (iSAQB / arc42)
+
+- Software-Architektur MUSS als explizites Design-Artefakt behandelt werden, wenn Änderungen Struktur, Schnittstellen, Quality Attributes, Laufzeitverhalten, Deployment oder technische Schulden berühren.
+- Verbindliche Regeln und Evidenzpfade: siehe `constitution.md`, Prinzip XX.
+- Architekturarbeit SOLL iSAQB/CPSA-F-Methodik und leichtgewichtige arc42-kompatible Dokumentation verwenden.
+- Architekturrelevante Entscheidungen MÜSSEN als ADRs dokumentiert werden; allgemeine ADRs standardmäßig in `docs/architecture/adr/`.
+- Systemkontext, Building Blocks, Runtime-Sichten, Deployment-Zwänge, Qualitäts-Szenarien sowie Architektur-Risiken oder akzeptierte Trade-offs MÜSSEN dokumentiert werden, wenn sie das Design materiell beeinflussen.
+- Allgemeine Architektur-Evidenz liegt standardmäßig unter `docs/architecture/`; Sicherheitsarchitektur verbleibt unter `docs/security/`.
+- Änderungen an dieser Regel erfordern ein gemeinsames Update in `constitution.md`, `.specify/memory/constitution.md`, `AGENTS.md`, `CLAUDE.md`, `GEMINI.md` und `.github/copilot-instructions.md`.
+
+*Software architecture MUST be treated as an explicit design artefact whenever changes affect structure, interfaces, quality attributes, runtime behavior, deployment, or technical debt. Authoritative rules: `constitution.md`, Principle XX. Architecture work SHOULD use iSAQB/CPSA-F discipline and lightweight arc42-compatible documentation. Architecturally significant decisions MUST be recorded as ADRs, defaulting to `docs/architecture/adr/`. Context, building blocks, runtime/deployment views, quality scenarios, and architecture risks or trade-offs MUST be documented when they materially affect the design. General architecture evidence defaults to `docs/architecture/`; security architecture remains under `docs/security/`. Changes require a joint update across `constitution.md`, `.specify/memory/constitution.md`, and all four agent guidance files.*
 ## Sicherheitsdokumentation / Security Documentation (XII–XVIII Extensions)
 
 - Jedes Level-2-Projekt MUSS die folgenden Sicherheitsdokumente pflegen, basierend auf den Templates in `.specify/templates/`:
@@ -336,6 +348,16 @@ Activation records use three reserved cells: Static Link, Dynamic Link, Return A
 - Default-Evidenzpfad: `docs/security/asvs-verification.md`, `docs/security/supply-chain-evidence.md`, `docs/security/zero-trust-applicability.md`, `docs/security/samm-assessment.md`; Abweichungen nur mit lokal dokumentierter Begründung.
 
 *Capture the applicable standards and the evidence path in `spec.md`, `plan.md`, and `tasks.md`. Use `STRIDE` as the base for threat modeling and add relevant `CAPEC` patterns for the highest-risk flows. For web/API work, record the chosen `ASVS` level and verification scope in `docs/security/` or equivalent project documentation. For release and artefact work, plan `SBOM`, `VEX`, provenance/SLSA evidence, and `OpenSSF Scorecard` review where applicable. For architectural changes, evaluate `Zero Trust`; for long-lived projects, consider `OWASP SAMM` follow-up actions. The default evidence path is `docs/security/asvs-verification.md`, `docs/security/supply-chain-evidence.md`, `docs/security/zero-trust-applicability.md`, and `docs/security/samm-assessment.md`, unless the repository documents a justified equivalent location.*
+
+## Agentischer Architektur-Workflow / Agentic Architecture Workflow
+
+- In `spec.md`, `plan.md` und `tasks.md` festhalten, ob Systemkontext, Schnittstellen, Building Blocks, Laufzeitverhalten, Deployment oder technische Schulden betroffen sind.
+- Bei architekturrelevanten Änderungen passende Evidenz unter `docs/architecture/` planen und pflegen: Context View, Building-Block View, Runtime View, Deployment View, Quality Scenarios, ADRs sowie Architektur-Risiken.
+- Für architekturell signifikante Entscheidungen ADRs in `docs/architecture/adr/` anlegen oder aktualisieren.
+- Qualitätsanforderungen als konkrete Szenarien formulieren statt als unscharfe Adjektive.
+- Wenn Sicherheitsarchitektur betroffen ist, die Evidenzpfade unter `docs/security/` zusätzlich gemeinsam mit der allgemeinen Architektur-Evidenz aktualisieren.
+
+*In `spec.md`, `plan.md`, and `tasks.md`, record whether system context, interfaces, building blocks, runtime behavior, deployment, or technical debt are affected. For architecture-relevant changes, plan and maintain the matching evidence under `docs/architecture/`: context, building-block, runtime, deployment, quality-scenario, ADR, and architecture-risk artefacts. Create or update ADRs in `docs/architecture/adr/` for significant decisions. Express quality requirements as concrete scenarios rather than vague adjectives. If security architecture is affected, update the `docs/security/` evidence path together with the general architecture evidence.*
 ## Hinweise / Notes
 
 - Diese Datei ergaenzt die projektspezifische Dokumentation mit agentischen Arbeitsregeln.
diff --git a/CLAUDE.md b/CLAUDE.md
index 435ffdb..5fd05b1 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -283,6 +283,18 @@ Use `CompilerOptions.Dialect` when modifying parser/lexer. Classic mode must sta
 - Änderungen an dieser Regel erfordern ein gemeinsames Update in `constitution.md`, `.specify/memory/constitution.md`, `AGENTS.md`, `CLAUDE.md`, `GEMINI.md` und `.github/copilot-instructions.md`.
 
 *AI-generated and human-written software architecture MUST follow secure-architecture principles. Authoritative rules: `constitution.md`, Principle XIII. Core principles: trust boundaries (validate all input at system boundaries), defense in depth (at least two independent security layers), least privilege (minimum required permissions), fail-safe defaults (deny by default), attack surface reduction (disable unused features), separation of concerns (auth/logging/validation as cross-cutting concerns), secure configuration (secrets in secret stores, never in code or Git), supply-chain security (verified registries, lock files, no known-vulnerable dependencies). Principles XII + XIII together form the complete secure-development approach: XII = tactical code-level security, XIII = strategic architecture-level security. Changes require a joint update across `constitution.md`, `.specify/memory/constitution.md`, and all four agent guidance files.*
+
+## Allgemeine Software-Architektur / General Software Architecture (iSAQB / arc42)
+
+- Software-Architektur MUSS als explizites Design-Artefakt behandelt werden, wenn Änderungen Struktur, Schnittstellen, Quality Attributes, Laufzeitverhalten, Deployment oder technische Schulden berühren.
+- Verbindliche Regeln und Evidenzpfade: siehe `constitution.md`, Prinzip XX.
+- Architekturarbeit SOLL iSAQB/CPSA-F-Methodik und leichtgewichtige arc42-kompatible Dokumentation verwenden.
+- Architekturrelevante Entscheidungen MÜSSEN als ADRs dokumentiert werden; allgemeine ADRs standardmäßig in `docs/architecture/adr/`.
+- Systemkontext, Building Blocks, Runtime-Sichten, Deployment-Zwänge, Qualitäts-Szenarien sowie Architektur-Risiken oder akzeptierte Trade-offs MÜSSEN dokumentiert werden, wenn sie das Design materiell beeinflussen.
+- Allgemeine Architektur-Evidenz liegt standardmäßig unter `docs/architecture/`; Sicherheitsarchitektur verbleibt unter `docs/security/`.
+- Änderungen an dieser Regel erfordern ein gemeinsames Update in `constitution.md`, `.specify/memory/constitution.md`, `AGENTS.md`, `CLAUDE.md`, `GEMINI.md` und `.github/copilot-instructions.md`.
+
+*Software architecture MUST be treated as an explicit design artefact whenever changes affect structure, interfaces, quality attributes, runtime behavior, deployment, or technical debt. Authoritative rules: `constitution.md`, Principle XX. Architecture work SHOULD use iSAQB/CPSA-F discipline and lightweight arc42-compatible documentation. Architecturally significant decisions MUST be recorded as ADRs, defaulting to `docs/architecture/adr/`. Context, building blocks, runtime/deployment views, quality scenarios, and architecture risks or trade-offs MUST be documented when they materially affect the design. General architecture evidence defaults to `docs/architecture/`; security architecture remains under `docs/security/`. Changes require a joint update across `constitution.md`, `.specify/memory/constitution.md`, and all four agent guidance files.*
 ## Sicherheitsdokumentation / Security Documentation (XII–XVIII Extensions)
 
 - Jedes Level-2-Projekt MUSS die folgenden Sicherheitsdokumente pflegen, basierend auf den Templates in `.specify/templates/`:
@@ -323,6 +335,16 @@ Use `CompilerOptions.Dialect` when modifying parser/lexer. Classic mode must sta
 - Default-Evidenzpfad: `docs/security/asvs-verification.md`, `docs/security/supply-chain-evidence.md`, `docs/security/zero-trust-applicability.md`, `docs/security/samm-assessment.md`; Abweichungen nur mit lokal dokumentierter Begründung.
 
 *Capture the applicable standards and the evidence path in `spec.md`, `plan.md`, and `tasks.md`. Use `STRIDE` as the base for threat modeling and add relevant `CAPEC` patterns for the highest-risk flows. For web/API work, record the chosen `ASVS` level and verification scope in `docs/security/` or equivalent project documentation. For release and artefact work, plan `SBOM`, `VEX`, provenance/SLSA evidence, and `OpenSSF Scorecard` review where applicable. For architectural changes, evaluate `Zero Trust`; for long-lived projects, consider `OWASP SAMM` follow-up actions. The default evidence path is `docs/security/asvs-verification.md`, `docs/security/supply-chain-evidence.md`, `docs/security/zero-trust-applicability.md`, and `docs/security/samm-assessment.md`, unless the repository documents a justified equivalent location.*
+
+## Agentischer Architektur-Workflow / Agentic Architecture Workflow
+
+- In `spec.md`, `plan.md` und `tasks.md` festhalten, ob Systemkontext, Schnittstellen, Building Blocks, Laufzeitverhalten, Deployment oder technische Schulden betroffen sind.
+- Bei architekturrelevanten Änderungen passende Evidenz unter `docs/architecture/` planen und pflegen: Context View, Building-Block View, Runtime View, Deployment View, Quality Scenarios, ADRs sowie Architektur-Risiken.
+- Für architekturell signifikante Entscheidungen ADRs in `docs/architecture/adr/` anlegen oder aktualisieren.
+- Qualitätsanforderungen als konkrete Szenarien formulieren statt als unscharfe Adjektive.
+- Wenn Sicherheitsarchitektur betroffen ist, die Evidenzpfade unter `docs/security/` zusätzlich gemeinsam mit der allgemeinen Architektur-Evidenz aktualisieren.
+
+*In `spec.md`, `plan.md`, and `tasks.md`, record whether system context, interfaces, building blocks, runtime behavior, deployment, or technical debt are affected. For architecture-relevant changes, plan and maintain the matching evidence under `docs/architecture/`: context, building-block, runtime, deployment, quality-scenario, ADR, and architecture-risk artefacts. Create or update ADRs in `docs/architecture/adr/` for significant decisions. Express quality requirements as concrete scenarios rather than vague adjectives. If security architecture is affected, update the `docs/security/` evidence path together with the general architecture evidence.*
 ## Hinweise / Notes
 
 - Diese Datei ergaenzt die projektspezifische Dokumentation mit agentischen Arbeitsregeln.
diff --git a/GEMINI.md b/GEMINI.md
index ecae16e..e708deb 100644
--- a/GEMINI.md
+++ b/GEMINI.md
@@ -155,6 +155,18 @@ The project uses Golden Master tests for the lexer and parser. To update these a
 - Änderungen an dieser Regel erfordern ein gemeinsames Update in `constitution.md`, `.specify/memory/constitution.md`, `AGENTS.md`, `CLAUDE.md`, `GEMINI.md` und `.github/copilot-instructions.md`.
 
 *AI-generated and human-written software architecture MUST follow secure-architecture principles. Authoritative rules: `constitution.md`, Principle XIII. Core principles: trust boundaries (validate all input at system boundaries), defense in depth (at least two independent security layers), least privilege (minimum required permissions), fail-safe defaults (deny by default), attack surface reduction (disable unused features), separation of concerns (auth/logging/validation as cross-cutting concerns), secure configuration (secrets in secret stores, never in code or Git), supply-chain security (verified registries, lock files, no known-vulnerable dependencies). Principles XII + XIII together form the complete secure-development approach: XII = tactical code-level security, XIII = strategic architecture-level security. Changes require a joint update across `constitution.md`, `.specify/memory/constitution.md`, and all four agent guidance files.*
+
+## Allgemeine Software-Architektur / General Software Architecture (iSAQB / arc42)
+
+- Software-Architektur MUSS als explizites Design-Artefakt behandelt werden, wenn Änderungen Struktur, Schnittstellen, Quality Attributes, Laufzeitverhalten, Deployment oder technische Schulden berühren.
+- Verbindliche Regeln und Evidenzpfade: siehe `constitution.md`, Prinzip XX.
+- Architekturarbeit SOLL iSAQB/CPSA-F-Methodik und leichtgewichtige arc42-kompatible Dokumentation verwenden.
+- Architekturrelevante Entscheidungen MÜSSEN als ADRs dokumentiert werden; allgemeine ADRs standardmäßig in `docs/architecture/adr/`.
+- Systemkontext, Building Blocks, Runtime-Sichten, Deployment-Zwänge, Qualitäts-Szenarien sowie Architektur-Risiken oder akzeptierte Trade-offs MÜSSEN dokumentiert werden, wenn sie das Design materiell beeinflussen.
+- Allgemeine Architektur-Evidenz liegt standardmäßig unter `docs/architecture/`; Sicherheitsarchitektur verbleibt unter `docs/security/`.
+- Änderungen an dieser Regel erfordern ein gemeinsames Update in `constitution.md`, `.specify/memory/constitution.md`, `AGENTS.md`, `CLAUDE.md`, `GEMINI.md` und `.github/copilot-instructions.md`.
+
+*Software architecture MUST be treated as an explicit design artefact whenever changes affect structure, interfaces, quality attributes, runtime behavior, deployment, or technical debt. Authoritative rules: `constitution.md`, Principle XX. Architecture work SHOULD use iSAQB/CPSA-F discipline and lightweight arc42-compatible documentation. Architecturally significant decisions MUST be recorded as ADRs, defaulting to `docs/architecture/adr/`. Context, building blocks, runtime/deployment views, quality scenarios, and architecture risks or trade-offs MUST be documented when they materially affect the design. General architecture evidence defaults to `docs/architecture/`; security architecture remains under `docs/security/`. Changes require a joint update across `constitution.md`, `.specify/memory/constitution.md`, and all four agent guidance files.*
 ## Sicherheitsdokumentation / Security Documentation (XII/XIII Extensions)
 
 - Jedes Level-2-Projekt MUSS die folgenden Sicherheitsdokumente pflegen, basierend auf den Templates in `.specify/templates/`:
@@ -190,6 +202,16 @@ The project uses Golden Master tests for the lexer and parser. To update these a
 - Default-Evidenzpfad: `docs/security/asvs-verification.md`, `docs/security/supply-chain-evidence.md`, `docs/security/zero-trust-applicability.md`, `docs/security/samm-assessment.md`; Abweichungen nur mit lokal dokumentierter Begründung.
 
 *Capture the applicable standards and the evidence path in `spec.md`, `plan.md`, and `tasks.md`. Use `STRIDE` as the base for threat modeling and add relevant `CAPEC` patterns for the highest-risk flows. For web/API work, record the chosen `ASVS` level and verification scope in `docs/security/` or equivalent project documentation. For release and artefact work, plan `SBOM`, `VEX`, provenance/SLSA evidence, and `OpenSSF Scorecard` review where applicable. For architectural changes, evaluate `Zero Trust`; for long-lived projects, consider `OWASP SAMM` follow-up actions. The default evidence path is `docs/security/asvs-verification.md`, `docs/security/supply-chain-evidence.md`, `docs/security/zero-trust-applicability.md`, and `docs/security/samm-assessment.md`, unless the repository documents a justified equivalent location.*
+
+## Agentischer Architektur-Workflow / Agentic Architecture Workflow
+
+- In `spec.md`, `plan.md` und `tasks.md` festhalten, ob Systemkontext, Schnittstellen, Building Blocks, Laufzeitverhalten, Deployment oder technische Schulden betroffen sind.
+- Bei architekturrelevanten Änderungen passende Evidenz unter `docs/architecture/` planen und pflegen: Context View, Building-Block View, Runtime View, Deployment View, Quality Scenarios, ADRs sowie Architektur-Risiken.
+- Für architekturell signifikante Entscheidungen ADRs in `docs/architecture/adr/` anlegen oder aktualisieren.
+- Qualitätsanforderungen als konkrete Szenarien formulieren statt als unscharfe Adjektive.
+- Wenn Sicherheitsarchitektur betroffen ist, die Evidenzpfade unter `docs/security/` zusätzlich gemeinsam mit der allgemeinen Architektur-Evidenz aktualisieren.
+
+*In `spec.md`, `plan.md`, and `tasks.md`, record whether system context, interfaces, building blocks, runtime behavior, deployment, or technical debt are affected. For architecture-relevant changes, plan and maintain the matching evidence under `docs/architecture/`: context, building-block, runtime, deployment, quality-scenario, ADR, and architecture-risk artefacts. Create or update ADRs in `docs/architecture/adr/` for significant decisions. Express quality requirements as concrete scenarios rather than vague adjectives. If security architecture is affected, update the `docs/security/` evidence path together with the general architecture evidence.*
 ## Hinweise / Notes
 
 - Diese Datei ergaenzt die projektspezifische Dokumentation mit agentischen Arbeitsregeln.
diff --git a/docs/project-statistics.md b/docs/project-statistics.md
index 1133bc3..3ac053c 100644
--- a/docs/project-statistics.md
+++ b/docs/project-statistics.md
@@ -1,6 +1,6 @@
 # Projektstatistik TinyPl0
 
-Stand: 2026-03-27
+Stand: 2026-05-05
 
 ## Zweck und Pflege
 
@@ -63,34 +63,35 @@ fortgeschrieben.
 
 | Kennzahl | Wert |
 |---|---:|
-| Beobachtbarer Projektzeitraum | 2026-02-08 bis 2026-03-15 |
-| Git-Commits gesamt | 186 |
+| Beobachtbarer Projektzeitraum | 2026-02-08 bis 2026-05-05 |
+| Git-Commits gesamt | 252 |
 | Autoren laut Git | 2 |
-| Git-Aktivtage | 20 |
-| Produktionscode aktuell | 58 Dateien / 6536 Zeilen |
-| Testcode aktuell | 15 Dateien / 3351 Zeilen |
-| Dokumentation aktuell | 380 Dateien / 19686 Zeilen |
-| Davon Spec-Kit-Artefakte | 21 Dateien / 3291 Zeilen |
-| Davon Governance/Agent-Dateien | 5 Dateien / 976 Zeilen |
-| Gesamtbasis fuer Handschaetzung (inkl. Dokumentation) | 29573 Zeilen |
-| Erfahrener Entwickler, konservative Untergrenze | 369.7 Arbeitstage |
-| Erfahrener Entwickler, konservative Untergrenze in Stunden | 2883.4 Stunden (369.7 * 7.8) |
-| Erfahrener Entwickler, brutto | 17.2 Arbeitsmonate (21.5 Tage/Monat) |
-| Erfahrener Entwickler, TVoeD-Annahme | 19.5 Kalendermonate bzw. 1.6 Jahre |
-| Thorsten solo, erfahrungsadjustierte Untergrenze | 236.6 Arbeitstage |
-| Thorsten solo, erfahrungsadjustierte Untergrenze in Stunden | 1845.4 Stunden (236.6 * 7.8) |
-| Thorsten solo, brutto | 11.0 Arbeitsmonate (21.5 Tage/Monat) |
-| Thorsten solo, TVoeD-Annahme | 12.5 Kalendermonate bzw. 1.0 Jahre |
-| Kleines Team (3 Personen, +20 % Koordination), Untergrenze | 147.9 Arbeitstage |
-| Kleines Team (3 Personen, +20 % Koordination), TVoeD-Annahme | 7.8 Kalendermonate |
-| Repo-weiter Beschleunigungsfaktor vs. konservative Referenz | 18.5x (369.7 / 20 Git-Aktivtage) |
-| Repo-weiter Beschleunigungsfaktor vs. Thorsten-Referenz | 11.8x (236.6 / 20 Git-Aktivtage) |
+| Git-Aktivtage | 43 |
+| Produktionscode aktuell | 88 Dateien / 6950 Zeilen |
+| Testcode aktuell | 22 Dateien / 3536 Zeilen |
+| Dokumentation aktuell | 562 Dateien / 36625 Zeilen |
+| Davon Spec-Kit-Artefakte | 155 Dateien / 11436 Zeilen |
+| Davon Governance/Agent-Dateien | 5 Dateien / 2263 Zeilen |
+| Gesamtbasis fuer Handschaetzung (inkl. Dokumentation) | 47111 Zeilen |
+| Erfahrener Entwickler, konservative Untergrenze | 588.9 Arbeitstage |
+| Erfahrener Entwickler, konservative Untergrenze in Stunden | 4593.3 Stunden (588.9 * 7.8) |
+| Erfahrener Entwickler, brutto | 27.4 Arbeitsmonate (21.5 Tage/Monat) |
+| Erfahrener Entwickler, TVoeD-Annahme | 31.0 Kalendermonate bzw. 2.6 Jahre |
+| Thorsten solo, erfahrungsadjustierte Untergrenze | 376.9 Arbeitstage |
+| Thorsten solo, erfahrungsadjustierte Untergrenze in Stunden | 2939.8 Stunden (376.9 * 7.8) |
+| Thorsten solo, brutto | 17.5 Arbeitsmonate (21.5 Tage/Monat) |
+| Thorsten solo, TVoeD-Annahme | 19.8 Kalendermonate bzw. 1.7 Jahre |
+| Kleines Team (3 Personen, +20 % Koordination), Untergrenze | 235.6 Arbeitstage |
+| Kleines Team (3 Personen, +20 % Koordination), TVoeD-Annahme | 12.4 Kalendermonate |
+| Repo-weiter Beschleunigungsfaktor vs. konservative Referenz | 13.7x (588.9 / 43 Git-Aktivtage) |
+| Repo-weiter Beschleunigungsfaktor vs. Thorsten-Referenz | 8.8x (376.9 / 43 Git-Aktivtage) |
 
 ## Branch-Ueberblick
 
 | Branch/Ref | Letzte sichtbare Aktivitaet | Einordnung |
 |---|---|---|
 | `002-vm-inc-compat` | 2026-03-27 | Aktiver Feature-Branch fuer die SPEC-Kit-Spezifikation zur `Inc`-/`Int`-VM-Kompatibilitaet |
+| `codex/constitution-preset-sync` | 2026-05-05 | Arbeitsbranch fuer die Governance-Pruefung nach Installation der sechs neuen Spec-Kit-Presets |
 | `main` | 2026-03-15 | Integrationsbranch |
 | `origin/main` | 2026-03-15 | Remote-Tracking-Branch |
 
@@ -269,6 +270,44 @@ rekonstruiert.
     Der `docfx`-Lauf regenerierte ausserdem ausgeschlossene `api/*.yml`-
     Artefakte, die gemaess Methodik nicht in die Handarbeitsbasis eingehen.
 
+### 6. Constitution-/Preset-Synchronisierung nach sechs neuen Spec-Kit-Presets
+
+- Status: im Arbeitsbranch `codex/constitution-preset-sync` fuer Commit und
+  Push vorbereitet; noch nicht in `main`
+- Beobachtbarer Zeitraum: 2026-05-05 bis 2026-05-05
+- Commit-Bild: aktueller Governance-Aenderungssatz vor dem Branch-Commit
+- Grundlegende Arbeiten: Pruefung der bestehenden Verfassung gegen die sechs
+  neu installierten Presets (`a11y-governance`, `agent-parity-governance`,
+  `architecture-governance`, `cross-platform-governance`,
+  `isaqb-architecture-governance`, `security-governance`), Ergaenzung eines
+  neuen allgemeinen Architektur-Grundsatzes in
+  `.specify/memory/constitution.md`, Synchronisierung der Spec-Kit-Templates
+  und Command-Templates sowie gleichlautende Nachpflege in `AGENTS.md`,
+  `CLAUDE.md`, `GEMINI.md` und `.github/copilot-instructions.md`.
+- Git-/Arbeitsbaum-Aenderungsvolumen fuer den aktuellen Aenderungssatz vor
+  dieser Ledger-Fortschreibung:
+  - Produktionscode: 0 Zeilen
+  - Testcode: 0 Zeilen
+  - Dokumentation: 162 Zeilen netto in Governance-, Template- und
+    Agent-Dateien
+- Konservative Handarbeits-Basis fuer Code und Dokumentation:
+  - 162 Zeilen netto gesamt
+  - 2.0 Arbeitstage fuer einen erfahrenen Entwickler
+  - 15.8 Stunden auf TVoeD-Basis (`2.0 * 7.8`)
+  - 0.1 Arbeitsmonate brutto bzw. 0.1 TVoeD-Kalendermonate
+- Thorsten-Solo-Referenz:
+  - 1.3 Arbeitstage
+  - 10.1 Stunden auf TVoeD-Basis (`1.3 * 7.8`)
+  - 0.1 Arbeitsmonate brutto bzw. 0.1 TVoeD-Kalendermonate
+- Blended Repository Speedup gegen sichtbare 1 Git-Aktivtag fuer diesen
+  Aenderungssatz:
+  - 2.0x gegen die konservative 80-Zeilen-Referenz
+  - 1.3x gegen die Thorsten-Solo-Referenz mit 125 Zeilen pro Arbeitstag
+- Vor dem Commit-/Push-Schritt wurden zusaetzlich die Versionsfelder in
+  `src/Pl0.Ide/Pl0.Ide.csproj` auf den neuen Commit-Zielstand synchronisiert;
+  diese Projektmetadatenpflege liegt ausserhalb der reinen
+  Produktionscode-/Testcode-/Markdown-Taxonomie.
+
 ## Einordnung der KI-/Spec-Kit-Wirkung
 
 - Die beobachtbare manuelle Gesamtbasis liegt bereits bei 29573 Zeilen
@@ -316,13 +355,14 @@ rekonstruiert.
 | 2026-03-30 | Bilinguale Abschlusspruefung und A11Y-Gate in Pflichtenheften verankert | `Pflichtenheft_PL0_CSharp_DotNet10.md`, `Pflichtenheft_PL0_Dokumentation.md` und `Pflichtenheft_IDE.md` nennen jetzt ausdruecklich die Abschlusspruefpunkte fuer Bilingualitaet, CEFR-B2-Niveau und A11Y. Zusaetzlich ist fuer grosse normative Dokumente eine synchron gepflegte `.EN.md`-Parallelfassung als zulaessige, uebersichtlichere Lieferform dokumentiert. Fuer DocFX-basierte HTML-Dokumentation ist die A11Y-Pflicht mit WCAG 2.2 AA, textorientiertem Review nach `docfx` sowie Nutzbarkeit fuer Braille-Zeile, Screenreader und Textbrowser Teil der Abnahme. Diese Runde war reine Dokumentationsarbeit mit `0` Produktionscode-Zeilen, `0` Testcode-Zeilen und ca. `+10` Dokumentationszeilen netto. Konservative Manualreferenz: 80 Zeilen/Tag = `0.1` Tage (ca. `1.0` Stunden); Thorsten-Solo-Referenz: 125 Zeilen/Tag = `0.1` Tage (ca. `0.6` Stunden); sichtbares Arbeitsfenster: 1 kurze Agentensitzung am 2026-03-30. |
 | 2026-03-30 | Parent-Guidance bewusst auf repo-uebergreifende Regeln begrenzt | In den lokalen Guidance-Dateien von `TinyPl0` ist jetzt ausdruecklich vermerkt, dass `/Users/thorstenhindermann/RiderProjects/AGENTS.md` nur gemeinsame Basisregeln fuer mehrere Repositories traegt. Repository-spezifische Build-, Test-, Workflow-, Architektur- und Feature-Vorgaben bleiben bewusst in `TinyPl0` selbst und sind dort die spezifischere Autoritaet. Diese Runde war reine Dokumentationsarbeit mit `0` Produktionscode-Zeilen, `0` Testcode-Zeilen und ca. `+10` Dokumentationszeilen netto. Konservative Manualreferenz: 80 Zeilen/Tag = `0.1` Tage (ca. `1.0` Stunden); Thorsten-Solo-Referenz: 125 Zeilen/Tag = `0.1` Tage (ca. `0.6` Stunden); sichtbares Arbeitsfenster: 1 kurze Agentensitzung am 2026-03-30. |
 | 2026-03-30 | Gemeinsame Governance- und Statistik-Baseline mit TuiVision abgeglichen | `AGENTS.md`, `CLAUDE.md`, `GEMINI.md`, `.github/copilot-instructions.md`, `README.md`, die drei Pflichtenhefte und `docs/project-statistics.md` wurden gegen die repo-uebergreifende Oberbasis aus `/Users/thorstenhindermann/RiderProjects/AGENTS.md`, die Merknote `project-statistics-tail-block.md` und den gemeinsamen Governance-/Doku-Stand von `TuiVision` abgeglichen. Nachgezogen wurden nur gemeinsame Regeln: `.EN.md` fuer grosse normative Dokumente bei kanonischer deutscher Fassung, formale Abschlusskriterien fuer DE-first/EN-second auf CEFR-B2 und fuer den dokumentierten A11Y-Nachweis nach `Programmierung #include<everyone>`, die DocFX-Folgepruefung mit Playwright/axe und `lynx`, text-first-A11Y fuer Braille-Zeile, Screenreader und Textbrowser sowie der finale `## Gesamtstatistik`-Block mit ASCII-Diagrammen. Zusaetzlich wurden fuer den anstehenden Branch-Commit die IDE-Versionsfelder in `src/Pl0.Ide/Pl0.Ide.csproj` auf `1.2.209.14` synchronisiert und der IDE-Worklog in `Pflichtenheft_IDE.md` fortgeschrieben. Diese Runde war reine Governance-/Doku-Arbeit mit `0` Produktionscode-Zeilen, `0` Testcode-Zeilen und ca. `+135` Dokumentationszeilen netto zuzueglich Projektmetadatenpflege ausserhalb der Markdown-Taxonomie. Konservative Manualreferenz: 80 Zeilen/Tag = `1.7` Tage (ca. `13.2` Stunden); Thorsten-Solo-Referenz: 125 Zeilen/Tag = `1.1` Tage (ca. `8.4` Stunden); sichtbares Arbeitsfenster: 1 Agentensitzung am 2026-03-30. |
+| 2026-05-05 | Constitution- und Preset-Sync nach Sechs-Preset-Integration | Die vorhandene `.specify/memory/constitution.md` wurde gegen die sechs neu installierten Spec-Kit-Presets geprueft. Ergebnis: A11Y-, Agent-Parity-, Cross-Platform-, Security- und Secure-Architecture-Governance waren bereits weitgehend gespiegelt; nachgezogen werden musste der allgemeine iSAQB-/arc42-Architektur-Grundsatz samt Evidenzpfad `docs/architecture/`. Dafuer wurden Constitution, Spec-Kit-Templates, Command-Templates sowie `AGENTS.md`, `CLAUDE.md`, `GEMINI.md` und `.github/copilot-instructions.md` synchron aktualisiert. Vor dem angeforderten Commit/Pull wurden ausserdem die IDE-Versionsfelder auf den neuen Zielstand `1.2.252.14` angehoben. Aenderungsumfang dieser Runde vor dieser Ledger-Fortschreibung: `0` Produktionscode-Zeilen, `0` Testcode-Zeilen und `+162` Dokumentationszeilen netto zuzueglich Projektmetadatenpflege ausserhalb der Markdown-Taxonomie. Konservative Manualreferenz: `2.0` Tage bzw. `15.8` Stunden; Thorsten-Solo-Referenz: `1.3` Tage bzw. `10.1` Stunden; sichtbares Arbeitsfenster: 1 Agentensitzung am 2026-05-05. |
 
 ## Gesamtstatistik
 
-- Stand 2026-03-30: `58` Produktionsdateien mit `6536` Zeilen, `15` Testdateien mit `3351` Zeilen und `380` Dokumentationsdateien mit `19686` Zeilen.
-- Die beobachtbare Gesamtbasis fuer die manuelle Referenz liegt bei `29573` Zeilen. Das entspricht konservativ `369.7` Arbeitstagen fuer einen erfahrenen Entwickler oder `236.6` Arbeitstagen fuer die Thorsten-Solo-Referenz; sichtbar dokumentiert sind `20` Git-Aktivtage.
-- Repo-weite Beschleunigungsfaktoren aus dem aktuellen Ledger: `18.5x` gegen die konservative 80-Zeilen-Referenz und `11.8x` gegen die Thorsten-Solo-Referenz.
-- Phasenkuerzel in den Diagrammen: `0` = Compiler-Basis, `1` = Doku/API, `2` = IDE, `3` = Governance/L10N, `4` = Pages/CI/DocFX, `5` = Branch `002-vm-inc-compat`.
+- Stand 2026-05-05: `88` Produktionsdateien mit `6950` Zeilen, `22` Testdateien mit `3536` Zeilen und `562` Dokumentationsdateien mit `36625` Zeilen.
+- Die beobachtbare Gesamtbasis fuer die manuelle Referenz liegt bei `47111` Zeilen. Das entspricht konservativ `588.9` Arbeitstagen fuer einen erfahrenen Entwickler oder `376.9` Arbeitstagen fuer die Thorsten-Solo-Referenz; sichtbar dokumentiert sind `43` Git-Aktivtage.
+- Repo-weite Beschleunigungsfaktoren aus dem aktuellen Ledger: `13.7x` gegen die konservative 80-Zeilen-Referenz und `8.8x` gegen die Thorsten-Solo-Referenz.
+- Phasenkuerzel in den Diagrammen: `0` = Compiler-Basis, `1` = Doku/API, `2` = IDE, `3` = Governance/L10N, `4` = Pages/CI/DocFX, `5` = Branch `002-vm-inc-compat`, `6` = Constitution-/Preset-Sync.
 
 Diese Schlusssektion fasst den aktuellen Repository-Stand bewusst textfreundlich zusammen. Die ASCII-Diagramme bleiben grob und ohne Farbcode, damit sie auf Braille-Zeile, mit Screenreadern und in Textbrowsern gut lesbar bleiben.
 
@@ -330,9 +370,9 @@ This closing section summarizes the current repository state in a deliberately t
 
 ```text
 Aktueller Artefaktmix im Repository (Zeilen)
-Produktion | ########                 |  6536
-Tests      | ####                     |  3351
-Doku       | ######################## | 19686
+Produktion | #####                    |  6950
+Tests      | ###                      |  3536
+Doku       | ######################## | 36625
 ```
 
 Dieser Block zeigt, wie stark TinyPl0 inzwischen von Dokumentation, Lehrmaterial und Governance-Artefakten gepraegt ist. Das ist fuer ein Lern- und Referenzprojekt erwartbar: Code, Tests und Dokumentation wachsen hier bewusst zusammen.
@@ -347,6 +387,7 @@ Dokumentiertes Volumen je Phase/Branch (Zeilen)
 3 Gov   | #################        |  8679
 4 CI    | #                        |    14
 5 002   | ###                      |  1557
+6 Sync  | #                        |   162
 ```
 
 Dieses Diagramm zeigt die grossen Lieferpakete ueber die bisher dokumentierten Phasen. Man sieht sofort, dass die Doku/API-Welle und die spaetere Governance-/L10N-Phase fuer TinyPl0 besonders viel sichtbaren Umfang gebracht haben.
@@ -355,14 +396,15 @@ This chart shows the major delivery packages across the phases documented so far
 
 ```text
 Dokumentierte Beschleunigungsfaktoren
-Repo80  | ############             | 18.5x
-Repo125 | ########                 | 11.8x
+Repo80  | ###########              | 13.7x
+Repo125 | #######                  |  8.8x
 0 Comp  | ###############          | 22.1x
 1 Doku  | ###############          | 22.3x
 2 IDE   | ##############           | 21.4x
 3 Gov   | ######################## | 36.2x
 4 CI    | #                        |  0.1x
 5 002   | #############            | 19.5x
+6 Sync  | #                        |  2.0x
 ```
 
 Hier werden keine Stoppuhrzeiten gemessen. Verglichen wird die dokumentierte Lieferdichte gegen zwei manuelle Referenzen. Hohe Werte bedeuten also: viel sichtbarer Output in wenigen belegten Aktivtagen.
@@ -371,9 +413,9 @@ This chart does not measure stopwatch time. It compares documented delivery dens
 
 ```text
 Vergleich dokumentierter Gesamtaufwand / sichtbares KI-Lieferfenster
-Erfahren    | ######################## | 369.7 d
-Thorsten    | ###############          | 236.6 d
-KI sichtbar | #                        |  20.0 d
+Erfahren    | ######################## | 588.9 d
+Thorsten    | ###############          | 376.9 d
+KI sichtbar | ##                       |  43.0 d
 ```
 
 Dieser Vergleich macht die grobe Groessenordnung sichtbar: Zwischen klassischer Handarbeit und dem im Repository sichtbaren Lieferfenster liegt eine deutliche Verdichtung. Genau diese Verdichtung beschreibt das Ledger als blended repository speedup.
@@ -381,15 +423,15 @@ Dieser Vergleich macht die grobe Groessenordnung sichtbar: Zwischen klassischer
 This comparison makes the scale visible at a glance: there is clear compression between classical manual effort and the delivery window visible in the repository. That documented compression is what the ledger labels as blended repository speedup.
 
 ```text
-X/Y-Diagramm: dokumentiertes Phasenvolumen (X = 0..5, Y = Zeilen)
+X/Y-Diagramm: dokumentiertes Phasenvolumen (X = 0..6, Y = Zeilen)
 12500 |  *
 10000 |
  7500 |      *
  5000 |*   *
  2500 |          *
-    0 |        *
-      +------------
-       0 1 2 3 4 5
+    0 |        * *
+      +--------------
+       0 1 2 3 4 5 6
 ```
 
 Als zweite Ansicht zeigt diese X/Y-Kurve denselben Verlauf ueber die Phasenachse. So werden Spruenge zwischen benachbarten Paketen leichter lesbar als in einer reinen Liste.
@@ -397,14 +439,14 @@ Als zweite Ansicht zeigt diese X/Y-Kurve denselben Verlauf ueber die Phasenachse
 As a second view, this X/Y curve shows the same progression across the phase axis. That makes jumps between neighboring packages easier to read than in a plain list.
 
 ```text
-X/Y-Diagramm: dokumentierte Beschleunigungsfaktoren (X = 0..5, Y = Faktor)
+X/Y-Diagramm: dokumentierte Beschleunigungsfaktoren (X = 0..6, Y = Faktor)
  40 |      *
  30 |
  20 |* * *     *
  10 |
-  0 |        *
-    +------------
-     0 1 2 3 4 5
+  0 |        * *
+    +--------------
+     0 1 2 3 4 5 6
 ```
 
 Diese zweite X/Y-Ansicht zeigt die dokumentierten Beschleunigungsfaktoren je Phase. Fehlende oder sehr kleine Punkte sind nicht automatisch schlecht; sie bedeuten hier nur, dass ein Paket klein war oder dass die sichtbare Aktivtag-Basis kaum Verdichtung zeigt.
diff --git a/src/Pl0.Ide/Pl0.Ide.csproj b/src/Pl0.Ide/Pl0.Ide.csproj
index aec87b5..6adde22 100644
--- a/src/Pl0.Ide/Pl0.Ide.csproj
+++ b/src/Pl0.Ide/Pl0.Ide.csproj
@@ -14,9 +14,9 @@
     <TargetFramework>net10.0</TargetFramework>
     <ImplicitUsings>enable</ImplicitUsings>
     <Nullable>enable</Nullable>
-    <Version>1.2.209.14</Version>
-    <AssemblyVersion>1.2.209.14</AssemblyVersion>
-    <FileVersion>1.2.209.14</FileVersion>
+    <Version>1.2.252.14</Version>
+    <AssemblyVersion>1.2.252.14</AssemblyVersion>
+    <FileVersion>1.2.252.14</FileVersion>
     <InformationalVersion>$(Version)</InformationalVersion>
     <GenerateDocumentationFile>true</GenerateDocumentationFile>
     <NoWarn>$(NoWarn);1591</NoWarn>