Styring af Kshana

Dette dokument fastslår, hvordan Kshana styres: hvem der træffer beslutninger, hvordan, og hvad projektet vil og ikke vil tage imod. Det er bevidst let — i forhold til projektets nuværende størrelse — og er ærligt om den nuværende virkelighed med én vedligeholder og om vejen mod bredere styring, efterhånden som fællesskabet vokser.

Mission og omfang#

Kshana er en neutral, reproducerbar og ærligt valideret reference for ydeevne og robusthed i hybrid kvante-/klassisk PNT. Missionen sætter tærsklen for enhver beslutning: korrekthed, kildehenvisninger og reproducerbarhed frem for bredde. Det ærlige omfang er dokumenteret i docs/CAPABILITY.md og valideringsstatus i docs/VALIDATION.md; forslag vurderes i forhold til dette omfang, ikke i forhold til antal funktioner.

Roller#

• Vedligeholder. Kshana vedligeholdes i øjeblikket af sin grundlægger, Ashforde OÜ (kontakt: contact@ashforde.org). Vedligeholderen træffer den endelige beslutning om omfang, udformning, udgivelser og hvad der flettes ind. Det er en model med en velvillig vedligeholder, fremstillet åbent frem for at være klædt ud som et udvalg, der ikke findes.
• Bidragydere. Enhver, der opretter en issue eller pull request. Bidrag måles mod tærsklen i CONTRIBUTING.md — proveniens for hver numerisk parameter, validering mod en offentliggjort sammenhæng og ærlighed om modenhed.
• Fremtidige committere. Når vedvarende bidrag af høj kvalitet berettiger til det, udvides commit-rettigheder til betroede bidragydere, og dette dokument opdateres til en model med flere vedligeholdere (beslutninger ved lazy consensus, hvor gruppen af vedligeholdere løser uenigheder). Indtil da er vejen: bidrag, opbyg en track record, og bliv inviteret.

Hvordan beslutninger træffes#

1. Drøftelse i det åbne. Væsentlige ændringer starter som en GitHub-issue, så begrundelse, alternativer og afvejninger er registreret.
2. Lazy consensus. Et forslag uden vedvarende indsigelse efter rimelig tid, og som består den tekniske tærskel nedenfor, går videre.
3. Vedligeholderen afgør ved uenighed. Hvor der ikke opnås enighed, afgør vedligeholderen og noterer begrundelsen. Uenighed afgøres ud fra missionen og den tekniske tærskel, ikke ud fra anciennitet eller mængde.

Den tekniske tærskel (ikke til forhandling)#

Det er faste invarianter, der håndhæves af CI og gennemgang, og som ingen beslutning tilsidesætter:

• Reproducibility. (scenario, seed, engine_version) skal gengive en kørsel bit-for-bit. En ændring, der gør dette ikke-deterministisk, er en fejl, ikke en funktion.
• Proveniens. Ingen anonyme numeriske konstanter — hver parameter angiver en kilde.
• Ærlighed i validering. Hver funktion er mærket validated (mod en uafhængig ekstern reference) eller modelled / not modeled. Intet hævdes ud over sit belæg. Se den maskinkontrollerede matrix i src/verification.rs.
• Hygiejne. Ingen angivelse af automatiske værktøjer som ophav nogen steder i commits, indhold eller historik (håndhæves af scripts/check-no-attribution.sh).

En ændring, der ikke kan nå tærsklen, afvises, uanset hvor nyttig den ville være.

Grænsen mellem åbent og lukket#

Kshana er open core. Dette repositorium er og forbliver den komplette åbne AGPL-3.0-motor — den neutrale reference, kommercielt dobbeltlicenseret af Ashforde OÜ (se LICENSING.md). Projektet vil ikke tage imod følgende i det åbne repositorium:

• Eksportkontrolleret eller dual-use-dybde — rigtige trusselsbiblioteker, modstanderes signalformer eller ydelsesparametre for anti-jam/anti-spoof. Det offentlige repositorium holder sig til generiske, offentliggjorte modeller og metoder (se CONTRIBUTING.md → Export control). Spørg før du bidrager, hvis du er i tvivl.
• Kunde- eller partnerfortrolige data eller kalibrering.
• Copyleft-afhængigheder (GPL/AGPL/LGPL/MPL) — ikke fordi de er i konflikt med motorens egen AGPL-licens (det er de ikke), men fordi de ikke kan omlicenseres ind i den kommercielle udgave: vi kan kun sælge en kommerciel licens over kode, vi ejer, eller som er permissiv. En copyleft-afhængighed ville smitte den kommercielle udgave og bryde dobbeltlicensen. Afhængigheder forbliver derfor permissive (Apache/MIT/BSD/ISC), hvilket håndhæves af deny.toml.

Omvendt vil projektet ikke udhule den åbne kerne for at skubbe proprietær værdi frem: den validerede motor, de offentlige valideringsankre, ærlighedsregisteret, udvekslings-/standardformatet og distributionskanalerne forbliver åbne. At sulte den åbne kerne er den ene skæbnesvangre fejl i open core, og den er ikke til diskussion.

Udgivelser#

• Semantisk versionering. Før 1.0 kan skemaet for scenarier og resultater ændres; brydende ændringer fremhæves, og udvekslingsskemaets version (src/interchange.rs::SCHEMA_VERSION) er den eneste sandhedskilde for artefakters kompatibilitet.
• Udgivelsesmyndighed. Publicering (for eksempel cargo publish) er et manuelt trin for vedligeholderen og kræver et registry-token. CI og den tag-styrede Release-workflow publicerer aldrig automatisk til eksterne registre — de kører kun alle kontroller igen og vedhæfter en build-artefakt. Se CONTRIBUTING.md → Commits and versioning.

Adfærdskodeks og sikkerhed#

• Adfærd er reguleret af CODE_OF_CONDUCT.md.
• Sikkerhedsproblemer følger den private indberetningsproces i SECURITY.md — opret ikke en offentlig issue for en sårbarhed.

Varemærke#

Navnet og logoet Kshana er varemærker tilhørende Ashforde OÜ. Licensen (AGPL-3.0 eller en kommerciel licens) dækker koden, ikke mærkerne: en fork må bruge koden under licensen, men ikke navnet Kshana eller den kanoniske distributionsidentitet. Det bevarer Ashforde som den citerede sandhedskilde og er en del af, hvordan den åbne kerne forbliver en neutral reference.

Ændring af dette dokument#

Ændringer af styringen foreslås selv som en pull request og afgøres ved processen ovenfor. Når projektets omfang ændrer sig, kan man forvente, at dette dokument får en beslutningsmodel med flere vedligeholdere; den tekniske tærskel bliver ikke sænket.

Let af design. Ærlig om i dag, med en angivet vej mod i morgen.