Bruk denne veiledningen til å orientere deg før du tar Symphony i bruk. Dokumentasjonen skiller mellom plattformdoktrine, brukervalgt infrastruktur, vektoreid semantikk og administrative kommandoer. Eksakte installasjons- og kjøringstrinn hører hjemme i den aktuelle komponentens gjeldende kontrakt.
1. Les driftsgrensene
Start med plattformdoktrinen. Den fastsetter brukereierskap til strategi og infrastruktur, nøytralitet overfor kallerklasse, evidensbasert kompatibilitet og beskyttelse av den varme stien.
2. Lær den fysiske modellen
Les Node, Habitat og Nest:
- Node: den identifiserte fysiske datamaskinressursen.
- Habitat: den eksakte kondisjoneringen av operativsystem og pakker som leveres til en Node.
- Nest: arbeidslasten med brukerformål som plasseres i et egnet Habitat.
En klynges busser og adaptere er eksplisitte arkitekturvalg. Symphony foreskriver ingen universell leverandør eller strategi.
3. Følg eierskapet til betydning
Arkitekturoversikten viser forholdet mellom vektorkontrakter, motorer, qxctl og styrt evidens. Vektorer og faser forklarer hvorfor en vektor forblir den semantiske eieren selv når leveransearbeid går gjennom faser. Symphony Knowledge Vector beskriver Contract Quad og de ledsagende overflatene.
4. Finn den administrative overflaten
qxctl-oversikten introduserer det administrative spørrings-CLI-et skrevet i Go. Bruk qxctl-sidene for en bestemt kommandofamilie, for eksempel kunnskap, livssyklus, motorer eller validering. qxctl leverer kommandogrammatikk og presentasjon; vektorkontrakter eier operasjonene og deres betydning.
5. Sjekk den relevante kontrakten og evidensen
Før du handler på en Node eller kaller en vektormotor, sjekk gjeldende eierkontrakt, måltilstand, autorisasjon og tilgjengelig kvittering eller valideringsevidens. Kallerautoritet og isolasjon av den varme stien forklarer disse grensene. En fremvoksende overflate er ingen implisitt driftsgaranti. Sist endret 10. oktober 2026
