OpenSpec

Woordenlijst ​

Alle OpenSpec-termen op één plek, in duidelijke taal uitgelegd. Lees het een keer door en de rest van de documentatie leest sneller.

Termen zijn gegroepeerd op onderwerp en binnen elke groep alfabetisch gerangschikt.

De kernbegrippen ​

Specificatie. Een document dat beschrijft hoe een deel van uw systeem zich gedraagt. Specificaties bevinden zich in openspec/specs/, zijn georganiseerd per domein en bestaan uit eisen en scenario's. De specificatie is het overeengekomen antwoord op de vraag “wat doet deze software?”. Zie Concepten.

Bron van waarheid. De map openspec/specs/ als geheel. Deze bevat het huidige, overeengekomen gedrag van uw systeem. Wijzigingen stellen bewerkingen ervan voor; archivering past ze toe.

Wijziging. Eén werkeenheid, verpakt als een map onder openspec/changes/<naam>/. Een wijziging bevat alles over dat werk: het voorstel, het ontwerp, de taken en de specificatiebewerkingen die het introduceert. Eén wijziging, één feature of fix.

Artefact. Een document binnen een wijziging. De standaard artefacten zijn het voorstel, de delta-specificaties, het ontwerp en de taken. Ze worden in volgorde van afhankelijkheid aangemaakt en voeden elkaar.

Delta-specificatie. Een specificatie binnen een wijziging die alleen beschrijft wat er verandert, met behulp van de secties ADDED, MODIFIED en REMOVED, in plaats van de hele specificatie te herhalen. Dit maakt het mogelijk dat OpenSpec bestaande systemen schoon bewerkt. Zie Concepten.

Domein. Een logische groepering voor specificaties, zoals auth/, payments/ of ui/. U kiest domeinen die overeenkomen met hoe u over uw systeem denkt.

Binnen een specificatie ​

Eis. Een enkel gedrag dat het systeem moet hebben, meestal geformuleerd met een RFC 2119-sleutelwoord: “Het systeem MOET sessies na 30 minuten laten verlopen.” Eisen verwoorden het wat, niet het hoe.

Scenario. Een concreet, testbaar voorbeeld van een eis in actie, doorgaans in de vorm Given/When/Then. Scenario's maken een eis verifieerbaar: u zou er een geautomatiseerde test van kunnen schrijven.

RFC 2119-sleutelwoorden. De woorden MUST, SHALL, SHOULD en MAY, die een gestandaardiseerde betekenis hebben over hoe strikt een eis is. MUST en SHALL zijn absoluut. SHOULD is aanbevolen met ruimte voor uitzonderingen. MAY is optioneel. De naam is afkomstig van het internetstandaarddocument dat ze definieerde.

De artefacten ​

Voorstel (proposal.md). Het waarom en wat van een wijziging: de intentie, de reikwijdte en de aanpak op hoofdlijnen. Het eerste artefact dat u aanmaakt.

Ontwerp (design.md). Het hoe: technische aanpak, architectuurbeslissingen en de bestanden die u verwacht aan te raken. Optioneel voor eenvoudige wijzigingen.

Taken (tasks.md). De implementatiechecklist, met selectievakjes. De AI doorloopt deze tijdens /opsx:apply en vinkt taken af terwijl ze voltooid worden.

De levenscyclus ​

Archiveren. De handeling om een wijziging af te ronden. De delta-specificaties worden samengevoegd met de hoofdspecificaties en de wijzigingsmap verplaatst naar openspec/changes/archive/YYYY-MM-DD-<naam>/. Na archivering beschrijven uw specificaties de nieuwe realiteit. Zie Concepten.

Synchroniseren. Het samenvoegen van de delta-specificaties van een wijziging met de hoofdspecificaties zonder de wijziging te archiveren. Meestal automatisch (archiveren biedt het aan), maar beschikbaar als apart commando /opsx:sync voor langlopende wijzigingen. Zie Commando's.

Workflow en commando's ​

OPSX. De huidige standaard OpenSpec-workflow, opgebouwd rond vloeiende acties in plaats van rigide fases. De slash-commando's beginnen allemaal met /opsx:. Zie OPSX Workflow.

Slash-commando. Een commando dat u in de chat van uw AI-assistent typt, zoals /opsx:propose. Slash-commando's sturen de workflow. Het zijn geen terminalcommando's. Zie Hoe commando's werken.

