aSPARK ist kein weiteres KI-Coding-Plugin. Es ist eine modulare Plattform, die vier Belange — Prozess, Wissen, Governance und Transparenz — in eigenständige, kombinierbare Produkte trennt und über den gesamten Lieferzyklus verbindet. aSPARK is not another AI coding plugin. It is a modular platform that separates four concerns — process, knowledge, governance and transparency — into independent, composable products, connected across the whole delivery lifecycle.
Prozess steckt im Wiki, Wissen in den Köpfen, Governance in ungelesenen PDFs, Standards werden pro Team neu erfunden. KI-gestützte Entwicklung hat das verschärft: Generieren ist billig — Konsistenz, Nachvollziehbarkeit und Compliance sind zum Engpass geworden.Process lives in the wiki, knowledge in people's heads, governance in unread PDFs, standards are re-invented per team. AI-assisted development amplified it: generation is cheap — consistency, traceability and compliance have become the bottleneck.
Prozesse stehen in Slides — durchgesetzt durch Disziplin. Unter Druck werden Schritte übersprungen: Specs entstehen nach dem Code, Reviews werden zum Stempel, „Definition of Done" verkommt zur Folklore.Processes live in slides — enforced by discipline. Under pressure steps are skipped: specs written after the code, reviews become rubber stamps, "definition of done" degrades into folklore.
Die Verbindung zwischen Anforderung und Code lebt in Köpfen. Wechseln Engineers das Team, kann niemand mehr beantworten: Welcher Code erfüllt diese Anforderung? Was bricht bei einer Änderung?The link between requirement and code lives in heads. When engineers rotate, no one can answer: which code implements this requirement? What breaks if we change it?
Architektur-Guidelines und Security-Baselines existieren — als Dokumente. Keine maschinenlesbare Form, keine automatische Prüfung, kein Nachweis beim Audit, welcher Standard für welches Release galt.Architecture guidelines and security baselines exist — as documents. No machine-readable form, no automated validation, no proof at audit which standard applied to which release.
KI-Assistenten liefern bei gleichem Input unterschiedlichen Output, kennen keinen Firmenkontext, hinterlassen keine Spur. Das Dilemma: KI einführen und Kontrolle verlieren — oder verzichten und zurückfallen.AI assistants produce different output for identical input, know no company context, leave no trail. The dilemma: adopt AI and lose control — or reject it and lose competitiveness.
Engineering-KPIs kommen aus Ticket-Metadaten, weil das die einzigen strukturierten Daten sind. Cycle Time und Velocity sagen nichts über Architektur-Gesundheit oder Traceability-Abdeckung.Engineering KPIs come from ticket metadata — the only structured data available. Cycle time and velocity say nothing about architecture health or traceability coverage.
Genau diese fünf Probleme adressiert aSPARK — jedes mit einem eigenen Produkt.These five problems are exactly what aSPARK addresses — each with a dedicated product.
| KategorieCategory | Optimiert fürOptimizes | Es fehltIt lacks |
|---|---|---|
| KI-Coding-AssistentenAI coding assistants Plugins, Copilots | Durchsatz einzelner EntwicklerIndividual developer throughput | Prozess, Governance, Traceability, GedächtnisProcess, governance, traceability, memory |
| ALM- / Prozess-SuitenALM / process suites | Ticketing, Planung, ReportingTicketing, planning, reporting | Code-Wissen, deterministische KI, Policy-as-CodeCode-level knowledge, deterministic AI, policy-as-code |
| aSPARK | End-to-End-Lieferung: Prozess + Wissen + Governance + AnalytikEnd-to-end delivery: process + knowledge + governance + analytics | — kombinierbar, integriert beide Kategorien— composable, integrates both categories |
Konsequenz für die Architektur: aSPARK ersetzt nie Versionsverwaltung, CI/CD oder Issue-Tracker. Es integriert sie über stabile Schnittstellen und ergänzt die Schicht, die sie nicht liefern können — ein deterministisches, policy-gesteuertes Engineering-Gewebe über den gesamten Lebenszyklus.Architectural consequence: aSPARK never replaces source control, CI/CD or issue trackers. It integrates them through stable interfaces and adds the layer they cannot provide — a deterministic, policy-governed engineering fabric spanning the whole lifecycle.
Jedes Produkt hat eine Verantwortung und stabile Schnittstellen. Eine Schwäche in einem darf nie Änderungen in einem anderen erzwingen. Jede Stufe lässt sich unabhängig einführen.Each product has one responsibility and stable interfaces. A weakness in one must never require changes in another. Every stage is independently adoptable.
Prozess. Der deterministische Workflow Specify → Plan → Act → Review → Keep mit Quality-Gates und Traceability-IDs. Definiert, wie Software gebaut wird.Process. The deterministic Specify → Plan → Act → Review → Keep workflow with quality gates and traceability IDs. Defines how software is built.
Wissen. Ein deterministischer Engineering-Wissensgraph, der Stories, Tasks, Code, Tests und Releases verbindet. Weiß, was gebaut wurde.Knowledge. A deterministic engineering knowledge graph connecting stories, tasks, code, tests and releases. Knows what has been built.
Governance. Enterprise-eigene Policy-as-Code mit hierarchischer Vererbung — 11 Packs, getestete JSON-Schemas, Adoption per git submodule. Definiert, welche Regeln jedes Projekt befolgen muss.Governance. Enterprise-owned policy-as-code with hierarchical inheritance — 11 packs, tested JSON Schemas, adopted with one git submodule. Defines which rules every project must follow.
Transparenz. Engineering-KPIs und Delivery-Analytik — berechnet aus Graph und Gate-Evidenz statt aus Ticket-Metadaten. Das Fundament steht: versiegelte Snapshots, CLI, byte-stabile Rebuilds. Die ersten echten Kennzahlen folgen.Transparency. Engineering KPIs and delivery analytics — computed from graph and gate evidence, not ticket metadata. The foundation is in: sealed snapshots, a CLI, byte-stable rebuilds. The first real numbers follow.
Durchsetzung. Gate- und Policy-Enforcement innerhalb bestehender CI/CD-Plattformen — GitHub Actions, GitLab CI, Azure DevOps, Jenkins.Enforcement. Gate and policy enforcement inside existing CI/CD platforms — GitHub Actions, GitLab CI, Azure DevOps, Jenkins.
Gedächtnis. Architektur-Entscheidungen und organisationale Lehren als dauerhaftes Engineering-Memory, verankert an den Graph-Knoten, die sie erklären.Memory. Architectural decisions and organizational lessons as durable engineering memory, anchored to the graph nodes they explain.
Bewusst als prüfbare Hypothesen formuliert: jede Organisation kann sie gegen ihre eigene Baseline validieren.Deliberately stated as testable hypotheses: any organization can validate them against its own baseline.
Neue Engineers fragen den Graphen statt Kollegen; der SPARK-Workflow erklärt den Lieferprozess von selbst.New engineers query the graph instead of interviewing colleagues; the SPARK workflow makes delivery self-explanatory.
Gates machen Qualitätskriterien nicht-überspringbar; Policies setzen Standards maschinell durch.Gates make quality criteria non-skippable; policies make standards machine-enforced.
Gleiche Inputs erzeugen gleiche abgeleitete Modelle; KI-Beiträge sind policy-beschränkt und mit Evidenz belegt.Identical inputs produce identical derived models; AI contributions are policy-constrained and evidenced.
Traceability-IDs und Gate-Evidenz entstehen als Nebenprodukt der Lieferung — nicht als Rekonstruktion zur Audit-Zeit.Traceability IDs and gate evidence exist as a by-product of delivery — not an audit-time reconstruction.
Policy-Packs werden einmal auf Unternehmensebene geschrieben und von jedem Projekt geerbt.Policy packs are written once at company level and inherited by every project.
Kein SCM. Keine CI/CD-Engine. Kein Issue-Tracker. Kein KI-Modell-Anbieter. Kein Beratungsartefakt — Standards bleiben im Besitz des Unternehmens.Not an SCM. Not a CI/CD engine. Not an issue tracker. Not an AI model provider. Not a consultancy artifact — standards stay owned by the enterprise.
Jedes Feature durchläuft fünf Phasen — und darf nur vorrücken, wenn das Gate der Vorphase grün ist. Jede Phase liest das Artefakt der Vorphase und verweigert den Start, wenn das Gate nicht erfüllt ist.Every feature travels through five phases — and may only advance when the previous gate is green. Each phase reads the prior phase's artifact and refuses to start if the gate isn't met.
Eine Person plus aSPARK arbeitet wie ein ganzes Team. Jede Rolle ist ein Subagent — stateless, mit eigenem Mindset, Standards und erlaubten Tools.One person plus aSPARK works like a whole team. Each role is a subagent — stateless, with its own mindset, standards and allowed tools.
Zwei Ceremonies gehören keiner einzelnen Rolle: /spark fährt den kompletten Loop am Stück — mit Halt an jedem Gate und Wiederaufnahme danach. /next-steps schlägt aus dem aktuellen Projektstand das nächste Feature vor, wenn die Frage lautet „womit weiter?".Two ceremonies belong to no single role: /spark runs the whole loop end to end — stopping at every gate, resuming after. /next-steps proposes the next feature from the project's current state, for when the question is "what now?".
Pro Feature entsteht ein Arbeitsverzeichnis — ein transparenter, reviewbarer Ticket-Trail, versioniert mit dem Code.Each feature gets a working directory — a transparent, reviewable ticket trail, versioned with the code.
Anforderungen tragen stabile IDs — US-, AC-, NFR- — von der Spec bis zum Release. Der Plan benennt, welche AC ein Task abdeckt; das Review verfolgt jede Muss-AC bis zum Code; QA verifiziert sie unter derselben ID. Nichts fällt still aus der Kette.Requirements carry stable IDs — US-, AC-, NFR- — from spec to release. The plan cites which AC a task covers; review traces each Must-AC to code; QA verifies it under the same ID. Nothing silently falls out of the chain.
Situative Lenses schalten sich je nach Projekttyp zu — seo · ux · api · cli · library · security · i18n · data — und geben dem bestehenden Team zusätzliche Checks, nur dort wo sie greifen.Situational lenses switch on by project type — seo · ux · api · cli · library · security · i18n · data — giving the existing team extra checks, only where they apply.
Optionaler Graph-Anschluss: Liegt aspark-graph im Projekt, nutzen /sprint-plan, /peer-review und /demo-day es still zur Eingrenzung — welche Dateien ein Task berührt, was ein Review zuerst liest, welche Stories QA am härtesten prüft. Fehlt es, ändert sich nichts. Eine Graph-Antwort ist eine Karte, nie ein Gate-Urteil; die Ceremonies bauen den Graphen nie selbst.Optional graph link: where aspark-graph is present in the project, /sprint-plan, /peer-review and /demo-day use it silently to scope — which files a task touches, what a review reads first, which stories QA should probe hardest. Absent, nothing changes. A graph answer is a map, never a gate verdict; the ceremonies never build the graph themselves.
Specs, Pläne, Reviews und QA-Berichte sind maschinenlesbar — der Code auch. Aber nichts verbindet beide Welten. aspark-graph berechnet diesen Join einmal, deterministisch, und macht ihn abfragbar.The spec→plan→review→QA trail is machine-parseable and linked to code by intent — but nothing joins the two. aspark-graph computes that join once, deterministically, and makes it queryable.
Folgt Story → ACs → Plan-Tasks → Code → QA-Ergebnisse. Ohne Grepping.Follows story → ACs → plan tasks → code → QA results. Zero grepping.
Verfolgt Code → Tasks → Stories/ACs und markiert jeden Treffer mit Vertrauensstufe. Was muss QA neu verifizieren?Walks code → tasks → stories/ACs, tagging each hit with a confidence tier. What must QA re-verify?
Jede Knoten-ID ist stabil & deterministisch — zwei Builds eines unveränderten Repos erzeugen ein byte-identisches graph.json.Every node id is stable & deterministic — two builds of an unchanged repo produce a byte-identical graph.json.
| Code-EbeneCode layer | File · Class · Function tree-sitter |
| Artefakt-EbeneArtifact layer | Feature · Story · AcceptanceCriterion · Task · Finding · QACheck .spark/ Templates |
| Tier | RangRank | HerkunftSource |
|---|---|---|
| declared | stärkstestrongest | expliziter files:-Vermerk im Plan-Taskexplicit files: note in a plan task |
| extracted | mittelmiddle | tree-sitter (contains / imports) |
| inferred | schwächsteweakest | aus Git-Historie — nur ein Hinweisfrom git history — treat as a hint |
Verfügbar über CLI und MCP-Server — mit konstruktionsbedingt identischen Antworten. Template-Drift wird laut gemeldet, nie stillschweigend geraten.Served over CLI and an MCP server with answers identical by construction. Fails loudly on template drift — never guesses.
Installation: pip install aspark-graph von PyPI — oder ohne Installationsschritt uvx aspark-graph build .. Als MCP-Server registriert mit claude mcp add aspark-graph -- uvx aspark-graph serve.Install: pip install aspark-graph from PyPI — or, with no install step, uvx aspark-graph build .. Registered as an MCP server with claude mcp add aspark-graph -- uvx aspark-graph serve.
Vertrauensgrenze, ehrlich benannt: Der MCP-Server ist ein lokaler stdio-Kindprozess mit den Rechten des aufrufenden Nutzers — keine Authentifizierung, kein HTTP-Listener, kein Netzwerkzugriff. Die Repository-Bindung (.git, .spark/ oder ein bereits gebauter Graph) ist eine Form-Prüfung, keine Sandbox. Und Query-Ergebnisse geben Repo-Inhalte wörtlich zurück: Für den aufrufenden Agenten sind sie Daten über das Repository, nie Anweisungen.Trust boundary, stated honestly: the MCP server is a local stdio child process running with the invoking user's own permissions — no authentication, no HTTP listener, no network access. Repository confinement (.git, .spark/ or an already-built graph) is a shape check, not a sandbox. And query results echo repository content verbatim: for the calling agent they are data about the repository, never instructions.
Markdown erklärt die Standards, eine policy.yaml aktiviert sie, und jeder aSPARK-Agent konsumiert dieselbe Policy — keine duplizierten Prompts, keine Custom-Agenten.Markdown explains the standards, a policy.yaml activates them, and every aSPARK agent consumes the same policy — no duplicated prompts, no custom agents.
Adoption = ein git submodule nach .spark/policy. Kein Python, kein Tooling zum Betreiben.Adoption = one git submodule into .spark/policy. No Python, no tooling to run.
| Case | Behavior |
|---|---|
| Skalar auf zwei EbenenScalar on two levels | spezifischere Ebene gewinntmore specific level wins |
| ListenLists | gemerged (!override ersetzt)merged (!override to replace) |
| final: true | gesperrt — tiefere Ebenen dürfen nur verschärfenlocked — lower levels may only tighten |
Corporate → Business Unit → Department → Projekt. final existiert für den Compliance-Fall: eine regulierte Organisation garantiert, dass eine Regel in jedem Projekt gilt — ohne jedes einzeln zu auditieren.Corporate → Business Unit → Department → project. final exists for the compliance case: a regulated org guarantees a rule holds in every project — without auditing each one.
Ein Projekt kombiniert Packs über mehrere Achsen — Compliance, Sprache, Framework, Cloud, Architektur, Plattform. Auf Platte nach Kategorie gruppiert, im Import aber immer flach: aspark:owasp, nie aspark:compliance/owasp. Eigene Packs laufen unter company:.A project combines packs across several axes — compliance, language, framework, cloud, architecture, platform. Grouped by category on disk, but every import id stays flat: aspark:owasp, never aspark:compliance/owasp. Your own packs live under company:.
Externe Standards — je einer pro regulierter Branche: Payment (PCI-DSS v4.0), Automotive-Cybersecurity (UN R155 / CSMS), plus die branchenübergreifenden OWASP und ISO 27001.External standards — one per regulated industry: payments (PCI-DSS v4.0), automotive cybersecurity (UN R155 / CSMS), plus cross-industry OWASP and ISO 27001.
MISRA liegt auf der Sprach-Achse neben Java — nicht in einem Branchen-Topf. Ein Coding-Standard für sicherheitskritisches C/C++ ist genau das: ein Coding-Standard, kein Industriesegment.MISRA sits on the language axis, next to Java — not in an industry bucket. A safety-critical C/C++ coding standard is exactly that: a coding standard, not an industry category.
Speisen den Developer direkt; react schaltet zusätzlich die bestehende ux-Lens scharf.Feed the Developer directly; react additionally switches on the existing ux lens.
Binden an den Engineering Manager. Eine cloud-Lens in Core gibt es noch nicht — bis dahin sind es schlichte Constraints.Bind to the Engineering Manager. There is no cloud lens in Core yet — until then they are plain constraints.
Engineering Manager und Reviewer — ebenfalls noch ohne eigene Lens.Engineering Manager and Reviewer — likewise without a lens of its own so far.
Die Achse für Plattform-Standards ist im Katalog angelegt. SAP ist das erste Pack auf dieser Achse.The axis for platform standards is laid out in the catalog. SAP is the first pack on it.
| SorteKind | final? | BeispieleExamples |
|---|---|---|
| universal | jayes | owasp · iso27001 · pci-dss · un-r155 |
| baseline | nienever | java · misra · spring · react · aws · azure |
Der Unterschied entscheidet, was gesperrt werden darf. Die OWASP Top 10 sind ein Fakt der Branche — eine Konzernebene darf sie final setzen. Ein Baseline-Pack, das Java 21 festnagelt, ist dagegen ein Default, kein Standard: jede Organisation hat eigene Konventionen, also ist eine Baseline ein Gerüst zum Verschärfen — nie eine Sperre.The distinction decides what may be locked. The OWASP Top 10 is a fact of the industry — a corporate level may set it final. A baseline pack pinning Java 21 is a default, not a standard: every organization has its own conventions, so a baseline is a scaffold to tighten — never a lock.
Ehrlich zum Umfang: Die Packs sind aSPARKs eigene, zusammenfassende Interpretation der Standards — sie geben keinen lizenzierten Regeltext wieder. UN R155 ist bewusst auf der öffentlichen UN-Regelung verankert, nicht auf der kostenpflichtigen ISO/SAE 21434. Ein Pack ist kein Zertifizierungsartefakt: weder eine QSA-Bewertung noch eine Typgenehmigung.Honest about scope: the packs are aSPARK's own summary interpretation of the standards — they reproduce no licensed rule text. UN R155 is deliberately anchored on the public UN regulation, not the paid ISO/SAE 21434. A pack is not a certification artifact: neither a QSA assessment nor a type approval.
Policies werden zu Quality-Gates statt Beratungsdokumenten — und jede Verletzung nennt Policy und Regel, aus der sie stammt. Das macht den Trail auditierbar.Policies become quality gates instead of advisory documents — and every violation names the policy and rule it comes from. That's what makes the trail auditable.
Ehrlicher Status: aSPARK-policy ist mit v0.2.0 einsetzbar — Format, JSON-Schemas, Regel-Anatomie (id/severity/scope/check) und 11 Packs stehen und werden per git submodule adoptiert, ohne Python und ohne Tooling. Was noch fehlt, ist die maschinelle Durchsetzung: validate-CLI und /charter-Bindung. Die Policy ist heute lesbar, vererbbar und auditierbar — aber ein Agent zieht sie noch nicht automatisch heran.Honest status: aSPARK-policy is usable at v0.2.0 — the format, JSON Schemas, rule anatomy (id/severity/scope/check) and 11 packs are in place, adopted with one git submodule, no Python and no tooling to run. What's still missing is machine enforcement: the validate CLI and the /charter binding. The policy is readable, inheritable and auditable today — but no agent picks it up automatically yet.
Die Reihenfolge ist architektonisch, nicht bloß kommerziell: jede Stufe erzeugt das versionierte Substrat, aus dem die nächste ableitet. Jede Stufe ist für sich lieferbar und wertvoll.The ordering is architectural, not merely commercial: each stage produces the versioned substrate the next derives from. Every stage is shippable and valuable on its own.
SPARK-Workflow, Agenten, Gates, Traceability-IDs, Artefakt-Schemata.SPARK workflow, agents, gates, traceability IDs, artifact schemas.
Graph-Builder, Query-Engine, Impact-Analyse, MCP-Interface. Graph builder, query engine, impact analysis, MCP interface.
11 Policy-Packs, Vererbungs-Semantik, JSON-Schemas, Regel-Anatomie. Die Durchsetzung — validate-CLI und /charter-Bindung — ist der nächste Schritt. 11 policy packs, inheritance semantics, JSON Schemas, rule anatomy. Enforcement — the validate CLI and /charter binding — is the next step.
aSPARK-insights FrühphaseEarly dev
Engineering-KPIs, Traceability-Abdeckung, Dashboards — gerechnet aus Graph- und Gate-Evidenz. Fundament released: versiegelte Snapshots, CLI, byte-stabile Rebuilds. Engineering KPIs, traceability coverage, dashboards — computed from graph and gate evidence. Foundation released: sealed snapshots, a CLI, byte-stable rebuilds.
aSPARK-ci GeplantPlanned
Gate- und Policy-Enforcement in bestehenden CI/CD-Plattformen, Release-Validierung. Gate and policy enforcement inside existing CI/CD platforms, release validation.
Beide leiten aus den Stufen 2–3 ab — keins aus dem anderen. Sie sind Geschwister, keine Kette, und rücken deshalb unabhängig voneinander vor.Both derive from Stages 2–3 — neither from the other. They are siblings, not a chain, and therefore advance independently.
ADR-/Entscheidungs-Gedächtnis, historischer Kontext; Intelligence-Services auf Graph+Memory. Decision Recall, Risk Prediction, Standards-Feedback — als Konsumenten versionierter Daten, nie als Bypass der Gates.ADR/decision memory, historical context; intelligence services on graph+memory. Decision recall, risk prediction, standards feedback — as consumers of versioned data, never a bypass of the gates.
Kompatibilitäts-Zusage: Jede Stufe lässt sich unabhängig einführen. Eine Organisation kann Core-only oder Core+Graph unbegrenzt betreiben und bleibt unterstützt. Graph-Rebuilds absorbieren Upgrades — nie eine Graph-Migration.Compatibility commitment: every stage is independently adoptable. An org may run Core-only or Core+Graph indefinitely and stay supported. Graph rebuilds absorb upgrades — never a stored-graph migration.
Beginnen Sie mit Core auf einem Pilotprojekt — die Stufen bauen aufeinander auf, aber jede liefert für sich. Workflow, Wissensgraph und Policy-Packs liegen offen auf GitHub.Start with Core on a pilot project — the stages build on each other, but each delivers on its own. The workflow, knowledge graph and policy packs are all open on GitHub.