Styring av Kshana

Dette dokumentet sier hvordan Kshana styres: hvem som tar beslutninger, hvordan, og hva prosjektet vil og ikke vil ta imot. Det er bevisst lett — tilpasset prosjektets nåværende størrelse — og er ærlig om dagens situasjon med én vedlikeholder og veien mot bredere styring etter hvert som fellesskapet vokser.

Oppdrag og omfang#

Kshana er en nøytral, reproduserbar og ærlig validert referanse for ytelse og robusthet i hybrid kvante/klassisk PNT. Oppdraget setter terskelen for hver beslutning: korrekthet, kilder og reproduserbarhet fremfor bredde. Det ærlige omfanget er dokumentert i docs/CAPABILITY.md og valideringsstatusen i docs/VALIDATION.md; forslag vurderes mot dette omfanget, ikke mot antall funksjoner.

Roller#

• Vedlikeholder. Kshana vedlikeholdes for tiden av grunnleggeren, Ashforde OÜ (kontakt: contact@ashforde.org). Vedlikeholderen tar den endelige avgjørelsen om omfang, utforming, utgivelser og hva som flettes inn. Dette er en modell med en velvillig vedlikeholder, uttrykt rett fram i stedet for å bli utkledd som en komité som ikke finnes.
• Bidragsytere. Alle som åpner en issue eller en pull request. Bidrag måles mot terskelen i CONTRIBUTING.md — opprinnelse for hver numeriske parameter, validering mot en publisert sammenheng og ærlighet om modenhet.
• Fremtidige committere. Når vedvarende bidrag av høy kvalitet tilsier det, gis commit-rettigheter til betrodde bidragsytere, og dette dokumentet oppdateres til en modell med flere vedlikeholdere (beslutninger ved lazy consensus, der vedlikeholdergruppen løser uenigheter). Fram til da er veien: bidra, bygg opp en merittliste og bli invitert.

Hvordan beslutninger tas#

1. Diskusjon i det åpne. Vesentlige endringer starter som en GitHub-issue, slik at begrunnelsen, alternativene og avveiningene er dokumentert.
2. Lazy consensus. Et forslag uten vedvarende innvendinger etter rimelig tid, og som består den tekniske terskelen nedenfor, går videre.
3. Vedlikeholderen avgjør ved uenighet. Der enighet ikke nås, avgjør vedlikeholderen og noterer begrunnelsen. Uenighet løses ut fra oppdraget og den tekniske terskelen, ikke ut fra ansiennitet eller høylytthet.

Den tekniske terskelen (ikke til forhandling)#

Dette er harde invarianter, håndhevet av CI og gjennomgang, som ingen beslutning overstyrer:

• Reproducibility. (scenario, seed, engine_version) må reprodusere en kjøring bit-for-bit. En endring som gjør dette ikke-deterministisk, er en feil, ikke en funksjon.
• Opprinnelse. Ingen anonyme numeriske konstanter — hver parameter oppgir en kilde.
• Ærlighet om validering. Hver funksjon er merket validated (mot en uavhengig referanse) eller modelled / not modeled. Ingenting hevdes utover det evidensen viser. Se den maskinkontrollerte matrisen i src/verification.rs.
• Hygiene. Ingen attribusjon til automatiserte verktøy noe sted i commits, innhold eller historikk (håndhevet av scripts/check-no-attribution.sh).

En endring som ikke kan nå terskelen, avslås, uansett hvor nyttig den ville vært.

Grensen mellom åpent og lukket#

Kshana er åpen kjerne. Dette repoet er, og forblir, den komplette åpne AGPL-3.0-motoren — den nøytrale referansen, med kommersiell dobbeltlisens fra Ashforde OÜ (se LICENSING.md). Prosjektet vil ikke ta imot i det åpne repoet:

• Eksportkontrollert eller tosidig bruk i dybden — ekte trusselbiblioteker, motstanderes bølgeformer eller ytelsesparametere mot jamming/spoofing. Det offentlige repoet holder seg til generelle, publiserte modeller og metoder (se CONTRIBUTING.md → Export control). Spør før du bidrar hvis du er usikker.
• Fortrolige data eller kalibrering fra kunder eller partnere.
• Copyleft-avhengigheter (GPL/AGPL/LGPL/MPL) — ikke fordi de strider mot motorens egen AGPL-lisens (det gjør de ikke), men fordi de ikke kan relisensieres inn i den kommersielle utgaven: vi kan bare selge en kommersiell lisens over kode vi eier eller som er permissiv. En copyleft-avhengighet ville smitte den kommersielle utgaven og bryte dobbeltlisensen. Avhengigheter forblir derfor permissive (Apache/MIT/BSD/ISC), håndhevet av deny.toml.

Omvendt vil prosjektet ikke tømme den åpne kjernen for å skyve proprietær verdi: den validerte motoren, de offentlige valideringsankrene, ærlighetsregisteret, utvekslings- og standardformatet og distribusjonskanalene forblir åpne. Å sulte den åpne kjernen er den ene fatale feilen i åpen kjerne-modellen, og det er uaktuelt.

Utgivelser#

• Semantisk versjonering. Før 1.0 kan scenario- og resultatskjemaet endres; brytende endringer varsles tydelig, og versjonen av utvekslingsskjemaet (src/interchange.rs::SCHEMA_VERSION) er den eneste kilden til sannhet for kompatibilitet mellom artefakter.
• Utgivelsesmyndighet. Publisering (for eksempel cargo publish) er et manuelt trinn for vedlikeholderen som krever et registertoken. CI og den tag-styrte utgivelsesarbeidsflyten publiserer aldri automatisk til eksterne registre — de kjører bare alle kontroller på nytt og legger ved en byggeartefakt. Se CONTRIBUTING.md → Commits and versioning.

Atferdskodeks og sikkerhet#

• Atferd styres av CODE_OF_CONDUCT.md.
• Sikkerhetsproblemer følger den private varslingsprosessen i SECURITY.md — ikke åpne en offentlig issue for en sårbarhet.

Varemerke#

Navnet og logoen Kshana er varemerker tilhørende Ashforde OÜ. Lisensen (AGPL-3.0, eller en kommersiell lisens) dekker koden, ikke merkene: en fork kan bruke koden under lisensen, men ikke navnet Kshana eller den kanoniske distribusjonsidentiteten. Dette holder Ashforde som den siterte kilden til sannhet og er en del av hvordan den åpne kjernen forblir en nøytral referanse.

Endring av dette dokumentet#

Endringer i styringen foreslås selv som en pull request og avgjøres etter prosessen ovenfor. Når prosjektets størrelse endres, må du regne med at dette dokumentet får en beslutningsmodell med flere vedlikeholdere; den tekniske terskelen blir ikke senket.

Lett av utforming. Ærlig om i dag, med en oppgitt vei videre.