Governance von Kshana

Dieses Dokument legt fest, wie Kshana geführt wird: wer Entscheidungen trifft, wie, und was das Projekt aufnimmt und was nicht. Es ist bewusst leicht — im Verhältnis zur aktuellen Größe des Projekts — und ehrlich über die derzeitige Lage mit einem einzigen Maintainer und den Weg zu breiterer Governance, wenn die Gemeinschaft wächst.

Auftrag und Umfang#

Kshana ist eine neutrale, reproduzierbare, ehrlich validierte Referenz für die Leistung und Resilienz hybrider Quanten-/klassischer PNT. Der Auftrag legt den Maßstab für jede Entscheidung fest: Korrektheit, Zitate und Reproduzierbarkeit vor Breite. Der ehrliche Umfang ist in docs/CAPABILITY.md dokumentiert und der Validierungsstand in docs/VALIDATION.md; Vorschläge werden an diesem Umfang gemessen, nicht an der Zahl der Funktionen.

Rollen#

Maintainer. Kshana wird derzeit von seinem Gründer gepflegt, Ashforde OÜ (Kontakt: contact@ashforde.org). Der Maintainer entscheidet letztverbindlich über Umfang, Entwurf, Releases und das, was zusammengeführt wird. Das ist ein Modell des wohlwollenden Maintainers, offen benannt statt als ein Gremium ausgegeben, das es nicht gibt.
Mitwirkende. Jeder, der ein Issue oder einen Pull Request öffnet. Beiträge werden an dem Maßstab in CONTRIBUTING.md gemessen — Herkunftsangabe für jeden numerischen Parameter, Validierung gegen eine veröffentlichte Beziehung und Ehrlichkeit zum Reifegrad.
Künftige Committer. Wenn nachhaltige, hochwertige Beiträge es rechtfertigen, werden Commit-Rechte auf vertrauenswürdige Mitwirkende ausgeweitet, und dieses Dokument wird auf ein Modell mit mehreren Maintainern aktualisiert (Entscheidungen durch stillschweigenden Konsens, wobei die Maintainer-Gruppe Meinungsverschiedenheiten klärt). Bis dahin lautet der Weg: beitragen, sich einen Ruf erarbeiten und eingeladen werden.

Wie Entscheidungen getroffen werden#

Offene Diskussion. Inhaltliche Änderungen beginnen als GitHub-Issue, damit Begründung, Alternativen und Abwägungen dokumentiert sind.
Stillschweigender Konsens. Ein Vorschlag ohne anhaltenden Widerspruch nach angemessener Zeit, der den unten genannten technischen Maßstab erfüllt, geht weiter.
Der Maintainer entscheidet bei Uneinigkeit. Wo kein Konsens erreicht wird, entscheidet der Maintainer und hält den Grund fest. Uneinigkeit wird durch den Auftrag und den technischen Maßstab gelöst, nicht durch Dienstalter oder Lautstärke.

Der technische Maßstab (nicht verhandelbar)#

Dies sind harte Invarianten, durch CI und Review durchgesetzt, die keine Entscheidung außer Kraft setzt:

Reproducibility. (scenario, seed, engine_version) muss einen Lauf bitgenau reproduzieren. Eine Änderung, die das nichtdeterministisch macht, ist ein Fehler, kein Feature.
Herkunft. Keine anonymen numerischen Konstanten — jeder Parameter nennt eine Quelle.
Ehrlichkeit bei der Validierung. Jede Fähigkeit ist als validated (gegen eine externe Referenz) oder als modelled / not modeled gekennzeichnet. Nichts wird über seinen Beleg hinaus behauptet. Siehe die maschinell geprüfte Matrix in src/verification.rs.
Sauberkeit. Keine Zuordnung zu automatisierten Werkzeugen irgendwo in Commits, Inhalten oder Verlauf (durchgesetzt von scripts/check-no-attribution.sh).

Eine Änderung, die den Maßstab nicht erfüllen kann, wird abgelehnt, so nützlich sie auch wäre.

