Een gedetailleerd technisch plan maken

Voltooid

Een specificatie definieert wat u nodig hebt om te bouwen. Een technisch plan definieert hoe u het bouwt. In deze eenheid worden geavanceerde planningstechnieken voor bedrijfs brownfieldscenario's behandeld.

Grondbeginselen van het plan beoordelen

Het plan.md-bestand fungeert als uw ontwerpdocument, waardoor de kloof tussen hoge vereisten in spec.md en de concrete implementatietaken die volgen, wordt overbrugd. Een uitgebreid technisch plan bevat:

• Overzicht van architectuur: Weergave op hoog niveau van de interactie tussen onderdelen.
• Technologiestack en belangrijke keuzes: Expliciete documentatie van technologische keuzes met onderbouwing.
• Implementatievolgorde: Logische voortgang van implementatiestappen.
• Grondwetscontrole: Expliciet controleren of voorgestelde oplossingen voldoen aan projectprincipes.
• Veronderstellingen en open vragen: Documentatie over veronderstellingen en onopgeloste vragen.

Met deze basisprincipes in gedachten, laten we geavanceerde planningsoverwegingen voor bedrijfsontwikkeling verkennen.

Scheiding van problemen - specificatie versus plan

De scheiding van zorgen tussen specificatie en technisch plan is van cruciaal belang. Hoewel de specificatie stabiel en gericht blijft op 'wat', kan het plan zich ontwikkelen naarmate u experimenteert met verschillende 'hoe'-benaderingen.

Stel dat voor uw specificatie een functie voor het uploaden van documenten is vereist voor een interne werknemersportal. De specificatie definieert gebruikersvereisten: bestandsgrootte limieten, ondersteunde indelingen, upload-feedback en toegangscontrole. Het technische plan vertaalt deze vereisten in concrete beslissingen over de architectuur: welke Azure Storage-service moet worden gebruikt, hoe u de API structuren, welk verificatiemechanisme moet worden geïmplementeerd en hoe u bestanden valideert. Als u besluit over te schakelen van de ene technologie naar de andere, zoals overstappen van Azure Blob Storage naar Azure Files, werkt u plan.md bij terwijl spec.md grotendeels ongewijzigd blijft. De functievereisten worden niet gewijzigd; alleen de implementatiebenadering wordt gewijzigd.

Planstructuur en -inhoud onderzoeken

Een uitgebreid technisch plan bevat verschillende belangrijke secties die gezamenlijk uw implementatiebenadering definiëren.

Overzicht van architectuur

Het overzicht van de architectuur biedt een algemeen overzicht van de interactie tussen onderdelen. Voor de functie voor het uploaden van documenten kan de architectuur het volgende beschrijven:

"Implementeer een nieuw back-end-API-eindpunt /api/documents/upload voor het verwerken van uploads van meerdere onderdelen. De React-front-end bevat een nieuw DocumentUpload-onderdeel met een bestandskiezer en voortgangsindicator. Wanneer een gebruiker een bestand selecteert, valideert de front-end de grootte en het type voordat deze wordt geüpload. De back-end ontvangt het bestand, valideert het opnieuw, slaat het op in Azure Blob Storage en registreert metagegevens in de SQL-database. Nadat het uploaden is voltooid, vernieuwt de front-end de lijst met documenten om het nieuwe bestand weer te geven.'

Met deze samenvatting wordt de algehele stroom tot stand gebracht zonder in te duiken in details op codeniveau. Het zorgt ervoor dat iedereen de belangrijkste onderdelen en hun interacties begrijpt.

Beslissingen over technologiestack en belangrijke beslissingen

Het plan documenteert expliciet technologische keuzes en logica. Deze sectie voorkomt toekomstige verwarring over waarom specifieke bibliotheken of services zijn geselecteerd.

Voorbeeld van beslissingen over technologie:

• Back-end: .NET 8-web-API met Azure.Storage.Blobs SDK v12 voor blobbewerkingen.
• Front-end: React 18 met het uploadonderdeel Upload van Ant Design voor ui-consistentie.
• Verificatie: gebruik een bestaand Microsoft Entra ID-token vanuit de verificatiecontext van de portal.
• Opslag: Azure Blob Storage-container met de naam employee-documents.
• Database: Bestaande SQL-database uitbreiden met een DocumentMetadata-tabel (kolommen: Id, UserId, FileName, BlobUrl, UploadDate, FileSize).

