Skip to content

CLAUDE.md

Latest commit

 

History

History
392 lines (304 loc) · 48.6 KB

CLAUDE.md

File metadata and controls

392 lines (304 loc) · 48.6 KB
Raw

CLAUDE.md

This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.

Project Overview

MicroCalc is a modern C#/.NET 10 port of the historical Borland MicroCalc Pascal spreadsheet example (CALC.PAS, CALC.INC, CALC.HLP). It uses Terminal.Gui for its TUI and demonstrates agentic AI-driven legacy porting. The original Pascal files at the repo root serve as behavioral reference for formula semantics, help content, and UI parity.

Solution Structure

MicroCalc.sln
src/
  MicroCalc.Core/          # Domain logic — no UI dependencies
    Engine/                # MicroCalcEngine (orchestrates all spreadsheet operations)
    Formula/               # FormulaEvaluator + recursive-descent Parser
    Model/                 # Spreadsheet, Cell, CellAddress, SpreadsheetSpec, CellStatusFlags
    IO/                    # SpreadsheetJsonStorage, SpreadsheetPrinter
  MicroCalc.Tui/           # Terminal.Gui front end
    Program.cs             # Entry point; supports --smoke flag
    Help/                  # HelpDocument (loads CALC.HLP)
    Smoke/                 # TuiSmokeRunner (non-interactive verification)
    Resources/CALC.HLP     # Bundled help asset
tests/
  MicroCalc.Core.Tests/    # xUnit: MicroCalcEngineTests, FormulaGoldenTests
  MicroCalc.Tui.Tests/     # xUnit: TuiSmokeTests

Key constants (defined in SpreadsheetSpec): columns A–G, 21 rows (147 cells), cell input limit 70 chars, default field width 10.

Build and Test Commands

# Restore
dotnet restore MicroCalc.sln

# Build (CI-aligned)
dotnet build MicroCalc.sln --configuration Release --no-restore

# Run all tests (CI-aligned)
dotnet test MicroCalc.sln --configuration Release --no-build

# Run single test class
dotnet test tests/MicroCalc.Core.Tests/MicroCalc.Core.Tests.csproj --configuration Release --filter "FullyQualifiedName~FormulaGoldenTests"

# Start interactive TUI
dotnet run --project src/MicroCalc.Tui/MicroCalc.Tui.csproj

# Smoke run (non-interactive CI check)
dotnet run --no-build --configuration Release --project src/MicroCalc.Tui/MicroCalc.Tui.csproj -- --smoke

