📊
Livev0.12.0 Transparenz

aSPARK-insights

Engineering-KPIs aus Graph- und Gate-Evidenz — nicht aus Ticket-Metadaten.

Engineering-KPIs kommen heute aus Ticket-Metadaten, weil das die einzigen strukturierten Daten sind. Cycle Time und Velocity sagen nichts über Architektur-Gesundheit oder Traceability-Abdeckung.

insights rechnet stattdessen aus dem, was der Lieferprozess ohnehin erzeugt: dem Graphen und der Gate-Evidenz. Echte Story→Task-, AC→QA- und Task→Code-Abdeckung, jede mit eigener Stichprobengröße, dazu ein Mid-Cycle-Board aus reinem Git (auch ohne Graph), ein Release-Board, das jeden Git-Tag auf die darin ausgelieferten Features abbildet — mit gemessenen Release-Kennzahlen und den Feature-Dokumenten zum Nachlesen an Ort und Stelle — und eine Feature-Sicht, die dieselben Daten pro Feature statt pro Release gruppiert. Flow-, Architektur- und Policy-Metriken folgen als Nächstes.

Ehrlicher Status: v0.12.0 liefert echte Traceability-Kennzahlen, einen offline lesbaren HTML-Report, MCP-Query, Mid-Cycle- und Release-Board mit gemessenen Kennzahlen sowie die Feature-Sicht. Flow-/Cycle-Time-, Architektur- und Policy-Metriken fehlen noch — jeweils blockiert durch Graph bzw. Policy, und noch nicht auf PyPI. insights baut auf graph auf, nicht auf aSPARK-ci: die beiden sind Geschwister, keine Kette.

Jedes Produkt hat eine Verantwortung und stabile Schnittstellen. Eine Schwäche in einem darf nie Änderungen in einem anderen erzwingen.

Passt das zu Ihrem Lieferprozess?

Beginnen Sie mit Core auf einem Pilotprojekt. Workflow, Wissensgraph und Policy-Packs liegen offen auf GitHub.