Elke beslissing moet overeenkomen met zowel de specificatievereisten als de beginselen van de grondwet. Als uw grondwet 'Azure-services gebruiken voor alle cloudresources' vereist, selecteert het plan expliciet Azure Blob Storage en verwijst naar dit principe.

Implementatievolgorde

In het plan wordt de volgorde van de implementatiestappen beschreven. Hoewel deze volgorde niet zo gedetailleerd is als de takenlijst die later wordt gegenereerd, biedt deze reeks een logische voortgang van de installatie tot voltooiing.

Een typische implementatievolgorde voor de functie voor het uploaden van documenten:

1. Databaseschema-update: Maak een DocumentMetadata-tabel met de juiste indexen en beperkingen.
2. Back-end-API-ontwikkeling: Implementeer POST /api/documents/upload-eindpunt met bestandsvalidatie, blobopslagintegratie en persistentie van metagegevens.
3. Front-endonderdeel maken: Bouw de DocumentUpload-component met bestandsselectie, validatie aan de clientzijde en weergave van de uploadvoortgang.
4. Integratie: Verbind het front-endonderdeel met de back-end-API, verwerkt antwoorden en werk de lijst met documenten bij.
5. Beveiligingsverharding: validatie van bestandstypen aan de serverzijde, groottelimieten en verificatiecontroles implementeren.
6. Foutafhandeling: Voeg uitgebreide foutberichten toe voor fouten aan de client- en serverzijde.
7. Testen: Eenheidstests maken voor API-methoden en integratietests voor de uploadstroom.

Deze reeks zorgt ervoor dat basiselementen (databaseschema) bestaan voordat afhankelijke onderdelen (API die naar de database schrijft) worden geïmplementeerd. Elke stap bouwt voort op het vorige werk, waardoor de kans op integratieproblemen wordt verminderd.

Verificatie van grondwet

Het plan bevat een verificatiesectie die expliciet voorgestelde oplossingen controleert op basis van de grondwet. Deze verificatie voorkomt architectuurdrift en zorgt voor consistentie met projectprincipes.

Als uw beleid 'Alle gegevensopslag moet gebruikmaken van Azure-services' en 'API's moeten invoer op zowel client als server valideren' bevat, bevestigt de verificatiesectie van het plan:

• 'Het gebruik van Azure Blob Storage voldoet aan de vereisten voor Azure-services'.
• "Validatie implementeren in zowel React-component (client) als .NET API (server) is afgestemd op een diepgaande beveiligingsprincipe."
• 'Aan de verificatievereiste voor Microsoft Entra-id wordt voldaan met behulp van de bestaande portalverificatiecontext'.

Deze verificatie fungeert als controlepunt. Als het plan iets voorstelt dat in strijd is met de grondwet, markeert de AI het meestal of u merkt tijdens de beoordeling. Het aanpakken van grondwetsconflicten in de planfase voorkomt dat later opnieuw wordt bewerkt.

Veronderstellingen en open vragen

Goed samengestelde plannen documenteren veronderstellingen en onopgeloste vragen. Deze transparantie helpt u potentiële problemen te identificeren voordat de implementatie begint.

Voorbeeldveronderstellingen:

• 'Stel dat de Azure Blob Storage-container 'employee-documents' bestaat en is geconfigureerd voor privétoegang.'
• "Stel dat de bestaande SQL-database voldoende opslagcapaciteit heeft voor metagegevens."
• "Stel dat virusscans van geüploade bestanden buiten het bereik van deze iteratie vallen."

Voorbeeld van geopende vragen:

• 'Moeten beheerders de geüploade documenten van andere gebruikers kunnen verwijderen?'
• 'Hebben we auditlogboeken nodig voor alle pogingen tot documenttoegang?'
• "Moet het systeem e-mailmeldingen verzenden wanneer documenten worden geüpload?"

Door deze aannames en vragen vast te leggen, helpt u scope creep tegen te gaan en zorgt u ervoor dat belanghebbenden belangrijke beslissingen nemen voordat met coderen wordt begonnen. Als een aanname onjuist blijkt tijdens de implementatie, kunt u het plan dienovereenkomstig bijwerken.

Een plan genereren met behulp van /speckit.plan

GitHub Spec Kit genereert plannen via de /speckit.plan opdracht in GitHub Copilot Chat. Deze opdracht maakt gebruik van zowel spec.md als constitution.md als invoer voor een uitgebreid technisch ontwerp.