Verkennen (/opsx:explore). Het denkpartner-commando. Het leest uw codebase, vergelijkt opties en verheldert een vaag idee tot een concreet plan, zonder artefacten aan te maken en zonder code te schrijven. Het aanbevolen startpunt wanneer u een probleem hebt maar nog geen plan. Zie Eerst verkennen.

CLI. Het openspec-programma dat u in uw terminal uitvoert. Het zet projecten op, toont en valideert wijzigingen, opent het dashboard en archiveert. De terminalhelft van OpenSpec. Zie CLI.

Skill. Een map met instructies (.../skills/openspec-*/SKILL.md) die uw AI-assistent automatisch detecteert en volgt. Skills zijn de opkomende cross-toolstandaard om de OpenSpec-workflow aan uw assistent te leveren.

Opdrachtbestand. Een per-tool slash-commandobestand (.../commands/opsx-*). Het oudere leveringsmechanisme, dat naast skills nog ondersteund wordt. U raakt deze zelden rechtstreeks aan.

Profiel. De set slash-commando's die in uw project is geïnstalleerd. Core (de standaard) bestaat uit propose, explore, apply, update, sync, archive. De uitgebreide set voegt new, continue, ff, verify, bulk-archive, onboard toe. Wijzig het met openspec config profile.

Levering. Of OpenSpec skills, opdrachtbestanden of beide voor uw tools installeert. Wordt globaal geconfigureerd en toegepast met openspec update.

Aanpassing ​

Schema. De definitie van welke artefacten een workflow heeft en hoe ze van elkaar afhankelijk zijn. De ingebouwde standaard is spec-driven (voorstel → specificaties → ontwerp → taken). U kunt het forken of uw eigen schrijven. Zie Aanpassing.

Sjabloon. Een Markdown-bestand binnen een schema dat bepaalt wat de AI voor een bepaald artefact genereert. Het bewerken van een sjabloon verandert de AI-uitvoer onmiddellijk, zonder opnieuw opbouwen.

Projectconfiguratie (openspec/config.yaml). Per-project instellingen: het standaardschema, de context: die in elke planningsaanvraag wordt geïnjecteerd, en per-artefact rules:. De eenvoudigste manier om OpenSpec te leren over uw stack en conventies. Zie Aanpassing.

Contextinjectie. Het plaatsen van projectachtergrond in het veld context: van config.yaml zodat deze automatisch wordt toegevoegd aan elk artefact dat de AI genereert. Betrouwbaarder dan hopen dat de AI een apart bestand leest.

Afhankelijkheidsgraaf. De gerichte graaf gevormd door de requires:-relaties van artefacten. Het is een DAG (directed acyclic graph: pijlen wijzen alleen vooruit, nooit in een lus), en OpenSpec gebruikt deze om te weten wat u hierna kunt aanmaken.

Mogelijkmakers, geen poorten. Het principe dat artefactafhankelijkheden laten zien wat er vervolgens mogelijk wordt, niet wat er vereist is. U kunt elk artefact op elk moment opnieuw bekijken en bewerken. Zie Kernconcepten in vogelvlucht.

Coördinatie over repo's heen (beta) ​

Deze termen zijn alleen van toepassing als uw planning meerdere repo's beslaat. Ze zijn in beta. De meeste gebruikers kunnen ze negeren. Zie de Stores-gebruikershandleiding.

Store. Een stand-alone repo die als enige taak planning heeft. Het heeft dezelfde openspec/-vorm die u al kent (specificaties en wijzigingen) plus een klein identiteitsbestand. U registreert het eenmalig op uw machine, op naam, waarna elk OpenSpec-commando er overal mee kan werken.

Verwijzing. Een declaratie, in de openspec/config.yaml van een coderepo, van een store waarop die repo leunt. Verwijzingen zijn alleen-lezen: de repo behoudt zijn eigen root, en openspec instructions krijgt een index van de specificaties van de gerefereerde store, elk met het exacte commando om deze op te halen.

Werkcontext. Wat openspec context samenstelt voor de huidige repo: zijn OpenSpec-root plus elke store waarnaar wordt verwezen, elk met hoe deze op te halen. Het antwoord op “waarmee werk ik?”

Werkset. Een persoonlijke, machine-lokale set mappen die u samen opent (een store naast de coderepo's waaraan u werkt). Expliciet aangemaakt met openspec workset create; niets van die lokale paden wordt vastgelegd in de gedeelde planningsrepo.

Zie ook ​