docs: sync constitution with installed presets

.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

.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.]

.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

.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.

.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.

.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.

.specify/templates/commands/tasks.md

@@ -6,18 +6,24 @@ 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
 
 - Every code change has corresponding tests.
 - 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.

.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
 

.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.