Voordat u de opdracht aanroept, moet u overwegen welke andere context de AI nodig heeft. Uw bestaande codebase, technologievoorkeuren en infrastructuurbeperkingen zijn allemaal van invloed op het plan. Als u deze context vooraf levert, levert u nauwkeurigere en bruikbare resultaten op.

Voor de functie voor het uploaden van documenten in een intern werknemersportalscenario kunt u context als volgt opgeven:

"De bestaande portal maakt gebruik van een React-front-end met een .NET 8 Web API-back-end. We moeten de uploadfunctie integreren in deze stack. Gebruik Azure Blob Storage voor bestandspersistentie. Microsoft Entra ID-verificatie vereisen voor alle uploadbewerkingen. In de portal is al een SQL-database beschikbaar voor metagegevensopslag.

Deze context begeleidt de AI om een plan te genereren dat naadloos in uw bestaande architectuur past in plaats van een greenfield-oplossing te voorstellen die niet overeenkomt met uw huidige stack.

De planningsopdracht aanroepen

Open GitHub Copilot Chat in Visual Studio Code en voer /speckit.plan in. Als de AI meer informatie aanvraagt, geeft u uw architectuurcontext op. GitHub Copilot verwerkt de specificatie, grondwet en uw extra context om plan.md te genereren.

De planningsfase kan even duren, omdat de AI verschillende benaderingen beschouwt, deze controleert op basis van uw grondwet en de uitvoer structureert in een coherent ontwerpdocument.

Het plan controleren en valideren

Het genereren van een plan is alleen de eerste stap. Kritieke beoordeling zorgt ervoor dat het plan nauwkeurig, volledig en afgestemd is op de behoeften van uw project.

Dekking van specificatievereisten controleren

Vergelijk het plan systematisch met spec.md. Elke vereiste in de specificatie moet worden toegewezen aan een implementatiebenadering in het plan.

Als spec.md bijvoorbeeld 'Een foutbericht weergeven voor bestanden van meer dan 50 MB' vereist, moet het plan beschrijven waar en hoe deze validatie plaatsvindt. Als het plan deze validatie weglaat, is het plan onvolledig of heeft de specificatie verduidelijking nodig.

Afstemming met technische standaarden controleren

Zorg ervoor dat de technologische keuzes van het plan overeenkomen met de standaarden en best practices van uw organisatie. Als uw team standaardiseert voor specifieke bibliotheken of patronen, moet het plan deze voorkeuren weerspiegelen.

Vragen die u moet overwegen:

• Past de voorgestelde architectuur bij bestaande systemen?
• Zijn de geselecteerde bibliotheken goedgekeurd voor gebruik in uw omgeving?
• Voldoen technologische keuzes aan het beveiligings- en nalevingsbeleid van de organisatie?
• Zijn er patronen voor vergelijkbare functionaliteit die moeten worden gevolgd?

Controleer voor de functie voor het uploaden van documenten in een Azure-omgeving of Azure Blob Storage een goedgekeurde service is, dat de verificatiemethode overeenkomt met standaarden voor bedrijfsidentiteiten (zoals het gebruik van Microsoft Entra-id) en of het voorgestelde SQL-schema de naamconventies van de database volgt.

Naleving van grondwet valideren

Het plan moet expliciete verificatie omvatten die voorgestelde oplossingen voldoen aan de grondwetsvereisten. Bekijk deze verificatiesectie zorgvuldig om ervoor te zorgen dat er geen principes worden geschonden.

Als voor uw grondwet 'Alle geheimen moeten worden opgeslagen in Azure Key Vault' is vereist en het plan voorstelt om Azure Storage-verbindingsreeksen op te slaan in appsettings.json, bestaat er een conflict. Het plan moet tijdens runtime worden herzien om verbindingsreeksen op te halen uit Key Vault.

Schendingen van de grondwet die tijdens de planning zijn ontdekt, zijn eenvoudig op te lossen. Schendingen van de grondwet die zijn gedetecteerd tijdens codebeoordeling of productie-implementatie, zijn kostbaar en verstorend.

Het plan herhalen en verfijnen

Plannen vereisen vaak verfijning na de eerste generatie. Verwacht geen perfectie bij de eerste poging. Gebruik de verduidelijkingsmogelijkheden van GitHub Copilot om de kwaliteit van het plan te verbeteren.