CI (.github/workflows/ci.yml) runs on main and all codex/** branches using Release configuration.

Architecture: Core Layer

MicroCalcEngine is the single façade for all spreadsheet operations: EditCell, Recalculate, FormatRange, Move, Clear, and rendering helpers. It holds a Spreadsheet (the cell grid) and a FormulaEvaluator.

FormulaEvaluator uses a hand-rolled recursive-descent Parser (private nested class). Supported syntax:

  • Arithmetic: +, -, *, /, ^
  • Cell reference: A1
  • Range sum: A1>B5 (using > as range operator, not SUM())
  • Functions: ABS, SQRT, SQR, SIN, COS, ARCTAN, LN, LOG, EXP, FACT
  • Cyclic reference detection via HashSet<CellAddress> per evaluation

CellStatusFlags is a [Flags] enum controlling cell type (Text, Constant, Formula, Calculated, Locked, OverWritten). Text overflow into adjacent cells is managed explicitly by MicroCalcEngine.

Save format is JSON (.mcalc.json); no legacy .MCS import.

Branching and PR Conventions

  • All work branches use either the agent branch form codex/<short-topic> or the numbered Spec-Kit form NNN-short-description.
  • When a dedicated feature branch has implemented the requirements of a Lastenheft, rename that file to Lastenheft_<topic>.<feature-branch>.md so the delivered scope stays traceable.
  • One focused PR per topic; add a PR description file docs/PR_TEXT_<TOPIC>.md.
  • Tests must pass under --configuration Release (not just Debug).
  • When a test calls dotnet run --no-build, pass the build configuration explicitly.

Repo Version Scheme

Directory.Build.props carries the repo-wide Version, AssemblyVersion, and FileVersion values for all projects using Major.Minor.Patch.Build:

  • Minor = current Spec-Kit feature/branch number, interpreted numerically as the canonical PR number for versioning (002 -> 2) and used immediately even before a GitHub PR exists
  • Patch = current commit count in that feature/PR branch (after committing the current change)
  • Build = manual build counter incremented before every dotnet build or dotnet test

Align the three version fields in Directory.Build.props whenever a commit is created or the branch is updated on a numbered Spec-Kit branch, before pushing.

Code Style

Governed by .editorconfig:

  • UTF-8, LF line endings, final newline, no trailing whitespace.
  • *.cs: 4-space indentation; *.csproj, *.sln, *.md, *.yml, *.json: 2-space indentation.
  • C# conventions: PascalCase for types/public members, _camelCase for private readonly fields.
  • Nullable reference types are enabled; do not suppress without reason.

Documentation & Language Rules

  • Documentation and didactic comments must be bilingual: German first, English second.
  • Write both language blocks at CEFR B2 readability so trainees can follow the codebase.
  • Large normative documents such as Pflichtenheft*.md and Lastenheft*.md may use a synchronized English sidecar with suffix .EN.md instead of an oversized inline-bilingual file; the German version remains canonical unless explicitly marked otherwise.
  • Public API changes must include complete XML docs (<summary>, <param>, <returns>, <exception> where applicable).
  • Do not suppress CS1591 globally; missing public XML docs are treated as errors.
  • If API signatures or XML comments change, regenerate DocFX output in the same PR/commit.
  • New or changed non-trivial logic must be reviewed for didactic inline-comment value when it affects learner understanding or maintainability.
  • Inline comments explain why a decision, trade-off, constraint, historical deviation, or proof boundary exists; do not add comments that merely restate obvious code.
  • Keep inline-comment intensity moderate: normally 1-3 lines before a non-trivial block, with German-first/English-second CEFR-B2 text for didactic explanation blocks.

Help File Resolution

CALC.HLP must be resolvable at runtime. It lives both at src/MicroCalc.Tui/Resources/CALC.HLP (bundled as a resource) and at the repo root (legacy reference). Path changes must preserve both locations.

Gemeinsame Governance-Ergaenzung / Shared Governance Addendum

  • Alle nutzerseitigen Artefakte muessen barrierefrei gedacht und geprueft werden: CLI-Ausgaben, Dokumentation, HTML, UI und generierte Templates; WCAG 2.2 Level AA ist die Standard-Basis, sobald die Kriterien auf das Artefakt anwendbar sind.

  • All user-facing artefacts must be designed and reviewed for accessibility: CLI output, documentation, HTML, UI, and generated templates; WCAG 2.2 Level AA is the default baseline wherever the criteria apply.

  • Fuer C#/.NET-Repositories gilt standardmaessig eine Thorsten-Solo-Basis von 125 Zeilen/Arbeitstag, sofern das Repo keinen abweichenden, begruendeten Wert dokumentiert.

  • The default Thorsten-solo baseline for C#/.NET repositories is 125 lines/workday unless the repository documents a justified deviation.

Active Technologies

  • C# 14 / .NET 10 + xUnit 2.x (tests); Terminal.Gui (TUI — untouched by this feature) (001-project-context)
  • N/A — JSON persistence format unchanged; new functions evaluated at runtime from (001-project-context)

Recent Changes

  • 001-project-context: Added C# 14 / .NET 10 + xUnit 2.x (tests); Terminal.Gui (TUI — untouched by this feature)

Agentische Skriptausfuehrung / Agentic Script Execution

  • Vor jeder Automationsaufgabe zuerst das Betriebssystem pruefen. Wenn ein passendes PowerShell-7-Skript oder Cmdlet vorhanden ist und pwsh verfuegbar ist, diese Variante bevorzugen. Fuer strukturierte lokale Automationen ist C# ueber .NET oder mono ein zulaessiger zweiter Weg, wenn Typisierung, Dateiformate oder Wiederverwendbarkeit dadurch klar besser werden. Erst wenn PowerShell oder C# nicht sinnvoll passen, die OS-nahe vorhandene Repo-Variante nutzen, auf macOS/Linux typischerweise Bash. Keine neue Sprache nur aus Bequemlichkeit einfuehren, wenn ein bestehendes Repo-Skript denselben Zweck erfuellt.
  • Detect the operating system before each automation task. If a matching PowerShell 7 script or cmdlet exists and pwsh is available, prefer that variant. For structured local automation, C# via .NET or mono is an acceptable second option when type safety, file formats, or reuse clearly benefit from it. Only when PowerShell or C# is not a good fit, use the existing OS-native repository variant, typically Bash on macOS/Linux. Do not introduce a new language merely for convenience when an existing repository script already solves the task.

Project Statistics

  • When shared AI-agent guidance, workflow conventions, or statistics methodology changes, review and update AGENTS.md, CLAUDE.md, GEMINI.md, .github/copilot-instructions.md, and .github/agents/copilot-instructions.md together when they are affected.
  • Shared guidance must not be updated in only one of these files; any intentional agent-specific divergence must be documented in the same change.
  • Maintain docs/project-statistics.md as the living statistics ledger for the repository.
  • Update the file after each completed Spec-Kit implementation phase, after each agent-driven repository change, or when a refresh is explicitly requested.
  • Within the ## Fortschreibungsprotokoll table, keep entries in strict chronological order: oldest entry at the top, newest and most recently added entry at the bottom; entries with the same date keep their insertion order.
  • Keep a final top-level ## Gesamtstatistik block as the last section of docs/project-statistics.md; no later top-level section should follow it.
  • Inside that final ## Gesamtstatistik block, maintain compact ASCII-only trend diagrams directly below the textual overall summary and refresh them together with every statistics update; cover at least the artifact mix, the documented branch/phase curves, the documented acceleration factors from agentic AI plus Spec-Kit/SDD support, and a direct comparison between experienced-developer effort, Thorsten-solo effort, and the visible AI-assisted delivery window.
  • Keep each short CEFR-B2 explanation directly adjacent to its matching ASCII diagram group.
  • When the data benefits from progression across an X-axis, add simple ASCII X/Y charts as a second visualization layer; keep them approximate, readable in plain Markdown, and explained in CEFR-B2 language.
  • Keep the statistics section plain-text friendly for Braille displays, screen readers, and text browsers; diagrams and explanations must stay understandable without relying on color or visual layout alone.
  • When DocFX content, documentation navigation, or API presentation changes, validate representative _site/ pages through a text-oriented review path, preferably with a local Playwright accessibility snapshot.
  • Treat every successful docfx regeneration as requiring the matching text-oriented A11y smoke check in the same work item.
  • Each update must capture branch or phase, observable work window, production/test/documentation line counts, main work packages, the conservative manual baseline of 80 manually created lines per workday across code, tests, and documentation, and the repo-specific Thorsten-Solo comparison baseline of 125 lines per workday for this Pascal-derived port.
  • When effort is converted into months, use explicit assumptions such as 21.5 workdays per month and, if applicable, 30 vacation days per year through calendar year 2026 and 31 vacation days per year from calendar year 2027 onward under a TVoeD-style 5-day-week calendar.
  • When reporting acceleration, compare both manual references against visible Git active days and label the result as a blended repository speedup rather than a stopwatch measurement.
  • When hour values are shown, convert the day-based estimates with the TVoeD working-day baseline of 7.8 hours (7h 48m) per day.

Inclusion & Accessibility

  • Programmierung #include<everyone> — Diese Lernbeispiele richten sich an Azubis (Fachinformatiker AE/SI) mit Deutsch und Englisch als Arbeitssprachen sowie an sehbehinderte Lernende, die mit Braille-Displays, Screen-Readern oder Textbrowsern arbeiten. Barrierefreiheit ist kein Nice-to-have, sondern Pflichtanforderung. Learner-facing guides, statistics, and generated HTML/API documentation must stay usable on Braille displays, with screen readers, and in text browsers.
  • Prefer semantic headings, lists, tables, and ASCII/text-first diagrams; do not encode essential meaning only through color, layout, or pointer-only affordances.
  • Treat WCAG 2.2 conformance level AA as the concrete review baseline for generated HTML documentation, especially for page language, bypass blocks, keyboard focus visibility, non-text contrast, and readable landmark structure.
  • If docfx output is regenerated, follow it with a text-oriented accessibility review, preferably with Playwright + @axe-core/playwright and a lynx cross-check.
  • Recommended A11y toolchain for DocFX-based repos: Node 24 LTS, npm, Playwright, @axe-core/playwright, and lynx.
  • Treat bilingual CEFR-B2 delivery and the documented A11Y proof path as formal completion criteria for learner-facing documentation and active requirement artifacts.

Shared Parent Guidance

  • The shared parent file /Users/thorstenhindermann/RiderProjects/AGENTS.md intentionally stores only repo-spanning baseline rules.
  • Keep repository-specific build, test, workflow, architecture, and feature guidance in this repository's own files; when both layers exist, the repository-local files are the more specific authority.

Level-2-Umgebungsregister / Level-2 Environment Registry

  • Die zentrale constitution.md enthält das verbindliche Level-2 Project Environment Registry.
  • Spec-Kit-Pläne und Claude-Arbeit in Level-2-Projekten müssen die passende Registry-Zeile als verbindlichen Kontext für Runtime, Build/Test, A11Y, Statistik und Agentenflächen verwenden.
  • Änderungen an einer Level-2-Runtime, Toolchain oder Statistik-Basis müssen constitution.md, .specify/memory/constitution.md und betroffene KI-Agenten-Dateien gemeinsam prüfen.

The central constitution.md contains the binding Level-2 Project Environment Registry. Spec-Kit plans and Claude work in Level-2 projects must use the matching registry row as binding context for runtime, build/test, A11Y, statistics, and agent surfaces. Changes to Level-2 runtime, toolchain, or statistics baselines require a joint review of constitution.md, .specify/memory/constitution.md, and affected AI-agent files.

Memory-Safe Languages (MSL) / Speichersichere Sprachen

  • Level-2-Projekte SOLLEN eine speichersichere Sprache (Memory-Safe Language, MSL) als primäre Laufzeit verwenden, wenn die Zielplattform es erlaubt.
  • Verbindliche MSL-Erlaubnisliste, Regeln und Begründungspflicht: siehe constitution.md, Prinzip XI.
  • MSL-Kurzliste: Rust, Swift, C#, F#, Java, Kotlin, Scala, Go, Dart, Python, Ruby, JavaScript, TypeScript, Haskell, OCaml, Erlang, Elixir, Ada, SPARK.
  • Nicht MSL (Begründung im Level-2-constitution.md erforderlich): C, C++, klassisches Objective-C, Assembly, cc65-C89, Zig (pre-1.0), Nim (manual), D ohne GC.
  • In Nicht-MSL-Repositories (z. B. C64Projects/cc65) die im Level-2-constitution.md hinterlegte Begründung im Plan- und Task-Kontext erwähnen.
  • speckit.constitution und speckit.specify SOLLEN bei Nicht-MSL-Primärsprache einen nicht blockierenden Hinweis ausgeben (Tooling-Aufgabe, separate Umsetzung).
  • Änderungen an dieser Empfehlung erfordern ein gemeinsames Update in constitution.md, .specify/memory/constitution.md, AGENTS.md, CLAUDE.md, GEMINI.md, .github/copilot-instructions.md und .github/agents/copilot-instructions.md.

Level-2 projects SHOULD use a memory-safe language (MSL) as their primary runtime when the target platform allows. Authoritative rules: constitution.md, Principle XI. MSL short list: Rust, Swift, C#/F#, Java/Kotlin/Scala, Go, Dart, Python, Ruby, JavaScript/TypeScript, Haskell, OCaml, Erlang/Elixir, Ada/SPARK. Non-MSL languages (C, C++, Assembly, cc65, Zig pre-1.0, …) require a documented justification in the Level-2 constitution.md. In non-MSL repositories (e.g. C64Projects/cc65), surface the documented justification in plans and tasks. speckit.constitution and speckit.specify SHOULD emit a non-blocking advisory warning when the primary language is not an MSL — tracked as a separate tooling task. Changes to this recommendation require a joint update across constitution.md, .specify/memory/constitution.md, and all four agent guidance files.

Sichere Code-Erzeugung / Secure Code Generation (ISO 27001/27002 A.8.28)

  • KI-generierter und menschlich geschriebener Code MUSS den etablierten Secure-Coding-Best-Practices der Zielsprache und des Frameworks folgen. LLMs erzeugen nicht zuverlässig sicheren Code; explizite Durchsetzung ist erforderlich.
  • Verbindliche Regeln und sprachspezifische Anforderungen: siehe constitution.md, Prinzip XII.
  • Sprachspezifische Kurzregeln (Detailprofil: .specify/templates/secure-coding-language-rules-template.md):
    • C / C89: Bounds-Checking, kein gets(), kein ungeprueftes sprintf()/strcpy(), CERT C.
    • C# / .NET: parametrisierte Queries, Output-Encoding gegen XSS, Anti-Forgery-Tokens, sichere Deserialisierung, Microsoft Secure Coding Guidelines.
    • Rust: unsafe isolieren und begruenden, keine Panic-Pfade aus nicht vertrauenswuerdigem Input, Deserialisierung validieren, cargo audit oder gleichwertig verwenden.
    • Go: HTTP-/Client-Timeouts setzen, context propagieren, SSRF pruefen, crypto/rand nutzen, govulncheck oder gleichwertig verwenden.
    • Swift: keine Force-Unwraps auf nicht vertrauenswuerdigen Daten, dekodierte Eingaben validieren, Keychain/CryptoKit/TLS-Defaults nutzen, Datei-URLs einschraenken.
    • Java / Kotlin: DTOs validieren, Persistence-Zugriffe parametrisieren, Deserialisierung beschraenken, Auth/CSRF/CORS/Session-Defaults pruefen.
    • Python: Boundary-Input validieren, keine unsichere Deserialisierung oder dynamische Ausfuehrung, subprocess/Dateipfade einschraenken, Dependency-Audit nutzen.
    • TypeScript / JavaScript: Runtime-Input validieren, XSS/Prototype-Pollution/SSRF pruefen, keine dynamische Code-Ausfuehrung, Lockfiles auditieren.
    • SQL: nur parametrisierte Statements, kein dynamisches SQL aus nicht vertrauenswuerdigem Input.
    • Bash: Variable in Anfuehrungszeichen ("$var"), kein eval auf nicht vertrauenswuerdigem Input, -- End-of-Options.
    • PowerShell: Set-StrictMode -Version Latest, validierte Parameter, kein Invoke-Expression auf nicht vertrauenswuerdigem Input.
  • Kryptografie: aktuelle Algorithmen (AES-256, RSA >= 3072, SHA-256+, Ed25519); veraltete (MD5, SHA-1 für Signaturen, DES, RC4) nur mit expliziter Risikobegründung.
  • Fehlerbehandlung darf keine internen Zustände, Stack-Traces oder Verbindungszeichenketten an Endbenutzer preisgeben.
  • Hinzugefügte Abhängigkeiten müssen aktiv gepflegt sein und dürfen keine bekannten kritischen CVEs aufweisen.
  • Code-Reviews MÜSSEN eine Sicherheitsperspektive für Eingabeverarbeitung, Authentifizierung, Autorisierung, Kryptografie und Datei-/Netzwerk-I/O enthalten.
  • Änderungen an dieser Regel erfordern ein gemeinsames Update in constitution.md, .specify/memory/constitution.md, AGENTS.md, CLAUDE.md, GEMINI.md, .github/copilot-instructions.md und .github/agents/copilot-instructions.md.

AI-generated and human-written code MUST follow the secure-coding best practices of the target language and framework. Authoritative rules: constitution.md, Principle XII, and .specify/templates/secure-coding-language-rules-template.md. Language-specific short rules cover C/C89, C#/.NET, Rust, Go, Swift, Java/Kotlin, Python, TypeScript/JavaScript, SQL, Bash, and PowerShell. MSL status does not replace secure API, I/O, auth, SQL, crypto, logging, or dependency review. Cryptography: use current algorithms (AES-256, SHA-256+, Ed25519); deprecated (MD5, SHA-1 for signatures, DES, RC4) only with explicit risk acknowledgement. Error handling must not expose internals. Dependencies must have no known critical CVEs. Code reviews must include a security perspective for input handling, auth, crypto, and I/O. Changes require a joint update across constitution.md, .specify/memory/constitution.md, and all four agent guidance files.

Sichere Software-Architektur / Secure Software Architecture (ISO 27001/27002 A.8.27)

  • KI-generierte und menschlich geschriebene Software-Architektur MUSS etablierten sicheren Architekturprinzipien folgen. Sicherer Code (Prinzip XII) ohne sichere Architektur reicht nicht aus — beide Ebenen müssen zusammenwirken.
  • Verbindliche Regeln und sprachspezifische Architekturvorgaben: siehe constitution.md, Prinzip XIII.
  • Verbindliche Architekturprinzipien:
    • Trust Boundaries: Explizite Vertrauensgrenzen definieren; alle Eingaben an Vertrauensgrenzen validieren und bereinigen.
    • Defense in Depth: Mindestens zwei unabhängige Sicherheitsschichten für kritische Assets.
    • Least Privilege: Jede Komponente, jeder Dienst und Prozess arbeitet mit minimalen Berechtigungen.
    • Fail-Safe Defaults: Zugriff standardmäßig verweigern, explizit gewähren; Fehlerpfade fallen in sicheren Zustand zurück.
    • Angriffsfläche reduzieren: Ungenutzte Endpunkte, Dienste und Debug-Funktionen deaktivieren oder entfernen.
    • Separation of Concerns: Authentifizierung, Autorisierung, Logging und Eingabevalidierung als Cross-Cutting Concerns implementieren, nicht ad-hoc verstreuen.
    • Sichere Konfiguration: Secrets in plattformgeeigneten Secret-Stores (z. B. Azure Key Vault, macOS Keychain), nie im Quellcode oder in Git-tracked Config-Dateien.
    • Supply-Chain-Sicherheit: Abhängigkeiten aus verifizierten Registries; Lock-Files committen; verwundbare Abhängigkeiten vor Release ersetzen.
  • Änderungen an dieser Regel erfordern ein gemeinsames Update in constitution.md, .specify/memory/constitution.md, AGENTS.md, CLAUDE.md, GEMINI.md, .github/copilot-instructions.md und .github/agents/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.

Sicherheitsdokumentation / Security Documentation (XII–XVIII Extensions)

  • Jedes Level-2-Projekt MUSS die folgenden Sicherheitsdokumente pflegen, basierend auf den Templates in .specify/templates/:
    • Bedrohungsmodell / Threat Model (threat-model-template.md) — STRIDE-Methodik, Trust Boundaries, Risikobewertung, CAPEC-Referenzen (Prinzip XIII + XVII)
    • Security Architecture Decision Records (S-ADR) (adr-template.md) — architektonische Sicherheitsentscheidungen mit Compliance-Nachweis (Prinzip XIII)
    • arc42 Section 8 Sicherheits-Querschnittskonzepte (arc42-security-template.md) — Authentifizierung, Autorisierung, Verschlüsselung, Eingabevalidierung, Fehlerbehandlung, Logging, Abhängigkeiten, Deployment (Prinzip XIII)
    • Sicherheits-Checkliste / Security Checklist (security-checklist-template.md) — sprachspezifische Code-Review-Checkliste (Prinzip XII)
    • Abhängigkeits-Audit / Dependency Audit (dependency-audit-template.md) — CVE-Tracking, Lizenz-Compliance, Supply-Chain-Sicherheit (Prinzip XII)
    • Sicherheits-Qualitätsszenarien / Security Quality Scenarios (security-quality-scenarios-template.md) — iSAQB CPSA-F Qualitätsszenario-Methodik (Prinzip XII + XIII, SHOULD)
    • ASVS-Verifikation / ASVS Verification (asvs-verification-template.md) — OWASP ASVS Level, Scope und Evidenz (Prinzip XV, Web-/API-Projekte MUST)
    • Supply-Chain-Evidenz / Supply Chain Evidence (supply-chain-evidence-template.md) — SBOM, AI-SBOM, VEX, SLSA, OpenSSF Scorecard (Prinzip XVI, releasefähige Projekte MUST; AI-SBOM nur bei KI-Runtime-/Produktkomponenten)
    • Zero-Trust-Anwendbarkeit / Zero Trust Applicability (zero-trust-applicability-template.md) — NIST SP 800-207-Bewertung (Prinzip XVIII, verteilte Systeme SHOULD)
    • SAMM-Bewertung / SAMM Assessment (samm-assessment-template.md) — OWASP SAMM Reifegrad und Verbesserungsplan (Prinzip XVIII, langlebige Projekte SHOULD)
  • Projektspezifische Instanzen werden in docs/security/ gepflegt; S-ADRs als einzelne Dateien in docs/security/adr/.

Every Level-2 project MUST maintain security documents based on templates in .specify/templates/: threat model (STRIDE+CAPEC), S-ADRs, arc42 Section 8 security concepts, security checklist, dependency audit, security quality scenarios (SHOULD), ASVS verification (web/API MUST), supply-chain evidence (release-capable MUST; AI-SBOM when AI runtime/product components apply), Zero Trust applicability note (distributed systems SHOULD), and SAMM assessment (long-lived projects SHOULD). Project-specific instances live in docs/security/; S-ADRs in docs/security/adr/. See constitution.md, Principles XII–XVIII for authoritative requirements.

Sicherheitsstandards & Anwendbarkeit / Security Standards & Applicability

  • Vor jeder Level-2-Aufgabe die anwendbaren Sicherheitsstandards aus constitution.md, Prinzipien XIV-XVIII bestimmen und explizit benennen.
  • NIST SSDF und CWE Top 25 gelten immer für Level-2-Arbeit.
  • OWASP ASVS gilt für Web-, API-, HTTP- und authentifizierte Dienste; der gewählte ASVS-Level muss benannt werden.
  • SBOM gilt für releasefähige oder verteilbare Artefakte; VEX, wenn bekannte Schwachstellen in ausgelieferten oder geprüften Komponenten bewertet werden müssen.
  • AI-SBOM gilt projektartabhängig bei KI-Modellen, KI-Diensten, Trainings-/Embedding-Daten, Inferenz-Infrastruktur oder KI-Runtime-Komponenten im ausgelieferten oder betriebenen System; reine Entwicklungswerkzeug-Nutzung wird als N/A mit Toolchain-Begründung dokumentiert.
  • SLSA gilt als Soll-Vorgabe für CI/CD- oder veröffentlichte Artefakte; Zero Trust ist für verteilte, servicebasierte, cloudnahe oder remote-verwaltete Systeme explizit zu prüfen.
  • CAPEC soll in Bedrohungsmodellen für die risikoreichsten Angriffswege verwendet werden; OWASP SAMM soll für langlebige Projekte/Workspaces in Verbesserungspläne einfließen.
  • OWASP Cheat Sheet Series, OWASP Proactive Controls und bei öffentlichen OSS-Repositories oder kritischen Abhängigkeiten OpenSSF Scorecard sind als ergänzende Referenzen zu berücksichtigen.
  • Nichtanwendbarkeit immer als N/A mit kurzer Begründung dokumentieren; keine stillschweigende Auslassung.

At the start of every Level-2 task, determine and name the applicable security standards from constitution.md, Principles XIV-XVIII. NIST SSDF and CWE Top 25 always apply. OWASP ASVS applies to web/API/HTTP/auth-bearing services; SBOM applies to releasable or distributable artefacts; AI-SBOM applies when AI models, AI services, datasets, inference infrastructure, or AI runtime components are part of the released or operated system; VEX applies when known vulnerabilities in shipped/evaluated components need a disposition statement. SLSA is the target model for CI/CD and published artefacts; Zero Trust must be explicitly evaluated for distributed, service-based, cloud, or remotely managed systems. CAPEC, OWASP SAMM, OWASP Cheat Sheet Series, OWASP Proactive Controls, and OpenSSF Scorecard are supporting references where relevant. Record non-applicability as N/A with justification rather than omitting it silently.

Agentischer Security-Workflow / Agentic Security Workflow

  • In spec.md, plan.md und tasks.md die anwendbaren Standards samt Evidenzpfad festhalten.
  • Bei Bedrohungsmodellen STRIDE als Basis und bei risikoreichen Flows zusätzlich relevante CAPEC-Patterns verwenden.
  • Bei Web/API-Features den ASVS-Level und den Verifikationsumfang in docs/security/ oder gleichwertiger Projektdokumentation ablegen.
  • KI-Nutzung explizit klassifizieren: Entwicklungswerkzeug, keine KI im ausgelieferten/betriebenen System, oder KI-Runtime-/Produktkomponente; AI-SBOM entsprechend als N/A begründen oder in der Supply-Chain-Evidenz dokumentieren.
  • Bei Release-/Artefakt-Arbeit SBOM, AI-SBOM, VEX, Provenance/SLSA-Nachweise und gegebenenfalls OpenSSF Scorecard in Release- oder Sicherheitsdokumentation einplanen.
  • Bei Architekturänderungen Zero Trust-Anwendbarkeit und bei langlebigen Projekten SAMM-Folgeaktionen prüfen.
  • 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. Classify AI usage as development tooling, absent from the released/operated system, or AI runtime/product component; document AI-SBOM as N/A or as supply-chain evidence accordingly. For release and artefact work, plan SBOM, AI-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.

GitHub/GitLab CLI First / GitHub/GitLab CLI zuerst

Für GitHub-Repositories zuerst die authentifizierte gh CLI für mögliche Schreibaktionen und Live-Repository-Operationen verwenden, einschließlich PR-/Issue-Kommentaren, PR-Statusprüfungen, Review-Follow-up, Workflow-Prüfung und Merge-/Statusabfragen. GitHub-Connector-Tools hauptsächlich für strukturierte Read-only-Inspektion oder Fälle nutzen, in denen die CLI nicht geeignet ist.

Für GitLab-Repositories die authentifizierte glab CLI zuerst für gleichwertige Aktionen verwenden. Bekanntermaßen fehlschlagende Connector-Schreibwege nicht wiederholt versuchen, wenn gh/glab die Aufgabe direkt erledigen kann.

For GitHub repositories, use the authenticated gh CLI first for feasible write actions and live repository operations, including PR/issue comments, PR status checks, review follow-up, workflow inspection, and merge/status queries. Use GitHub connector tools mainly for structured read-only inspection or when the CLI is not suitable.

For GitLab repositories, use the authenticated glab CLI first for equivalent actions. Do not repeatedly try connector write paths that are known to fail when gh/glab can perform the task directly.

Spec-Kit-Modell-Routing / Spec Kit Model Routing

  • Modellwahl ist operative Agenten-Routing-Guidance, keine Feature-Anforderung. Modellnamen nicht in spec.md, plan.md, tasks.md oder einzelne Feature-Specs schreiben; diese Artefakte muessen reproduzierbar bleiben, auch wenn Modellnamen wechseln oder ein anderer KI-Agent verwendet wird.
  • Der jeweilige Agent soll diese Empfehlungen auf seine aktuell verfuegbaren Modelle abbilden; keine feste Anbieter- oder Modellbindung ableiten.
  • Fuer Spec-Kit-Spezifikation, Klaerung, Planung, Tasks und Analyse (/speckit-specify, /speckit-clarify, /speckit-plan, /speckit-tasks, /speckit-analyze; je nach Agent auch /speckit.specify usw.) das staerkste verfuegbare Frontier-Reasoning-/Coding-Modell bevorzugen.
  • Fuer vollstaendige, lang laufende /speckit-implement-Laeufe das staerkste verfuegbare Long-Running-Agent-Modell bevorzugen; das Frontier-Modell nutzen, wenn maximale Urteilsguete wichtiger ist als Laufzeitstabilitaet.
  • Fuer fokussierte Reviews oder CI-Fixes ein coding-optimiertes Modell bevorzugen.
  • Fuer triviale Bereinigung, Formatierung oder risikoarme mechanische Edits ist ein schnelles kleines Coding-Modell akzeptabel.

Model choice is operational agent-routing guidance, not a feature requirement. Do not pin model names in spec.md, plan.md, tasks.md, or individual feature specs; those artifacts must stay reproducible even when model names change or another AI agent is used. Each agent should map these recommendations to its currently available models; do not derive a fixed vendor or model requirement. For Spec-Kit specification, clarification, planning, task generation, and analysis (/speckit-specify, /speckit-clarify, /speckit-plan, /speckit-tasks, /speckit-analyze; or /speckit.specify etc. depending on the agent surface), prefer the strongest available frontier reasoning/coding model. For complete long-running /speckit-implement runs, prefer the strongest available long-running agent model; use the frontier model when maximum judgment quality is more important than runtime stability. For focused review or CI fixes, prefer a coding-optimized model. For trivial cleanup, formatting, or low-risk mechanical edits, a fast small coding model is acceptable.

Spec-Kit-Preset-Pflege / Spec Kit Preset Maintenance

  • Standard-Preset-Set: security-governance v0.6.1 prio 10, architecture-governance v0.5.1 prio 20, isaqb-architecture-governance v0.2.1 prio 30, a11y-governance v0.4.1 prio 40, cross-platform-governance v0.2.1 prio 50, agent-parity-governance v0.4.0 prio 60, autonomous-run-governance v0.3.0 prio 70, parallel-autonomous-run-governance v0.2.1 prio 80.
  • autonomous-run-governance v0.3.0 prio 70 ist Teil der Standard-Achtermatrix. Ein vollständiger autonomer Lauf bleibt ausdrücklich delegationspflichtig; die Installation allein erteilt weder Ausführungsberechtigung noch Remote-, Merge-, Bypass- oder Provider-Rechte und LocalImplementation bleibt Default. Dokumentations-, Status-, Schema- oder Evidence-Änderungen gelten erst dann als testfrei, wenn keine ausführbaren Validatoren die geänderten Pfade, Marker, Schemas oder Zustandswerte konsumieren. Vor autorisierten Commits wird der exakt beabsichtigte Kandidat mit git diff --cached --check und Statusabgleich geprüft; fremde Änderungen bleiben unberührt. Vor einem Merge wird jeder Acceptance-Gate dem tatsächlich ausgeführten Workflow, Job, Runner beziehungsweise der Plattform und dem Befehl zugeordnet; grüne Namen oder ein Bypass ersetzen keinen technischen Nachweis. Bewusst pausierte Läufe werden als PausedByUser gespeichert und nur über speckit.autonomous-resume fortgesetzt; speckit.autonomous-stop wirkt kooperativ am nächsten sicheren Grenzpunkt, und ein gespeicherter Delivery-Modus ist keine aktuelle Berechtigung. Nach Preset- oder Governance-Drift werden neue zwingende Korrektheits-, Sicherheits-, Berechtigungs- und Evidenzregeln minimal mit akzeptierten Plan-, Task- und Checklist-Artefakten abgeglichen; reine Effizienzpräferenzen lösen keine rückwirkende Neugenerierung aus. Die lesbare Skill-Überschrift Deliver ist kein Run-State-Wert; für Remote-Closeout gelten ausschließlich Publish, Review oder MergeAndSync.
  • parallel-autonomous-run-governance v0.2.1 prio 80 ist Teil der Standard-Achtermatrix. Die Installation startet keine Kampagne und erteilt keine zusaetzlichen Remote-, Merge-, Bypass-, Abbruch-, Secret- oder Provider-Rechte. Kampagnen bleiben ausdruecklich delegationspflichtig, verwenden getrennte Worktrees und maximal drei gleichzeitig aktive Worker. Schema 1.1 erlaubt ein runnerProfile je Worker mit Kampagnen-Fallback; Modell und Reasoning-Stufe sind optionale, nicht geheime Metadaten und werden ohne Deklaration nicht erraten. Konsolidierung verlangt exakten Head, aktuelle Review- und Check-Evidenz, ist nach Teilmerges fortsetzbar und setzt Completed erst nach Synchronisation, manifestdeklarierten idempotenten Post-Merge-Aktionen und Abschlussvalidierung.
  • a11y-governance v0.4.1 ergänzt didaktische Inline-Code-Kommentar-Governance für neue oder geaenderte nicht-triviale Logik.
  • security-governance v0.6.1 fuehrt AI-SBOM weiter als bedingt anwendbare Supply-Chain-Evidenz, ergänzt sprachspezifische Secure-Coding-Profile und ergänzt regulatorische Anwendbarkeit für NIS2, CRA, EU AI Act und DORA. Reine Entwicklungswerkzeug-Nutzung bleibt N/A; KI-Runtime-/Produktkomponenten benoetigen Evidenz nach G7/BSI AI-SBOM-Clustern; private Ausbildungsprojekte dokumentieren regulatorische Nichtanwendbarkeit mit kurzer Begründung.
  • architecture-governance v0.5.1 ergänzt BSI C3A als bedingte Cloud-Autonomie-Evidenz und BSI C5 als bedingte Cloud-Compliance-Assurance-Evidenz für Cloud-Service-Auswahl, Provider-Abhängigkeiten, Audit-/Nachweisstand, Shared Responsibility und Betriebsnachweise.
  • Alle acht Presets enthalten ab diesem Release-Block audit-ready Spec-Kit-Run-Evidenz: Applicable / N/A / Open, Begründung, Evidenzpfad, Reviewer, Restrisiko und Follow-up muessen im aktuellen Spec-Kit-Lauf dokumentiert werden.
  • Die ursprünglichen sechs Presets sind seit 2026-05-04 und autonomous-run-governance v0.2.2 ist seit 2026-07-17 im github/spec-kit Community-Katalog enthalten und liegen zusätzlich als veröffentlichte Repos unter https://github.com/hindermath/spec-kit-preset-*.
  • parallel-autonomous-run-governance v0.2.1 ist eigenstaendig veroeffentlicht und wurde mit github/spec-kit#3591 fuer den Community-Katalog eingereicht.
  • Registrierte Level-0-, Level-1- und Level-2-Repositories installieren bei vorhandener Spec-Kit-Integration standardmäßig alle acht Presets aus scripts/config/spec-kit-governance-presets.json, sofern keine begründete Ausnahme dokumentiert ist.
  • Referenz-Rollout für alle acht Presets: RiderProjects/TinyPl0, RiderProjects/TinyCalc, RiderProjects/TuiVision, RiderProjects/InventarWorkerService.
  • Installation erfolgt bevorzugt mit install-spec-kit-governance-presets.* aus der zentralen Matrix; die Skriptlogik enthaelt keine fest eingebauten Versionen. Bei neuen Preset-Releases zuerst die Matrix aktualisieren, dann bestehende Repos bewusst mit --force / -Force nachziehen.
  • Flotten-Rollouts erfassen Level-0, Level-1 und Level-2 explizit. Eine reine Level-2-Registry beweist keine vollstaendige Abdeckung; jeder Zielstatus wird bis Installation, exakter Matrixvalidierung, Commit, Push und Remote-Synchronisation verfolgt.
  • Vor dem Staging werden generierte Preset-/Agentenpfade mit dem gesamten Arbeitsbaum abgeglichen. Fremde Aenderungen bleiben unberuehrt; bei Konflikten wird ein sauberer Worktree statt eines erzwungenen Misch-Commits verwendet.
  • Aktuelle normative Sechs-/Siebenerangaben werden auf die Achtermatrix migriert. Historische Statistik-, Changelog-, Feldnachweis- und Kompatibilitaetsangaben bleiben erhalten und werden durch einen dokumentierten Allowlist-Scan unterschieden.
  • Provider-/Billing-Ablehnung, technischer Gate-Fehler und bestandener Gate sind getrennte Ergebnisse. Bypass oder gruene Sammelnamen ersetzen keinen exakten technischen Nachweis.
  • .specify/presets/ und generierte Agenten-/Command-Dateien committen, wenn Presets Projekt-Policy sind; .specify/presets/.cache/ nie committen.
  • Nach Installation oder Update prüfen: specify preset list, mindestens ein specify preset info <id>, bei Template-Fragen zusätzlich specify preset resolve <template>.
  • Die lokale Arbeitskopie der veröffentlichten Preset-Repos liegt unter ~/SpecKitPresetProjects/; kanonische Scaffolds in diesem Repo liegen unter specs/spec-kit-presets/ und specs/spec-kit-preset-repos/.
  • Verbesserungen an Presets zuerst im home-baseline-Scaffold einarbeiten, dann in die passenden Repos unter ~/SpecKitPresetProjects/ übertragen, committen, pushen und mit GitHub-ZIP-URL smoke-testen.
  • Bei Änderungen an Preset-Regeln immer prüfen, ob constitution.md, .specify/memory/constitution.md, AGENTS.md, CLAUDE.md, GEMINI.md, .github/copilot-instructions.md und scripts/templates/* ebenfalls aktualisiert werden müssen.
  • Bei jeder Preset-Version oder Prioritätsänderung zuerst scripts/config/spec-kit-governance-presets.json aktualisieren und danach README-Tabellen, Constitution, Agenten-Dateien, scripts/templates/speckit-workflow-section.md und Agenten-Templates gemeinsam prüfen.

Fleet rollouts explicitly cover level 0, level 1, and level 2 and track each target through installation, exact matrix validation, commit, push, and remote synchronization. Separate generated paths from unrelated work before staging. Migrate current normative six/seven references while preserving allowlisted history and compatibility aliases. Provider refusal, technical gate failure, and passing evidence are distinct; bypass is not technical proof.

  • Community-/Katalog-Abstimmung läuft über github/spec-kit#2362.

Standard preset set: security-governance v0.6.1 prio 10, architecture-governance v0.5.1 prio 20, isaqb-architecture-governance v0.2.1 prio 30, a11y-governance v0.4.1 prio 40, cross-platform-governance v0.2.1 prio 50, agent-parity-governance v0.4.0 prio 60, autonomous-run-governance v0.3.0 prio 70, and parallel-autonomous-run-governance v0.2.1 prio 80. a11y-governance v0.4.1 adds didactic inline-code-comment governance for new or changed non-trivial logic. architecture-governance v0.5.1 adds conditional BSI C3A cloud-autonomy evidence and BSI C5 cloud-compliance assurance evidence for cloud-service selection, provider dependencies, audit/assurance status, shared responsibility, and operational evidence. security-governance v0.6.1 keeps conditional AI-SBOM evidence, language-specific secure-coding profiles, and regulatory applicability screening for NIS2, CRA, EU AI Act, and DORA: development-tool-only AI usage is N/A, AI runtime/product components require G7/BSI AI-SBOM cluster evidence, and private training projects record regulatory N/A when no regulated scope exists. All eight presets now include audit-ready Spec-Kit run evidence: Applicable / N/A / Open, rationale, evidence path, reviewer, residual risk, and follow-up must be documented for the current Spec-Kit run. The original six presets have been in the github/spec-kit community catalog since 2026-05-04, and autonomous-run-governance v0.2.2 was verified there on 2026-07-17. All eight are also published under https://github.com/hindermath/spec-kit-preset-*. parallel-autonomous-run-governance v0.2.1 was submitted to the community catalog as github/spec-kit#3591. Registered level-0, level-1, and level-2 repositories with Spec Kit default to all eight presets from scripts/config/spec-kit-governance-presets.json unless a justified exception is documented. Use install-spec-kit-governance-presets.* so preset versions stay centralized in the matrix. Commit .specify/presets/ and generated agent command updates when presets are project policy, but never commit .specify/presets/.cache/. Verify installs with specify preset list, specify preset info, and where relevant specify preset resolve. Improve presets in the home-baseline scaffold first, propagate to standalone preset repos, then commit, push, and smoke-test via GitHub ZIP URL. Preset-rule changes and preset version/priority changes require reviewing the central matrix, constitution, README tables/install snippets, all agent guidance files, and relevant templates together. Community/catalog coordination happens in github/spec-kit#2362.

Hinweise zur Lernenden- und A11Y-Basis / Notes on the Learner and A11Y Baseline

  • Verbindliche Zielgruppen ab dem ersten Ausbildungsjahr sind Fachinformatiker*innen, Kaufleute für IT-System-Management und Kaufleute für Digitalisierungsmanagement.
  • Lern-, Bedien-, Governance- und Spec-Kit-Inhalte stehen auf Deutsch zuerst und Englisch danach, verwenden ungefähr CEFR B2 und erklären Fachbegriffe beim ersten Auftreten.
  • Spec-Kit-Erfahrung wird nicht vorausgesetzt. Befehle, Artefakte, Zustände und Übergänge werden beim ersten Gebrauch verständlich eingeführt.
  • Abhängigkeiten, Zustände und Entscheidungen erhalten eine vollständige textorientierte Erklärung; eine ausschließlich visuelle Darstellung genügt nicht.
  • Programmierung #include<everyone> und WCAG 2.2 Level AA gelten als verbindliche Prüfbasis, soweit die Kriterien auf das Artefakt anwendbar sind.

The binding audience starts in the first training year and includes IT specialist apprentices and both IT management occupations. Learner, usage, governance, and Spec Kit content is German-first/English-second at about CEFR B2, explains technical terms at first use, assumes no prior Spec Kit experience, and never relies on visual-only dependency, state, or decision information. Programmierung #include<everyone> and WCAG 2.2 Level AA are the review baseline wherever applicable.

For additional context about technologies to be used, project structure, shell commands, and other important information, read the current plan

Hinweise / Notes

  • Diese Datei ergaenzt die projektspezifische Dokumentation mit agentischen Arbeitsregeln.
  • This file complements the project-specific documentation with agent-oriented working rules.

For additional context about technologies to be used, project structure, shell commands, and other important information, read the current plan

Statistikprofil 2 / Statistics Profile 2

  • Verbindlich sind docs/project-statistics.config.json und der markierte Profil-2-Block in docs/project-statistics.md; aktualisieren mit render-project-statistics.*.
  • Profil 2 zeigt exakte KPI, Artefaktmix, 52-Wochen-Aktivitaet, Wochen- und kumulatives Volumen, belastbare Phasen oder Monatsfallback sowie Speedup-Vergleiche.
  • Nur ASCII verwenden: Heatmap 0..4, - fuer noch nicht abgelaufene Tage und Gauges #/.; jedes Textdiagramm bleibt hoechstens 100 Zeichen breit.
  • Jede Grafik braucht genaue Zahlen und eine bilinguale CEFR-B2-Textalternative, Deutsch zuerst und Englisch danach.
  • Methodik v2 wertet Git-getrackten Text und Bruttoaenderungen aus Nicht-Merge-Commits aus; Ledger, STATS.md und Binaerdaten bleiben ausgeschlossen.
  • Referenzen dieses Repositories: 80 Zeilen/Arbeitstag konservativ und 125 Zeilen/Arbeitstag Thorsten-Solo. Speedup bleibt Lieferdichte, keine Stoppuhr- oder Personenbewertung.
  • Dieser Vertrag ersetzt aeltere Visualisierungsvorgaben; historische Ledger-Eintraege und archivierte Profil-1-Diagramme bleiben unveraendert.
  • Gemeinsame Aenderungen werden synchron in AGENTS.md, CLAUDE.md, GEMINI.md, .github/copilot-instructions.md und .github/agents/copilot-instructions.md gepflegt.

Profile 2 is governed by the JSON configuration and generated marker block. Use ASCII 0..4, -, and #/., exact values, German-first bilingual CEFR-B2 alternatives, and a 100-character chart limit. Methodology v2 excludes the ledger, STATS.md, and binaries. This repository uses manual references of 80 and 125 lines per workday. Speedup describes delivery density, not stopwatch or personal performance. This contract supersedes older visualization rules while retaining historical entries and archived Profile 1 charts.

Requirements- und Intake-Governance / Requirements and Intake Governance

  • Pflichtenheft.md ist der schlanke Einstieg; verbindliche Reihenfolge und Zustände stehen im Serienmanifest unter requirements/intakes/series/.
  • Neue oder aktualisierte Lastenhefte gehören nach requirements/intakes/active/; abgeschlossene, ersetzte und optionale Intakes werden getrennt archiviert.
  • Nur Eligible bezeichnet den bevorzugten nächsten Intake. Der Zustand erteilt keine Ausführungs-, Remote- oder Merge-Berechtigung.

Pflichtenheft.md is the slim entry point; binding order and states live in the series manifest. Active, completed, superseded, and optional intakes remain separated. Eligible only identifies the preferred next intake and grants no execution, remote, or merge authority.