Die Grenze zwischen offen und geschlossen#

Kshana ist Open Core. Dieses Repository ist die vollständige offene AGPL-3.0-Engine und bleibt es — die neutrale Referenz, von Ashforde OÜ zusätzlich kommerziell doppelt lizenziert (siehe LICENSING.md). Das Projekt wird in das offene Repository nicht aufnehmen:

Exportkontrollierte Tiefe oder Tiefe mit doppeltem Verwendungszweck — echte Bedrohungsbibliotheken, Wellenformen von Gegnern oder Leistungsparameter für Anti-jamming/Anti-spoofing. Das öffentliche Repository bleibt bei allgemeinen, veröffentlichten Modellen und Methoden (siehe CONTRIBUTING.md → Exportkontrolle). Fragen Sie im Zweifel vor dem Beitrag nach.
Vertrauliche Daten oder Kalibrierung von Kunden oder Partnern.
Copyleft-(GPL/AGPL/LGPL/MPL-)Abhängigkeiten — nicht weil sie mit der eigenen AGPL-Lizenz der Engine kollidieren (das tun sie nicht), sondern weil sie nicht in die kommerzielle Ausgabe umlizenziert werden können: Wir können eine kommerzielle Lizenz nur über Code verkaufen, den wir besitzen oder der permissiv ist. Eine Copyleft-Abhängigkeit würde die kommerzielle Ausgabe belasten und die Doppellizenz brechen. Abhängigkeiten bleiben daher permissiv (Apache/MIT/BSD/ISC), durchgesetzt von deny.toml.

Umgekehrt wird das Projekt den offenen Kern nicht aushöhlen, um proprietären Wert voranzutreiben: Die validierte Engine, die öffentlichen Validierungsanker, das Ehrlichkeitsregister, das Austausch-/Standardformat und die Vertriebskanäle bleiben offen. Den offenen Kern auszuhungern ist der eine tödliche Fehler bei Open Core, und er kommt nicht in Frage.

Releases#

Semantic Versioning. Vor 1.0 kann sich das Schema für Szenario/Ergebnis ändern; brechende Änderungen werden hervorgehoben, und die Version des Austauschschemas (src/interchange.rs::SCHEMA_VERSION) ist die einzige Quelle der Wahrheit für die Kompatibilität von Artefakten.
Release-Befugnis. Die Veröffentlichung (z. B. cargo publish) ist ein manueller Schritt des Maintainers, der ein Registry-Token braucht. CI und der durch Tags ausgelöste Workflow Release veröffentlichen nie automatisch in externen Registries — sie führen nur alle Prüfungen erneut aus und hängen ein Build-Artefakt an. Siehe CONTRIBUTING.md → Commits und Versionierung.

Verhaltenskodex und Sicherheit#

Das Verhalten wird durch CODE_OF_CONDUCT.md geregelt.
Sicherheitsprobleme folgen dem privaten Meldeverfahren in SECURITY.md — öffnen Sie für eine Schwachstelle kein öffentliches Issue.

Marke#

Der Name und das Logo von Kshana sind Marken von Ashforde OÜ. Die Lizenz (AGPL-3.0 oder eine kommerzielle Lizenz) deckt den Code ab, nicht die Marken: Ein Fork darf den Code unter der Lizenz verwenden, aber nicht den Namen Kshana oder die kanonische Vertriebsidentität. Das hält Ashforde als zitierte Quelle der Wahrheit und gehört dazu, wie der offene Kern eine neutrale Referenz bleibt.

Dieses Dokument ändern#

Änderungen an der Governance werden selbst als Pull Request vorgeschlagen und nach dem obigen Verfahren entschieden. Mit der Größe des Projekts ist zu erwarten, dass dieses Dokument ein Entscheidungsmodell mit mehreren Maintainern erhält; den technischen Maßstab wird es nicht senken.

Leicht gewollt. Ehrlich über heute, mit einem benannten Weg für morgen.