Ambiguïteiten en hiaten aanpakken

Als het plan vage instructies bevat, zoals 'juiste foutafhandeling implementeren', drukt u op specifieke informatie. Welke fouten kunnen zich voordoen? Hoe moet elke fout worden verwerkt? Welke foutgegevens moeten worden geregistreerd of weergegeven voor gebruikers?

Gebruik GitHub Copilot Chat om vervolgvragen te stellen: 'Welke specifieke fouten moeten het uploadeindpunt verwerken?' of 'Wat moet er gebeuren als Azure Blob Storage niet beschikbaar is?' De AI kan vage secties uitbreiden naar concrete specificaties.

Technische haalbaarheid valideren

Controleer of de voorgestelde architectuur technisch haalbaar is gezien uw beperkingen. Als het plan voorstelt om 50 MB-bestanden synchroon te uploaden via een web-API met een time-out van 30 seconden, bestaat er een probleem. Voor bestanden die meer dan 50 MB zijn, zijn mogelijk gesegmenteerde uploads of verhoogde time-outs vereist.

Neem contact op met teamleden die relevante expertise hebben. Als het plan wijzigingen in het databaseschema voorstelt, neem dan contact op met een databasebeheerder. Als er nieuwe Azure-resources nodig zijn, controleert u met infrastructuurtechnici of het inrichten mogelijk is.

Overweeg niet-functionele vereisten

Zorg ervoor dat het plan voldoet aan niet-functionele vereisten uit de specificatie: prestaties, beveiliging, schaalbaarheid, onderhoudbaarheid, toegankelijkheid.

Controleer voor het uploaden van documenten of het plan het volgende bevat:

• Prestaties: Hoe snel moet een upload worden voltooid? Wat is het maximum aantal gelijktijdige uploadvolumes?
• Beveiliging: Hoe worden bestanden gescand op malware? Hoe wordt toegang beheerd? Waar worden auditlogboeken opgeslagen?
• Schaalbaarheid: Hoe verwerkt het systeem een verhoogd uploadvolume? Wat zijn opslagcapaciteitslimieten?
• Onderhoudbaarheid: Hoe worden geüploade bestanden opgeschoond wanneer werknemers de organisatie verlaten?
• Toegankelijkheid: Voldoet de uploadinterface aan wcag-standaarden (Web Content Accessibility Guidelines) 2.1 AA?

Als in het plan een van deze overwegingen wordt weggelaten, voegt u deze expliciet toe. Niet-functionele vereisten worden vaak een bijzaak tijdens de implementatie als ze niet tijdens de planning worden aangepakt.

Haalbaarheid en volledigheid beoordelen

Evalueer of het plan voldoende richtlijnen biedt voor de implementatie. Plannen die te vaag zijn ('Uploaden van bestanden implementeren') zijn niet nuttig. Plannen die te voorschrijvend zijn ("gebruik exact 47 regels code") zijn te beperkend.

Het juiste detailniveau biedt duidelijke richting zonder alle flexibiliteit te verwijderen. Het plan moet beantwoorden:

• Welke onderdelen moeten worden gemaakt of gewijzigd?
• Hoe communiceren deze onderdelen?
• Welke technologieën en bibliotheken worden gebruikt?
• Wat is de implementatieorder?
• Welke verificatiestappen zorgen voor juistheid?

Als u niet kunt zien hoe u de functie vanuit het plan kunt implementeren, hebt u meer informatie nodig. Als het plan aanvoelt alsof het de code voor u schrijft, kan het te gedetailleerd zijn.

Ontbrekende elementen identificeren

Zoek naar hiaten in het plan. Veelvoorkomende weglatingen zijn:

• Foutafhandeling: Hoe verwerkt het systeem netwerkfouten, opslagfouten of databaseproblemen?
• Prestatieoverwegingen: Zijn er problemen met betrekking tot uploadsnelheid, gelijktijdige gebruikers of opslaglimieten?
• Teststrategie: Welke tests moeten worden geschreven om de implementatie te valideren?
• Aanpak voor terugdraaien: als de implementatie problemen veroorzaakt, hoe kunt u wijzigingen terugdraaien?

Los deze hiaten op door handmatig plan.md te bewerken of meer context te bieden en relevante secties opnieuw te genereren.

Opnieuw genereren met verfijnde context

Als het eerste plan niet aan de verwachtingen voldoet, geef meer specifieke context en genereer het plan opnieuw. Als het plan bijvoorbeeld voorstelt om een nieuwe database te gebruiken, maar u een bestaande database moet gebruiken, moet u het volgende verduidelijken: 'Gebruik de bestaande EmployeePortal-database. Voeg een DocumentMetadata-tabel toe aan deze database in plaats van een nieuwe te maken.

Genereer het plan opnieuw met /speckit.plan, gebruikmakend van deze bijgewerkte context. De AI past de benadering dienovereenkomstig aan.

Het plan handmatig bewerken

Aangezien plan.md een Markdown-bestand is, kunt u het rechtstreeks bewerken. Als de AI een benadering voorstelt die 90% juist is, maar kleine aanpassingen nodig heeft, bewerkt u het bestand in plaats van alles opnieuw te genereren.

Als het plan bijvoorbeeld een specifieke blobcontainernaam voorstelt, maar uw organisatie naamconventies heeft, werkt u de containernaam rechtstreeks bij in plan.md.

Samenwerken met teamleden

Deel plan.md in teamomgevingen voor beoordeling. Een senior ontwikkelaar of architect kan architectuurbeslissingen valideren voordat de implementatie begint. Deze peer review onderschept problemen die geautomatiseerde controles kunnen missen.

Teambeoordeling bouwt ook gedeeld begrip op. Wanneer meerdere ontwikkelaars aan een functie werken, zorgt het controleren van het plan ervoor dat iedereen de aanpak kent en potentiële conflicten met andere lopende werkzaamheden kan identificeren.

Architecturale beslissingen documenteren

Plannen moeten niet alleen documenteren wat u gaat bouwen, maar waarom u specifieke architectuurkeuzes hebt gemaakt om toekomstige ontwikkelaars inzicht te geven in de beslissingscontext.

Recordalternatieven overwogen

Wanneer u kiest tussen meerdere levensvatbare benaderingen, documenteert u de alternatieven die u hebt overwogen en waarom u er een hebt geselecteerd voor andere methoden.

Voor bestandsopslag kunt u drie benaderingen overwegen:

• Azure Blob Storage: geselecteerd voor kosteneffectiviteit, schaalbaarheid en integratie met bestaande Azure-omgeving.
• Azure Files: Geweigerd vanwege hogere kosten voor grote bestandsopslag en onnodige SMB-protocoloverhead (Server Message Block).
• SQL Database FILESTREAM: Geweigerd om te voorkomen dat de database groter en complexer wordt.

Deze documentatie voorkomt dat toekomstige ontwikkelaars zich afvragen waarom eenvoudigere benaderingen niet werden gebruikt. De beslissingsredenering wordt behouden in plaats van te verdwijnen na verloop van tijd.

Veronderstellingen vastleggen

Plannen maken veronderstellingen over bestaande systemen, infrastructuur en organisatiebeperkingen. Maak deze veronderstellingen expliciet.

Voorbeeldveronderstellingen voor het uploaden van documenten:

• Azure Blob Storage-container employee-documents wordt ingericht door het infrastructuurteam voordat de ontwikkeling begint.
• Bestaande portalverificatie biedt gevalideerde Microsoft Entra ID-tokens die kunnen worden vertrouwd voor gebruikersidentificatie.
• SQL Database heeft voldoende capaciteit voor een andere metagegevenstabel zonder opslaguitbreiding.
• Netwerkinfrastructuur ondersteunt HTTP-uploads van 50 MB zonder proxy- of firewallbeperkingen.

Als een veronderstelling onjuist blijkt tijdens de implementatie, kunt u het plan opnieuw bekijken en dienovereenkomstig aanpassen. Gedocumenteerde veronderstellingen maken impactanalyse eenvoudig wanneer de omstandigheden veranderen.

Plannen voor toekomstige evolutie

Overweeg hoe de functie zich kan ontwikkelen en ervoor te zorgen dat uw architectuur geschikt is voor waarschijnlijke extensies.

Voor het uploaden van documenten kunnen mogelijke toekomstige vereisten het volgende omvatten:

• Ondersteuning voor andere bestandstypen dan PDF en DOCX.
• Bestandsdeling tussen werknemers implementeren.
• Documentversiebeheer toevoegen.
• Bulksgewijs uploaden van meerdere bestanden inschakelen.
• Virusscans integreren

Als uw architectuur deze extensies moeilijk maakt, kunt u overwegen of het oorspronkelijke ontwerp moet worden aangepast. U implementeert op dit moment geen functies die voor de toekomst zijn bedoeld, maar u vermijdt situaties waarin toekomstige wijzigingen moeilijk en pijnlijk worden.

Het plan delen en onderhouden tijdens de implementatie

Het plan wordt uw referentie tijdens de implementatie. Ontwikkelaars moeten het plan regelmatig raadplegen om ervoor te zorgen dat hun code overeenkomt met de gedocumenteerde architectuur.

Het plan delen met belanghebbenden

Nadat u het plan hebt voltooid, deelt u het met relevante belanghebbenden voor validatie:

• Productmanagers: Controleer of het plan voldoet aan alle specificatievereisten.
• Beveiligingsteam: controleer of beveiligingscontroles voldoen aan de organisatiestandaarden.
• Infrastructuurteam: Zorg ervoor dat voorgestelde Azure-resources kunnen worden ingericht en geconfigureerd.
• Architectuurteam: De afstemming met de principes van de organisatiearchitectuur valideren.

Deze belanghebbende beoordeelt problemen voordat de implementatie begint. Als feedback van beveiligingsteam aangeeft dat voorgestelde verificatie onvoldoende is, werkt u het plan bij voordat u code schrijft.

Werk het plan indien nodig bij

Plannen zijn levende documenten. Wanneer u tijdens de implementatie ontdekt dat een benadering niet werkt zoals bedoeld, werkt u het plan bij zodat deze overeenkomt met de nieuwe aanpak.

Als u had gepland de voortgang van het uploaden op te slaan in localStorage in de browser, maar zodra u ontdekt dat dit problemen veroorzaakt in de modus voor privé browsen, pas dan het plan aan om een geheugenstatus te gebruiken. Documenteer waarom de wijziging nodig was, zodat de redenering behouden blijft.

Houd plan.md gesynchroniseerd met de werkelijke implementatie. Wanneer plannen en code afwijken, verliest het plan de waarde als referentiedocumentatie.

• Voldoen de beveiligingsmethoden aan de vereisten van de organisatie?
• Volgt het databaseschema de volgende naamconventies?

Als het plan voorstelt om een database te gebruiken, maar uw bestaande portal al een database heeft, is dat waarschijnlijk overkill. Als het plan een technologie voorstelt die uw team vermijdt, documenteer dan waarom of pas het plan aan.

Veelvoorkomende valkuilen voor planning om te voorkomen

Vermijd deze veelvoorkomende fouten bij het maken en controleren van plannen:

• De planningsfase overslaan: Springen van specificatie naar code zonder plan verhoogt het risico op architecturale fouten. De tijd die in de planning is geïnvesteerd, betaalt dividenden door herwerk te voorkomen.

• Plannen accepteren zonder beoordeling: DOOR AI gegenereerde plannen zijn uitgangspunten, niet definitieve ontwerpen. Controleer altijd kritisch en controleer op basis van uw specifieke context.

• Implementatie met te veel beperkingen: plannen moeten leiden, niet elk detail dicteren. Laat ontwikkelaars de ruimte over om de juiste tactische beslissingen te nemen tijdens de implementatie.

• Grondwetsconflicten negeren: Als het plan de beginselen van de grondwet schendt, moet u het conflict onmiddellijk aanpakken. Pas het plan aan om de grondwet na te leven of bij te werken als het beginsel moet worden herzien.

• Vergeet plannen bij te werken: wanneer de implementatie nieuwe informatie weergeeft, werkt u plan.md bij. Verouderde plannen misleiden toekomstige ontwikkelaars en verminderen de waarde van uw documentatie.

Samenvatting

Het technische plan transformeert uw specificatie in bruikbare architectuur. Genereer plannen met behulp van /speckit.plan, met de juiste context over uw technologiestack en infrastructuur. Bekijk kritisch plannen om ervoor te zorgen dat ze voldoen aan alle specificatievereisten, in overeenstemming zijn met uw grondwet en voldoende implementatierichtlijnen bieden. Gebruik het gevalideerde plan om het genereren en implementeren van taken te begeleiden. Behandel plan.md als een levend document dat zich ontwikkelt met uw begrip en waardevolle context biedt voor de volledige ontwikkelingslevenscyclus.