# Eerste stappen. Geavanceerde AI.
**GEPUBLICEERDE GIDS**
Bouw je eerste website met een AI-agent.
Instructies voor het laatst gecontroleerd: 2026-10-08. Controleer software-instructies, links en prijzen opnieuw voordat je ze gebruikt.
Volg de stappen op volgorde. De vinkjes zijn persoonlijke herinneringen; ze bewijzen niet dat een site getest, veilig of klaar voor publicatie is.
## Inhoud
- [1. Codex klaarzetten](#agentic-harness) (Voorbereiden)
- [2. Maak je GitHub-project](#github-account) (Voorbereiden)
- [3. Open het project op je computer](#local-project) (Voorbereiden)
- [4. Kies je toegang tot OpenAI](#openai-access) (Voorbereiden)
- [5. Houd privégegevens veilig](#secrets) (Voorbereiden)
- [6. Geef Codex je werkafspraken](#working-agreements) (Voorbereiden)
- [7. Voeg vier handige skills toe](#design-quality-skills) (Voorbereiden)
- [8. Schrijf je websitebrief](#website-brief) (Plannen)
- [9. Plan je pagina’s en inhoud](#sitemap-content) (Plannen)
- [10. Kies een eenvoudige websiteopzet](#technical-foundation) (Plannen)
- [11. Kies het uiterlijk van je website](#visual-direction) (Plannen)
- [12. Plan kleine bouwstappen](#implementation-plan) (Plannen)
- [13. Bouw je eerste pagina](#build-the-foundation) (Bouwen en controleren)
- [14. Rond de andere pagina’s af](#complete-the-pages) (Bouwen en controleren)
- [15. Probeer de website als bezoeker](#test-as-a-visitor) (Bouwen en controleren)
- [16. Controleer beveiliging en privacy](#review-security-and-privacy) (Bouwen en controleren)
- [17. Maak de site sneller en duidelijker](#polish-speed-and-search) (Bouwen en controleren)
- [18. Beoordeel de site en stel automatische controles in](#review-and-automate-checks) (Publiceren en onderhouden)
- [19. Publiceer je site en controleer hem online](#publish-and-verify) (Publiceren en onderhouden)
- [20. Houd je site werkend](#maintain-and-improve) (Publiceren en onderhouden)
## 1. Codex klaarzetten
Fase: Voorbereiden
Installeer de desktopapp, kies een oefenmap en probeer je eerste taak met Codex.
Een gewone chat stelt code voor. Een agent kan bestanden bekijken en aanpassen, commando’s uitvoeren, resultaten controleren en fouten herstellen. De werkomgeving, ook wel harness genoemd, biedt deze hulpmiddelen en regelt de toegang. Jij bepaalt wat je bouwt en wanneer het klaar is.
Ons voorbeeld is Fieldnotes Studio, een fictief bedrijf met de pagina’s Home, About, Services en Contact. Volgens de huidige officiële snelstart installeer je de ChatGPT-desktopapp en kies je daarin Codex. Volg de gekoppelde instructies als namen veranderen.
### Doe dit
1. Gebruik de [officiële snelstart](https://learn.chatgpt.com/docs/quickstart) om de ChatGPT-desktopapp voor jouw computer te installeren.
**Installeer de app**
Voorbeeld ter illustratie: Illustratie: download de ChatGPT-desktopapp, installeer en open hem. Kooka wijst naar de geopende app.
- **Klikroute:** Downloaden → Installeren → Openen
**Let op:** De desktopapp opent op je computer.
2. Open de app en [meld je aan met ChatGPT](https://learn.chatgpt.com/docs/auth). Gebruik het account waarmee je wilt werken.
**Meld je aan**
Voorbeeld ter illustratie: Illustratie: kies Sign in, rond de aanmelding met je account af in een browser en ga terug naar de desktopapp.
- **Klikroute:** Sign in → Aanmelden in de browser → Terug naar de app
**Let op:** Je bent aangemeld met het account dat je wilde gebruiken.
3. Maak in Documents een lege map website-workshop: [instructies voor Mac](https://support.apple.com/guide/mac-help/organize-files-with-folders-mh26885/mac) of [instructies voor Windows](https://support.microsoft.com/en-us/word/create-a-new-folder).
**Maak je oefenmap**
Voorbeeld ter illustratie: Illustratie: open Documents, maak een nieuwe map website-workshop, open de map en controleer of die leeg is.
- **Mac:** Finder → Documents → File → New Folder
- **Windows:** File Explorer → Documents → New → Folder
- **Beide:** Noem de map website-workshop. Druk op Return of Enter en dubbelklik erop.
**Let op:** Een lege map website-workshop in Documents.
Een map bevat bestanden, zoals een lade met een etiket. Documents staat al op je computer. Maak daarin website-workshop als oefenplek en laat die voorlopig leeg. Klik op de instructies voor jouw computer. We gebruiken Engelse menunamen; Documents kan in het Nederlands Documenten heten.
**Op een Mac: bekijk de klikken**
1. Klik op Finder, het blauwe gezichtje in het Dock. Het Dock is de rij app-iconen, meestal onder aan je scherm. [Apples uitleg over Finder](https://support.apple.com/en-euro/guide/mac-pro/apddf030866a/mac) laat zien hoe het eruitziet.
2. Klik links in Finder op Documents. Staat het er niet? Gebruik dan de menubalk helemaal boven aan het scherm: klik op [Go en daarna Documents](https://support.apple.com/guide/mac-help/go-directly-to-a-specific-folder-on-mac-mchlp1236/mac).
3. Open Documents, klik in die bovenste menubalk op File en daarna New Folder. Typ website-workshop, met kleine letters en een koppelteken, en druk op Return op je toetsenbord.
4. Dubbelklik op website-workshop om de map te openen. Controleer of de naam boven aan het venster staat en er geen bestanden of andere mappen in staan. Laat dit venster open zodat je de map terugvindt.
**Op Windows: bekijk de klikken**
1. Open File Explorer, het mapicoon in de taakbalk onder aan je scherm. Kun je het niet vinden? Houd de toets met het Windows-logo ingedrukt, druk op E en laat beide toetsen los. [Microsofts uitleg over File Explorer](https://support.microsoft.com/en-us/windows/experience/fileexplorer/file-explorer-in-windows) beschrijft dit venster.
2. Klik links in File Explorer op Documents. Je kunt ook op Home klikken en Documents onder Quick access openen. Staat het er niet? Klik op Home, daarna op de pijl omhoog naast de adresbalk, en open Documents uit de getoonde mappen.
3. Open Documents, klik boven in het venster op New en daarna Folder. Heeft jouw versie een knop New folder? Gebruik die. Typ website-workshop, met kleine letters en een koppelteken, en druk op Enter op je toetsenbord.
4. Dubbelklik op website-workshop om de map te openen. Controleer of de adresbalk bovenaan eindigt op Documents > website-workshop en of er geen bestanden of andere mappen in staan. Laat dit venster open zodat je de map terugvindt.
**Dit zou je nu moeten zien:** Een lege map met de naam website-workshop in Documents. De locatie is Documents → website-workshop; de pijl betekent ‘in’. Als Documents ook iCloud of OneDrive toont, wordt de map mogelijk gesynchroniseerd. Je kiest hem nog steeds via het bestandsvenster op je computer. Bestaat website-workshop al en staan er bestanden in? Maak dan website-workshop-practice en gebruik die naam in dit hele hoofdstuk.
4. Kies Codex in het ChatGPT-menu. [Voeg een lokaal project toe](https://learn.chatgpt.com/docs/projects?surface=app) via Documents → website-workshop en begin een New chat.
**Koppel je map**
Voorbeeld ter illustratie: Illustratie: kies in Codex Add project, selecteer Documents en website-workshop, bevestig de map en begin een New chat.
- **Klikroute:** ChatGPT-menu → Codex → Add project → Documents → website-workshop
- **Daarna:** Open op Mac / Select Folder op Windows → New chat. Kies Local als dat gevraagd wordt.
**Let op:** Je nieuwe chat hoort bij website-workshop.
Ga terug naar de desktopapp die je bij actie 1 installeerde. Door een lokaal project te koppelen vertel je Codex welke map je werk bevat. Je kiest de map die je zojuist maakte; uploaden of een tweede kopie maken is niet nodig.
**Open je oefenmap in Codex**
1. Toont de app ChatGPT? Klik linksboven op het ChatGPT-keuzemenu en kies Codex, zoals in de [officiële snelstart](https://learn.chatgpt.com/docs/quickstart). Zit je al in Codex? Ga dan verder.
2. Kies Add project in de linkerzijbalk van Codex. Zie je eerst een Projects-pagina? Open die en kies daar de optie om een project toe te voegen. Kies een lokale map op deze computer als de app vraagt waar het project moet staan.
3. Er opent een venster om een map te kiezen. Klik links op Documents en selecteer website-workshop. Bevestig met Open op Mac of Select Folder op Windows; de knopnaam kan verschillen. Selecteer website-workshop zelf, niet de hele map Documents.
4. Controleer of website-workshop als project in de zijbalk staat. Klik op dat project en begin daarin een New chat. Biedt de chat een keuze bij Work in? Kies Local: deze computer.
**Dit zou je nu moeten zien:** Een nieuwe Codex-chat die hoort bij de gekozen map: website-workshop of website-workshop-practice als je die alternatieve naam gebruikte. Het is prima dat er nog geen websitebestanden zijn. In hoofdstuk 3 open je een andere map met je GitHub-project; houd deze oefenmap voorlopig.
5. Kies onder het berichtvak [Ask for approval](https://learn.chatgpt.com/docs/permission-modes). Daarmee zijn projectwijzigingen toegestaan; voor extra toegang vraagt Codex toestemming.
**Kies je toegangsinstelling**
Voorbeeld ter illustratie: Illustratie: open de toegangsinstelling onder het berichtvak en kies Ask for approval. Een schild markeert de projectmap; een vraagteken markeert verzoeken om extra toegang.
- **Klikroute:** Onder het berichtvak → Permissions → Ask for approval
**Let op:** Ask for approval is geselecteerd. Lees verzoeken om extra toegang voordat je ze goedkeurt.
Toegangsinstellingen bepalen wat Codex mag doen en wanneer het je eerst iets vraagt. De workspace is de projectmap uit actie 4. Ask for approval laat Codex bestanden daarin aanpassen en gewone lokale taken uitvoeren; voor extra toegang vraagt het toestemming. Het vraagt niet vóór elke wijziging binnen de map.
**Vind de instelling en begrijp een verzoek**
1. Kijk onder het berichtvak waar je je opdracht typt. Open de toegangsinstelling: die kan de huidige stand tonen, zoals Ask for approval, Approve for me of Full access.
2. Kies Ask for approval. Staat die stand al aan? Laat hem geselecteerd. Voor deze oefening hoef je geen extra standen in Settings aan te zetten.
3. Verschijnt bij een latere taak een toestemmingsverzoek? Lees welke toegang of welk commando wordt gevraagd en waarom. ‘De pakketten van de website installeren’ betekent bijvoorbeeld dat ondersteunende software voor het project wordt gedownload. Keur het specifieke verzoek één keer goed als het past bij jouw opdracht.
4. Noemt een verzoek een ander project, vraagt het bestanden te verwijderen of is het onduidelijk? Kies de optie om te weigeren of te annuleren. Vraag Codex: ‘Leg in gewone taal uit wat dit verzoek doet en waarom het nodig is.’ Houd Ask for approval geselecteerd terwijl je leert.
**Dit zou je nu moeten zien:** Ask for approval staat onder het berichtvak. Bij actie 6 vraagt je eerste bericht expliciet om de map te bekijken zonder iets te wijzigen. Dat is een opdracht voor deze taak; de gekozen toegangsinstelling staat wijzigingen binnen de projectmap nog steeds toe.
6. Kopieer en verstuur de [oriëntatieprompt zonder wijzigingen](#agentic-harness-prompts). Controleer of Codex je map noemt en leeg laat.
**Probeer je eerste taak**
Voorbeeld ter illustratie: Illustratie: kopieer de oriëntatieprompt, plak hem in Codex en verstuur hem. Controleer of het antwoord website-workshop noemt en of er geen bestanden zijn gewijzigd.
- **Klikroute:** Prompt kopiëren → In Codex plakken → Versturen
**Let op:** Codex herkent je map zonder de bestanden te wijzigen.
De basis uitgelegd
**Documents en een projectmap**
Documents is een standaardmap op je computer. Een projectmap kies je voor één werkstuk, zoals website-workshop in Documents. Bewaar alle bestanden voor dat project samen in die map.
**Lokaal en cloud**
Lokaal betekent dat de agent werkt met bestanden op jouw computer. Cloud betekent dat het werk op een externe computer gebeurt. Deze oefening gebruikt een lokale map. Een map in Documents kan daarnaast door iCloud of OneDrive worden geback-upt.
**Venster om een map te kiezen**
Een venster waarmee je door je computer bladert en een map voor een app kiest. Selecteer de bedoelde projectmap en bevestig met Open of Select Folder.
**Agentic harness**
De softwareomgeving rond een AI-model die hulpmiddelen, projectinformatie, werkinstructies en toegangsinstellingen biedt.
**AI-agent**
Een AI-systeem dat een taak kan uitvoeren met hulpmiddelen en feedback, bijvoorbeeld een pagina aanpassen en daarna controleren in een browser.
**Werkruimte (workspace)**
De map of omgeving met de projectbestanden waaraan de agent werkt.
**Toestemming**
Een regel die bepaalt welke bestanden, commando’s, netwerkverbindingen of apps de agent mag gebruiken.
### Prompt: Je eerste Codex-taak
```text
Ik bouw voor het eerst een website met een AI-agent. Bekijk deze map zonder bestanden te wijzigen of iets te installeren. Noem de map, leg je hulpmiddelen en toegangsinstellingen uit en beschrijf hoe ik wijzigingen kan controleren. Leg onbekende woorden uit.
```
### Controleer je werk
- [ ] De app opent en toont het account dat je wilde gebruiken.
- [ ] Codex herkent je gekozen oefenmap (website-workshop of website-workshop-practice) en Ask for approval is geselecteerd.
- [ ] De oriëntatietaak eindigt zonder projectbestanden te maken of te wijzigen.
Als er iets misgaat
**Ik heb een project toegevoegd, maar Codex gebruikt de verkeerde map.**
Open het menu van dat project en kies Edit project. Controleer de gekoppelde map. Gebruik Add folder om Documents → website-workshop te koppelen, verwijder onbedoeld gekoppelde mappen en maak website-workshop de hoofdmap als er meerdere staan. Begin een nieuwe chat in dat project.
**Codex kan de map niet lezen.**
Controleer de geselecteerde map en lees het toestemmingsverzoek. Geef toegang tot die projectmap of gebruik een gewone map in Documents.
### Officiële links & verder lezen
- [Officiële installatie en snelstart voor de desktopapp](https://learn.chatgpt.com/docs/quickstart)
- [Officiële aanmeldopties voor Codex](https://learn.chatgpt.com/docs/auth)
## 2. Maak je GitHub-project
Fase: Voorbereiden
Maak een gratis GitHub-account en een afgeschermde plek voor je websitebestanden.
GitHub bewaart projectbestanden en hun wijzigingsgeschiedenis. GitHub Free is genoeg voor dit afgeschermde oefenproject.
Private beperkt de toegang tot de bronbestanden. Het maakt een gepubliceerde website niet privé en beschermt geen opgeslagen wachtwoorden.
### Doe dit
1. Maak een [GitHub Free-account](https://docs.github.com/en/account-and-profile/how-tos/account-management/creating-an-account-on-github). Kies een gebruikersnaam en bevestig je e-mailadres.
**Maak je account**
Voorbeeld ter illustratie: Illustratie: maak een gratis GitHub-account en bevestig het e-mailadres.
- **Klikroute:** GitHub → Sign up → E-mailadres bevestigen
**Let op:** Je GitHub-account opent en je e-mailadres is bevestigd.
GitHub staat los van OpenAI. GitHub Free ondersteunt private repositories; hiervoor is geen betaald abonnement nodig. Geavanceerde functies en hostingdiensten hebben hun eigen abonnementen. Een repository bewaart projectbestanden en geschiedenis. Private beperkt de toegang tot de bronbestanden; het beveiligt de website niet en voorkomt niet dat hosting die later publiceert. Bewaar nooit inloggegevens in repositories.
**Toon de stappen**
1. Volg de [handleiding voor een GitHub-account](https://docs.github.com/en/account-and-profile/how-tos/account-management/creating-an-account-on-github), kies een gebruikersnaam, rond de registratie af en bevestig je e-mailadres.
2. Gebruik een e-mailadres waar je bij kunt. Kies het persoonlijke Free-abonnement als GitHub je een keuze biedt.
3. Open de bevestigingsmail en volg de instructies; kijk in spam als hij niet aankomt.
**Dit zou je nu moeten zien:** Je GitHub-account opent en je e-mailadres is bevestigd.
2. Open in GitHub Settings → Password and authentication. Stel [tweestapsverificatie](https://docs.github.com/en/authentication/securing-your-account-with-two-factor-authentication-2fa/configuring-two-factor-authentication) in met een authenticator-app.
**Bescherm je aanmelding**
Voorbeeld ter illustratie: Illustratie: koppel een authenticator-app via GitHubs instellingen voor tweestapsverificatie.
- **Klikroute:** Profielfoto → Settings → Password and authentication → Enable two-factor authentication
**Let op:** Je authenticator-app is gekoppeld; sla bij de volgende actie de herstelcodes op om het af te ronden.
Volg deze stappen als je meer uitleg wilt.
**Toon de stappen**
1. Open je profielfoto > Settings > Password and authentication. [Zet tweestapsverificatie aan](https://docs.github.com/en/authentication/securing-your-account-with-two-factor-authentication-2fa/configuring-two-factor-authentication) met een authenticator-app en rond de controle af.
2. Gebruik een authenticator-app die je vertrouwt op je telefoon of computer.
3. Volg GitHubs instructies voor het scannen of invoeren van de instelsleutel in je eigen account. Voer daarna de tijdelijke code uit de app in.
4. Houd de instelsleutel en codes geheim. Ga verder naar het scherm met herstelcodes; bij de volgende actie rond je de instelling af.
**Dit zou je nu moeten zien:** Je authenticator-app is gekoppeld; sla bij de volgende actie de herstelcodes op om het af te ronden.
3. Bewaar je [herstelcodes](https://docs.github.com/en/authentication/securing-your-account-with-two-factor-authentication-2fa/configuring-two-factor-authentication-recovery-methods) in een wachtwoordmanager. Controleer of je ze kunt terugvinden en rond de instelling af.
**Bewaar je herstelcodes**
Voorbeeld ter illustratie: Illustratie: bewaar herstelcodes op een beveiligde plek en bevestig dat ze zijn opgeslagen.
- **Klikroute:** Herstelcodes opslaan → Wachtwoordmanager → Opslag bevestigen
**Let op:** Tweestapsverificatie staat aan en je kunt je herstelcodes vinden.
Volg deze stappen als je meer uitleg wilt.
**Toon de stappen**
1. Bewaar je [GitHub-herstelcodes](https://docs.github.com/en/authentication/securing-your-account-with-two-factor-authentication-2fa/configuring-two-factor-authentication-recovery-methods) in een wachtwoordmanager of een andere beveiligde plek die niet afhankelijk is van je telefoon. Controleer of je ze kunt terugvinden.
2. Download of kopieer de codes op het scherm Save your recovery codes naar een beveiligde opslagplek.
3. Controleer of je het opgeslagen item zonder je authenticator-apparaat kunt openen. Laat geen onbeveiligde kopie in Downloads achter.
4. Ga terug naar GitHub en kies I have saved my recovery codes om tweestapsverificatie aan te zetten.
**Dit zou je nu moeten zien:** Tweestapsverificatie staat aan en je kunt je herstelcodes vinden.
4. Kies GitHubs plusmenu → [New repository](https://docs.github.com/en/repositories/creating-and-managing-repositories/quickstart-for-repositories). Noem het fieldnotes-studio, kies Private en zet Add README aan.
**Bereid je repository voor**
Voorbeeld ter illustratie: Illustratie: noem de repository fieldnotes-studio, kies Private en zet Add README aan.
- **Klikroute:** Plusmenu → New repository
- **Kies:** fieldnotes-studio → Private → Add README: On
**Let op:** Het formulier toont fieldnotes-studio, Private en Add README ingeschakeld.
Volg deze stappen als je meer uitleg wilt.
**Toon de stappen**
1. Gebruik GitHubs plusmenu > New repository en volg de [instructies voor een repository](https://docs.github.com/en/repositories/creating-and-managing-repositories/quickstart-for-repositories). Noem hem fieldnotes-studio, kies Private en zet Add README aan.
2. Kies je eigen account als eigenaar van de repository.
3. Gebruik precies de naam fieldnotes-studio, zodat latere commando’s kloppen. Controleer het formulier voordat je hem maakt.
**Dit zou je nu moeten zien:** Het formulier toont fieldnotes-studio, Private en Add README ingeschakeld.
5. Klik op [Create repository](https://docs.github.com/en/repositories/creating-and-managing-repositories/quickstart-for-repositories). Bewaar de pagina als bladwijzer; hoofdstuk 3 gebruikt your-username/fieldnotes-studio.
**Maak hem en bewaar de link**
Voorbeeld ter illustratie: Illustratie: maak de afgeschermde repository en bewaar de GitHub-pagina als bladwijzer.
- **Klikroute:** Create repository → Pagina als bladwijzer bewaren
**Let op:** De repositorypagina toont fieldnotes-studio, Private en README.md.
Volg deze stappen als je meer uitleg wilt.
**Toon de stappen**
1. Maak de repository en bewaar de pagina als bladwijzer. Het adres eindigt op your-username/fieldnotes-studio; gebruik die exacte naam bij het [koppelen van het lokale project in hoofdstuk 3](#local-project).
2. Controleer het label Private en README.md op de nieuwe repositorypagina.
3. your-username is een voorbeeldnaam die je vervangt door je echte GitHub-gebruikersnaam. Noteer het deel eigenaar/project van het adres.
4. Een repository maken bewaart bronbestanden; het publiceert geen website.
**Dit zou je nu moeten zien:** De repositorypagina toont fieldnotes-studio, Private en README.md.
6. Open README.md → Edit. Voeg een korte projectbeschrijving toe, [sla je eerste wijziging op als commit](https://docs.github.com/en/repositories/creating-and-managing-repositories/quickstart-for-repositories) en zoek die in de geschiedenis.
**Sla je eerste wijziging op**
Voorbeeld ter illustratie: Illustratie: bewerk en bekijk README.md en sla daarna een benoemde commit op.
- **Klikroute:** README.md → Potlood / Edit → Preview → Commit changes
- **Bericht:** Describe practice website
**Let op:** De GitHub-geschiedenis bevat je README-wijziging en het commitbericht.
Volg deze stappen als je meer uitleg wilt.
**Toon de stappen**
1. Volg GitHubs [uitleg voor een eerste commit](https://docs.github.com/en/repositories/creating-and-managing-repositories/quickstart-for-repositories): open README.md, kies Edit en voeg een projectbeschrijving toe. Sla op met het bericht Describe practice website en zoek het item in de geschiedenis.
2. Gebruik bijvoorbeeld deze beschrijving: Een oefenwebsite van vier pagina’s voor Fieldnotes Studio.
3. Kies Preview en controleer de tekst voordat je Commit changes kiest.
4. Sla deze kleine README-wijziging voor je nieuwe afgeschermde oefenproject op in de huidige standaardbranch. Hoofdstuk 3 maakt een aparte bouwbranch.
**Dit zou je nu moeten zien:** De GitHub-geschiedenis bevat je README-wijziging en het commitbericht.
De basis uitgelegd
**Repository**
Een projectmap met een geschiedenis van wijzigingen. GitHub bewaart repositories online; op je computer komt een lokale kopie.
**Commit**
Een opgeslagen momentopname van gekozen projectwijzigingen, met een bericht dat uitlegt wat is veranderd.
**Tweestapsverificatie**
Een tweede controle bij het aanmelden, naast je wachtwoord, zoals een tijdelijke code uit een authenticator-app.
**README**
Het inleidende bestand dat uitlegt wat een project is en hoe je ermee werkt.
### Prompt: Begrijp GitHub
```text
Leg een repository, een commit en een lokale kopie uit met een website van vier pagina’s als voorbeeld. Ik heb een private repository fieldnotes-studio met een README gemaakt. Leg uit wat ik moet zien. Vraag niet om inloggegevens of herstelcodes.
```
### Controleer je werk
- [ ] Je GitHub-e-mailadres is bevestigd en tweestapsverificatie staat aan.
- [ ] Je kunt je bewaarde herstelcodes vinden zonder ze in het project te zetten.
- [ ] De repository fieldnotes-studio toont het label Private en je README-commit.
Als er iets misgaat
**GitHub vraagt om een betaald abonnement.**
Kies het persoonlijke Free-abonnement. Voor deze afgeschermde oefenrepository is Pro niet nodig.
**Je kunt de repository niet maken.**
Controleer de e-mailbevestiging, ook in spam. Volg GitHubs hulp bij bevestiging voordat je een ander account maakt.
### Officiële links & verder lezen
- [Maak een GitHub-account](https://docs.github.com/en/account-and-profile/how-tos/account-management/creating-an-account-on-github)
- [Vergelijk GitHub-abonnementen](https://docs.github.com/en/get-started/learning-about-github/githubs-plans)
- [Stel tweestapsverificatie in](https://docs.github.com/en/authentication/securing-your-account-with-two-factor-authentication-2fa/configuring-two-factor-authentication)
- [Maak een repository en je eerste commit](https://docs.github.com/en/repositories/creating-and-managing-repositories/quickstart-for-repositories)
## 3. Open het project op je computer
Fase: Voorbereiden
Installeer drie hulpmiddelen, download je GitHub-project en open het in Codex.
Git bewaart versies. Node voert websitebouwgereedschap uit en npm installeert de bijbehorende pakketten. GitHub CLI, afgekort gh, helpt ons om met GitHub te verbinden.
Een branch houdt je bouwwerk apart. Voer commando’s één voor één uit en lees elk resultaat voordat je verdergaat.
### Doe dit
1. Installeer [Git](https://git-scm.com/install/), [Node LTS](https://nodejs.org/en/download) en [GitHub CLI](https://cli.github.com/) voor je computer. Open daarna je terminal opnieuw.
**Installeer de drie hulpmiddelen**
Voorbeeld ter illustratie: Illustratie: installeer Git, Node LTS met npm en GitHub CLI vanuit officiële bronnen.
- **Installeer:** Git → Node LTS → GitHub CLI
**Let op:** Alle drie de hulpmiddelen zijn geïnstalleerd op je computer.
Git bewaart versies; GitHub bewaart ze online. Node voert ontwikkelhulpmiddelen uit en npm installeert hun pakketten. Gebruik een huidige Node LTS-versie die Astro ondersteunt: dit concept vereist minimaal 22.12 en sluit oneven versienummers uit. We gebruiken GitHub CLI, gh, om via de browser aan te melden en te klonen. Codex CLI is optioneel als je de desktopapp gebruikt. Voer commando’s apart uit en los fouten op voordat je verdergaat.
**Toon de stappen**
1. Installeer [Git](https://git-scm.com/install/), [Node LTS](https://nodejs.org/en/download) en [GitHub CLI](https://cli.github.com/) volgens de officiële instructies voor je besturingssysteem. Open daarna de terminal opnieuw.
2. Gebruik de officiële installatie-instructies voor je besturingssysteem. npm wordt met Node meegeleverd.
3. [Astro vereist Node 22.12 of hoger](https://docs.astro.build/en/install-and-setup/) en ondersteunt geen oneven Node-versienummers.
4. Het commando van GitHub CLI heet gh. Het is iets anders dan Codex CLI, dat optioneel is als je de desktopapp gebruikt.
**Dit zou je nu moeten zien:** Alle drie de hulpmiddelen zijn geïnstalleerd op je computer.
2. Open Terminal op Mac of PowerShell op Windows. Voer de [versiecontroles](#local-project-example-1) regel voor regel uit.
**Controleer de hulpmiddelen**
Voorbeeld ter illustratie: Illustratie: controleer geïnstalleerde hulpmiddelen in Terminal of PowerShell en lees de versienummers.
- **Mac:** Terminal → Versiecontroles
- **Windows:** PowerShell → Versiecontroles
**Let op:** Git, Node, npm en gh geven versienummers terug; Node voldoet aan de eis van Astro.
Volg deze stappen als je meer uitleg wilt.
**Toon de stappen**
1. Open Terminal op macOS/Linux of PowerShell op Windows. Voer de [versiecontroles](#local-project-example-1) één commando tegelijk uit; elk commando moet een versienummer geven.
2. Zoek op Mac naar Terminal met Spotlight. Open op Windows Start en zoek naar PowerShell.
3. Kopieer één regel uit Controleer de geïnstalleerde hulpmiddelen, plak hem in de terminal, druk op Enter en bekijk het resultaat.
4. Ontbreekt een commando? Open de terminal opnieuw en controleer de installatie van dat hulpmiddel voordat je verdergaat.
**Dit zou je nu moeten zien:** Git, Node, npm en gh geven versienummers terug; Node voldoet aan de eis van Astro.
3. Voer [gh auth login](https://cli.github.com/manual/gh_auth_login) uit. Kies GitHub.com → HTTPS → Browser, rond de aanmelding af en voer gh auth status uit.
**Verbind de terminal met GitHub**
Voorbeeld ter illustratie: Illustratie: meld GitHub CLI aan via een browser en controleer de aanmeldstatus.
- **Kies:** GitHub.com → HTTPS → Aanmelden via de browser
- **Daarna:** gh auth status
**Let op:** gh auth status noemt je bedoelde GitHub-account zonder een token te tonen.
Volg deze stappen als je meer uitleg wilt.
**Toon de stappen**
1. Voer [gh auth login](https://cli.github.com/manual/gh_auth_login) uit. Kies GitHub.com, HTTPS, aanmelden via de browser en Yes als gevraagd wordt om Git te authenticeren. Rond de browserstappen af en voer gh auth status uit.
2. Hiermee meld je GitHub CLI aan bij GitHub; je Codex- of OpenAI-account verandert niet.
3. Kies Yes als gevraagd wordt om Git te authenticeren. Rond de browserstappen af in je eigen account.
4. Deel nooit een tijdelijke apparaatcode of token. Controleer het account dat gh auth status toont.
**Dit zou je nu moeten zien:** gh auth status noemt je bedoelde GitHub-account zonder een token te tonen.
4. Open Documents: [Mac](#local-project-example-2) / [Windows](#local-project-example-3). Voer de [klooncommando’s](#local-project-example-4) uit; vervang YOUR\_USERNAME door je GitHub-gebruikersnaam.
**Download je project**
Voorbeeld ter illustratie: Illustratie: kloon fieldnotes-studio van GitHub en open de lokale kopie.
- **Begin in:** Terminal of PowerShell → Documents
- **Voer uit:** gh repo clone YOUR\_USERNAME/fieldnotes-studio
- **Daarna:** cd fieldnotes-studio
**Let op:** Je computer bevat fieldnotes-studio met README.md en de Git-geschiedenis van het project.
Download je GitHub-repository naar Documents met de [klooncommando’s](#local-project-example-4); [GitHub CLI legt klonen uit](https://cli.github.com/manual/gh_repo_clone).
**Begin in Documents**
1. Open op Mac Terminal en kopieer [Open Documents op een Mac](#local-project-example-2). Plak het commando en druk op Return.
2. Open op Windows PowerShell en kopieer [Open Documents op Windows](#local-project-example-3). Plak het commando en druk op Enter. Dit vraagt Windows naar je [Documents-map](https://learn.microsoft.com/en-us/dotnet/api/system.environment.getfolderpath), ook als die naar een andere locatie is verplaatst.
3. Kopieer daarna de [klooncommando’s](#local-project-example-4). Vervang YOUR\_USERNAME door je GitHub-gebruikersnaam en voer elke regel in volgorde uit.
4. Bestaat fieldnotes-studio daar al? Stop en vraag Codex om de map te bekijken. Verwijder of overschrijf geen bestaand project.
**Dit zou je nu moeten zien:** Je computer bevat fieldnotes-studio met README.md en de Git-geschiedenis van het project.
5. Voer in fieldnotes-studio de [commando’s voor auteur en branch](#local-project-example-5) uit. Vervang de voorbeeldnaam en het e-mailadres; controleer of git status codex/first-site toont.
**Maak je bouwbranch**
Voorbeeld ter illustratie: Illustratie: stel een projectauteur voor commits in en maak de branch codex/first-site.
- **Stel in:** Je commitnaam en e-mailadres
- **Voer uit:** git switch -c codex/first-site → git status
**Let op:** Git kent je commitauteur en meldt de branch codex/first-site.
Volg deze stappen als je meer uitleg wilt.
**Toon de stappen**
1. Gebruik binnen fieldnotes-studio de [commando’s voor de projectauteur](#local-project-example-5). Vervang de voorbeeldwaarden; kopieer voor je privacy je [GitHub noreply-adres voor commits](https://docs.github.com/en/account-and-profile/how-tos/email-preferences/setting-your-commit-email-address) uit Settings > Emails.
2. De twee git config-commando’s gelden voor dit project. Vervang hun voorbeeldnaam en e-mailadres voordat je ze uitvoert.
3. Voer git switch -c codex/first-site uit en daarna git status. Bestaat de branch al? Vraag Codex om die te bekijken voordat je een andere maakt.
4. De volgende actie koppelt Codex aan deze repository in plaats van de oefenmap.
**Dit zou je nu moeten zien:** Git kent je commitauteur en meldt de branch codex/first-site.
6. [Open fieldnotes-studio in Codex](https://learn.chatgpt.com/docs/projects?surface=app). Verstuur in de nieuwe chat de [verbindingscontrole](#local-project-prompts) voordat je bestanden aanpast.
**Controleer het project in Codex**
Voorbeeld ter illustratie: Illustratie: bekijk fieldnotes-studio in Codex en controleer de README en branch zonder wijzigingen.
- **Klikroute:** Codex → Lokaal project → fieldnotes-studio → New chat
- **Daarna:** Verbindingsprompt kopiëren → Versturen
**Let op:** Codex bevestigt de repository, remote, branch en versies zonder bestanden aan te passen.
Volg deze stappen als je meer uitleg wilt.
**Toon de stappen**
1. Voer de [commando’s om een branch te maken](#local-project-snippets) uit, maak codex/first-site en controleer git status. [Open fieldnotes-studio als lokaal Codex-project](https://learn.chatgpt.com/docs/projects), ter vervanging van website-workshop.
2. Vraag Codex om opslaan en herstellen uit te leggen. Bekijk wijzigingen met [git diff](https://git-scm.com/docs/git-diff); [een bestand herstellen](https://git-scm.com/docs/git-restore) gooit niet-opgeslagen wijzigingen weg, dus controleer die eerst.
3. Kies de gedownloade map fieldnotes-studio zelf, niet Documents of website-workshop. Kies Local als dat gevraagd wordt.
4. Verstuur Controleer de verbinding. Vergelijk het antwoord met README.md, de GitHub-repository en codex/first-site.
5. Een bestand herstellen kan wijzigingen weggooien die nog niet als commit zijn opgeslagen. Bekijk wat verloren zou gaan voordat je herstelcommando’s gebruikt.
**Dit zou je nu moeten zien:** Codex bevestigt de repository, remote, branch en versies zonder bestanden aan te passen.
De basis uitgelegd
**Terminal**
Een venster om computercommando’s te typen. Enter voert een commando uit; cd gevolgd door een mappad gaat naar die map. Lees elk resultaat voordat je verdergaat.
**Klonen (clone)**
Een werkkopie van een repository downloaden, inclusief de opgeslagen geschiedenis.
**Branch**
Een benoemde reeks wijzigingen waarmee je apart kunt werken voordat je die met de hoofdversie samenvoegt.
**LTS**
Long Term Support: een reeks versies die langer wordt onderhouden voor stabiliteit en herstel van fouten.
### Prompt: Controleer de verbinding
```text
Bekijk het project zonder wijzigingen. Controleer de repository, de GitHub-remote, de branch en de versies van de hulpmiddelen. Leg git diff, commits opslaan, naar GitHub pushen en één bestand veilig herstellen uit. Gooi nooit wijzigingen weg zonder te laten zien wat verloren zou gaan.
```
### Controleer de geïnstalleerde hulpmiddelen
```shell
git --version
node --version
npm --version
gh --version
```
### Open Documents op een Mac
```sh
cd "$HOME/Documents"
```
### Open Documents op Windows
```powershell
Set-Location ([Environment]::GetFolderPath("MyDocuments"))
```
### Kloon je repository
```shell
gh repo clone YOUR_USERNAME/fieldnotes-studio
cd fieldnotes-studio
```
### Stel de projectauteur in en maak een branch
```shell
git config user.name "Your Name"
git config user.email "YOUR_GITHUB_EMAIL"
git switch -c codex/first-site
git status
```
### Controleer je werk
- [ ] De versiecontroles geven nummers terug en Node voldoet aan de eisen van Astro.
- [ ] gh auth status noemt het bedoelde account zonder een token te tonen.
- [ ] Codex ziet README.md in fieldnotes-studio; git status meldt codex/first-site.
Als er iets misgaat
**Een commando wordt niet herkend.**
Open de terminal opnieuw. Volg de PATH-instructies van het hulpmiddel: PATH bevat de locaties waar je computer naar commando’s zoekt.
**Klonen lukt niet.**
Controleer de spelling van de gebruikersnaam en repository. Controleer of gh auth status een account toont dat de private repository kan openen.
### Officiële links & verder lezen
- [Installeer Git](https://git-scm.com/install/)
- [Download Node LTS](https://nodejs.org/en/download)
- [Installeer GitHub CLI](https://cli.github.com/)
- [Git: afzonderlijke bestanden herstellen](https://git-scm.com/docs/git-restore)
## 4. Kies je toegang tot OpenAI
Fase: Voorbereiden
Blijf aanmelden met ChatGPT of bekijk de optionele API-route en de aparte kosten daarvan.
Aanmelden met ChatGPT gebruikt de toegang van je abonnement. API-sleutels gebruiken apart gefactureerd OpenAI Platform-gebruik; een betaald ChatGPT-abonnement betaalt je API-rekening niet.
Deze statische website heeft geen OpenAI-sleutel nodig. Acties 3–5 zijn optioneel; sla ze over als je met ChatGPT blijft aanmelden.
### Doe dit
1. Open het profielmenu van Codex. Controleer je account en [aanmeldmethode](https://learn.chatgpt.com/docs/auth); houd ChatGPT aan als dat al werkt.
**Controleer je account**
Voorbeeld ter illustratie: Illustratie: controleer je Codex-account en ChatGPT-aanmeldmethode.
- **Klikroute:** Codex → Profielmenu → Account / aanmeldstatus
**Let op:** Je weet welk account en welke aanmeldroute Codex gebruikt.
ChatGPT-abonnementen en OpenAI API-facturering staan los van elkaar. Een ChatGPT-abonnement bevat geen API-tegoed. Lokale Codex-taken ondersteunen beide routes; API-gebruik wordt aan je Platform-account gefactureerd. Codex in de cloud vereist ChatGPT-aanmelding en sommige functies verschillen. De uiteindelijke statische website heeft geen OpenAI-sleutel nodig. AI helpt je bouwen; bezoekers krijgen gewone pagina’s. Een toekomstige chatbot heeft een eigen beveiligde backend en gebruiksbudget nodig.
**Toon de stappen**
1. Controleer in Codex’ profielmenu het bedoelde account en de [aanmeldroute](https://learn.chatgpt.com/docs/auth). Ga verder met ChatGPT-aanmelding als taken al werken.
2. Controleer of het bedoelde persoonlijke of zakelijke account actief is.
3. Werken ChatGPT-taken al? Houd die route. Sla de optionele acties 3–5 over en ga verder met actie 6.
4. Lokaal ondersteunt Codex beide methoden; de cloud vereist ChatGPT-aanmelding en beschikbare functies kunnen verschillen.
**Dit zou je nu moeten zien:** Je weet welk account en welke aanmeldroute Codex gebruikt.
2. Lees [hoe facturering werkt](https://learn.chatgpt.com/docs/auth). ChatGPT-aanmelding en API-gebruik hebben aparte rekeningen; kies welke route je wilt.
**Begrijp de twee rekeningen**
Voorbeeld ter illustratie: Illustratie: toegang via het ChatGPT-abonnement en optioneel API-gebruik worden apart gefactureerd.
- **Kies:** ChatGPT-aanmelding: toegang via abonnement / API-sleutel: aparte gebruiksrekening
**Let op:** Je weet welk account je gekozen route betaalt.
Volg deze stappen als je meer uitleg wilt.
**Toon de stappen**
1. Lees [hoe aanmelden de facturering bepaalt](https://learn.chatgpt.com/docs/auth) en bekijk de huidige gebruiksinstellingen van je account. Kies je eigen bestedingsgrens vóór langere taken en controleer de actuele abonnementsgegevens in je account.
2. Koop geen API-tegoed alleen omdat je een statische website bouwt.
3. API-aanmelding gebruikt de gewone Platform API-tarieven in plaats van inbegrepen gebruik van je ChatGPT-abonnement.
4. Een toekomstige chatbot voor bezoekers heeft een beveiligde backend en een eigen gebruiksbudget nodig.
**Dit zou je nu moeten zien:** Je weet welk account je gekozen route betaalt.
3. Optionele API-route: open [OpenAI Platform Billing](https://platform.openai.com/settings/organization/billing/overview). Lees de voorwaarden voordat je betaling of tegoed toevoegt.
**Optioneel: stel API-betaling in**
Voorbeeld ter illustratie: Illustratie: bekijk de optionele Platform API-facturering voordat je kosten accepteert.
- **Optionele klikroute:** OpenAI Platform → Billing → Accountkosten bekijken
**Let op:** Als je API-aanmelding kiest, is Platform-facturering klaar en begrijp je de kosten.
Volg deze stappen als je meer uitleg wilt.
**Toon de stappen**
1. Optionele API-route: meld je aan bij [OpenAI Platform Billing](https://platform.openai.com/settings/organization/billing/overview) en voeg betaling of tegoed toe als je account dat vereist.
2. Sla deze actie over als je met ChatGPT blijft aanmelden.
3. Lees de eisen die worden getoond voor het Platform-account dat je wilt laten betalen.
4. Voeg alleen betaling of tegoed toe als je die kosten accepteert. Houd betaalgegevens buiten chat en projectbestanden.
**Dit zou je nu moeten zien:** Als je API-aanmelding kiest, is Platform-facturering klaar en begrijp je de kosten.
4. Optionele API-route: maak een sleutel voor je oefenproject in [API keys](https://platform.openai.com/api-keys). Voeg een vervaldatum toe en bewaar hem privé.
**Optioneel: maak een geheime sleutel**
Voorbeeld ter illustratie: Illustratie: maak een optionele API-sleutel met vervaldatum en sla hem privé op.
- **Optionele klikroute:** Oefenproject → API keys → Create key → Wachtwoordmanager
**Let op:** Een eventuele API-sleutel is privé opgeslagen en hoort bij je bedoelde Platform-project.
Volg deze stappen als je meer uitleg wilt.
**Toon de stappen**
1. Maak of kies een oefenproject in het Platform-dashboard. Maak bij [API keys](https://platform.openai.com/api-keys) een geheime sleutel met een herkenbare naam en vervaldatum en sla hem op in een wachtwoordmanager.
2. Maak of kies een oefenproject in het Platform-account dat je wilt laten betalen.
3. Sla het geheim direct op in je wachtwoordmanager terwijl het dashboard het toont.
4. Zet hem nooit in fieldnotes-studio, screenshots of de Codex-chat. Hij meldt Codex aan; de statische pagina’s hebben hem niet nodig.
**Dit zou je nu moeten zien:** Een eventuele API-sleutel is privé opgeslagen en hoort bij je bedoelde Platform-project.
5. Optionele API-route: stel een [harde bestedingslimiet](https://developers.openai.com/api/docs/guides/spend-limits) in en [meld je aan met de sleutel](https://learn.chatgpt.com/docs/auth). Voeg een vroege waarschuwing toe.
**Optioneel: begrens kosten en meld je aan**
Voorbeeld ter illustratie: Illustratie: stel een optionele harde API-limiet in voordat je de geheime sleutel in het aanmeldveld van de app gebruikt.
- **Stel eerst in:** Project settings → Limits → Spend → Edit spend limit → Enforce a hard limit → Save
- **Daarna:** Afgemelde app → Sign in another way → Sleutelveld → Continue
**Let op:** API-aanmelding werkt met een opgeslagen harde projectlimiet en vroege waarschuwingen.
Volg deze stappen als je meer uitleg wilt.
**Toon de stappen**
1. Volg de [instructies voor een harde projectlimiet](https://developers.openai.com/api/docs/guides/spend-limits): Project settings > Limits > Spend > Edit spend limit. Kies je maandbedrag, zet Enforce a hard limit aan en sla op.
2. Gebruik voor API-aanmelding de [officiële instructies voor de desktopapp](https://learn.chatgpt.com/docs/auth). Meld je zo nodig af, kies Sign in another way, voer de sleutel in het aanmeldveld in en ga verder.
3. Sla deze actie over bij ChatGPT-aanmelding. Stel kostenbeperkingen in voordat je API-taken uitvoert.
4. Waarschuwingen stoppen geen verzoeken. Een harde limiet stopt het betreffende verkeer zodra het geregistreerde verbruik die grens bereikt; de verwerking kan iets achterlopen.
5. Plak de sleutel op het afgemelde scherm van de app alleen in het aanmeldveld, nooit in het chatberichtvak.
6. Voeg bestedingswaarschuwingen onder je geaccepteerde grens toe om eerder een melding te krijgen.
**Dit zou je nu moeten zien:** API-aanmelding werkt met een opgeslagen harde projectlimiet en vroege waarschuwingen.
6. Verstuur in Codex de [prompt voor kostencontrole](#openai-access-prompts). Probeer een kleine taak en bekijk het gebruik van je gekozen account.
**Controleer toegang en gebruik**
Voorbeeld ter illustratie: Illustratie: probeer een kleine Codex-taak en zoek de gebruiksinformatie van het gekozen account.
- **In Codex:** Kostenprompt kopiëren → Versturen → Kleine taak
- **Daarna:** Je gekozen account → Gebruiksinformatie
**Let op:** Een kleine taak werkt en je kunt de gebruiksinformatie vinden van het account dat ervoor betaalt.
Volg deze stappen als je meer uitleg wilt.
**Toon de stappen**
1. Voeg [bestedingswaarschuwingen toe](https://developers.openai.com/api/docs/guides/spend-limits), voer een kleine taak uit en bekijk het gebruik. Waarschuwingen stoppen geen verzoeken; harde limieten wel, maar de verwerking kan iets achterlopen.
2. Verstuur Controleer wie betaalt in je projectchat. Die prompt legt beide routes uit zonder je sleutel te vragen.
3. Probeer een heel kleine taak zonder wijzigingen, zoals Codex vragen om README.md te herkennen.
4. Bekijk bij ChatGPT-aanmelding de gebruiksinformatie van je abonnement, of bij API-aanmelding het Platform-gebruik. Controleer zelf het echte accountdashboard.
**Dit zou je nu moeten zien:** Een kleine taak werkt en je kunt de gebruiksinformatie vinden van het account dat ervoor betaalt.
De basis uitgelegd
**API**
Een verbinding waarmee een programma diensten van een ander programma vraagt, bijvoorbeeld een antwoord van een OpenAI-model.
**API-sleutel**
Een geheim toegangsbewijs dat softwareverzoeken toestaat en kosten op je account kan veroorzaken.
**Betalen naar gebruik**
Kosten op basis van hoeveel een dienst verbruikt, in plaats van één vast abonnementsbedrag.
**Authenticatie**
Het controleren welk account of toegangsbewijs toegang vraagt.
### Prompt: Controleer wie betaalt
```text
Leg het verschil uit tussen aanmelden met ChatGPT en API-facturering voor Codex. Ik bouw een statische website zonder AI-functie voor bezoekers. Leg uit welke toegang nodig is, waar ik het gebruik kan bekijken en welke kosteninstellingen ik moet controleren. Vraag nooit om mijn sleutel.
```
### Controleer je werk
- [ ] Je weet welke aanmeldroute je gebruikt en welk account het gebruik betaalt.
- [ ] Een kleine taak werkt en je kunt de bijbehorende gebruiksinformatie vinden.
- [ ] Een eventuele API-sleutel is privé opgeslagen, buiten chat en projectbestanden.
Als er iets misgaat
**API-verzoeken werken niet, ondanks een betaald ChatGPT-abonnement.**
Controleer Platform-facturering en projecttoegang apart. Toegang via een ChatGPT-abonnement betaalt geen API-verzoeken.
**Een functie ontbreekt bij API-aanmelding.**
Lees de officiële aanmeldhandleiding. Gebruik ChatGPT-aanmelding als de functie dat account of die werkruimte vereist.
### Officiële links & verder lezen
- [Officiële uitleg over aanmelden en aparte API-facturering](https://learn.chatgpt.com/docs/auth)
- [OpenAI Platform-dashboard voor API-sleutels](https://platform.openai.com/api-keys)
- [OpenAI Platform-dashboard voor facturering](https://platform.openai.com/settings/organization/billing/overview)
- [Stel API-waarschuwingen en harde bestedingslimieten in](https://developers.openai.com/api/docs/guides/spend-limits)
## 5. Houd privégegevens veilig
Fase: Voorbereiden
Bescherm wachtwoorden en sleutels en controleer wat in je projectgeschiedenis terechtkomt.
Bezoekers kunnen browsercode bekijken. Wachtwoorden en sleutels horen in beveiligde opslag, nooit in code die naar hun browser gaat.
Git bewaart oude versies. Lekt een sleutel uit? Trek die eerst in; het bestand van vandaag verwijderen maakt de sleutel niet veilig.
### Doe dit
1. Bewaar sleutels en herstelcodes in een [wachtwoordmanager of beveiligde opslag](https://developers.openai.com/api/docs/guides/production-best-practices), buiten chat en fieldnotes-studio.
**Bewaar geheimen buiten het project**
Voorbeeld ter illustratie: Illustratie: bewaar toegangsgegevens privé in plaats van in een websitemap of chat.
- **Bewaar:** Wachtwoorden, sleutels en herstelcodes → Beveiligde opslag
**Let op:** Geheime toegangsgegevens blijven buiten chat en het websiteproject.
Git onthoudt oude commits: een sleutel uit het huidige bestand verwijderen laat de geschiedenis staan. Trek gelekte toegangsgegevens bij hun aanbieder in voordat je de repositorygeschiedenis aanpakt. Private repositories zijn geen wachtwoordmanagers. Omgevingsvariabelen geven instellingen aan hulpmiddelen. Een .env-bestand kan lokale instellingen bevatten, maar is niet nodig voor aanmelding in de desktopapp. Bezoekers kunnen browsercode lezen; Astro PUBLIC\_-variabelen mogen alleen openbare informatie bevatten.
**Toon de stappen**
1. Gebruik een wachtwoordmanager voor herstelcodes en sleutels en volg de [uitleg over bescherming van toegangsgegevens](https://developers.openai.com/api/docs/guides/production-best-practices). Gebruik de aanmeldschermen van apps in plaats van documenten met toegangsgegevens in fieldnotes-studio te maken.
2. Gebruik het aanmeldscherm van de app in plaats van een wachtwoordendocument in je project te maken.
3. Een private GitHub-repository is geen wachtwoordmanager. Houd geheimen buiten screenshots, logboeken, prompts en bronbestanden.
4. Deze statische website heeft geen OpenAI-sleutel nodig.
**Dit zou je nu moeten zien:** Geheime toegangsgegevens blijven buiten chat en het websiteproject.
2. Verstuur de [prompt voor geheime gegevens](#secrets-prompts). Vraag Codex de [.gitignore-basisregels](#secrets-example-1) samen te voegen zonder bestaande regels te verwijderen.
**Negeer lokale privébestanden**
Voorbeeld ter illustratie: Illustratie: voeg .gitignore-regels samen om lokale instellingen en gegenereerde bestanden uit nieuwe commits te houden.
- **In Codex:** Prompt voor geheime gegevens kopiëren → Versturen
- **Controleer:** .gitignore → Bestaande regels behouden
**Let op:** De samengevoegde .gitignore sluit lokale geheime bestanden en gegenereerde mappen uit.
Volg deze stappen als je meer uitleg wilt.
**Toon de stappen**
1. Vraag Codex de [.gitignore-basisregels](#secrets-example-1) met bestaande regels samen te voegen. Lees [GitHubs uitleg over genegeerde bestanden](https://docs.github.com/en/get-started/git-basics/ignoring-files) en behoud bestaande uitsluitingen.
2. Open de samengevoegde .gitignore en vergelijk die met de basisregels.
3. De regels sluiten node\_modules, dist, .astro, .env en .env.\* uit en staan een onschuldige .env.example toe.
4. Een uitsluitingsregel werkt voor bestanden die Git nog niet volgt; hij verwijdert geen bestaande commits en wist geen geschiedenis.
**Dit zou je nu moeten zien:** De samengevoegde .gitignore sluit lokale geheime bestanden en gegenereerde mappen uit.
3. Deze statische site [heeft geen .env-bestand nodig](https://docs.astro.build/en/guides/environment-variables/). Documenteer toekomstige instellingen alleen met onschuldige voorbeelden in .env.example.
**Gebruik onschuldige voorbeelden**
Voorbeeld ter illustratie: Illustratie: deze statische site heeft geen .env nodig; optionele voorbeelden bevatten alleen onschuldige instellingen.
- **Voor deze site:** Geen .env nodig
- **Als het later nuttig is:** .env.example → Alleen onschuldige instellingen
**Let op:** Het project bevat geen onnodig bestand met toegangsgegevens en geen echte geheimen in voorbeelden.
Volg deze stappen als je meer uitleg wilt.
**Toon de stappen**
1. Deze statische site heeft geen .env-bestand nodig. Gebruik voor toekomstige instellingen .env.example met onschuldige waarden; lees [Astro’s omgevingsvariabelen](https://docs.astro.build/en/guides/environment-variables/) zodat er geen echt geheim in staat.
2. Maak geen .env-bestand alleen omdat een handleiding het noemt.
3. Een optionele .env.example is documentatie. Gebruik duidelijk onschuldige voorbeeldinstellingen in plaats van echte geheimen te kopiëren.
4. Astro PUBLIC\_-instellingen kunnen de browser van de bezoeker bereiken en mogen alleen openbare informatie bevatten.
**Dit zou je nu moeten zien:** Het project bevat geen onnodig bestand met toegangsgegevens en geen echte geheimen in voorbeelden.
4. Voor een toekomstige backend: [controleer waar instellingen werken](https://docs.astro.build/en/guides/environment-variables/). Vraag Codex welke waarden bezoekers kunnen lezen voordat je een geheim toevoegt.
**Houd toekomstige sleutels op de server**
Voorbeeld ter illustratie: Illustratie: geheime sleutels blijven op de server, terwijl browsercode en PUBLIC\_-instellingen openbaar zijn.
- **Optionele toekomstige functie:** Vraag waar elke instelling werkt → Server of browser?
**Let op:** Je begrijpt waarom browsercode en PUBLIC\_-waarden geen sleutel kunnen verbergen.
Volg deze stappen als je meer uitleg wilt.
**Toon de stappen**
1. Gebruik voor een toekomstige backenddienst [lokale omgevingsinstellingen](https://docs.astro.build/en/guides/environment-variables/) en de geheime instellingen van je hosting. Vraag Codex waar elke waarde werkt en of bezoekers die kunnen lezen.
2. Dit bereidt een toekomstige functie voor; je voegt nu geen backend toe. Een werkende e-maillink heeft geen geheim nodig.
3. Vraag bij een latere dienst welke code op een server draait en welke code naar de browser gaat.
4. Gebruik beschermde hostinginstellingen voor servergegevens. Een vermomde tekenreeks of verborgen formulierveld in browsercode blijft leesbaar.
**Dit zou je nu moeten zien:** Je begrijpt waarom browsercode en PUBLIC\_-waarden geen sleutel kunnen verbergen.
5. Voer de [controles op uitsluitingen en wijzigingen](#secrets-example-2) uit. Laat Codex mogelijke geheimen melden met bestandsnaam en type, zonder hun waarden te tonen.
**Controleer vóór de commit**
Voorbeeld ter illustratie: Illustratie: controleer genegeerde bestanden en wijzigingen zonder waarden van mogelijke geheimen te tonen.
- **Voer uit:** git check-ignore .env → git status → git diff
- **In Codex:** Meld alleen bestandsnamen en typen geheimen
**Let op:** De uitsluitingscontrole geeft .env terug en de openstaande wijzigingen bevatten geen toegangsgegevens of herstelcodes.
Volg deze stappen als je meer uitleg wilt.
**Toon de stappen**
1. Controleer vóór een commit git status en [git diff](https://git-scm.com/docs/git-diff). Laat Codex mogelijke geheimen herkennen zonder hun waarden te tonen.
2. Voer git check-ignore .env uit binnen fieldnotes-studio; het moet .env teruggeven, ook zonder dat bestand te maken.
3. Bekijk git status en git diff. Zet ook nieuwe bestanden klaar en controleer die; gewone git diff toont geen inhoud van bestanden die Git nog niet volgt.
4. Vraag alleen naar locaties en typen van mogelijke geheimen. Los die op vóór de commit; deze controle biedt bewijs, geen veiligheidsgarantie.
**Dit zou je nu moeten zien:** De uitsluitingscontrole geeft .env terug en de openstaande wijzigingen bevatten geen toegangsgegevens of herstelcodes.
6. Lekt een sleutel uit? [Trek hem in bij de aanbieder](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/removing-sensitive-data-from-a-repository). Het bestand verwijderen haalt de sleutel niet uit de geschiedenis.
**Weet wat je na een lek doet**
Voorbeeld ter illustratie: Illustratie: trek gelekte toegangsgegevens in voordat je bestanden en opgeslagen geschiedenis aanpakt.
- **Als een sleutel lekt:** Instellingen van de aanbieder → Sleutel intrekken → Lek en geschiedenis controleren
**Let op:** Je weet dat je gelekte toegangsgegevens eerst intrekt voordat je bestanden en geschiedenis opruimt.
Volg deze stappen als je meer uitleg wilt.
**Toon de stappen**
1. Komt een toegangsbewijs in chat, Git, screenshots of op een openbare pagina terecht? Trek het direct in. Volg de [uitleg voor herstel na een datalek](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/removing-sensitive-data-from-a-repository); alleen de zichtbare gegevens verwijderen is onvoldoende.
2. Dit is uitleg voor herstel, geen verzoek om een werkende sleutel in te trekken. Sla dit over als er niets is gelekt.
3. Trek gelekte toegangsgegevens eerst in bij hun aanbieder. Vervang ze alleen als de dienst ze nog nodig heeft.
4. Pak daarna de repositorygeschiedenis en andere kopieën aan. .gitignore wist geen oude commits en stopt niet automatisch met het volgen van een bestaand bestand.
**Dit zou je nu moeten zien:** Je weet dat je gelekte toegangsgegevens eerst intrekt voordat je bestanden en geschiedenis opruimt.
De basis uitgelegd
**Geheim**
Een waarde die toegang geeft, zoals een wachtwoord, API-sleutel, privé-token of herstelcode.
**Omgevingsvariabele**
Een benoemde instelling die de omgeving aan een programma meegeeft. Die kan openbare instellingen of geheime toegangsgegevens bevatten.
**.gitignore**
Een bestand met lokale paden die Git niet moet volgen. Het verwijdert geen bestanden die al als commit zijn opgeslagen.
**Backend**
Code op een server of dienst, waar geheime toegangsgegevens en beschermde handelingen buiten de browser van de bezoeker kunnen blijven.
### Prompt: Stel grenzen voor geheime gegevens in
```text
Controleer of toegangsgegevens blootstaan zonder geheimen te tonen. Voeg passende Astro-regels en regels voor lokale geheimen samen in .gitignore en behoud bestaande regels. Deze statische site heeft geen API-sleutels nodig. Meld vermoedelijke toegangsgegevens alleen met bestandsnaam en type. Leg het verschil uit tussen nieuwe bestanden negeren en gevolgde bestanden niet meer volgen.
```
### Basisuitsluitingen om toe te voegen aan .gitignore
```text
node_modules/
dist/
.astro/
.env
.env.*
!.env.example
```
### Controleer of een lokaal omgevingsbestand wordt genegeerd
```shell
git check-ignore .env
git status
git diff
```
### Controleer je werk
- [ ] git check-ignore .env geeft .env terug, ook zonder dat je dat bestand maakt.
- [ ] De openstaande wijzigingen bevatten geen toegangsgegevens of herstelcodes.
- [ ] Je begrijpt waarom browsercode en PUBLIC\_-waarden geen sleutels kunnen verbergen.
Als er iets misgaat
**Een genegeerd geheim wordt nog steeds door Git gevolgd.**
Vraag Codex te controleren welke bestanden Git volgt en het lokale bestand te bewaren terwijl het volgen stopt. Trek gelekte toegangsgegevens eerst in; de geschiedenis blijft bestaan.
**Codex vraagt om een sleutel voor gewone pagina’s.**
Leg uit dat Codex al is aangemeld. Vraag welke echte websitedienst de sleutel nodig heeft voordat je er een toevoegt.
### Officiële links & verder lezen
- [OpenAI: API-toegangsgegevens beschermen](https://developers.openai.com/api/docs/guides/production-best-practices)
- [Astro: omgevingsvariabelen en openbare waarden](https://docs.astro.build/en/guides/environment-variables/)
- [GitHub: bestanden negeren](https://docs.github.com/en/get-started/git-basics/ignoring-files)
- [GitHub: gevoelige gegevens uit een repository verwijderen](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/removing-sensitive-data-from-a-repository)
## 6. Geef Codex je werkafspraken
Fase: Voorbereiden
Sla een kort instructiebestand op, zodat Codex weet hoe het aan je website moet werken.
AGENTS.md is een tekstbestand met instructies dat Codex leest wanneer het werk begint. Het legt verwachtingen en controles voor het project vast.
Instructies sturen de agent; ze maken geen tests en vervangen geen toegangsinstellingen. Jij controleert de resultaten en beslist wanneer je publiceert.
### Doe dit
1. Download [AGENTS.md](https://kookaburraadvies.nl/nl/gidsen/advanced-agentic-website-design/files/AGENTS.md). Bewaar het in fieldnotes-studio, naast README.md.
**Bewaar de basisregels**
Voorbeeld ter illustratie: Illustratie: sla AGENTS.md op naast README.md in de hoofdmap fieldnotes-studio.
- **Bewaar in:** fieldnotes-studio → AGENTS.md naast README.md
**Let op:** AGENTS.md staat naast README.md in de projectmap.
Codex leest AGENTS.md bij het begin van het werk. Leg daarin projectinformatie, verwachtingen voor beoordeling en controles vast. Houd de afspraken leesbaar en concreet. AGENTS.md geeft vaste verwachtingen; skills geven gerichte werkwijzen. Geen van beide vervangt toegangsinstellingen of bewijst dat alles klopt. Jij bekijkt de resultaten en beslist wanneer je publiceert.
**Toon de stappen**
1. Download het [AGENTS.md-basisbestand](https://kookaburraadvies.nl/nl/gidsen/advanced-agentic-website-design/files/AGENTS.md). Zet het naast README.md in fieldnotes-studio, niet in docs.
2. De projecthoofdmap is de bovenste map fieldnotes-studio.
3. Zet dit bestand niet in website-workshop of in een onderliggende docs-map.
4. Voegt je browser bij een dubbele download iets aan de naam toe? Houd één bestand met precies de naam AGENTS.md.
**Dit zou je nu moeten zien:** AGENTS.md staat naast README.md in de projectmap.
2. Open AGENTS.md als gewone tekst. Controleer de [exacte naam en locatie](https://learn.chatgpt.com/docs/agent-configuration/agents-md); de naam mag niet eindigen op .txt.
**Controleer de bestandsnaam**
Voorbeeld ter illustratie: Illustratie: gebruik precies de bestandsnaam AGENTS.md en voorkom een extra .txt-extensie.
- **Controleer:** AGENTS.md: hoofdletters, .md, geen extra .txt
**Let op:** Het instructiebestand is gewone tekst en heet precies AGENTS.md.
Volg deze stappen als je meer uitleg wilt.
**Toon de stappen**
1. Open het bestand als gewone tekst. Controleer de [officiële naam- en plaatsingsregels voor AGENTS.md](https://learn.chatgpt.com/docs/agent-configuration/agents-md): de bestandsnaam is AGENTS.md, met hoofdletters en zonder extra .txt.
2. Open het met een teksteditor of de bestandsviewer van Codex.
3. Controleer de hele bestandsnaam, inclusief de extensie. Sommige editors voegen ongemerkt .txt toe.
4. Andere algemene instructies of instructies in submappen kunnen ook gelden; vraag Codex later welke het heeft geladen.
**Dit zou je nu moeten zien:** Het instructiebestand is gewone tekst en heet precies AGENTS.md.
3. Lees de regels en pas ze aan je [websitebrief](#website-brief) aan: statische Astro-site, npm, kleine wijzigingen en beschermde geheimen.
**Pas de regels aan je site aan**
Voorbeeld ter illustratie: Illustratie: pas AGENTS.md aan je websitebrief en afgesproken werkwijze aan.
- **Lees en pas aan:** AGENTS.md → Jouw website-eisen
**Let op:** De regels beschrijven hoe jij wilt dat Codex aan deze website werkt.
Volg deze stappen als je meer uitleg wilt.
**Toon de stappen**
1. Lees alle afspraken en pas ze aan je [websitebrief](#website-brief) aan: statische Astro-site, npm, kleine wijzigingen, beschermde geheimen en begrijpelijke code.
2. De starter bevat algemene afspraken, geen bedrijfsgegevens. Voeg korte informatie over Fieldnotes Studio en de vier pagina’s toe.
3. Houd regels die je begrijpt en pas formuleringen aan die niet bij je project passen.
4. Vergelijk dit bestand na hoofdstuk 8 met je volledige brief en werk afwijkende beslissingen bij.
**Dit zou je nu moeten zien:** De regels beschrijven hoe jij wilt dat Codex aan deze website werkt.
4. Vraag Codex te controleren [welke projectcommando’s bestaan](https://docs.npmjs.com/cli/v11/using-npm/scripts/). Vóór de installatie bestaan websitetests en package.json mogelijk nog niet.
**Gebruik echte controlecommando’s**
Voorbeeld ter illustratie: Illustratie: maak onderscheid tussen beschikbare package.json-scripts en controles die nog moeten worden gemaakt.
- **Vraag Codex:** Zoek package.json → Noem bestaande scripts → Noem ontbrekende controles
**Let op:** Je kunt bestaande controles onderscheiden van controles die nog moeten worden ingesteld.
Volg deze stappen als je meer uitleg wilt.
**Toon de stappen**
1. Vóór de projectinstallatie bestaan websitecontroles niet. Gebruik daarna [scripts die echt in package.json staan](https://docs.npmjs.com/cli/v11/using-npm/scripts/); een testinstructie maakt geen tests.
2. Het is normaal dat deze nieuwe repository vóór het Astro-hoofdstuk geen package.json bevat.
3. Vraag Codex om bestaande scripts voor bouwen, typecontrole en tests te bekijken als het bestand bestaat.
4. Noteer ontbrekende controles als nog uit te voeren werk. Accepteer nooit een geslaagde controle voor een niet-bestaand commando; werk de regels bij zodra echte scripts zijn gemaakt.
**Dit zou je nu moeten zien:** Je kunt bestaande controles onderscheiden van controles die nog moeten worden ingesteld.
5. Behoud de [basisregels voor controle en publicatie](https://kookaburraadvies.nl/nl/gidsen/advanced-agentic-website-design/files/AGENTS.md): toon een lokale preview, leg resultaten uit en vraag toestemming voor publiceren of nieuwe kosten.
**Behoud beoordelings- en kostenregels**
Voorbeeld ter illustratie: Illustratie: beoordeel een lokale preview en vraag toestemming vóór publicatie of nieuwe kosten.
- **Regels:** Lokale preview → Jouw beoordeling → Toestemming voor publicatie
**Let op:** Je afspraken behandelen beoordeling, toegangsgegevens, kosten en publicatie.
Volg deze stappen als je meer uitleg wilt.
**Toon de stappen**
1. Behoud de [werkafspraken uit de starterkit](https://kookaburraadvies.nl/nl/gidsen/advanced-agentic-website-design/files/AGENTS.md): een beoordeelbare preview en jouw toestemming vóór publicatie of nieuwe kosten.
2. Behoud de eis om een werkende preview te tonen, veranderd gedrag uit te leggen en controlebewijs en beperkingen te melden.
3. Publiceren, echte berichten versturen of productiegegevens wijzigen vereist toestemming voor die handeling.
4. Voeg je bestedingsvoorkeur voor nieuwe diensten toe. Stem de tekst af op al gegeven toestemming; deze regels vervangen geen toegangsinstellingen.
**Dit zou je nu moeten zien:** Je afspraken behandelen beoordeling, toegangsgegevens, kosten en publicatie.
6. Verstuur in een nieuwe Codex-chat de [prompt voor werkafspraken](#working-agreements-prompts). Controleer en bewaar AGENTS.md met de [commitcommando’s](#working-agreements-snippets).
**Bevestig en bewaar je regels**
Voorbeeld ter illustratie: Illustratie: bevestig de werkafspraken in een nieuwe chat, zet ze klaar, controleer en sla ze als commit op.
- **In Codex:** New chat → Afsprakenprompt kopiëren → Versturen
- **Bewaar:** git add → Klaargezette wijzigingen controleren → Commit van AGENTS.md
**Let op:** Codex vat de echte afspraken samen en Git bewaart het gecontroleerde instructiebestand.
Volg deze stappen als je meer uitleg wilt.
**Toon de stappen**
1. Begin een nieuwe projectchat en gebruik de [bevestigingsprompt voor werkafspraken](#working-agreements-prompts). Vergelijk het antwoord met AGENTS.md en zet het bestand klaar, controleer en maak een commit met de [bijbehorende commando’s](#working-agreements-snippets).
2. Vergelijk het antwoord in de nieuwe chat met de echte regels, inclusief bestaande en ontbrekende controles.
3. Voer voor een nieuw bestand eerst git add AGENTS.md uit en daarna git diff --cached -- AGENTS.md; gewone git diff toont geen inhoud van bestanden die Git nog niet volgt.
4. Lees de klaargezette wijzigingen vóór de commit. Deze regels opslaan is geen opdracht om te gaan bouwen.
**Dit zou je nu moeten zien:** Codex vat de echte afspraken samen en Git bewaart het gecontroleerde instructiebestand.
De basis uitgelegd
**AGENTS.md**
Een Markdown-bestand met blijvende instructies en projectinformatie voor de programmeeragent.
**Projecthoofdmap**
De bovenste map van het project; hier is dat fieldnotes-studio, met README.md en de Git-geschiedenis.
**Markdown**
Een tekstformaat met eenvoudige tekens voor koppen en lijsten. Een .md-bestand kun je zonder speciale software lezen.
### Prompt: Controleer de werkafspraken
```text
Noem de geladen instructiebestanden en vat AGENTS.md samen, inclusief geheimen, kleine wijzigingen, controles, kosten en publicatie. Maak onderscheid tussen bestaande scripts en controles die nog moeten worden ingesteld. Begin nog niet met bouwen.
```
### Zet het instructiebestand klaar, controleer en sla op
```shell
git add AGENTS.md
git diff --cached -- AGENTS.md
git commit -m "Add website working agreements"
```
### Controleer je werk
- [ ] AGENTS.md staat naast README.md.
- [ ] Een nieuwe projectchat herkent de afspraken en vat ze correct samen.
- [ ] Bestaande en toekomstige controles zijn onderscheiden en Git bewaart de gecontroleerde instructies.
Als er iets misgaat
**Codex ziet je nieuwe instructies niet.**
Controleer map en bestandsnaam en begin een nieuwe chat. Vraag welke instructies zijn geladen; algemene of instructies in submappen kunnen ook gelden.
**Een instructie vraagt om een niet-bestaand commando.**
Gebruik het echte script uit package.json of noteer dat de controle tijdens het opzetten moet worden gemaakt. Houd fouten zichtbaar.
### Officiële links & verder lezen
- [Officiële uitleg over AGENTS.md en werkinstructies](https://learn.chatgpt.com/docs/agent-configuration/agents-md)
- [GitHub: eenvoudig schrijven met Markdown](https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax)
## 7. Voeg vier handige skills toe
Fase: Voorbereiden
Geef Codex vier duidelijke werkwijzen voor ontwerp, leesbare code, testen en beveiliging.
Een skill is een herbruikbare werkwijze in een SKILL.md-bestand. Projectskills staan in .agents/skills, zodat Codex ze kan vinden.
Deze vier werkwijzen helpen bij ontwerp, nette code, testen en beveiligingscontrole. Ze kunnen niet garanderen dat een website veilig of foutloos is.
### Doe dit
1. Download en lees de vier skills: [ontwerp](https://kookaburraadvies.nl/nl/gidsen/advanced-agentic-website-design/files/website-design-SKILL.md), [nette code](https://kookaburraadvies.nl/nl/gidsen/advanced-agentic-website-design/files/clean-code-SKILL.md), [testen](https://kookaburraadvies.nl/nl/gidsen/advanced-agentic-website-design/files/website-testing-SKILL.md) en [beveiliging](https://kookaburraadvies.nl/nl/gidsen/advanced-agentic-website-design/files/website-security-SKILL.md).
**Download de vier skills**
Voorbeeld ter illustratie: Illustratie: download en lees de vier basisskills voor ontwerp, code, testen en beveiliging.
- **Download:** website-design · clean-code · website-testing · website-security
**Let op:** Je hebt alle vier de basisbestanden gelezen voordat je ze gebruikt.
Een skillmap bevat SKILL.md met een naam, beschrijving en instructies. Codex vindt projectskills onder .agents/skills en leest de volledige uitleg wanneer het ze gebruikt. website-design behandelt de visuele richting; clean-code begrijpelijke bouw; website-testing bezoekersroutes; website-security beveiligingsgrenzen. Deze workshopinstructies garanderen geen veilige of foutloze site.
**Toon de stappen**
1. Download de vier basisskills: [website-design](https://kookaburraadvies.nl/nl/gidsen/advanced-agentic-website-design/files/website-design-SKILL.md), [clean-code](https://kookaburraadvies.nl/nl/gidsen/advanced-agentic-website-design/files/clean-code-SKILL.md), [website-testing](https://kookaburraadvies.nl/nl/gidsen/advanced-agentic-website-design/files/website-testing-SKILL.md) en [website-security](https://kookaburraadvies.nl/nl/gidsen/advanced-agentic-website-design/files/website-security-SKILL.md). Lees ze vóór gebruik; controleer scripts waarnaar skills van derden verwijzen.
2. Elke skill is een gerichte set instructies. Lees wat je Codex vraagt te volgen.
3. Bevat een skill van iemand anders scripts? Bekijk die voordat je ze uitvoert.
4. De langere downloadnamen houden de bestanden uit elkaar; de uiteindelijke naam binnen elke map is SKILL.md.
**Dit zou je nu moeten zien:** Je hebt alle vier de basisbestanden gelezen voordat je ze gebruikt.
2. Vraag Codex de [skillmappen](#design-quality-skills-snippets) voor te bereiden. Verplaats elke download naar de juiste map en hernoem het bestand naar SKILL.md.
**Zet elk bestand in zijn map**
Voorbeeld ter illustratie: Illustratie: elke skill heeft een eigen map en een apart bestand met de naam SKILL.md.
- **Mappad:** fieldnotes-studio → .agents → skills → Eén map per skill
- **Elk bestand:** Bijbehorende skillmap → SKILL.md
**Let op:** Alle vier de skills staan op de exacte paden uit de mapstructuur.
Volg deze stappen als je meer uitleg wilt.
**Toon de stappen**
1. Volg de [instructies voor projectskills](https://learn.chatgpt.com/docs/build-skills): maak in fieldnotes-studio .agents/skills en daarbinnen de mappen website-design, clean-code, website-testing en website-security.
2. Gebruik de [vereiste mapstructuur](#design-quality-skills-snippets). Verplaats elke download naar de juiste map en hernoem hem naar SKILL.md, zodat elke map een eigen SKILL.md bevat.
3. Vraag Codex alleen de vier mappen uit Vereiste skillstructuur te maken, zonder de website te bouwen.
4. Verplaats website-design-SKILL.md naar .agents/skills/website-design en hernoem het naar SKILL.md. Herhaal dat in de juiste mappen voor de andere drie.
5. Is .agents verborgen? Gebruik Finder Command + Shift + punt of Windows View → Show → Hidden items. Laat Codex de exacte eindpaden vergelijken.
**Dit zou je nu moeten zien:** Alle vier de skills staan op de exacte paden uit de mapstructuur.
3. Controleer of elk SKILL.md begint met [name en description](https://agentskills.io/specification). Houd de naam gelijk aan de mapnaam en sla op als gewone tekst.
**Controleer het label van elke skill**
Voorbeeld ter illustratie: Illustratie: controleer de naam en beschrijving van elke skill en vergelijk de naam met de map.
- **Controleer:** SKILL.md → name + description → Naam past bij de map
**Let op:** Elke skill heeft geldige name- en description-metadata en is opgeslagen als gewone tekst.
Volg deze stappen als je meer uitleg wilt.
**Toon de stappen**
1. Controleer de [specificatie van skillmetadata](https://agentskills.io/specification). Behoud name en description bovenaan, laat elke naam bij de map passen en sla op als gewone tekst.
2. Bovenaan staat een metadatablok met name en description tussen twee regels met ---.
3. Laat de vier namen overeenkomen met hun mappen: website-design, clean-code, website-testing, website-security.
4. Behoud de basismetadata tenzij je een duidelijke reden hebt om die te veranderen; vermijd lange of tegenstrijdige instructies.
**Dit zou je nu moeten zien:** Elke skill heeft geldige name- en description-metadata en is opgeslagen als gewone tekst.
4. Begin een nieuwe projectchat en verstuur de [controleprompt voor vier skills](#design-quality-skills-prompts). Laat Codex elk bestand lezen en ontbrekende bestanden melden.
**Controleer of Codex ze kan lezen**
Voorbeeld ter illustratie: Illustratie: laat een nieuwe Codex-chat alle vier de skillbestanden bekijken.
- **In Codex:** New chat → Vier-skills-prompt kopiëren → Versturen
**Let op:** Codex leest alle vier de bestanden en legt uit wanneer het elke werkwijze toepast.
Volg deze stappen als je meer uitleg wilt.
**Toon de stappen**
1. Gebruik de [prompt om skills te vinden](#design-quality-skills-prompts) in een nieuwe projectchat. Codex herkent wijzigingen automatisch; herstart als de bestanden niet verschijnen.
2. Vergelijk de gemelde paden met de echte bestanden. Vraag naar ongeldige of ontbrekende bestanden in plaats van aan te nemen dat alles klopt.
3. Codex herkent skillwijzigingen automatisch; herstart als de bestanden niet verschijnen.
4. Controleer of fieldnotes-studio de hoofdmap van het project is. De skills vinden bewijst niet dat elke werkwijze is toegepast.
**Dit zou je nu moeten zien:** Codex leest alle vier de bestanden en legt uit wanneer het elke werkwijze toepast.
5. Verstuur de [prompt voor de ontwerpskill](#design-quality-skills-prompt-2). Noem website-design rechtstreeks en vraag vóór de bouw om een plan.
**Probeer de ontwerpskill**
Voorbeeld ter illustratie: Illustratie: roep website-design rechtstreeks aan en controleer het plan vóór de bouw.
- **In Codex:** Ontwerpskill-prompt kopiëren → website-design gebruiken → Plan beoordelen
**Let op:** Rechtstreeks aanroepen levert een ontwerpplan op dat je kunt beoordelen.
Volg deze stappen als je meer uitleg wilt.
**Toon de stappen**
1. Probeer de [prompt om de ontwerpskill rechtstreeks aan te roepen](#design-quality-skills-prompt-2). Noem de skill of het pad; de [officiële uitleg](https://learn.chatgpt.com/docs/build-skills) behandelt ook optionele CLI- en IDE-notatie.
2. De prompt geeft .agents/skills/website-design/SKILL.md als exact pad.
3. Laat Codex het bestand lezen en de resultaten en beoordelingscontroles van de werkwijze uitleggen.
4. Controleer het plan vóór de bouw. Je kunt de skill gewoon noemen zonder CLI- of IDE-keuzemenu’s te gebruiken.
**Dit zou je nu moeten zien:** Rechtstreeks aanroepen levert een ontwerpplan op dat je kunt beoordelen.
6. Controleer de vier bestanden en laat Codex de [skillmappen als commit opslaan](https://git-scm.com/docs/git-commit). Bewaar alleen de bedoelde wijzigingen.
**Bewaar de skills in Git**
Voorbeeld ter illustratie: Illustratie: controleer de vier bedoelde skillbestanden en sla ze in Git op als commit.
- **Bewaar:** .agents/skills controleren → Vier bestanden klaarzetten → Commit
**Let op:** Git bewaart de vier gecontroleerde skills, zodat medewerkers dezelfde instructies kunnen bekijken.
Volg deze stappen als je meer uitleg wilt.
**Toon de stappen**
1. Controleer alle vier de bestanden en [bewaar ze als Git-commit](https://git-scm.com/docs/git-commit), zodat toekomstige medewerkers dezelfde instructies kunnen bekijken.
2. Laat de vier uiteindelijke paden tonen en controleer ze vóór het opslaan.
3. Zet alleen de bedoelde SKILL.md-bestanden klaar en controleer daarna de klaargezette wijzigingen.
4. Gebruik bijvoorbeeld het bericht Add website workflow skills. Houd andere openstaande wijzigingen apart; een commit bewijst niet dat websitecontroles slagen.
**Dit zou je nu moeten zien:** Git bewaart de vier gecontroleerde skills, zodat medewerkers dezelfde instructies kunnen bekijken.
De basis uitgelegd
**Skill**
Een herbruikbare set instructies voor een bepaalde taak, eventueel met hulpmiddelen, die een agent helpt een specifieke werkwijze te volgen.
**Metadata**
Korte beschrijvende informatie bovenaan een skillbestand, zoals de naam en wanneer je de skill gebruikt.
**Expliciet aanroepen**
De agent rechtstreeks vragen een genoemde skill te gebruiken, in plaats van te wachten tot hij die zelf kiest.
**Verborgen map**
Een map die een bestandsvenster standaard kan verbergen. Namen die met een punt beginnen, zoals .agents, zijn op macOS en Linux vaak verborgen.
### Prompt: Controleer alle vier de skills
```text
Bekijk .agents/skills. Lees de vier SKILL.md-bestanden en bevestig hun namen en paden. Leg uit wanneer je elke werkwijze toepast. Meld ongeldige of ontbrekende bestanden. Bouw nog niets en installeer nog geen hulpmiddelen.
```
### Prompt: Roep de ontwerpskill aan
```text
Gebruik website-design in .agents/skills/website-design/SKILL.md. Lees het bestand en pas de planningswerkwijze toe op Fieldnotes Studio. Leg vóór de bouw uit welke concrete resultaten en beoordelingscontroles het oplevert.
```
### Vereiste skillstructuur
```text
fieldnotes-studio/
AGENTS.md
.agents/
skills/
website-design/SKILL.md
clean-code/SKILL.md
website-testing/SKILL.md
website-security/SKILL.md
```
### Controleer je werk
- [ ] Alle vier de bestanden staan op precies de getoonde paden.
- [ ] Codex leest elk bestand en legt de instructies uit.
- [ ] Rechtstreeks aanroepen levert de verwachte planningswerkwijze op en Git bewaart de bestanden.
Als er iets misgaat
**.agents is verborgen.**
Gebruik in macOS Finder Command + Shift + punt. Gebruik op Windows zo nodig View > Show > Hidden items.
**Codex negeert de skill nadat ik die noem.**
Geef het exacte pad. Vraag Codex het bestand te lezen, de relevante eisen te noemen en uit te leggen hoe het resultaat eraan voldoet.
### Officiële links & verder lezen
- [Officiële uitleg over skills vinden en aanroepen in Codex](https://learn.chatgpt.com/docs/build-skills)
- [Open Agent Skills-bestandsspecificatie](https://agentskills.io/specification)
## 8. Schrijf je websitebrief
Fase: Plannen
Vertel Codex voor wie je website is, wat die moet doen en wat in de eerste versie hoort.
Je hoeft niet elke regel code te beschrijven. Je moet wel uitleggen voor wie de website is, wat die bezoekers nodig hebben en welke stap je wilt dat ze zetten. ‘Maak het mooi’ laat de agent gokken; ‘help een ondernemer mijn diensten te begrijpen en contact op te nemen’ geeft een bruikbare richting.
Fieldnotes Studio is ons fictieve voorbeeld: een kleine ontwerpstudio die aanvragen wil ontvangen. De eerste versie heeft vier pagina’s en een echt contactadres. Accounts, betalingen, een boekingssysteem en een AI-chatbot zijn toekomstige functies met eigen eisen. Een kleine, complete website is makkelijker te controleren en te onderhouden.
### Doe dit
1. Gebruik het [briefvoorbeeld](#website-brief-snippets). Schrijf wie je helpt en wat je bedrijf biedt.
**Noem je bedrijf en doelgroep**
Voorbeeld ter illustratie: Kooka laat zien hoe je bedrijf en doelgroep benoemt: Bedrijf → Doelgroep → Wat je biedt.
- **Schrijf:** Bedrijf → Doelgroep → Wat je biedt
**Let op:** Eén zin die je bedrijf en de mensen die je helpt beschrijft.
Begin met het [voorbeeld van een websitebrief](#website-brief-snippets). Beschrijf in één zin je bedrijf, de primaire doelgroep en het probleem waarmee je site hen moet helpen.
**Stap voor stap**
1. Open een gewone tekstnotitie of laat Codex een notitie van jouw woorden maken.
2. Schrijf één zin over je bedrijf, de mensen die je helpt en het probleem dat je helpt oplossen.
3. Gebruik Fieldnotes Studio alleen als oefenvoorbeeld; vervang het voor een echte site door je eigen gegevens.
**Dit zou je nu moeten zien:** Eén zin die je bedrijf en de mensen die je helpt beschrijft.
2. Kies één [hoofdactie voor bezoekers](https://developer.mozilla.org/en-US/docs/Learn_web_development/Getting_started/Your_first_website/What_will_your_website_look_like), bijvoorbeeld jou mailen over een project.
**Kies de hoofdactie voor bezoekers**
Voorbeeld ter illustratie: Kooka laat de hoofdactie zien: Bezoekersvraag → Bruikbaar antwoord → Contact.
- **Kies:** Bezoekersvraag → Bruikbaar antwoord → Contact
**Let op:** Een duidelijke stap die bezoekers na het lezen kunnen zetten.
Gebruik de [planningsvragen voor je eerste website](https://developer.mozilla.org/en-US/docs/Learn_web_development/Getting_started/Your_first_website/What_will_your_website_look_like) om één hoofdactie te kiezen. Voor Fieldnotes Studio is dat mailen over een project; noteer wat bezoekers eerst moeten weten.
**Stap voor stap**
1. Stel je iemand voor die voor het eerst op je site komt.
2. Schrijf wat die moet weten vóór het eerste contact: wat je biedt, wie je helpt en hoe die een vraag stelt.
3. Kies voor deze oefensite een aanvraag per e-mail als hoofdactie.
**Dit zou je nu moeten zien:** Een duidelijke stap die bezoekers na het lezen kunnen zetten.
3. Zet Home, About, Services en Contact in het [briefsjabloon](#website-brief-snippets). Zet extra functies onder Later.
**Kies vier pagina’s**
Voorbeeld ter illustratie: Kooka laat de vier pagina’s zien: Home · About · Services · Contact → Latere ideeën.
- **Plan:** Home · About · Services · Contact → Latere ideeën
**Let op:** Vier paginanamen met elk één taak; extra functies bewaard voor later.
Gebruik het [briefsjabloon](#website-brief-snippets) voor Home, About, Services en Contact. Geef elke pagina één doel en zet extra ideeën onder Later.
**Stap voor stap**
1. Laat Home je aanbod introduceren, About de mensen erachter, Services de beschikbare hulp en Contact de manier om een aanvraag te doen.
2. Zet boekingen, betalingen, accounts en AI-chat onder Later.
3. Houd de eerste versie klein genoeg om elke pagina te lezen en te testen.
**Dit zou je nu moeten zien:** Vier paginanamen met elk één taak; extra functies bewaard voor later.
4. Voeg taal, inhoud, beelden, planning en je eigen budget toe aan het [briefsjabloon](#website-brief-snippets). Noem wie de site onderhoudt.
**Bepaal je grenzen**
Voorbeeld ter illustratie: Kooka laat projectgrenzen zien: Taal → Inhoud → Budget en planning → Eigenaar.
- **Schrijf:** Taal → Inhoud → Budget en planning → Eigenaar
**Let op:** Je eigen bestedingsgrens en een genoemde website-eigenaar.
Voeg taal, inhoud, beelden, bestedingsvoorkeur, planning en onderhoudseigenaar toe aan het [briefsjabloon](#website-brief-snippets). Kies je eigen budget in plaats van een bedrag van de agent te accepteren.
**Stap voor stap**
1. Voeg je gewenste taal toe en de teksten en toegestane beelden die je al hebt.
2. Bepaal je eigen budget en streefdatum; laat de agent geen bestedingsruimte verzinnen.
3. Noem wie de site bijwerkt en geef een echte inbox die je beheert en kunt testen.
**Dit zou je nu moeten zien:** Je eigen bestedingsgrens en een genoemde website-eigenaar.
5. Kopieer de [briefprompt](#website-brief-prompts), vervang de voorbeeldnotities en verstuur hem. Vraag Codex om docs/website-brief.md op te slaan.
**Laat Codex de brief schrijven**
Voorbeeld ter illustratie: Kooka laat de briefopdracht zien: Prompt kopiëren → Notities toevoegen → Versturen → docs/website-brief.md.
- **Codex:** Prompt kopiëren → Notities toevoegen → Versturen → docs/website-brief.md
**Let op:** Een brief met jouw notities, zichtbare aannames en gemarkeerde ontbrekende inhoud.
Kopieer de [projectbriefprompt](#website-brief-prompts), vervang de voorbeeldnotities en verstuur hem. Vraag vóór de bouw om docs/website-brief.md met aannames en ontbrekende inhoud.
**Stap voor stap**
1. Open de gekoppelde prompt en gebruik de knop om de prompt te kopiëren.
2. Vervang de laatste voorbeeldnotities door de notities uit de vorige acties.
3. Plak de prompt in de fieldnotes-studio-chat en verstuur hem. De taak maakt docs/website-brief.md; bouwen volgt later.
**Dit zou je nu moeten zien:** Een brief met jouw notities, zichtbare aannames en gemarkeerde ontbrekende inhoud.
6. Lees de brief, verbeter feiten en keur de afbakening goed. Vraag Codex een [Git-commit op te slaan](https://git-scm.com/docs/git-commit).
**Controleer en bewaar de brief**
Voorbeeld ter illustratie: Kooka laat de beoordeling zien: Brief openen → Feiten verbeteren → Afbakening goedkeuren → Commit.
- **Controleer:** Brief openen → Feiten verbeteren → Afbakening goedkeuren → Commit
**Let op:** Een opgeslagen brief waar je achter staat, zonder verzonnen claims of functies.
Lees de gemaakte brief, controleer feiten, beantwoord noodzakelijke vragen en verwijder ongewenste functies. [Bewaar de beoordeelde brief als commit](https://git-scm.com/docs/git-commit) om je planningsbesluiten vast te leggen.
**Stap voor stap**
1. Lees docs/website-brief.md helemaal.
2. Verbeter bedrijfsgegevens, beantwoord noodzakelijke vragen en verwijder verzonnen prijzen, kwalificaties, citaten of ongewenste functies.
3. Vraag Codex de wijzigingen te tonen en de beoordeelde brief als Git-commit op te slaan.
**Dit zou je nu moeten zien:** Een opgeslagen brief waar je achter staat, zonder verzonnen claims of functies.
De basis uitgelegd
**Brief**
Een korte schriftelijke afspraak over het doel, de doelgroep, de afbakening en de beperkingen van de website.
**Afbakening (scope)**
De pagina’s en functies die horen bij de versie die je bouwt.
**Oproep tot actie (call to action)**
Een duidelijke uitnodiging om iets te doen, zoals ‘Bespreek je project’ of ‘Mail de studio’.
**Aanname**
Iets wat de agent voor waar houdt zonder het te controleren. Maak aannames zichtbaar zodat je ze kunt beoordelen.
### Prompt: Maak je projectbrief
```text
Zet mijn notities om in docs/website-brief.md. Beschrijf doel, primaire doelgroep, bezoekersbehoeften, hoofdactie, doelen van de vier pagina’s, functies voor de eerste versie, latere functies, ontbrekende inhoud en beperkingen. Gebruik Fieldnotes Studio als oefenvoorbeeld tenzij ik mijn eigen bedrijf opgeef. Stel maximaal drie noodzakelijke vragen; markeer overige aannames. Verzin geen klantcitaten, kwalificaties, prijzen of bedrijfsclaims. Bouw de website nog niet. Mijn notities: [vervang deze zin door je notities].
```
### Een brief om aan te passen
```text
Project: Fieldnotes Studio, een fictieve ontwerpstudio
Doelgroep: Ondernemers die ontwerphulp overwegen
Doel: Bezoekers onze diensten laten begrijpen en ons laten mailen
Pagina’s: Home / About / Services / Contact
Eerste versie: Statische pagina’s, mobiel menu, echte e-maillink
Later: Boekingen, betalingen, accounts, AI-functies
Inhoud: Goedgekeurde teksten en beelden die we mogen gebruiken
Stijl: Rustig, helder, redactioneel, goed leesbaar
Budget en planning: Voeg je eigen grenzen toe
Contactadres: Geef een inbox die je beheert en kunt testen
```
### Controleer je werk
- [ ] De brief noemt één primaire doelgroep, één hoofdactie en de doelen van de vier pagina’s.
- [ ] Functies voor de eerste versie en latere ideeën staan apart; aannames zijn zichtbaar.
- [ ] Je kunt beoordelen of een voorgestelde pagina de brief volgt zonder de code te begrijpen.
Als er iets misgaat
**De brief groeit uit tot een ingewikkelde app.**
Ga terug naar de ene hoofdactie. Zet functies die de eerste vier pagina’s niet ondersteunen onder ‘Later’ en laat Codex de brief bijwerken.
**Je weet niet goed wat de doelgroep nodig heeft.**
Vraag iemand uit die doelgroep wat die wil weten voordat die contact opneemt. Voeg de antwoorden toe aan de brief in plaats van een bezoekersprofiel te verzinnen.
### Officiële links & verder lezen
- [MDN: plan je eerste website](https://developer.mozilla.org/en-US/docs/Learn_web_development/Getting_started/Your_first_website/What_will_your_website_look_like)
- [W3C: betrek gebruikers bij het plannen van een website](https://www.w3.org/WAI/planning/involving-users/)
## 9. Plan je pagina’s en inhoud
Fase: Plannen
Geef elke pagina een duidelijk doel. Verzamel de echte teksten, beelden en contactgegevens die Codex moet gebruiken.
Een bruikbare bezoekersroute verbindt een vraag met een antwoord en daarna met een actie. Een bezoeker van Fieldnotes Studio kan op Home beginnen, Services bekijken, About lezen voor achtergrond en Contact gebruiken. Elke pagina moet ook werken als iemand rechtstreeks via een gedeelde link binnenkomt.
Echte tekst verandert een ontwerp. Een korte voorbeeldkop past misschien wel, terwijl je echte dienstenbeschrijving niet past. Bereid inhoud vroeg voor en markeer duidelijk wat ontbreekt. AI kan formuleringen verbeteren, maar jij controleert bedrijfsfeiten en keurt goed wat onder jouw naam verschijnt.
### Doe dit
1. Verstuur de [prompt voor inhoudsplanning](#sitemap-content-prompts). Vraag Codex de vier pagina-adressen in docs/sitemap.md te bewaren.
**Maak een paginaoverzicht**
Voorbeeld ter illustratie: Kooka laat het paginaoverzicht zien: Prompt kopiëren → Versturen → docs/sitemap.md.
- **Codex:** Prompt kopiëren → Versturen → docs/sitemap.md
**Let op:** Home /, About /about/, Services /services/ en Contact /contact/.
Gebruik de [prompt voor inhoudsplanning](#sitemap-content-prompts) om docs/sitemap.md te maken met /, /about/, /services/ en /contact/. Vergelijk het met de [oefensitemap](#sitemap-content-snippets).
**Stap voor stap**
1. Kopieer de gekoppelde prompt naar je projectchat.
2. Laat Codex de brief lezen en docs/sitemap.md maken.
3. Vergelijk de adressen met de oefensitemap: /, /about/, /services/ en /contact/.
**Dit zou je nu moeten zien:** Home /, About /about/, Services /services/ en Contact /contact/.
2. Schrijf per pagina de bezoekersvraag, kop, onderdelen en volgende actie. Gebruik [duidelijke paginakoppen](https://www.w3.org/WAI/tips/designing/).
**Geef elke pagina één taak**
Voorbeeld ter illustratie: Kooka laat paginataakjes zien: Bezoekersvraag → Kop → Onderdelen → Volgende actie.
- **Plan:** Bezoekersvraag → Kop → Onderdelen → Volgende actie
**Let op:** Elke pagina beantwoordt een andere vraag en biedt een logische volgende actie.
Noteer per pagina de bezoekersvraag, kop, onderdelen en volgende actie. Volg de [uitleg over duidelijke koppen en paginastructuur](https://www.w3.org/WAI/tips/designing/) zodat Home het bedrijfsaanbod begrijpelijk maakt.
**Stap voor stap**
1. Noem per pagina de vraag waarop de bezoeker antwoord wil.
2. Schrijf de hoofdkop en tussenkoppen in gewone taal.
3. Kies de volgende nuttige actie, zoals Services bekijken of Contact openen.
**Dit zou je nu moeten zien:** Elke pagina beantwoordt een andere vraag en biedt een logische volgende actie.
3. Gebruik de [inhoudsprompt](#sitemap-content-prompts) om goedgekeurde tekst en je echte inbox in docs/content.md te bewaren. Markeer wat nog niet af is.
**Voeg je echte inhoud toe**
Voorbeeld ter illustratie: Kooka laat inhoud toevoegen zien: Goedgekeurde tekst → Echte inbox → docs/content.md → Ontbrekende inhoud markeren.
- **Codex:** Goedgekeurde tekst → Echte inbox → docs/content.md → Ontbrekende inhoud markeren
**Let op:** Je echte informatie, met ontbrekende passages duidelijk gemarkeerd.
Gebruik de [inhoudsprompt](#sitemap-content-prompts) om goedgekeurde beschrijving, diensten, biografie en echte inbox in docs/content.md te ordenen. Markeer onafgemaakte passages als schrijfwerk.
**Stap voor stap**
1. Verzamel je bedrijfsbeschrijving, diensten, biografie en echte contactadres.
2. Laat Codex ze met jouw feiten ordenen in docs/content.md.
3. Markeer onafgemaakte onderdelen als schrijfwerk in plaats van geloofwaardig klinkende verzinsels te accepteren.
**Dit zou je nu moeten zien:** Je echte informatie, met ontbrekende passages duidelijk gemarkeerd.
4. Verzamel beelden die je mag publiceren. Noteer bronnen en [bruikbare beeldbeschrijvingen](https://www.w3.org/WAI/tutorials/images/decision-tree/) in docs/content.md.
**Kies toegestane beelden**
Voorbeeld ter illustratie: Kooka laat beeldkeuze zien: Toegestaan beeld → Bron → Wat het overbrengt.
- **Verzamel:** Toegestaan beeld → Bron → Wat het overbrengt
**Let op:** Een bekende bron en bruikbare beschrijving voor elk betekenisvol beeld.
Verzamel toegestane beelden en noteer hun bron en doel in docs/content.md. Gebruik de [W3C-beslisboom voor beeldalternatieven](https://www.w3.org/WAI/tutorials/images/decision-tree/) om te beschrijven wat betekenisvolle beelden overbrengen.
**Stap voor stap**
1. Controleer of je eigenaar bent van elk beeld of toestemming hebt om het te gebruiken.
2. Noteer de bron, gebruikstoestemming en waarom het beeld op die pagina hoort.
3. Gebruik de gekoppelde beslisboom voor betekenisvolle alternatieve tekst; puur decoratieve beelden hebben meestal lege alt-tekst.
**Dit zou je nu moeten zien:** Een bekende bron en bruikbare beschrijving voor elk betekenisvol beeld.
5. Gebruik [vaste navigatie](https://www.w3.org/WAI/tips/designing/) in kop en voettekst. Plan privacyinformatie als je gegevensgebruik dat vereist.
**Kies de navigatie**
Voorbeeld ter illustratie: Kooka laat navigatie zien: Links in de kop → Links in de voettekst → Privacyinformatie waar nodig.
- **Kies:** Links in de kop → Links in de voettekst → Privacyinformatie waar nodig
**Let op:** Dezelfde paginanamen in je plan en navigatie.
Kies hoofdnavigatie en voettekstlinks met de [uitleg over vaste navigatie](https://www.w3.org/WAI/tips/designing/). Bekijk je echte gegevensgebruik en plan waar nodig vóór publicatie een pagina met privacyinformatie.
**Stap voor stap**
1. Gebruik dezelfde korte paginanamen in sitemap, kop en voettekst.
2. Controleer of de echte sitefuncties en diensten gegevens verzamelen.
3. Voeg waar nodig duidelijke privacyinformatie aan het plan toe; controleer de inhoud vóór publicatie.
**Dit zou je nu moeten zien:** Dezelfde paginanamen in je plan en navigatie.
6. Laat iemand die je bedrijf niet kent de [paginavolgorde beoordelen](https://www.w3.org/WAI/planning/involving-users/). Verbeter onduidelijke woorden en ontbrekende antwoorden.
**Probeer de bezoekersroute**
Voorbeeld ter illustratie: Kooka laat de route zien: Home → Services → About → Contact → Onduidelijkheden noteren.
- **Probeer:** Home → Services → About → Contact → Onduidelijkheden noteren
**Let op:** Een lezer vindt het aanbod en de contactroute zonder jouw uitleg.
Volg het idee om [bezoekers vroeg te betrekken](https://www.w3.org/WAI/planning/involving-users/): doorloop de paginavolgorde met iemand die je bedrijf niet kent. Noteer onduidelijke termen en ontbrekende antwoorden en werk inhoud en sitemap bij.
**Stap voor stap**
1. Doorloop de geplande pagina’s met iemand die je bedrijf nog niet kent.
2. Vraag wat onduidelijk blijft en hoe die contact zou opnemen.
3. Werk docs/sitemap.md en docs/content.md bij met hun vragen en jouw verbeteringen.
**Dit zou je nu moeten zien:** Een lezer vindt het aanbod en de contactroute zonder jouw uitleg.
De basis uitgelegd
**Sitemap**
Hier een lijst of schema met pagina’s en hun verbanden. Een machineleesbare XML-sitemap voor zoekmachines komt later.
**Navigatie**
De links en menu’s waarmee bezoekers zich door een website verplaatsen.
**Bezoekersroute**
De reeks vragen en acties die een bezoeker volgt om iets te bereiken.
**Alternatieve tekst**
Een tekst die het doel van een betekenisvol beeld uitlegt voor mensen die het niet kunnen zien. Puur decoratieve beelden hebben meestal lege alternatieve tekst.
### Prompt: Maak het inhoudsplan
```text
Lees docs/website-brief.md. Maak docs/sitemap.md voor Home, About, Services en Contact met /, /about/, /services/ en /contact/. Noteer per pagina de bezoekersvraag, kop, onderdelen, benodigde inhoud en volgende actie. Maak docs/content.md met aangeleverde tekst, beeldbronnen en duidelijk gemarkeerde ontbrekende inhoud. Stel eenvoudige navigatie voor. Verzin geen klantbeoordelingen of bedrijfsfeiten en bouw nog geen pagina’s.
```
### Oefensitemap
```text
Home / Wat doet de studio?
About /about/ Met wie werk ik samen?
Services /services/ Welke hulp kan ik vragen?
Contact /contact/ Hoe neem ik contact op?
Hoofdactie: Bespreek je project → Contact
Contactmethode: E-maillink naar je gecontroleerde inbox
```
### Controleer je werk
- [ ] Elke geplande pagina beantwoordt een eigen bezoekersvraag en heeft een logische volgende actie.
- [ ] De sitemap en navigatie gebruiken dezelfde paginanamen en adressen.
- [ ] Ontbrekende inhoud is genoteerd; het contactadres is echt en je kent de bron van elk gepland beeld.
Als er iets misgaat
**Twee pagina’s herhalen dezelfde informatie.**
Geef elke pagina een duidelijk doel: Home introduceert het aanbod, Services legt het uit, About geeft achtergrond en Contact maakt aanvragen mogelijk. Houd korte, noodzakelijke samenvattingen en verwijder lange herhalingen.
**De agent voegt geloofwaardig klinkende klantcitaten toe.**
Verwijder die tenzij ze uit goedgekeurd, echt bronmateriaal komen. Vraag Codex ontbrekend bewijs te markeren in plaats van het te verzinnen.
### Officiële links & verder lezen
- [Astro: paginabestanden en adressen](https://docs.astro.build/en/basics/astro-pages/)
- [W3C: bruikbare beeldalternatieven kiezen](https://www.w3.org/WAI/tutorials/images/decision-tree/)
- [W3C: duidelijke navigatie en paginastructuur](https://www.w3.org/WAI/tips/designing/)
## 10. Kies een eenvoudige websiteopzet
Fase: Plannen
Gebruik Astro voor vier pagina’s, CSS voor de vormgeving en een echte e-maillink voor contact.
Astro is een websiteframework voor sites waar inhoud centraal staat. In deze gids maakt het tijdens een build gewone HTML-pagina’s. CSS bepaalt hoe ze eruitzien; een beetje JavaScript in de browser kan bijvoorbeeld een mobiel menu bedienen. Node voert de ontwikkel- en bouwgereedschappen op je computer uit.
De eerste versie heeft geen gebruikersaccounts, database of server voor privéverzoeken nodig. Een zichtbaar e-mailadres en mailto-link laten bezoekers contact opnemen via hun mailprogramma. Een echt formulier heeft een werkende ontvangstdienst of backend nodig; alleen formuliervelden tekenen bezorgt geen berichten.
We kiezen deze leerroute bewust voor een kleine bedrijfswebsite. Vereist je brief betalingen, privéaccounts of een AI-functie? Bekijk dan de technische opzet en beveiligingseisen opnieuw voordat je deze statische opzet voldoende vindt.
### Doe dit
1. Vergelijk je brief met [Astro’s aanpak](https://docs.astro.build/en/concepts/why-astro/). Bevestig dat je pagina’s nodig hebt, zonder accounts of opgeslagen formulierberichten.
**Houd de eerste versie eenvoudig**
Voorbeeld ter illustratie: Kooka laat een eenvoudige eerste versie zien: Jouw brief → Vier pagina’s → Statische website.
- **Kies:** Jouw brief → Vier pagina’s → Statische website
**Let op:** Een eerste versie zonder database of bezoekersaccounts.
Lees de brief en [Astro’s aanpak met inhoud centraal](https://docs.astro.build/en/concepts/why-astro/). Bevestig dat de eerste versie alleen pagina’s en browserinteracties nodig heeft, zonder bezoekersaccounts of formulierberichten op te slaan.
**Stap voor stap**
1. Lees de functies uit je brief voor de eerste versie.
2. Controleer of ze kunnen werken als pagina’s met kleine browserinteracties en een e-maillink.
3. Heb je nu accounts, betalingen, privégegevens of een AI-functie nodig? Pas de technische opzet aan voordat je deze route volgt.
**Dit zou je nu moeten zien:** Een eerste versie zonder database of bezoekersaccounts.
2. Verstuur de [prompt voor de technische opzet](#technical-foundation-prompts). Laat Codex Astro, CSS, ondersteunde Node LTS en npm vastleggen in docs/architecture.md.
**Leg de hulpmiddelen vast**
Voorbeeld ter illustratie: Kooka laat het vastleggen zien: Prompt kopiëren → Versturen → docs/architecture.md.
- **Codex:** Prompt kopiëren → Versturen → docs/architecture.md
**Let op:** Eén framework en één pakketbeheerder, met een ondersteunde Node-versie.
Gebruik de [architectuurprompt](#technical-foundation-prompts) voor docs/architecture.md met statische Astro, CSS, Node LTS en npm. Controleer [Astro’s installatie-eisen](https://docs.astro.build/en/install-and-setup/) en gebruik één pakketbeheerder.
**Stap voor stap**
1. Kopieer de gekoppelde architectuurprompt naar Codex.
2. Laat de huidige Node-eisen van Astro controleren en gebruik één pakketbeheerder: npm.
3. Controleer docs/architecture.md vóór installatie of het maken van de projectstructuur.
**Dit zou je nu moeten zien:** Eén framework en één pakketbeheerder, met een ondersteunde Node-versie.
3. Plan vier paginabestanden en een gedeelde kop en voettekst met [Astro-pagina’s](https://docs.astro.build/en/basics/astro-pages/) en [layouts](https://docs.astro.build/en/basics/layouts/).
**Plan gedeelde paginaonderdelen**
Voorbeeld ter illustratie: Kooka laat gedeelde onderdelen zien: src/pages → Vier pagina’s → Gedeelde kop en voettekst.
- **Plan:** src/pages → Vier pagina’s → Gedeelde kop en voettekst
**Let op:** Een plan met vier paginabestanden en een gedeelde kop en voettekst.
Noteer src/pages/index.astro, about.astro, services.astro en contact.astro volgens [Astro’s pagina-afspraken](https://docs.astro.build/en/basics/astro-pages/). Plan een [gedeelde layout](https://docs.astro.build/en/basics/layouts/), kop en voettekst.
**Stap voor stap**
1. Noteer src/pages/index.astro, about.astro, services.astro en contact.astro.
2. Plan een gedeelde layout met kop en voettekst.
3. Leg Codex uit dat wijzigingen in gedeelde navigatie op elke pagina hetzelfde moeten verschijnen.
**Dit zou je nu moeten zien:** Een plan met vier paginabestanden en een gedeelde kop en voettekst.
4. Plan een [mailto-contactlink](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/a#linking_to_an_email_address) naar je eigen inbox. Houd het adres zichtbaar en kopieerbaar.
**Gebruik een echte e-maillink**
Voorbeeld ter illustratie: Kooka laat een e-maillink zien: Zichtbaar e-mailadres → E-maillink → Mailprogramma van de bezoeker.
- **Contact:** Zichtbaar e-mailadres → E-maillink → Mailprogramma van de bezoeker
**Let op:** Een echte inbox die bezoekers kunnen kopiëren of openen in hun mailprogramma.
Leg het contactgedrag vast met [e-maillinks in HTML](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/a#linking_to_an_email_address): toon je echte inbox, open het mailprogramma van de bezoeker en houd het adres kopieerbaar.
**Stap voor stap**
1. Geef een inbox die je beheert en kunt testen.
2. Vraag Codex het adres als tekst te tonen en met mailto te koppelen.
3. De link opent het mailprogramma van de bezoeker; de website zelf verstuurt geen bericht.
**Dit zou je nu moeten zien:** Een echte inbox die bezoekers kunnen kopiëren of openen in hun mailprogramma.
5. Behandel een [werkend contactformulier](https://docs.astro.build/en/recipes/build-forms-api/) als optionele latere functie. Noteer eisen voor bezorging, invoercontrole, misbruikbeperking en privacy.
**Bewaar een formulier voor later**
Voorbeeld ter illustratie: Kooka laat het latere formulier zien: Formulier → Ontvangstdienst → Echte bezorgtest.
- **Later:** Formulier → Ontvangstdienst → Echte bezorgtest
**Let op:** Een apart formulierplan; geen nep-succesbericht.
Bewaar een werkend formulier als optionele geavanceerde stap. Lees [Astro’s backend-formuliervoorbeeld](https://docs.astro.build/en/recipes/build-forms-api/) en noteer eisen voor ontvangstdienst, invoercontrole, misbruikbeperking, bezorgtests en privacy.
**Stap voor stap**
1. Een getekend formulier bezorgt zelf geen berichten.
2. Kies vóór toevoeging een ontvangstdienst of backend, invoercontrole op de server, misbruikbeperking en passende privacyinformatie.
3. Eis een echte bezorgtest en eerlijke foutmeldingen. Houd de e-maillink totdat dit klaar is.
**Dit zou je nu moeten zien:** Een apart formulierplan; geen nep-succesbericht.
6. Laat Codex [ontwikkelen, bouwen en previewen](https://docs.astro.build/en/reference/cli-reference/) uitleggen. Rond het plan af voordat je bouwt.
**Begrijp de drie standen**
Voorbeeld ter illustratie: Kooka laat drie standen zien: Lokaal ontwikkelen → Websitebestanden bouwen → Gebouwde bestanden previewen.
- **Leer:** Lokaal ontwikkelen → Websitebestanden bouwen → Gebouwde bestanden previewen
**Let op:** Je kunt een ontwikkelpreview onderscheiden van de laatst gebouwde versie.
Laat Codex [lokaal ontwikkelen, bouwen en previewen](https://docs.astro.build/en/reference/cli-reference/) uitleggen. Vergelijk het antwoord met docs/architecture.md; bouw pas in de bouwfase.
**Stap voor stap**
1. Bij ontwikkelen draait een lokale server die je lopende wijzigingen toont.
2. Een build maakt de bestanden die je host toont. Preview toont de laatst gebouwde versie; voor latere wijzigingen moet je opnieuw bouwen.
3. Controleer of docs/architecture.md deze route uitlegt; laat de uitvoering tot het bouwhoofdstuk wachten.
**Dit zou je nu moeten zien:** Je kunt een ontwikkelpreview onderscheiden van de laatst gebouwde versie.
De basis uitgelegd
**Frontend**
De pagina’s, vormgeving en interacties die bezoekers in hun browser zien en gebruiken.
**Framework**
Een set hulpmiddelen en afspraken om een website of app te organiseren en te bouwen.
**Statische website**
Een website uit bestanden die tijdens een build zijn gemaakt. Hij kan nog steeds browserinteracties hebben en naar externe diensten linken.
**Build**
Het proces dat projectbronbestanden omzet in de bestanden die hosting aan bezoekers toont.
### Prompt: Leg de technische opzet vast
```text
Lees de brief en sitemap. Bewaar docs/architecture.md voor een statische Astro-website met CSS, een huidige ondersteunde Node LTS-versie en npm. Noem de vier paginabestanden, gedeelde layout, kop, voettekst, beeldverwerking en een echte e-maillink als contactmethode. Leg lokaal ontwikkelen, bouwresultaat en hosting uit in beginnerstaal. Houd accounts, betalingen, databases en AI-functies buiten deze eerste versie. Beschrijf een contactformulier met backend als aparte optionele uitbreiding. Maak nog geen projectstructuur.
```
### Controleer je werk
- [ ] Het architectuurbestand noemt één framework, één pakketbeheerder, vier pagina’s en hun gedeelde onderdelen.
- [ ] Je kunt uitleggen dat Node de site bouwt en bezoekers de gegenereerde bestanden ontvangen.
- [ ] Het contactplan heeft een echte contactmethode; een formulieruitbreiding heeft expliciete backend-eisen.
Als er iets misgaat
**De agent stelt veel frameworks en diensten voor.**
Laat elk voorstel onderbouwen vanuit de brief. Ga voor deze oefensite van vier pagina’s terug naar statische Astro en npm; leg een noodzakelijke uitzondering vast vóór toevoeging.
**Een voorgesteld formulier toont een nep-succesbericht.**
Gebruik de e-maillink totdat er een ontvangstdienst bestaat. Bezorging, foutmeldingen en backend-invoercontrole zijn vereiste onderdelen van een echt formulier.
### Officiële links & verder lezen
- [Astro’s doel en aanpak met inhoud centraal](https://docs.astro.build/en/concepts/why-astro/)
- [Astro installeren en ondersteunde Node-versies](https://docs.astro.build/en/install-and-setup/)
- [Astro: gedeelde layouts](https://docs.astro.build/en/basics/layouts/)
- [Geavanceerde optie: Astro-serverweergave](https://docs.astro.build/en/guides/on-demand-rendering/)
## 11. Kies het uiterlijk van je website
Fase: Plannen
Kies een duidelijke stijl. Bekijk vóór de bouw een schets van Home op laptop- en telefoonformaat.
Ontwerp combineert volgorde van aandacht, leesbaarheid, navigatie, beelden en visuele identiteit. Vaste lettergroottes en afstanden helpen vaak meer dan veel decoratieve effecten. De oefenrichting van Fieldnotes Studio is rustig en redactioneel: warme neutrale vlakken, donkere leesbare tekst, één bescheiden accent en voldoende ruimte met een doel.
Een wireframe is een grove indeling van inhoud. Een visueel concept voegt letters, kleuren en beelden toe. Je kunt beide bespreken voordat de agent ze gaat bouwen. Ontwerpvoorbeelden helpen om uit te leggen wat je mooi vindt; maak een eigen indeling en gebruik materiaal waarvoor je toestemming hebt.
### Doe dit
1. Kies met de [ontwerpvragen](https://developer.mozilla.org/en-US/docs/Learn_web_development/Getting_started/Your_first_website/What_will_your_website_look_like) twee of drie voorbeeldpagina’s. Noteer in docs/design-direction.md wat je mooi vindt.
**Verzamel enkele voorbeelden**
Voorbeeld ter illustratie: Kooka laat voorbeeldkeuze zien: Twee of drie voorbeelden → Concrete notities → docs/design-direction.md.
- **Verzamel:** Twee of drie voorbeelden → Concrete notities → docs/design-direction.md
**Let op:** Notities over wat je aanspreekt, geen opdracht om een site te kopiëren.
Verzamel twee of drie voorbeeldpagina’s met [MDN’s ontwerpvragen](https://developer.mozilla.org/en-US/docs/Learn_web_development/Getting_started/Your_first_website/What_will_your_website_look_like). Beschrijf concreet wat je aanspreekt en bewaar adressen en notities in docs/design-direction.md.
**Stap voor stap**
1. Bewaar de adressen van twee of drie pagina’s die je mooi vindt.
2. Schrijf concrete notities over kopgrootte, duidelijke navigatie, kleuren, afstanden of beeldstijl.
3. Maak een eigen indeling en gebruik materiaal dat je mag publiceren.
**Dit zou je nu moeten zien:** Notities over wat je aanspreekt, geen opdracht om een site te kopiëren.
2. Verstuur de [ontwerpprompt](#visual-direction-prompts) met website-design. Vraag twee opties met je echte Home-tekst en contactactie.
**Vraag twee richtingen**
Voorbeeld ter illustratie: Kooka laat twee richtingen zien: Prompt kopiëren → Twee ontwerpopties → Vergelijken.
- **Codex:** Prompt kopiëren → Twee ontwerpopties → Vergelijken
**Let op:** Twee praktische opties met jouw echte inhoud.
Gebruik de [ontwerpprompt](#visual-direction-prompts) om website-design aan te roepen. Vraag twee richtingen met je echte Home-kop, diensten en contactactie.
**Stap voor stap**
1. Open de gekoppelde prompt, kopieer hem en plak hem in je projectchat.
2. Noem de skill website-design en laat Codex de brief, sitemap, inhoud en technische opzet lezen.
3. Vraag twee praktische richtingen in plaats van veel losse stijlen.
**Dit zou je nu moeten zien:** Twee praktische opties met jouw echte inhoud.
3. Vergelijk Home-schetsen op beide formaten met [toegankelijke opmaak](https://www.w3.org/WAI/tips/designing/) in gedachten. Vind je het aanbod en de contactactie?
**Beoordeel laptop- en telefoonschetsen**
Voorbeeld ter illustratie: Kooka laat schetsbeoordeling zien: Laptopschets → Telefoonschets → Aanbod en contact.
- **Controleer:** Laptopschets → Telefoonschets → Aanbod en contact
**Let op:** Beide formaten leggen het bedrijf uit en maken contact makkelijk vindbaar.
Beoordeel Home-wireframes voor laptop en telefoon met [toegankelijke opmaak](https://www.w3.org/WAI/tips/designing/) in gedachten. Controleer eerste indruk, diensten en contactactie; een schets is genoeg om de structuur te bepalen.
**Stap voor stap**
1. Gebruik je echte kop, diensten en contactactie in de schetsen.
2. Bekijk het eerste scherm van beide versies: is het aanbod duidelijk?
3. Controleer of mobiel de inhoud logisch herordent in plaats van de desktopindeling te verkleinen.
**Dit zou je nu moeten zien:** Beide formaten leggen het bedrijf uit en maken contact makkelijk vindbaar.
4. Kies één optie. Leg kleuren, letters, afstanden, knoppen en beeldstijl vast met de [ontwerpvragen](https://developer.mozilla.org/en-US/docs/Learn_web_development/Getting_started/Your_first_website/What_will_your_website_look_like).
**Bewaar de ontwerpkeuzes**
Voorbeeld ter illustratie: Kooka laat keuzes opslaan zien: Gekozen optie → Kleuren · Letters · Ruimte · Knoppen → Ontwerpnotities.
- **Bewaar:** Gekozen optie → Kleuren · Letters · Ruimte · Knoppen → Ontwerpnotities
**Let op:** Een kleine set keuzes die Codex op elke pagina kan hergebruiken.
Kies één richting en leg kleuren, letters, groottes, afstanden, inhoudsbreedte, knoppen en beeldstijl vast. Gebruik de [ontwerpvragen](https://developer.mozilla.org/en-US/docs/Learn_web_development/Getting_started/Your_first_website/What_will_your_website_look_like) om de keuzes klein en herbruikbaar te houden.
**Stap voor stap**
1. Kies één richting en vertel Codex waarom die bij de brief past.
2. Leg kleuren, letterkeuzes en groottes, afstanden, inhoudsbreedte, knoppen en beeldstijl vast.
3. Houd de keuzes klein en herbruikbaar; bewaar ze in docs/design-direction.md.
**Dit zou je nu moeten zien:** Een kleine set keuzes die Codex op elke pagina kan hergebruiken.
5. Controleer [leesbaarheid, toetsenbordfocus en beweging](https://www.w3.org/WAI/tips/designing/). Plan duidelijke links, prettige knoppen en ondersteuning voor minder beweging.
**Neem toegankelijk gedrag op**
Voorbeeld ter illustratie: Kooka laat toegankelijk gedrag zien: Leesbare tekst → Zichtbare focus → Prettige bediening → Minder beweging.
- **Controleer:** Leesbare tekst → Zichtbare focus → Prettige bediening → Minder beweging
**Let op:** Toegankelijkheidskeuzes zijn opgenomen vóór de bouw.
Pas de [W3C-uitleg over toegankelijk ontwerp](https://www.w3.org/WAI/tips/designing/) toe: leesbaar contrast, zichtbare toetsenbordfocus, duidelijke linktekst, prettige bediening en rustige beweging die de voorkeur voor minder beweging respecteert.
**Stap voor stap**
1. Controleer leesbaar tekstcontrast en duidelijke linktekst.
2. Plan een zichtbare focusrand voor toetsenbordgebruikers en voldoende grote bedieningselementen.
3. Houd beweging beperkt en respecteer de voorkeur voor minder beweging; leg deze keuzes vast.
**Dit zou je nu moeten zien:** Toegankelijkheidskeuzes zijn opgenomen vóór de bouw.
6. Laat iemand het [concept beoordelen](https://www.w3.org/WAI/planning/involving-users/). Verbeter onduidelijke inhoud en keur de richting goed in docs/design-direction.md.
**Laat iemand meekijken**
Voorbeeld ter illustratie: Kooka laat een frisse blik zien: Bedrijf duidelijk? → Aanbod duidelijk? → Volgende stap duidelijk? → Notities bijwerken.
- **Controleer:** Bedrijf duidelijk? → Aanbod duidelijk? → Volgende stap duidelijk? → Notities bijwerken
**Let op:** Een lezer begrijpt het bedrijf, het aanbod en de volgende stap.
Gebruik [bezoekersfeedback](https://www.w3.org/WAI/planning/involving-users/) bij de conceptbeoordeling. Controleer of bedrijf, aanbod en volgende stap duidelijk zijn; werk docs/design-direction.md bij vóór goedkeuring van de bouw.
**Stap voor stap**
1. Vraag iemand die je bedrijf niet kent wat de pagina aanbiedt en wat die daarna zou doen.
2. Noteer verwarrende taal, ontbrekende antwoorden of een moeilijk vindbare contactactie.
3. Werk docs/design-direction.md bij voordat je de bouw goedkeurt.
**Dit zou je nu moeten zien:** Een lezer begrijpt het bedrijf, het aanbod en de volgende stap.
De basis uitgelegd
**Wireframe**
Een eenvoudige schets die toont waar inhoud en bedieningselementen komen voordat de vormgeving vaststaat.
**Visuele hiërarchie**
De verdeling van grootte, ruimte en nadruk die laat zien wat een lezer het eerst moet zien.
**Ontwerpsysteem**
Een herbruikbare set keuzes en onderdelen, zoals kleuren, letters, afstanden, knoppen en navigatie.
**Responsive ontwerp**
Een indeling die zich aanpast aan de beschikbare schermruimte, bijvoorbeeld op telefoons en grotere schermen.
### Prompt: Verken het ontwerp
```text
Gebruik de skill website-design en lees onze brief, sitemap, inhoud en technische opzet. Stel twee verschillende maar praktische visuele richtingen voor Fieldnotes Studio voor. Leg de volgorde van aandacht uit en maak leesbare Home-wireframes voor laptop- en telefoonbreedte met onze echte tekst. Neem beslissingen op over kleur, letters, afstanden, toetsenbordfocus, beeldgebruik en minder beweging. Bewaar na mijn feedback de gekozen richting in docs/design-direction.md. Bouw de volledige site nog niet.
```
### Controleer je werk
- [ ] De gekozen richting is vastgelegd met concrete kleuren, letters, afstanden en herbruikbare onderdelen.
- [ ] De telefoon- en laptopindeling houden het hoofdaanbod en de contactactie begrijpelijk.
- [ ] Contrast, toetsenbordfocus en bewegingsvoorkeuren zijn opgenomen in de ontwerpkeuzes.
Als er iets misgaat
**Het concept ziet er mooi uit, maar de boodschap is onduidelijk.**
Vervang de vage kop door een concrete beschrijving van het aanbod en maak de contactactie herkenbaar. Beoordeel opnieuw met je echte tekst.
**De telefoonversie perst de desktopindeling in een smalle kolom.**
Vraag een bewust gekozen mobiele indeling: leesbare koppen, aangepaste afstanden, eenvoudige navigatie en beelden waarop het onderwerp zichtbaar blijft.
### Officiële links & verder lezen
- [W3C: toegankelijke vormgeving](https://www.w3.org/WAI/tips/designing/)
- [MDN: indeling, kleur en inhoud plannen](https://developer.mozilla.org/en-US/docs/Learn_web_development/Getting_started/Your_first_website/What_will_your_website_look_like)
## 12. Plan kleine bouwstappen
Fase: Plannen
Vraag Codex om een bouwplan met kleine taken en zichtbare controles. Keur de eerste stap goed wanneer je klaar bent.
Een bruikbaar plan is concreter dan ‘pagina’s maken, testen, publiceren’. Het noemt te maken bestanden of gedrag, afhankelijkheden tussen taken en bewijs dat nodig is vóór de volgende stap. Eerst één complete pagina bouwen maakt ontwerp- en installatiefouten zichtbaar voordat ze door de website verspreiden.
Acceptatiecriteria beschrijven wat je moet kunnen waarnemen. ‘Alle vier de menulinks openen de bedoelde pagina’ is bijvoorbeeld controleerbaar. ‘De website is volledig veilig’ is een ononderbouwde absolute claim. Beveiliging en toegankelijkheid vragen passende controles, vastgelegde bevindingen en duidelijke beperkingen.
### Doe dit
1. Verstuur de [bouwplanprompt](#implementation-plan-prompts). Laat Codex instructies, skills en planningsbestanden lezen en ontbrekende informatie markeren.
**Controleer de planningsbestanden**
Voorbeeld ter illustratie: Kooka laat planningscontrole zien: Prompt kopiëren → Instructies en plannen lezen → Vragen oplossen.
- **Codex:** Prompt kopiëren → Instructies en plannen lezen → Vragen oplossen
**Let op:** Codex herkent ontbrekende of tegenstrijdige beslissingen vóór de bouw.
Gebruik de [uitvoeringsplanprompt](#implementation-plan-prompts) om AGENTS.md, planningsdocumenten en skills te lezen. Laat Codex eerst tegenstrijdige keuzes en noodzakelijke ontbrekende informatie markeren.
**Stap voor stap**
1. Open de gekoppelde prompt en plak hem in je fieldnotes-studio-chat.
2. Laat Codex AGENTS.md en de vijf planningsbestanden lezen: website-brief.md, sitemap.md, content.md, architecture.md en design-direction.md.
3. Gebruik clean-code, website-testing en website-security. Los belangrijke hiaten en tegenstrijdige keuzes op voordat je de projectstructuur maakt.
**Dit zou je nu moeten zien:** Codex herkent ontbrekende of tegenstrijdige beslissingen vóór de bouw.
2. Laat Codex docs/build-plan.md bewaren met de [prompt voor bouwstappen](#implementation-plan-prompts). Bouw Home vóór de overige pagina’s.
**Noem de bouwstappen**
Voorbeeld ter illustratie: Kooka laat de stappen zien: Installatie → Home → Andere pagina’s → Controles → Latere publicatie.
- **Plan:** Installatie → Home → Andere pagina’s → Controles → Latere publicatie
**Let op:** Kleine bouwstappen, met publicatie apart gehouden.
Maak docs/build-plan.md met de [prompt voor bouwstappen](#implementation-plan-prompts): installatie, gedeelde layout en Home, overige pagina’s, testen, beveiliging, verfijning, automatische controles en aparte publicatie.
**Stap voor stap**
1. Maak stappen voor installatie, gedeelde layout en Home, overige pagina’s, testen, beveiliging, verfijning en automatische controles.
2. Rond Home af voordat je het patroon op de andere pagina’s herhaalt.
3. Houd publicatie als aparte latere stap die jouw beoordeling en beslissing vereist.
**Dit zou je nu moeten zien:** Kleine bouwstappen, met publicatie apart gehouden.
3. Vraag om doelen, bestanden, afhankelijkheden, controles en een Git-mijlpaal. Noteer [commando’s die echt bestaan](https://docs.astro.build/en/reference/cli-reference/).
**Geef elke stap een duidelijk eindpunt**
Voorbeeld ter illustratie: Kooka laat afronding zien: Stap → Resultaat → Controle → Git-mijlpaal.
- **Schrijf:** Stap → Resultaat → Controle → Git-mijlpaal
**Let op:** Elke stap zegt wat verandert en hoe je dat controleert.
Noteer per stap doelen, bestanden, afhankelijkheden, browsercontroles en een Git-mijlpaal. Noem [echte bouw- en controlecommando’s](https://docs.astro.build/en/reference/cli-reference/) die je instelt of uitvoert; eis eerlijke melding van mislukte of onbeschikbare controles.
**Stap voor stap**
1. Vraag per stap wat die oplevert, welke bestanden veranderen en wat eerst nodig is.
2. Noem de browsercontroles en echte bouw- en controlecommando’s die je instelt of uitvoert.
3. Eis eerlijke verslagen van mislukte of onbeschikbare controles en een beoordeelde Git-mijlpaal.
**Dit zou je nu moeten zien:** Elke stap zegt wat verandert en hoe je dat controleert.
4. Pas de [acceptatiechecklist](#implementation-plan-snippets) aan voor links, telefoonindeling, toetsenbordfocus, beelden en contact. Gebruik [W3C-basiscontroles](https://www.w3.org/WAI/test-evaluate/preliminary/).
**Gebruik zichtbare controles**
Voorbeeld ter illustratie: Kooka laat zichtbare controles zien: Routes → Navigatie → Telefoon → Toetsenbord → Contact.
- **Controleer:** Routes → Navigatie → Telefoon → Toetsenbord → Contact
**Let op:** Controles beschrijven zaken die je echt kunt bekijken.
Pas de [voorbeeldchecklist](#implementation-plan-snippets) aan voor routes, navigatie, toetsenbordfocus, leesbaarheid op telefoons, beeldalternatieven en echte contactgegevens. Gebruik [W3C-basiscontroles voor toegankelijkheid](https://www.w3.org/WAI/test-evaluate/preliminary/) voor zichtbaar bewijs.
**Stap voor stap**
1. Kopieer de voorbeeldchecklist en pas die aan je website aan.
2. Gebruik zichtbare controles: vier routes laden, links openen de bedoelde pagina’s, toetsenbordfocus is zichtbaar en mobiele inhoud loopt niet buiten beeld.
3. Neem passende beeldalternatieven, echte contactgegevens en vastgelegde resterende problemen op.
**Dit zou je nu moeten zien:** Controles beschrijven zaken die je echt kunt bekijken.
5. Laat Codex een geslaagde build en nuttige tests plannen, inclusief ontbrekende [controlescripts in package.json](https://docs.npmjs.com/cli/v11/using-npm/scripts/).
**Plan echte automatische controles**
Voorbeeld ter illustratie: Kooka laat automatische controles plannen zien: benoem controles, maak ontbrekende scripts tijdens de bouw en voer ze daarna uit met een resultatenverslag.
- **Plan:** Controles benoemen → Ontbrekende scripts tijdens de bouw maken → Uitvoeren en resultaten melden
**Let op:** Het plan benoemt de controles, wanneer ontbrekende scripts worden gemaakt en hoe resultaten worden gemeld.
Plan een geslaagde [productiebuild](https://docs.astro.build/en/reference/cli-reference/) en passende automatische controles. Neem ontbrekende [package.json-scripts](https://docs.npmjs.com/cli/v11/using-npm/scripts/) als bouwtaak op; neem niet aan dat npm test al bestaat.
**Stap voor stap**
1. Laat Codex package.json bekijken in plaats van aan te nemen dat npm test al bestaat.
2. Plan de hulpmiddelen en scripts voor nuttige code- en browsercontroles.
3. Eis een geslaagde productiebuild en browserbeoordeling van de gebouwde versie.
**Dit zou je nu moeten zien:** Het plan benoemt de controles, wanneer ontbrekende scripts worden gemaakt en hoe resultaten worden gemeld.
6. Beoordeel de [acceptatiechecklist](#implementation-plan-snippets). Keur alleen de eerste bouwstap goed en laat Codex het [plan als commit bewaren](https://git-scm.com/docs/git-commit).
**Keur de eerste stap goed**
Voorbeeld ter illustratie: Kooka laat goedkeuring zien: Plan beoordelen → Eerste stap goedkeuren → Opslaan → Lokaal bouwen.
- **Beslis:** Plan beoordelen → Eerste stap goedkeuren → Opslaan → Lokaal bouwen
**Let op:** Je kent de eerste taak; publicatie wacht nog op latere beoordeling.
Vergelijk het plan met de [acceptatiechecklist](#implementation-plan-snippets) en keur alleen de eerste bouwstap goed. Laat publicatie wachten op je latere previewbeoordeling en [bewaar de planningsmijlpaal als commit](https://git-scm.com/docs/git-commit).
**Stap voor stap**
1. Lees docs/build-plan.md en vergelijk het met je brief en acceptatiechecklist.
2. Keur de eerste bouwstap goed zodra je het resultaat en de controles begrijpt.
3. Laat Codex het beoordeelde plan als commit bewaren. Laat publicatie wachten op je latere previewbeoordeling.
**Dit zou je nu moeten zien:** Je kent de eerste taak; publicatie wacht nog op latere beoordeling.
De basis uitgelegd
**Acceptatiecriteria**
Concrete voorwaarden die je controleert om te bepalen of een functie of versie klaar is.
**Afhankelijkheid**
Iets wat een taak nodig heeft om te werken, zoals een gedeelde layout voordat pagina’s die kunnen gebruiken.
**Mijlpaal**
Een kleine, afgeronde stap die in Git is bewaard, zodat je een bekend punt hebt om te beoordelen of te herstellen.
**Productiebuild**
Het resultaat voor hosting, gemaakt uit de bronbestanden. Dit moet naast de ontwikkelpreview worden gecontroleerd.
### Prompt: Maak een uitvoerbaar plan
```text
Lees AGENTS.md en de vijf planningsbestanden in docs/: website-brief.md, sitemap.md, content.md, architecture.md en design-direction.md. Gebruik de skills clean-code, website-testing en website-security. Bewaar docs/build-plan.md met kleine stappen, afhankelijkheden, bedoelde bestanden, betekenisvolle acceptatiecriteria, benodigde controlescripts, browsercontroles en Git-mijlpalen. Bouw Home helemaal af voordat je patronen herhaalt. Toon tegenstrijdige aannames en ontbrekende invoer. Houd publicatie als latere goedkeuringsstap. Maak alleen het plan; maak geen projectstructuur voordat ik de eerste stap goedkeur.
```
### Voorbeeld van acceptatiecriteria
```text
[ ] Home, About, Services en Contact laden op hun geplande adressen
[ ] Navigatie in kop en voettekst opent de bedoelde pagina’s
[ ] Toetsenbordgebruikers bereiken links en zien de focus
[ ] Op 360px en 1280px loopt inhoud niet horizontaal buiten beeld
[ ] Contact toont mijn echte inbox en de bijbehorende e-maillink
[ ] Beelden hebben passende alternatieve tekst en bekende bronnen
[ ] Ingestelde controles en de productiebuild slagen
[ ] Browsercontroles en resterende problemen zijn vastgelegd
[ ] Publicatie wacht na de beoordeling op mijn toestemming
```
### Controleer je werk
- [ ] Elke geplande stap heeft een concreet resultaat en een zichtbare controle voor afronding.
- [ ] Het plan stelt ontbrekende scripts in vóór gebruik en bevat browserbeoordeling van de gebouwde site.
- [ ] Je weet welke taak Codex eerst uitvoert en waar publicatie jouw beslissing vereist.
Als er iets misgaat
**Het plan belooft kwaliteit zonder uit te leggen hoe je die controleert.**
Vraag bewijs bij elke claim: geteste routes, bekeken schermbreedtes, uitgevoerde commando’s, beoordeelde beveiligingsbevindingen en vastgelegde beperkingen.
**Codex begint te bouwen terwijl je het plan nog beoordeelt.**
Stop die taak, bekijk eventuele wijzigingen en herhaal de huidige grens: rond het plan af en wacht op goedkeuring van de eerste bouwstap. Bewaar nuttige wijzigingen voordat je beslist hoe je verdergaat.
### Officiële links & verder lezen
- [Astro: ontwikkel-, bouw- en controlecommando’s](https://docs.astro.build/en/reference/cli-reference/)
- [W3C: eerste toegankelijkheidscontroles](https://www.w3.org/WAI/test-evaluate/preliminary/)
- [W3C: toegankelijkheid in de projectplanning opnemen](https://www.w3.org/WAI/planning-and-managing/plan/)
## 13. Bouw je eerste pagina
Fase: Bouwen en controleren
Laat Codex Home bouwen. Open de pagina, controleer hem en bewaar een werkende versie.
Astro maakt gewone websitebestanden uit je project. Ons voorbeeld gebruikt statische uitvoer: pagina’s worden vóór publicatie gemaakt, dus deze eerste versie heeft geen database of OpenAI API-sleutel op de website nodig.
De installer maakt de beginbestanden. Codex moet je repository, instructies, skills en brief behouden. Een geslaagde build is nuttig bewijs, maar bewijst niet dat links, indeling of bezoekersroutes werken. Begin nu met browsercontroles.
### Doe dit
1. Laat Codex je project en Node-versie vergelijken met de [Astro-eisen](https://docs.astro.build/en/install-and-setup/#prerequisites).
**Controleer je hulpmiddelen**
Voorbeeld ter illustratie: Geïllustreerd voorbeeld: fieldnotes-studio → New chat → Vraag de hulpmiddelen te controleren. Kooka wijst de actie aan.
- **In Codex:** fieldnotes-studio → New chat → Vraag de hulpmiddelen te controleren
**Let op:** Codex bevestigt het juiste project en of Node wordt ondersteund.
Laat Codex de projectmap en Node-versie controleren voordat het iets installeert. Laat bevestigen dat je ondersteunde Node LTS-versie voldoet aan de [huidige Astro-installatie-eisen](https://docs.astro.build/en/install-and-setup/#prerequisites).
**Controleer vóór installatie**
1. Open het project fieldnotes-studio in Codex. Begin een chat in dat project, zodat de agent in de juiste map werkt.
2. Vraag: ‘Controleer de huidige branch en mijn Node- en npm-versies. Vergelijk Node met de huidige Astro-eisen. Installeer nog niets.’
3. Lees het resultaat. Ontbreekt een hulpmiddel of wordt het niet ondersteund? Ga terug naar het hoofdstuk over computerinstellingen en los dat eerst op.
**Dit zou je nu moeten zien:** Codex bevestigt het juiste project en of Node wordt ondersteund.
2. Kopieer de [prompt voor de eerste pagina](#build-the-foundation-prompts) naar Codex. Vraag Astro-beginbestanden te maken zonder je eerdere werk te overschrijven.
**Maak de beginbestanden**
Voorbeeld ter illustratie: Geïllustreerd voorbeeld: Prompt kopiëren → Plakken → Versturen. Kooka wijst de actie aan.
- **In Codex:** Prompt kopiëren → Plakken → Versturen
- **Behoud:** Bestaande Git-geschiedenis, instructies, skills en notities
**Let op:** Het project bevat Astro-bestanden en je eerdere werk is er nog.
Gebruik de [prompt voor de eerste mijlpaal](#build-the-foundation-prompts) voor een minimaal Astro-project. Is de bestaande map ongeschikt voor de wizard? Gebruik een tijdelijke projectstructuur. Kopieer de .git-map niet, voeg README.md en .gitignore samen en behoud AGENTS.md, .agents/ en docs/.
**Behoud het bestaande project**
1. Open de gekoppelde prompt, kopieer hem, plak hem in je fieldnotes-studio-chat en verstuur hem.
2. De map bevat al Git-geschiedenis en instructies. Heeft Astro een lege map nodig? Laat Codex een tijdelijke structuur maken en alleen de nodige beginbestanden kopiëren.
3. Kopieer de tijdelijke .git-map niet. Voeg README.md en .gitignore samen in plaats van ze te vervangen en behoud AGENTS.md, .agents/ en docs/.
4. Laat Codex opsommen wat het toevoegde en bevestigen dat branch, geschiedenis en planningsbestanden behouden zijn.
**Dit zou je nu moeten zien:** Het project bevat Astro-bestanden en je eerdere werk is er nog.
3. Laat Codex Home bouwen met je brief en een [gedeelde paginalayout](https://docs.astro.build/en/basics/layouts/). Gebruik echte tekst en toegestane beelden.
**Bouw Home**
Voorbeeld ter illustratie: Geïllustreerd voorbeeld: Jouw brief → Gedeelde layout → Home. Kooka wijst de actie aan.
- **Bouwopdracht:** Jouw brief → Gedeelde layout → Home
**Let op:** Home toont je goedgekeurde aanbod en een duidelijke contactmogelijkheid.
Laat Codex een [gedeelde Astro-layout](https://docs.astro.build/en/basics/layouts/), kop, voettekst, kleuren, letters en Home maken vanuit de goedgekeurde brief. Gebruik echte tekst en beelden die je mag publiceren.
**Bouw één complete pagina**
1. Laat Codex docs/website-brief.md, docs/content.md en de goedgekeurde ontwerprichting lezen voordat het de pagina maakt.
2. Laat de gedeelde layout, kop, voettekst, kleuren en letters maken en daarna op Home gebruiken.
3. Controleer of de tekst je echte aanbod beschrijft. Vervang oefenbedrijfsgegevens en gebruik beelden die je mag publiceren.
**Dit zou je nu moeten zien:** Home toont je goedgekeurde aanbod en een duidelijke contactmogelijkheid.
4. Laat Codex een [Astro-codecontrole](https://docs.astro.build/en/reference/cli-reference/#astro-check) en [browsertest](https://playwright.dev/docs/intro) toevoegen en samen met de build uitvoeren.
**Voeg de eerste controles toe**
Voorbeeld ter illustratie: Geïllustreerd voorbeeld: Code controleren → Home testen → Bouwen. Kooka wijst de actie aan.
- **Vraag Codex:** Code controleren → Home testen → Bouwen
**Let op:** Je hebt echte controlecommando’s en een verslag van wat er gebeurde.
Laat Codex package.json bekijken, de echte bouw- en previewcommando’s documenteren en een expliciet [Astro-codecontrolecommando](https://docs.astro.build/en/reference/cli-reference/#astro-check) en eerste [Playwright-browserbasistest](https://playwright.dev/docs/intro) toevoegen. Het moet de benodigde hulpmiddelen installeren en instellen.
**Stel controles in die echt werken**
1. Laat Codex package.json bekijken en de echte bouw-, preview-, codecontrole- en testcommando’s documenteren.
2. Laat de benodigde controlehulpmiddelen installeren en instellen. De eerste browsertest opent Home en controleert een belangrijk zichtbaar resultaat.
3. Laat controles en build uitvoeren, echte resultaten tonen en fouten door dit werk herstellen. Alleen een geslaagde build bewijst niet dat de pagina werkt.
**Dit zou je nu moeten zien:** Je hebt echte controlecommando’s en een verslag van wat er gebeurde.
5. Open de [lokale preview](https://docs.astro.build/en/develop-and-build/). Controleer Home op een breed scherm en op telefoonformaat.
**Open je preview**
Voorbeeld ter illustratie: Geïllustreerd voorbeeld: Previewadres → Browser → Brede en smalle schermen. Kooka wijst de actie aan.
- **Op je computer:** Previewadres → Browser → Brede en smalle schermen
**Let op:** Home opent lokaal en blijft op beide formaten leesbaar.
Gebruik de [instructies voor lokaal ontwikkelen, bouwen en previewen](https://docs.astro.build/en/develop-and-build/) om de website te starten. Open het adres uit de terminal, bekijk Home op desktop- en telefoonbreedte en voer codecontrole, browsertest en productiebuild uit.
**Open het adres dat Codex geeft**
1. Laat Codex de lokale preview starten en het adres van de draaiende server geven. Klik erop of kopieer het naar je browser.
2. Bekijk kop, navigatie, beelden en contactactie. Maak de browser smaller of gebruik de apparaathulpmiddelen van je browser voor een telefoonindeling.
3. Bekijk na geslaagde controles en build ook de productiepreview. Die toont de laatst gebouwde versie, dus bouw opnieuw na latere wijzigingen.
**Dit zou je nu moeten zien:** Home opent lokaal en blijft op beide formaten leesbaar.
6. Bekijk de gewijzigde bestanden. Laat Codex een [Git-commit](https://git-scm.com/docs/git-commit) opslaan zodra de pagina en controles werken.
**Bewaar deze mijlpaal**
Voorbeeld ter illustratie: Geïllustreerd voorbeeld: Wijzigingen beoordelen → Controles uitvoeren → Commit. Kooka wijst de actie aan.
- **Bewaarstappen:** Wijzigingen beoordelen → Controles uitvoeren → Commit
**Let op:** Een benoemde commit bewaart je gecontroleerde eerste pagina.
Controleer gewijzigde bestanden en bewaar een [Git-commit](https://git-scm.com/docs/git-commit) pas nadat de eerste pagina deze controles doorstaat. Noteer bewust onafgemaakte pagina’s in de takenlijst.
**Bewaar een herstelbare versie**
1. Laat Codex gewijzigde bestanden tonen en elke wijziging uitleggen. Zoek naar ongewenste wijzigingen of onbedoelde privégegevens.
2. Controleer of codecontrole, browsertest, build en je eigen previewbeoordeling klaar zijn. Noteer onafgemaakte pagina’s in de takenlijst.
3. Laat Codex goedgekeurde wijzigingen opslaan met een beschrijvend commitbericht, bijvoorbeeld ‘Build checked Home page’, en de commitcode melden.
**Dit zou je nu moeten zien:** Een benoemde commit bewaart je gecontroleerde eerste pagina.
De basis uitgelegd
**Projectstructuur (scaffold)**
De eerste mappen en bestanden waarmee een nieuw project werkend kan beginnen.
**Onderdeel (component)**
Een herbruikbaar stukje pagina, zoals de kop. Eén gedeeld onderdeel aanpassen verandert elke pagina die het gebruikt.
**Basistest (smoke test)**
Een kleine automatische controle op eenvoudige fouten, zoals Home dat niet laadt of zijn hoofdkop mist.
### Prompt: Bouw de eerste mijlpaal
```text
Lees onze brief, AGENTS.md en relevante skills. Bekijk eerst deze repository. Maak een minimale statische Astro-site met de huidige officiële installer. Gebruik je een tijdelijke projectstructuur? Kopieer de .git-map niet, voeg README.md en .gitignore samen in plaats van ze te overschrijven en behoud bestaande Git-geschiedenis, AGENTS.md, .agents/ en docs/. Bouw alleen de gedeelde basis en Home van Fieldnotes Studio. Voeg een werkende lokale preview, expliciete codecontrole en één betekenisvolle browserbasistest toe. Documenteer commando’s die echt in package.json staan. Voer controles en build uit, meld resultaten en geef me het lokale adres om te bekijken. Houd de site lokaal.
```
### Officiële Astro-installer; laat Codex een veilige bestemming kiezen
```sh
npm create astro@latest
```
### Standaard startcommando’s; controleer eerst package.json
```sh
npm run dev
# Stop de ontwikkelserver met Ctrl+C voordat je dezelfde terminal opnieuw gebruikt.
npx astro check
npm run build
npm run preview
```
### Controleer je werk
- [ ] De lokale Home-pagina laadt met de goedgekeurde kop en inhoud van Fieldnotes Studio; je eerdere instructies en Git-geschiedenis zijn behouden.
- [ ] Codex toont een afgeronde codecontrole, geslaagde browserbasistest en geslaagde build in plaats van alleen te zeggen dat het werk klaar is.
- [ ] De productiepreview opent na de build en Home is bruikbaar op desktop- en telefoonbreedte.
Als er iets misgaat
**De terminal meldt dat Node niet wordt ondersteund.**
Vergelijk node --version met de huidige Astro-eisen. Installeer een ondersteunde LTS-versie volgens de installatie-instructies, herstart de terminal en probeer opnieuw.
**Het previewadres opent niet.**
Controleer of de terminal nog een draaiende server toont en welk adres die meldt. Herstart de ontwikkelserver als die gestopt is; een bezette poort kan het adres veranderen.
### Officiële links & verder lezen
- [Astro: een project installeren en opzetten](https://docs.astro.build/en/install-and-setup/)
- [Astro: ontwikkelen, bouwen en previewen](https://docs.astro.build/en/develop-and-build/)
- [Astro: commando’s voor codecontrole](https://docs.astro.build/en/reference/cli-reference/#astro-check)
## 14. Rond de andere pagina’s af
Fase: Bouwen en controleren
Bouw About, Services en Contact. Gebruik hetzelfde ontwerp en controleer elke pagina onderweg.
Astro maakt van bestanden in src/pages/ websiteadressen. Zo levert about.astro de About-pagina. Codex kan tijdens het maken uitleggen hoe bestanden en adressen samenhangen; je hoeft de code niet uit je hoofd te leren.
Voor de eerste publicatie toont Contact je echte e-mailadres en een e-maillink. Een mailto-link opent het ingestelde mailprogramma van de bezoeker; die kiest zelf of het bericht wordt verstuurd. Een websiteformulier heeft een echte ontvangstdienst en gecontroleerde bezorging nodig. Een succesanimatie bewijst niets over bezorging.
### Doe dit
1. Gebruik je [paginaplan](#sitemap-content) om About, Services en Contact elk één duidelijk doel te geven.
**Plan de volgende pagina’s**
Voorbeeld ter illustratie: Geïllustreerd voorbeeld: Paginadoel → Echte inhoud → Volgende actie. Kooka wijst de actie aan.
- **Je notities:** Paginadoel → Echte inhoud → Volgende actie
**Let op:** Elke resterende pagina heeft een duidelijke taak en goedgekeurde inhoud.
Gebruik het [pagina- en inhoudsplan](#sitemap-content) voor een taak per resterende pagina met doel, goedgekeurde tekst, beelden en volgende actie. Vervang bedrijfsvoorbeelden vóór publicatie door je eigen gegevens.
**Houd paginataken klein**
1. Open docs/sitemap.md en docs/content.md met Codex. Maak aparte taken voor About, Services en Contact.
2. Noem per taak het paginadoel, goedgekeurde tekst en beelden en de volgende actie voor bezoekers.
3. Vervang fictieve bedrijfsgegevens door je eigen gegevens. Houd ontbrekende inhoud zichtbaar in de takenlijst in plaats van Codex die te laten verzinnen.
**Dit zou je nu moeten zien:** Elke resterende pagina heeft een duidelijke taak en goedgekeurde inhoud.
2. Laat Codex een [branch maken](https://git-scm.com/docs/git-switch) met de naam codex/remaining-pages, vanuit je gecontroleerde Home-pagina.
**Begin een nieuwe branch**
Voorbeeld ter illustratie: Geïllustreerd voorbeeld: Gecontroleerde Home → codex/remaining-pages. Kooka wijst de actie aan.
- **Vraag Codex:** Gecontroleerde Home → codex/remaining-pages
**Let op:** Je nieuwe branch bevat de werkende Home-pagina.
Laat Codex een [nieuwe Git-branch](https://git-scm.com/docs/git-switch) voor deze mijlpaal maken met de naam codex/remaining-pages en bevestigen dat het startpunt de gecontroleerde Home-pagina bevat.
**Houd een bekend startpunt**
1. Controleer eerst of de gecontroleerde Home-pagina als commit is opgeslagen. Laat Codex de huidige branch en niet-opgeslagen wijzigingen melden.
2. Laat codex/remaining-pages vanuit die werkende versie maken. Je huidige bestanden en geschiedenis moeten behouden blijven.
3. Laat Codex de branchnaam bevestigen en controleren of Home nog opent. Een branch laat je deze mijlpaal apart beoordelen.
**Dit zou je nu moeten zien:** Je nieuwe branch bevat de werkende Home-pagina.
3. Bouw About en Services met de [gedeelde layout](https://docs.astro.build/en/basics/layouts/). Open en beoordeel elke pagina voordat je verdergaat.
**Bouw de volgende pagina’s**
Voorbeeld ter illustratie: Geïllustreerd voorbeeld: About bouwen → Beoordelen → Services bouwen → Beoordelen. Kooka wijst de actie aan.
- **Pagina voor pagina:** About bouwen → Beoordelen → Services bouwen → Beoordelen
**Let op:** Beide pagina’s openen en gebruiken dezelfde kop, voettekst en stijl als Home.
Bouw About en Services met de [gedeelde Astro-layout](https://docs.astro.build/en/basics/layouts/). Bekijk elke pagina in de lokale browser voordat je verdergaat.
**Hergebruik de basis van de eerste pagina**
1. Laat Codex About vanuit de taak en gedeelde layout bouwen. Open de lokale pagina en controleer tekst, beelden en volgende actie.
2. Geef concrete feedback, zoals ‘deze kop is te lang op mijn telefoon’. Laat Codex dit herstellen en betrokken controles opnieuw uitvoeren.
3. Herhaal voor Services. Beoordeel beide pagina’s rechtstreeks via hun adressen én via de navigatie.
**Dit zou je nu moeten zien:** Beide pagina’s openen en gebruiken dezelfde kop, voettekst en stijl als Home.
4. Bouw Contact met je zichtbare e-mailadres en een bijbehorende [e-maillink](https://developer.mozilla.org/en-US/docs/Learn_web_development/Core/Structuring_content/Creating_links#email_links).
**Voeg echt contact toe**
Voorbeeld ter illustratie: Geïllustreerd voorbeeld: Adres tonen → E-maillink → Je mailprogramma. Kooka wijst de actie aan.
- **Op Contact:** Adres tonen → E-maillink → Je mailprogramma
**Let op:** Bezoekers kunnen je adres kopiëren of een bericht aan jou openen.
Bouw Contact met een zichtbaar, kopieerbaar e-mailadres en een bijbehorende [mailto-link](https://developer.mozilla.org/en-US/docs/Learn_web_development/Core/Structuring_content/Creating_links#email_links). Voeg dezelfde navigatie en voettekst aan elke pagina toe, plus een bruikbaar scherm voor ontbrekende pagina’s.
**Begin met de eenvoudige e-mailroute**
1. Geef Codex een inbox die je beheert en kunt testen. Laat het adres als selecteerbare tekst tonen en een bijbehorende mailto-link maken.
2. Klik op de link op een apparaat met een ingesteld mailprogramma. Controleer het ontvangeradres; de bezoeker kiest nog steeds zelf of die verstuurt.
3. Houd het kopieerbare adres als alternatief. Voeg gedeelde navigatie en een bruikbaar scherm voor ontbrekende pagina’s toe, zodat bezoekers hun weg terugvinden.
**Dit zou je nu moeten zien:** Bezoekers kunnen je adres kopiëren of een bericht aan jou openen.
5. Probeer het telefoonmenu met aanraking en toetsenbord, met de [toegankelijkheidscontroles](https://www.w3.org/WAI/test-evaluate/preliminary/).
**Probeer het telefoonmenu**
Voorbeeld ter illustratie: Geïllustreerd voorbeeld: Menu openen → Pagina kiezen → Menu sluiten. Kooka wijst de actie aan.
- **Aanraking:** Menu openen → Pagina kiezen → Menu sluiten
- **Toetsenbord:** Met Tab naar knoppen → Activeren → Focus controleren
**Let op:** Je kunt het menu openen, gebruiken en sluiten zonder je plek kwijt te raken.
Vraagt het ontwerp om een mobiel menu? Controleer openen, sluiten, focus en navigatie met aanraking en toetsenbord via de [W3C-toegankelijkheidscontroles](https://www.w3.org/WAI/test-evaluate/preliminary/). Laat Codex interacties verwijderen die ingewikkeld zijn zonder bezoekers te helpen.
**Controleer het menu dat je ontwerp gebruikt**
1. Open de preview op telefoonformaat. Tik op het menu, kies een pagina, open het opnieuw en probeer de sluitknop.
2. Leg de muis weg en gebruik het toetsenbord. Controleer zichtbare focus, logische volgorde en een manier om het open menu te verlaten.
3. Vertel Codex precies welke actie mislukte en wat je verwachtte. Maakt een menu het ingewikkelder zonder te helpen? Vereenvoudig het.
**Dit zou je nu moeten zien:** Je kunt het menu openen, gebruiken en sluiten zonder je plek kwijt te raken.
6. Voer controles uit, beoordeel wijzigingen en bewaar een [commit](https://git-scm.com/docs/git-commit) voor elke afgeronde mijlpaal.
**Controleer en bewaar**
Voorbeeld ter illustratie: Geïllustreerd voorbeeld: Controles uitvoeren → Wijzigingen beoordelen → Commit. Kooka wijst de actie aan.
- **Na een pagina:** Controles uitvoeren → Wijzigingen beoordelen → Commit
**Let op:** De afgeronde pagina’s hebben controlebewijs en opgeslagen mijlpalen.
Voer na elke afgeronde mijlpaal bestaande controles uit, beoordeel gewijzigde bestanden en bewaar een beschrijvende [Git-commit](https://git-scm.com/docs/git-commit). Kies je later een backend-formulier? Plan via het [hoofdstuk over bezoekerstests](#test-as-a-visitor) een aparte mijlpaal met echte ontvangstroute, invoercontrole, foutafhandeling, spambeperking en een testbericht in je inbox.
**Houd voortgang beoordeelbaar**
1. Laat Codex na elke mijlpaal de ingestelde controles uitvoeren. Bekijk gewijzigde bestanden en open de betrokken pagina’s zelf.
2. Bewaar een beschrijvende commit nadat het werk is gecontroleerd. Houd onafgemaakte taken en mislukte controles in het verslag.
3. Een backend-formulier is een optionele latere mijlpaal. Het vereist een echte ontvangstroute, servercontrole van invoer, spambeperking, foutmeldingen en een ontvangen bericht in je inbox; alleen een succesanimatie is onvoldoende.
**Dit zou je nu moeten zien:** De afgeronde pagina’s hebben controlebewijs en opgeslagen mijlpalen.
De basis uitgelegd
**Route**
Een adres binnen je website, zoals /services/. Elke route moet naar de pagina gaan die bezoekers verwachten.
**Branch**
Een aparte reeks opgeslagen werk waarin je wijzigingen ontwikkelt voordat je die aan de hoofdversie toevoegt.
**mailto-link**
Een link die het mailprogramma van de bezoeker vraagt een bericht aan een adres te beginnen. De link verstuurt of bewaart dat bericht zelf niet.
### Prompt: Rond de volgende pagina af
```text
Gebruik de goedgekeurde Fieldnotes Studio-brief en het gedeelde ontwerp om de volgende onafgemaakte pagina af te ronden. Leg uit welke route en bestanden je aanpast. Gebruik voor Contact het echte adres dat ik geef, toon het als selecteerbare tekst en maak een bijbehorende mailto-link. Hergebruik gedeelde onderdelen, controleer desktop- en mobiel gedrag en voer bestaande controles uit. Meld wat veranderde en welke taken overblijven. Houd het werk op onze mijlpaalbranch en bereid een beschrijvende commit voor ter beoordeling.
```
### Controleer je werk
- [ ] Home, About, Services en Contact openen elk rechtstreeks en elke navigatielink gaat naar de verwachte pagina.
- [ ] Het Contact-adres komt overeen met de bedoelde inbox. De link opent een bericht aan dat adres als een mailprogramma is ingesteld; het adres blijft bruikbaar door het te kopiëren.
- [ ] De mijlpaal heeft een beschrijvende commit en controleverslag. Optioneel formulierwerk is pas klaar wanneer een echt testbericht aankomt.
Als er iets misgaat
**De e-maillink doet op één computer niets.**
Controleer of een mailprogramma of webmailkoppeling is ingesteld. Houd het adres zichtbaar zodat bezoekers het naar hun eigen maildienst kunnen kopiëren.
**Een navigatielink geeft een melding dat de pagina ontbreekt.**
Geef Codex het exacte foutieve adres en de verwachte pagina. Laat de link vergelijken met de echte paginaroute, het verschil herstellen en opnieuw testen.
### Officiële links & verder lezen
- [Astro: pagina’s en routes](https://docs.astro.build/en/basics/astro-pages/)
- [MDN: e-maillinks maken](https://developer.mozilla.org/en-US/docs/Learn_web_development/Core/Structuring_content/Creating_links#email_links)
- [GitHub: pull requests en branchwijzigingen beoordelen](https://docs.github.com/en/pull-requests/reference/pull-requests)
## 15. Probeer de website als bezoeker
Fase: Bouwen en controleren
Volg links, gebruik het telefoonmenu en probeer het toetsenbord. Laat Codex belangrijke controles herhalen.
Playwright kan een browser bedienen en verwachte resultaten controleren. Nuttige tests beschrijven wat een bezoeker bereikt: van Home naar Services gaan, Contact vinden of het mobiele menu gebruiken. Vermijd tests die alleen controleren of de code dezelfde tekst bevat die Codex zojuist schreef.
Automatische toegankelijkheidscontroles vinden sommige problemen, zoals bepaalde ontbrekende labels en contrastfouten. Ze bewijzen geen volledige toegankelijkheid. Toetsenbordgebruik, leesbare inhoud, zoom, betekenisvolle beeldbeschrijvingen en schermlezercontroles vragen ook menselijke beoordeling.
### Doe dit
1. Gebruik de [testprompt](#test-as-a-visitor-prompts) voor drie bezoekersroutes. Geef aan wat bij elke stap moet gebeuren.
**Kies de routes**
Voorbeeld ter illustratie: Geïllustreerd voorbeeld: Home → Services → Contact. Kooka wijst de actie aan.
- **Hoofdroute:** Home → Services → Contact
- **Probeer ook:** About → Contact en het telefoonmenu
**Let op:** Drie korte routes hebben elk een verwachte uitkomst.
Gebruik de [prompt voor bezoekersroutes](#test-as-a-visitor-prompts) om drie routes als testgevallen te beschrijven: Home naar Services naar Contact; rechtstreeks About openen en naar Contact gaan; en navigatie op een telefoon openen. Noem per route het verwachte resultaat.
**Test een bezoekersdoel**
1. Schrijf de hoofdroute: op Home aankomen, Services vinden en Contact bereiken. Noem na elke actie de verwachte pagina of uitkomst.
2. Test ook rechtstreeks op About aankomen en Contact vinden, plus het openen en gebruiken van het telefoonmenu.
3. Geef Codex deze routes met de gekoppelde prompt. Vraag controles van zichtbaar gedrag, geen tests die alleen de code herhalen.
**Dit zou je nu moeten zien:** Drie korte routes hebben elk een verwachte uitkomst.
2. Laat Codex [Playwright-tests](https://playwright.dev/docs/intro) voor je routes instellen en uitvoeren met een [lokale testserver](https://playwright.dev/docs/test-webserver).
**Herhaal de controles automatisch**
Voorbeeld ter illustratie: Geïllustreerd voorbeeld: Browsertests instellen → Routes uitvoeren → Resultaten tonen. Kooka wijst de actie aan.
- **Vraag Codex:** Browsertests instellen → Routes uitvoeren → Resultaten tonen
**Let op:** Het testverslag toont welke routes slaagden of mislukten.
Laat Codex de eerste basistest uitbreiden tot [Playwright-browsertests](https://playwright.dev/docs/intro) voor deze routes. Laat een [lokale testserver](https://playwright.dev/docs/test-webserver) instellen, benodigde browsers installeren en het exacte testcommando documenteren.
**Laat de browsertest echte acties uitvoeren**
1. Laat Codex de eerste basistest uitbreiden met controles voor je drie bezoekersroutes.
2. Laat benodigde browsers installeren, de lokale testserver instellen en het echte testcommando documenteren. Gebruik waar praktisch de gebouwde preview.
3. Voer de tests uit en lees de resultaten. Vraag herhaalbaar bewijs van een fout in plaats van een ononderbouwd ‘het werkt’ te accepteren.
**Dit zou je nu moeten zien:** Het testverslag toont welke routes slaagden of mislukten.
3. Verander het previewformaat en probeer een telefoon. Gebruik waar handig [Chrome-apparaatmodus](https://developer.chrome.com/docs/devtools/device-mode).
**Probeer verschillende schermgroottes**
Voorbeeld ter illustratie: Geïllustreerd voorbeeld: Breed → Tabletbreedte → Telefoonbreedte. Kooka wijst de actie aan.
- **In de browser:** Breed → Tabletbreedte → Telefoonbreedte
**Let op:** Je kunt de site lezen en gebruiken zonder zijwaarts te scrollen.
Test de productiepreview op smalle telefoon-, tablet- en desktopbreedte, waar nodig met [Chrome-apparaatmodus](https://developer.chrome.com/docs/devtools/device-mode). Probeer ook een echte telefoon als die beschikbaar is; let op verborgen knoppen, overlopende tekst, afgesneden beelden en ongewenst zijwaarts scrollen.
**Bekijk wat verandert als er minder ruimte is**
1. Open de productiepreview op brede desktopgrootte. Maak de browser smaller en bekijk de tablet- en telefoonindelingen.
2. Gebruik de gekoppelde Chrome-instructies voor een gecontroleerd telefoonformaat. Probeer ook een echte telefoon als die beschikbaar is.
3. Let op afgesneden koppen, verborgen knoppen, onhandig afgesneden beelden en zijwaarts scrollen. Geef Codex de pagina en schermbreedte bij een probleem.
**Dit zou je nu moeten zien:** Je kunt de site lezen en gebruiken zonder zijwaarts te scrollen.
4. Leg de muis weg. Probeer elke knop met Tab en Enter volgens de [toetsenbordcontroles](https://www.w3.org/WAI/test-evaluate/preliminary/).
**Gebruik alleen het toetsenbord**
Voorbeeld ter illustratie: Geïllustreerd voorbeeld: Tab → Focus zien → Enter. Kooka wijst de actie aan.
- **Toetsroute:** Tab → Focus zien → Enter
- **Ga terug:** Shift + Tab
**Let op:** Elk bedieningselement is bereikbaar, bruikbaar en zichtbaar gefocust.
Gebruik de [W3C-toetsenbordcontroles](https://www.w3.org/WAI/test-evaluate/preliminary/) met de muis opzij. Druk op Tab en Shift+Tab om tussen knoppen en links te bewegen, Enter om links te openen en de ondersteunde toetsen van het menu. Controleer zichtbare focus, logische volgorde en of je elke geopende interface kunt verlaten.
**Controleer waar het toetsenbord je brengt**
1. Begin in de adresbalk van de browser en druk op Tab om de pagina in te gaan. Gebruik Shift+Tab om terug te gaan.
2. Controleer of een rand of andere duidelijke markering toont welke link of knop focus heeft. Gebruik Enter voor links en de ondersteunde toetsen van elk menu.
3. Controleer de volgorde en of je elke geopende interface kunt verlaten. Noteer de exacte toetsvolgorde als focus verdwijnt of vastloopt.
**Dit zou je nu moeten zien:** Elk bedieningselement is bereikbaar, bruikbaar en zichtbaar gefocust.
5. Zoom tot 200% en controleer koppen en beelden met de [toegankelijkheidsgids](https://www.w3.org/WAI/test-evaluate/preliminary/). Laat Codex [axe-controles](https://playwright.dev/docs/accessibility-testing) toevoegen.
**Controleer lezen en toegankelijkheid**
Voorbeeld ter illustratie: Geïllustreerd voorbeeld: Tot 200% zoomen → Lezen → Koppen en beeldtekst controleren. Kooka wijst de actie aan.
- **In de browser:** Tot 200% zoomen → Lezen → Koppen en beeldtekst controleren
**Let op:** Je verslag bevat handmatige bevindingen en automatische toegankelijkheidsresultaten.
Volg de [eerste W3C-toegankelijkheidsbeoordeling](https://www.w3.org/WAI/test-evaluate/preliminary/): zoom tot 200%, bekijk paginatitels en kopvolgorde en controleer betekenisvolle beeldbeschrijvingen. Laat Codex [axe-toegankelijkheidstests](https://playwright.dev/docs/accessibility-testing) naast Playwright toevoegen; automatische resultaten vragen nog handmatige beoordeling.
**Combineer zelf bekijken met automatische controles**
1. Zoom de browser tot 200%. Controleer of de pagina leesbaar blijft en belangrijke knoppen nog werken.
2. Bekijk verschillende paginatitels, een logische kopvolgorde en beschrijvingen die nuttige beelden uitleggen. Decoratieve beelden moeten geen onnodige ruis geven.
3. Laat Codex axe-tests uitvoeren en bevindingen uitleggen. Automatische controles bewijzen geen volledige toegankelijkheid; noteer ook toetsenbord-, zoom- en andere handmatige bevindingen.
**Dit zou je nu moeten zien:** Je verslag bevat handmatige bevindingen en automatische toegankelijkheidsresultaten.
6. Bewaar een verslag met de [hoofdstukcontroles](#test-as-a-visitor-checks). Laat Codex fouten herstellen en die controles opnieuw proberen.
**Noteer, herstel en probeer opnieuw**
Voorbeeld ter illustratie: Geïllustreerd voorbeeld: Verwacht resultaat → Echt resultaat → Herstellen en opnieuw proberen. Kooka wijst de actie aan.
- **Je verslag:** Verwacht resultaat → Echt resultaat → Herstellen en opnieuw proberen
**Let op:** Fouten zijn herhaalbaar en herstellingen zijn opnieuw gecontroleerd.
Bewaar een kort verslag met de [succescontroles](#test-as-a-visitor-checks): pagina, apparaat of viewport, actie, verwacht resultaat, echt resultaat en status. Laat Codex fouten reproduceren, herstellen en betrokken controles opnieuw uitvoeren. Test bij een backend-formulier echte bezorging én geweigerde of mislukte verzending.
**Bewaar bruikbaar bewijs**
1. Noteer pagina, apparaat of viewport, actie, verwacht resultaat, echt resultaat en status. Daarmee kan Codex het probleem reproduceren.
2. Laat Codex bevestigde fouten herstellen en betrokken controles opnieuw uitvoeren. Verzwak geen resultaatcontroles en verwijder geen bevindingen alleen voor een geslaagd verslag.
3. Controleer bij de e-maillink de ontvanger in plaats van te claimen dat een bericht is verstuurd. Een optioneel backend-formulier vraagt apart bezorgbewijs en controles van geweigerde of mislukte verzending.
**Dit zou je nu moeten zien:** Fouten zijn herhaalbaar en herstellingen zijn opnieuw gecontroleerd.
De basis uitgelegd
**End-to-end-test**
Een test die een actie door het werkende systeem tot het resultaat volgt, zoals een formulier versturen en controleren of de ontvangstdienst het kreeg.
**Viewport**
Het zichtbare gedeelte van een browserpagina. Een smalle viewport helpt problemen op telefoons te vinden.
**Toetsenbordfocus**
Het bedieningselement dat op dat moment toetsenbordinvoer ontvangt. Een zichtbare focusmarkering laat zien waar je op de pagina bent.
**Regressie**
Iets dat eerder werkte maar na een wijziging stukgaat. Herhaalbare tests helpen dat ontdekken.
### Prompt: Test betekenisvolle bezoekersroutes
```text
Lees de acceptatiecriteria en bestaande testopzet. Gebruik Playwright voor de Fieldnotes Studio-routes Home > Services > Contact, About > Contact en mobiele navigatie. Controleer zichtbaar gedrag met betekenisvolle resultaatcontroles. Voeg een axe-toegankelijkheidsscan toe en leg de beperkingen uit. Test waar praktisch tegen de gebouwde preview. Meld echte resultaten en bewaar reproduceerbare fouten; verzwak geen controles om te slagen. Herstel bevestigde fouten en voer betrokken controles opnieuw uit. Geef me een aparte handmatige checklist voor toetsenbord en zoom.
```
### Controleer je werk
- [ ] Het testverslag noemt echte geslaagde of mislukte resultaten voor alle drie de routes, met herhaalbare instructies voor fouten.
- [ ] Elk interactief element is bereikbaar en bruikbaar met het toetsenbord, met zichtbare focus en zonder dat de focus vastloopt.
- [ ] Inhoud blijft leesbaar op telefoonbreedte en bij 200% zoom; automatische toegankelijkheidsresultaten en handmatige bevindingen zijn beide vastgelegd.
- [ ] Een mailto-actie is gecontroleerd als e-maillink met de juiste ontvanger. Een optioneel websiteformulier heeft apart bewijs van echte ontvangst en foutafhandeling.
Als er iets misgaat
**Playwright kan de website niet bereiken.**
Laat Codex het ingestelde servercommando, de poort en de basis-URL vergelijken met de echte preview. Controleer of de build bestaat en de benodigde browser is geïnstalleerd.
**De automatische scan slaagt, maar toetsenbordnavigatie is verwarrend.**
Noteer de precieze toetsvolgorde en onverwachte focusbeweging. Herstel het gedrag en controleer handmatig opnieuw; een automatische geslaagde controle vervangt deze bevinding niet.
### Officiële links & verder lezen
- [Playwright: installatie en eerste tests](https://playwright.dev/docs/intro)
- [Playwright: de testwebserver starten](https://playwright.dev/docs/test-webserver)
- [Playwright: toegankelijkheid testen met axe](https://playwright.dev/docs/accessibility-testing)
- [W3C: eerste toegankelijkheidscontroles](https://www.w3.org/WAI/test-evaluate/preliminary/)
## 16. Controleer beveiliging en privacy
Fase: Bouwen en controleren
Vraag Codex wat het controleerde, wat het vond en wat nog aandacht nodig heeft. Bewaar het bewijs.
Ons statische voorbeeld heeft geen bezoekersaccounts, database of AI-toegangspunt. Er blijven risico’s, zoals gelekte geheimen, kwetsbare bouwpakketten, ongewenste scripts van derden en accounttoegang. Formulieren, betalingen of accounts voegen systemen toe die een eigen controle nodig hebben.
Een beveiligingsskill stuurt het werk van de agent; het is geen veiligheidscertificaat. npm audit meldt bekende pakketkwetsbaarheden en heeft ook beperkingen. Vraag wat is onderzocht en wat onbevestigd blijft in plaats van een algemene claim dat de site veilig is te accepteren.
### Doe dit
1. Gebruik de [beveiligingsprompt](#review-security-and-privacy-prompts) om functies, diensten, accounts en gegevens van de site te noemen.
**Noem wat gecontroleerd moet worden**
Voorbeeld ter illustratie: Geïllustreerd voorbeeld: Pagina’s → Diensten → Accounts → Gegevens. Kooka wijst de actie aan.
- **Begin met:** Pagina’s → Diensten → Accounts → Gegevens
**Let op:** De beoordeling heeft een duidelijke reikwijdte gebaseerd op je echte website.
Gebruik de [afgebakende beveiligingsprompt](#review-security-and-privacy-prompts) om Codex de echte sitefuncties, pakketten, externe diensten, verzamelde gegevens en accounts met extra rechten te laten noemen. Neem hostinglogboeken en e-mailaanvragen mee, ook bij statische pagina’s.
**Controleer de systemen die je echt gebruikt**
1. Laat Codex pagina’s, pakketten, scripts van derden, externe diensten en accounts met extra toegang inventariseren.
2. Neem hostinglogboeken en e-mailaanvragen mee in het gegevensoverzicht, ook al gebruikt de website statische pagina’s.
3. Neem accounts, databases, AI-toegangspunten en formulieren alleen op als ze echt bestaan. Latere toevoegingen vragen een aparte controle.
**Dit zou je nu moeten zien:** De beoordeling heeft een duidelijke reikwijdte gebaseerd op je echte website.
2. Laat Codex bestanden en geschiedenis op [gelekte geheimen](https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html) controleren. Trek gelekte toegangsgegevens bij hun aanbieder in.
**Zoek naar gelekte sleutels**
Voorbeeld ter illustratie: Geïllustreerd voorbeeld: Intrekken → Zo nodig vervangen → Blootstelling opruimen. Kooka wijst de actie aan.
- **Als een sleutel is gelekt:** Intrekken → Zo nodig vervangen → Blootstelling opruimen
**Let op:** Mogelijke geheimen worden zonder waarden gemeld; gelekte sleutels zijn uitgeschakeld.
Controleer gevolgde bestanden, Git-geschiedenis en de gegenereerde dist-map op geheimen met [OWASP-uitleg over geheimenbeheer](https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html). Eis een verslag met locaties zonder geheime waarden. Is een sleutel blootgesteld? Trek hem bij de aanbieder in of vervang hem; alleen het huidige bestand verwijderen is onvoldoende.
**Een bestand verwijderen schakelt een sleutel niet uit**
1. Laat Codex gevolgde bestanden, relevante Git-geschiedenis en gegenereerde dist-uitvoer bekijken. Het verslag noemt locaties en soorten toegangsgegevens zonder geheime waarden te tonen.
2. Zijn echte toegangsgegevens blootgesteld? Open de accountinstellingen van de aanbieder en trek ze in of vervang ze. Plak de waarde niet in de chat.
3. Bekijk daarna het gebruik van de oude sleutel en volg een afgebakend opruimplan. Het nieuwste bestand verwijderen of .gitignore toevoegen wist geen oude geschiedenis en trekt geen toegang in.
**Dit zou je nu moeten zien:** Mogelijke geheimen worden zonder waarden gemeld; gelekte sleutels zijn uitgeschakeld.
3. Voer [npm audit](https://docs.npmjs.com/cli/v11/commands/npm-audit/) uit. Laat Codex bevindingen uitleggen, relevante problemen herstellen en controles opnieuw uitvoeren.
**Beoordeel pakketbevindingen**
Voorbeeld ter illustratie: Geïllustreerd voorbeeld: npm audit → Bevindingen beoordelen → Herstellen en opnieuw testen. Kooka wijst de actie aan.
- **Met Codex:** npm audit → Bevindingen beoordelen → Herstellen en opnieuw testen
**Let op:** Elke relevante bevinding heeft een herstel of vastgelegde beoordeling.
Voer [npm audit](https://docs.npmjs.com/cli/v11/commands/npm-audit/) uit en laat Codex relevante waarschuwingen, betrokken onderdelen en herstellingen uitleggen. Pas beoordeelde updates op een branch toe, bouw opnieuw en herhaal tests. Vermijd automatische geforceerde upgrades zonder hun impact te begrijpen.
**Beoordeel vóór een upgrade**
1. Laat Codex npm audit uitvoeren en de waarschuwing, het betrokken pakket en de waarschijnlijke impact voor dit project uitleggen.
2. Pas passende updates binnen de taak op een branch toe. Vermijd automatische geforceerde upgrades die gedrag kunnen veranderen of de build kunnen breken.
3. Bouw opnieuw en herhaal relevante tests. Noteer openstaande problemen en onbevestigde zaken; npm audit behandelt bekende pakketwaarschuwingen, niet elk mogelijk risico.
**Dit zou je nu moeten zien:** Elke relevante bevinding heeft een herstel of vastgelegde beoordeling.
4. Noteer externe diensten en verzamelde gegevens. Gebruik de [EU-uitleg](https://commission.europa.eu/law/law-topic/data-protection/information-business-and-organisations/obligations_en) voor juiste privacyinformatie waar die geldt.
**Leg de gegevensstroom uit**
Voorbeeld ter illustratie: Geïllustreerd voorbeeld: Website → Dienstaanbieder → Privacyinformatie. Kooka wijst de actie aan.
- **Volg de gegevens:** Website → Dienstaanbieder → Privacyinformatie
**Let op:** De privacytekst beschrijft de echte diensten en gegevensverwerking.
Bekijk externe scripts, ingesloten inhoud, lettertypen en statistieken. Houd alleen wat je nodig hebt. Noteer welke aanbieders bezoekersgegevens krijgen en gebruik hun echte instellingen plus de [EU-uitleg over persoonsgegevens](https://commission.europa.eu/law/law-topic/data-protection/information-business-and-organisations/obligations_en) voor juiste privacyinformatie waar nodig.
**Gebruik echte instellingen en aanbieders**
1. Bekijk scripts, ingesloten inhoud, lettertypen en statistieken met Codex. Verwijder wat de site niet nodig heeft.
2. Noteer welke aanbieders informatie krijgen, waarvoor die wordt gebruikt en de echte bewaartermijnen. Neem zakelijke e-mailaanvragen en hostinglogboeken mee.
3. Maak privacyinformatie die bij deze feiten en geldende eisen past. Alleen een codescan of AI-geschreven verklaring bewijst geen wettelijke naleving.
**Dit zou je nu moeten zien:** De privacytekst beschrijft de echte diensten en gegevensverwerking.
5. Heb je een formulier toegevoegd? Controleer [invoercontrole op de server](https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html) en bevestig dat een echt testbericht aankomt.
**Controleer een optioneel formulier**
Voorbeeld ter illustratie: Geïllustreerd voorbeeld: Versturen → Servercontroles → Ontvangst bevestigen. Kooka wijst de actie aan.
- **Alleen als je een formulier toevoegde:** Versturen → Servercontroles → Ontvangst bevestigen
**Let op:** Een formulier heeft maatregelen bij de ontvangstdienst en echt bezorgbewijs, of staat als niet van toepassing genoteerd.
Heb je een ontvangstdienst voor formulieren toegevoegd? Gebruik de [OWASP-uitleg over serverinvoercontrole](https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html) voor passende inhouds- en lengtecontroles, naast spambeperking en foutafhandeling. Controleer echte bezorging opnieuw; browsercontrole is te omzeilen. Houd toegangsgegevens in de beveiligde instellingen van de ontvangstdienst.
**Deze actie geldt alleen als nodig**
1. De eerste versie gebruikt een e-maillink. Is er geen backend-formulier? Noteer dit onderdeel als niet van toepassing.
2. Eis voor een echt formulier inhouds- en lengtecontrole op de server, spambeperking, beschermde toegangsgegevens en bruikbare foutmeldingen. Browsercontrole is te omzeilen.
3. Gebruik een toegestane testbestemming om echte ontvangst, ongeldige invoer en bezorgfouten te controleren. Alleen een succesbericht op de website is onvoldoende.
**Dit zou je nu moeten zien:** Een formulier heeft maatregelen bij de ontvangstdienst en echt bezorgbewijs, of staat als niet van toepassing genoteerd.
6. Bewaar de gedateerde beoordeling. Volg met de [hoofdstukcontroles](#review-security-and-privacy-checks) herstellingen, openstaande bevindingen en resterende beslissingen.
**Bewaar het beoordelingsverslag**
Voorbeeld ter illustratie: Geïllustreerd voorbeeld: Reikwijdte → Bewijs → Openstaande problemen → Volgende actie. Kooka wijst de actie aan.
- **Verslaginhoud:** Reikwijdte → Bewijs → Openstaande problemen → Volgende actie
**Let op:** Het verslag legt vast wat is gecontroleerd en wat nog openstaat.
Bewaar het gedateerde verslag en beoordeel de [succescontroles voor beveiliging en privacy](#review-security-and-privacy-checks). Herstel openstaande problemen met grote impact vóór publicatie, noem een eigenaar voor overige beslissingen en beoordeel waar nodig persoonsgegevensinformatie met de [EU-uitleg](https://commission.europa.eu/law/law-topic/data-protection/information-business-and-organisations/obligations_en).
**Maak het resultaat beoordeelbaar**
1. Bewaar een gedateerd verslag met reikwijdte, methoden, bewijs, bevindingen, herstellingen en onbeschikbare of onbevestigde gebieden.
2. Herstel openstaande problemen met grote impact vóór publicatie. Noem een eigenaar voor overige beslissingen en bewaar bewijs van controles na herstel.
3. Controleer persoonsgegevensinformatie waar nodig. Vermijd absolute claims zoals ‘volledig veilig’ of ‘wettelijk conform’ op basis van deze beoordeling.
**Dit zou je nu moeten zien:** Het verslag legt vast wat is gecontroleerd en wat nog openstaat.
De basis uitgelegd
**Afhankelijk pakket (dependency)**
Software waarop je project steunt, zoals Astro of een testbibliotheek. Fouten en kwetsbaarheden daarin kunnen je project raken.
**Geheim vervangen (rotation)**
Een toegangsbewijs vervangen en het oude uitschakelen, zodat een gekopieerde of gelekte oude waarde geen toegang meer geeft.
**Invoercontrole op de server**
Ingezonden gegevens bij de ontvangstdienst controleren voordat die ze accepteert. Browsercontroles zijn nuttig, maar kunnen worden overgeslagen.
### Prompt: Maak een afgebakend beveiligingsverslag
```text
Gebruik website-security om de echte Fieldnotes Studio-bouw te controleren. Maak een overzicht van functies, pakketten, externe diensten en stromen van persoonsgegevens. Bekijk gevolgde bestanden, relevante Git-geschiedenis en dist op geheimen zonder waarden te tonen. Voer npm audit uit en leg relevante bevindingen uit. Controleer bij een backend-formulier serverinvoercontrole, misbruikbeperking, toegangsgegevens en foutafhandeling. Schrijf een gedateerd verslag met bewijs, ernst, herstellingen en onbevestigde gebieden. Pas veilige herstellingen binnen de taak toe en voer controles opnieuw uit. Claim geen volledige beveiliging of wettelijke naleving.
```
### Meld bekende pakketkwetsbaarheden zonder pakketten te wijzigen
```sh
npm audit
```
### Controleer je werk
- [ ] Het verslag noemt onderzochte onderdelen, resultaten, openstaande bevindingen en gebieden die meer kennis of informatie vereisen.
- [ ] Gepubliceerde uitvoer en gevolgde bestanden bevatten geen toegangsgegevens; gevonden gelekte gegevens zijn uitgeschakeld of vervangen.
- [ ] Pakketbevindingen hebben vastgelegde herstellingen of beoordeeld resterend risico, met geslaagde controles na wijzigingen.
- [ ] De privacytekst beschrijft echt gegevensgebruik en aanbieders. Optionele formulieren hebben servermaatregelen én bezorgbewijs.
Als er iets misgaat
**Codex meldt gelekte toegangsgegevens.**
Schakel ze uit of vervang ze bij de aanbieder, verwijder daarna de blootstelling en bekijk hun gebruik. Vraag Codex om een afgebakend opruimplan; plak de gegevens niet in de chat.
**npm audit biedt een geforceerde update die de site kan breken.**
Vraag de waarschuwing en een passend herstelplan op. Test de wijziging op een branch en noteer openstaande problemen voordat je beslist of publicatie verantwoord is.
### Officiële links & verder lezen
- [npm: auditcommando’s en beperkingen](https://docs.npmjs.com/cli/v11/commands/npm-audit/)
- [OWASP: geheimen beheren](https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html)
- [OWASP: invoer controleren](https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html)
- [Europese Commissie: verwerking van persoonsgegevens uitleggen](https://commission.europa.eu/law/law-topic/data-protection/information-business-and-organisations/obligations_en)
## 17. Maak de site sneller en duidelijker
Fase: Bouwen en controleren
Verbeter laden, paginatitels en de laatste details. Controleer het resultaat na elke wijziging opnieuw.
Grote beelden en onnodige scripts kunnen een eenvoudige website traag maken. Astro biedt beeldgereedschap, maar Codex moet nog geschikte afmetingen, laadgedrag en beschrijvingen voor elk beeld kiezen.
Zoekmachineoptimalisatie helpt zoeksystemen bruikbare pagina’s begrijpen. Duidelijke titels, beschrijvende links en juiste inhoud zijn een goed begin. Een technische checklist belooft geen posities of bezoekers. Lighthouse geeft metingen onder testomstandigheden en suggesties; de score kan per testomgeving verschillen.
### Doe dit
1. Open de gebouwde preview in Chrome. Voer een mobiele [Lighthouse-controle](https://developer.chrome.com/docs/lighthouse/overview/) uit en bewaar het verslag.
**Voer een paginacontrole uit**
Voorbeeld ter illustratie: Geïllustreerd voorbeeld: Inspect → Lighthouse → Mobile → Controle uitvoeren. Kooka wijst de actie aan.
- **In Chrome:** Inspect → Lighthouse → Mobile → Controle uitvoeren
**Let op:** Je hebt een verslag voor de nieuwste gebouwde pagina, met vastgelegde testomstandigheden.
Bouw de nieuwste versie en start de productiepreview. Volg de [Chrome Lighthouse-instructies](https://developer.chrome.com/docs/lighthouse/overview/) om Developer Tools te openen, Lighthouse te kiezen en een mobiele controle uit te voeren. Bewaar het verslag en noteer de geteste pagina en omstandigheden.
**Controleer de versie die je wilt publiceren**
1. Vraag Codex om een nieuwe build en productiepreview en open het gemelde adres in Chrome.
2. Klik met rechts op de pagina en kies Inspect om [Developer Tools te openen](https://developer.chrome.com/docs/devtools/open). Kies Lighthouse, selecteer Mobile en voer de laadcontrole uit; knopnamen kunnen verschillen.
3. Bewaar het verslag of noteer de bevindingen. Noteer pagina en omstandigheden zodat latere vergelijkingen nuttig zijn.
**Dit zou je nu moeten zien:** Je hebt een verslag voor de nieuwste gebouwde pagina, met vastgelegde testomstandigheden.
2. Geef Codex het verslag en de [verfijningsprompt](#polish-speed-and-search-prompts). Vraag de drie nuttigste verbeteringen.
**Kies wat je herstelt**
Voorbeeld ter illustratie: Geïllustreerd voorbeeld: Verslag delen → Prioriteiten vragen → Plan beoordelen. Kooka wijst de actie aan.
- **In Codex:** Verslag delen → Prioriteiten vragen → Plan beoordelen
**Let op:** De volgende herstellingen bieden duidelijke voordelen voor bezoekers.
Gebruik de [bezoekersgerichte verfijningsprompt](#polish-speed-and-search-prompts) om Codex de grootste praktische problemen in gewone taal te laten uitleggen. Geef trage hoofdbeelden, onnodige browserscripts, ontoegankelijke tekst en verspringende inhoud voorrang boven kleine scoreveranderingen.
**Kies nuttige verbeteringen**
1. Geef Codex het opgeslagen verslag of de belangrijkste bevindingen. Gebruik de gekoppelde prompt met je huidige preview en goedgekeurde ontwerp.
2. Vraag drie praktische prioriteiten in gewone taal: bijvoorbeeld een traag hoofdbeeld, onnodige browsercode, onleesbare tekst of inhoud die tijdens laden beweegt.
3. Spreek gerichte herstellingen af. Lighthouse meet onder testomstandigheden en de score kan verschillen; behandel één score niet als garantie en verander het ontwerp niet alleen om de score te verhogen.
**Dit zou je nu moeten zien:** De volgende herstellingen bieden duidelijke voordelen voor bezoekers.
3. Laat Codex beelden optimaliseren met [Astro’s beeldgereedschap](https://docs.astro.build/en/guides/images/). Vergelijk de pagina vóór en na de wijziging.
**Verbeter de beelden**
Voorbeeld ter illustratie: Geïllustreerd voorbeeld: Origineel beeld → Geoptimaliseerd bestand → Pagina bekijken. Kooka wijst de actie aan.
- **Vergelijk:** Origineel beeld → Geoptimaliseerd bestand → Pagina bekijken
**Let op:** Beelden laden passend en behouden hun bedoelde onderwerp en ruimte.
Laat Codex [Astro’s beeldgereedschap](https://docs.astro.build/en/guides/images/) gebruiken voor geschikte groottes en formaten, gereserveerde beeldruimte en geen onnodige vertraging van het eerste belangrijke beeld. Vergelijk de pagina vóór en na de wijziging.
**Houd beeldkwaliteit en indeling in beeld**
1. Laat Codex geschikte beeldgroottes en formaten kiezen voor de plek waar elk beeld wordt getoond.
2. Reserveer ruimte zodat de indeling niet verspringt. Vertraag het eerste belangrijke beeld niet onnodig.
3. Bekijk het resultaat op telefoon- en desktopformaat. Vergelijk laadbewijs en uiterlijk en herhaal betrokken controles.
**Dit zou je nu moeten zien:** Beelden laden passend en behouden hun bedoelde onderwerp en ruimte.
4. Gebruik de [SEO-gids](https://developers.google.com/search/docs/fundamentals/seo-starter-guide) voor een juiste titel, beschrijving en koppen op elke pagina.
**Geef elke pagina een duidelijke titel**
Voorbeeld ter illustratie: Geïllustreerd voorbeeld: Juiste titel → Bruikbare beschrijving → Duidelijke koppen. Kooka wijst de actie aan.
- **Voor elke pagina:** Juiste titel → Bruikbare beschrijving → Duidelijke koppen
**Let op:** Pagina-informatie past bij de echte inhoud.
Gebruik de [Google SEO-beginnersgids](https://developers.google.com/search/docs/fundamentals/seo-starter-guide) om elke pagina een eigen juiste titel en beschrijving te geven. Vergelijk koppen, beschrijvende links, beeldbeschrijvingen en deelinformatie met de echte inhoud.
**Help mensen en zoekmachines pagina’s begrijpen**
1. Laat Codex Home, About, Services en Contact beoordelen. Elk krijgt een eigen titel en juiste beschrijving.
2. Vergelijk kopvolgorde, beschrijvende links, betekenisvolle beeldbeschrijvingen en deelinformatie met de echte inhoud.
3. Lees de woorden zelf. Technische SEO helpt begrip, maar belooft geen posities of bezoekersaantallen.
**Dit zou je nu moeten zien:** Pagina-informatie past bij de echte inhoud.
5. Zodra je het openbare adres kent, laat Codex het gebruiken in de [sitemap en canonieke URL’s](https://developers.google.com/search/docs/fundamentals/seo-starter-guide).
**Gebruik het echte openbare adres**
Voorbeeld ter illustratie: Geïllustreerd voorbeeld: Je openbare adres → Pagina-URL’s → Sitemap. Kooka wijst de actie aan.
- **Zodra bekend:** Je openbare adres → Pagina-URL’s → Sitemap
**Let op:** Openbare pagina-adressen gebruiken het gekozen domein of blijven een expliciete taak totdat dat bekend is.
Laat Codex sitemap en canonieke URL’s voorbereiden met het bedoelde openbare adres zodra dat bekend is, volgens de [uitleg over zoekvindbaarheid](https://developers.google.com/search/docs/fundamentals/seo-starter-guide). Houd onafgemaakte of privéconcepten uit openbare uitvoer; uitsluiting van zoekmachines beschermt geen toegang.
**Verzin het definitieve adres niet**
1. Geef Codex het bedoelde openbare websiteadres zodra het bevestigd is. Is het onbekend? Houd dit als vastgelegde publicatietaak.
2. Laat sitemap en canonieke URL’s op dat adres instellen. Zoek naar localhost, verzonnen domeinen en oude adressen.
3. Houd privé- of onafgemaakte inhoud uit gepubliceerde uitvoer. Uitsluiting van zoekmachines beschermt geen toegang.
**Dit zou je nu moeten zien:** Openbare pagina-adressen gebruiken het gekozen domein of blijven een expliciete taak totdat dat bekend is.
6. Doorloop nogmaals de [bezoekerschecklist](#test-as-a-visitor-checks). Herstel laatste problemen en bewaar de gecontroleerde mijlpaal.
**Beoordeel de afgeronde pagina’s**
Voorbeeld ter illustratie: Geïllustreerd voorbeeld: Vier pagina’s controleren → Details herstellen → Controles herhalen → Opslaan. Kooka wijst de actie aan.
- **Laatste ronde:** Vier pagina’s controleren → Details herstellen → Controles herhalen → Opslaan
**Let op:** De verfijnde site slaagt nog voor de bezoekerscontroles en heeft een bewaarde mijlpaal.
Gebruik de [bezoekerschecklist](#test-as-a-visitor-checks) voor Home, About, Services en Contact op telefoon- en desktopbreedte. Verwijder voorbeeldtekst, controleer bedrijfsgegevens en beeldrechten, herhaal betrokken controles en bewaar de verfijnde mijlpaal.
**Rond de praktische details af**
1. Bekijk alle vier de pagina’s op telefoon- en desktopbreedte. Verwijder voorbeeldtekst, controleer bedrijfsgegevens en bevestig beeldrechten.
2. Let op vervormde beelden, afgesneden inhoud, onleesbare knoppen en onverwacht zijwaarts scrollen.
3. Laat Codex de controles herhalen die door de verfijning worden geraakt. Bekijk de nieuwste gebouwde preview en bewaar de gecontroleerde versie in Git.
**Dit zou je nu moeten zien:** De verfijnde site slaagt nog voor de bezoekerscontroles en heeft een bewaarde mijlpaal.
De basis uitgelegd
**SEO**
Zoekmachineoptimalisatie: bruikbare inhoud en paginastructuur makkelijker vindbaar en begrijpelijk maken voor zoekmachines.
**Canonieke URL**
Het openbare voorkeursadres van een pagina, waarmee je duidelijk maakt welke versie de inhoud vertegenwoordigt.
**Verspringende indeling (layout shift)**
Inhoud die onverwacht beweegt tijdens het laden, bijvoorbeeld als een beeld verschijnt zonder dat er ruimte voor was gereserveerd.
### Prompt: Herstel wat voor bezoekers telt
```text
Beoordeel de nieuwste Fieldnotes Studio-productiepreview en dit Lighthouse-verslag. Leg de drie nuttigste verbeteringen voor bezoekers uit en pas gerichte herstellingen toe voor beeldladen, onnodige JavaScript, stabiele indeling en leesbare inhoud. Controleer per pagina titel, beschrijving, koppen, links en deelinformatie. Bereid sitemap- en canonieke instellingen voor met de openbare URL die ik geef; markeer een onbekend adres in plaats van er een te verzinnen. Herhaal relevante controles en vergelijk bewijs. Behoud de goedgekeurde visuele richting en meld resterende beperkingen.
```
### Controleer je werk
- [ ] De nieuwste gebouwde preview heeft een bewaard Lighthouse-verslag met concrete verbeteringen of uitgelegde resterende bevindingen.
- [ ] Elke pagina heeft een juiste titel en beschrijving; canonieke en sitemapadressen bevatten geen verzonnen domein of localhost-adres.
- [ ] De beoordeelde indelingen bevatten geen onafgemaakte voorbeeldtekst, vervormde beelden, onleesbare knoppen of onverwacht horizontaal scrollen.
- [ ] Bestaande bezoekersroutecontroles slagen nog na optimalisatie.
Als er iets misgaat
**De preview toont nog oude inhoud.**
Stop de preview, maak een nieuwe build en start de preview opnieuw. Die toont de laatst gegenereerde uitvoer, terwijl de ontwikkelserver tijdens bewerken bijwerkt.
**Een prestatiescore verandert tussen metingen.**
Vergelijk tests onder vergelijkbare omstandigheden en bekijk de concrete gemelde problemen. Gebruik herhaalde metingen om een betekenisvolle wijziging te beoordelen in plaats van één score als garantie te zien.
### Officiële links & verder lezen
- [Chrome: Lighthouse-controles uitvoeren](https://developer.chrome.com/docs/lighthouse/overview/)
- [Astro: beelden verwerken en optimaliseren](https://docs.astro.build/en/guides/images/)
- [Google: SEO-beginnersgids](https://developers.google.com/search/docs/fundamentals/seo-starter-guide)
## 18. Beoordeel de site en stel automatische controles in
Fase: Publiceren en onderhouden
Laat opnieuw beoordelen, herstel problemen en laat GitHub controles herhalen wanneer je code verandert.
Een pull request vergelijkt een voorgestelde wijziging met de bewaarde hoofdversie. Je beoordeelt die voordat je de versies samenvoegt.
GitHub Actions voert afgesproken controles automatisch uit. Een geslaagde uitvoering is nuttig bewijs, maar jij beslist of de site klaar is.
### Doe dit
1. Kopieer de [beoordelingsprompt](#review-and-automate-checks-prompts) naar een nieuwe Codex-chat. Laat wijzigingen vergelijken met je [projecteisen](#implementation-plan).
**Vraag een nieuwe beoordeling**
Voorbeeld ter illustratie: Illustratie: open een nieuwe Codex-chat, verstuur de beoordelingsprompt en vergelijk het verslag met de projecteisen.
- **In Codex:** New chat → Beoordelingsprompt plakken → Verslag lezen
- **Daarna:** Vergelijk eisen en gewijzigde bestanden.
**Let op:** Een apart beoordelingsverslag met bevindingen die je kunt controleren.
Gebruik een nieuw gesprek, zodat de beoordeling begint met het bekijken van het werk.
**Toon de beoordelingsstappen**
1. Open een nieuwe chat in hetzelfde Codex-project. Kopieer Vraag een nieuwe beoordeling uit de prompts en verstuur die met de branchnaam, je brief en het testverslag.
2. Laat de beoordelaar gewijzigde bestanden bekijken en vermoedelijke problemen reproduceren. Vergelijk het resultaat met je acceptatiecriteria uit hoofdstuk 12.
3. Een aparte AI-chat blijft een AI-beoordeling. Regel passende menselijke beoordeling voor werk dat je niet kunt beoordelen, vooral bij accounts, betalingen of persoonsgegevens.
**Dit zou je nu moeten zien:** Een verslag dat bevestigde fouten, vragen en beperkingen onderscheidt. De beoordelaar wijzigt geen bestanden en voegt de branch niet samen.
2. Herstel bevestigde problemen en herhaal betrokken [bezoekerscontroles](#test-as-a-visitor-checks). Houd resterende bevindingen in je beoordelingsnotitie.
**Herstel en controleer opnieuw**
Voorbeeld ter illustratie: Illustratie: een gemeld probleem leidt tot een kleine herstelling en herhaling van betrokken bezoekerstests.
- **Werkcyclus:** Probleem bevestigen → Herstellen → Betrokken controles herhalen
**Let op:** Bevestigde fouten hebben herstellingen en nieuwe resultaten. Openstaande bevindingen blijven zichtbaar.
Een bevinding is nuttig als je kunt laten zien wat misgaat en het herstel kunt controleren.
**Werk de bevindingen af**
1. Laat Codex elke gemelde fout reproduceren vóór het wijzigen. Herstel één duidelijk probleem tegelijk.
2. Herhaal betrokken tests en belangrijke bezoekersroutes uit hoofdstuk 15. Noteer wat is gecontroleerd en het resultaat.
3. Houd onbeantwoorde vragen in de publicatienotitie. Blijft een ernstig probleem open? Houd de publicatie als concept.
**Dit zou je nu moeten zien:** Bevestigde fouten die publicatie blokkeren zijn hersteld met nieuw controlebewijs. Openstaande bevindingen blijven genoteerd.
3. Gebruik de [workflowprompt](#review-and-automate-checks-prompt-2) voor [automatische GitHub-controles](https://docs.github.com/en/actions/tutorials/build-and-test-code/nodejs). Gebruik commando’s die al op je computer werken.
**Bewaar de automatische controles**
Voorbeeld ter illustratie: Illustratie: Codex maakt quality.yml met projectcommando’s die lokaal al werken.
- **In het project:** .github → workflows → quality.yml
- **Vraag Codex:** Gebruik de gecontroleerde installatie-, codecontrole- en bouwcommando’s.
**Let op:** Een workflowbestand dat echte projectcontroles herhaalt zonder de site te publiceren.
Een workflow is een opgeslagen lijst commando’s die GitHub uitvoert.
**Maak werkende controles herhaalbaar**
1. Kopieer [Maak de gecontroleerde tests herhaalbaar](#review-and-automate-checks-prompt-2). Laat Codex package.json, de opgeslagen lockfile en de ondersteunde Node-versie bekijken.
2. Vraag om .github/workflows/quality.yml voor pushes en pull requests. Gebruik npm ci en de echte controle- en bouwcommando’s die lokaal al zijn getest.
3. Gebruik huidige officiële GitHub-actions en minimale leesrechten. Deze statische website heeft geen OpenAI API-sleutel in de workflow nodig. Voeg geen automatische publicatie toe.
**Dit zou je nu moeten zien:** De bewaarde workflow gebruikt echte projectcommando’s, de bedoelde Node-versie en geen onnodige toegangsgegevens.
4. Neem [Playwright-browsertests](https://playwright.dev/docs/ci) op en verslagen die fouten begrijpelijk maken.
**Neem de browsertests op**
Voorbeeld ter illustratie: Illustratie: installeer testbrowsers, voer websitetests uit en bewaar een verslag bij een mislukte controle.
- **Workflow:** Browsers installeren → Testsite starten → Tests uitvoeren → Verslagen bewaren
**Let op:** De workflow kan de bedoelde browsertests uitvoeren en bruikbaar foutbewijs bewaren.
Browsertests hebben eigen browsers en een website om te bezoeken nodig.
**Bereid de browsertesttaak voor**
1. Volg Playwrights huidige CI-instructies om browsers en benodigde systeempakketten te installeren.
2. Laat Codex de werkende projecttestinstellingen gebruiken om de lokale testsite te starten en de bedoelde browsercontroles uit te voeren.
3. Bewaar foutverslagen, logboeken en bruikbare screenshots. Die helpen een mislukte controle onderzoeken zonder te gokken.
**Dit zou je nu moeten zien:** Browsertests kunnen op GitHub draaien en bewaren bruikbaar bewijs bij een mislukte controle.
5. Push je branch en [open een pull request](https://docs.github.com/en/pull-requests/how-tos/create-pull-requests/creating-a-pull-request). Lees de Actions-uitvoering voor de nieuwste wijziging.
**Open een pull request**
Voorbeeld ter illustratie: Illustratie: maak een GitHub-pull request, open Actions en lees de logboeken voor de nieuwste commit.
- **Op GitHub:** Je branch → Compare & pull request → Create Pull Request
- **Lees de controles:** Actions → Nieuwste uitvoering → Logboek van de taak
**Let op:** Een pull request en afgeronde controle voor de nieuwste commit.
Een pull request houdt voorgestelde wijzigingen samen ter beoordeling.
**Vind de pull request en resultaten**
1. Bewaar je branchwijzigingen als commits en push die branch naar je GitHub-repository.
2. Kies op GitHub de branch en Compare & pull request. Controleer of base je hoofdbranch is en compare je werkbranch; kies daarna Create Pull Request.
3. Open het Actions-tabblad van de repository en bekijk de nieuwste uitvoering. Lees het logboek van mislukte taken. Controleer of de uitvoering bij de nieuwste pull-requestcommit hoort en niet bij een oudere versie.
**Dit zou je nu moeten zien:** De pull request toont afgeronde controleresultaten voor de wijziging die je werkelijk beoordeelt.
6. Bekijk [Actions-gebruik](https://docs.github.com/en/billing/concepts/product-billing/github-actions) en beoordeel resultaten. Voeg pas samen als relevante controles slagen en jij de wijziging goedkeurt.
**Beoordeel vóór samenvoegen**
Voorbeeld ter illustratie: Illustratie: bekijk het beoordelingsverslag en controleresultaten voordat je kiest of je de wijziging samenvoegt.
- **Beslissing:** Bevindingen lezen → Nieuwste resultaten controleren → Goedkeuren of verderwerken
**Let op:** Je keurt alleen een beoordeelde wijziging goed waarvan relevante controles slagen.
Groene controles helpen je beslissing; ze beslissen niet voor je.
**Beslis of je samenvoegt**
1. Bekijk GitHub Actions-gebruik en eventuele accountkosten. Je hebt geen API-toegang nodig voor controles van deze statische site.
2. Lees het aparte beoordelingsverslag en de nieuwste bouw- en browserresultaten. Los ernstige bevindingen op vóór goedkeuring.
3. Voeg alleen samen als je het beoordeelde resultaat goedkeurt. In deze gids upload je later handmatig naar hosting; deze workflow publiceert de website niet. Voeg je later automatische hosting toe? Controleer vóór samenvoegen wat publicatie start.
**Dit zou je nu moeten zien:** De hoofdversie bevat alleen de wijziging die je na geslaagde relevante controles goedkeurde.
De basis uitgelegd
**Diff**
Een vergelijking die laat zien wat tussen twee bestandsversies is toegevoegd, gewijzigd en verwijderd.
**CI**
Continuous integration: afgesproken controles automatisch uitvoeren bij codewijzigingen, zodat fouten vóór publicatie worden ontdekt.
**Lockfile**
Een bestand met pakketversies. npm ci gebruikt het voor dezelfde installatie en stopt als het niet overeenkomt met package.json.
**Workflow**
Een opgeslagen reeks taken en commando’s die start bij gebeurtenissen zoals een push of pull request.
### Prompt: Vraag een nieuwe beoordeling
```text
Beoordeel de wijzigingen op de Fieldnotes Studio-branch tegenover onze brief en acceptatiecriteria. Bekijk zelfstandig functionaliteit, toegankelijkheid, geheimen, pakketten en testdekking. Reproduceer vermoedelijke fouten en noem betrokken bestanden. Onderscheid bevestigde problemen van vragen en beperkingen. Meld bevindingen zonder bestanden te wijzigen of de branch samen te voegen.
```
### Prompt: Maak de gecontroleerde tests herhaalbaar
```text
Bekijk package.json, de lockfile, Node-eisen en onze werkende browsertestinstellingen. Maak .github/workflows/quality.yml voor push en pull_request met huidige officiële GitHub Actions, minimale leesrechten, npm ci en de echte gecontroleerde codecontrole-, bouw- en browsertestcommando’s. Stel benodigde Playwright-browserinstallatie en foutbestanden in. Deze statische site heeft geen OpenAI API-sleutel nodig. Leg elke taak uit en hoe ik de resultaten op GitHub bekijk. Voeg geen automatische websitepublicatie toe.
```
### Controleer je werk
- [ ] Er is een apart beoordelingsverslag en bevestigde fouten die publicatie blokkeren zijn hersteld met controlebewijs.
- [ ] De pull request toont een afgeronde Actions-uitvoering voor de nieuwste commit, inclusief bedoelde bouw- en browsercontroles.
- [ ] De workflow bevat echte projectcommando’s, passende Node-instellingen en geen leesbare toegangsgegevens of onnodige API-toegang.
Als er iets misgaat
**De workflow meldt dat een script ontbreekt.**
Vergelijk het foutieve commando met package.json. Laat Codex de workflow herstellen of het bedoelde script expliciet lokaal instellen en controleren vóór opnieuw uitvoeren.
**Tests werken lokaal maar mislukken op GitHub.**
Lees het logboek van de mislukte taak en bewaard browserbewijs. Controleer Node-compatibiliteit, browserinstallatie, serverstart, hoofdlettergevoelige paden en overeenstemming met de lockfile.
### Officiële links & verder lezen
- [GitHub: wijzigingen voorstellen met pull requests](https://docs.github.com/en/pull-requests/reference/pull-requests)
- [GitHub Actions: Node.js bouwen en testen](https://docs.github.com/en/actions/tutorials/build-and-test-code/nodejs)
- [Playwright: automatische integratiecontroles](https://playwright.dev/docs/ci)
- [GitHub: Actions-facturering en gebruik](https://docs.github.com/en/billing/concepts/product-billing/github-actions)
## 19. Publiceer je site en controleer hem online
Fase: Publiceren en onderhouden
Publiceer pas na je beoordeling. Controleer daarna het echte webadres en oefen teruggaan naar een oudere versie.
Hosting zet een gebouwde kopie van je website online. Deze gids gebruikt Netlify en handmatig uploaden; dit concept lezen publiceert niets.
Een geüpload adres kan openbaar of privé zijn, afhankelijk van accountinstellingen. Controleer die vóór uploaden of delen.
### Doe dit
1. Maak een account of meld je aan bij [Netlify](https://app.netlify.com/). Lees [abonnementen en gebruiksvoorwaarden](https://www.netlify.com/pricing/) en stel [tweestapsverificatie](https://docs.netlify.com/manage/accounts-and-billing/user-settings/#enable-two-factor-authentication-2fa) in.
**Bereid het hostingaccount voor**
Voorbeeld ter illustratie: Illustratie: meld je aan bij Netlify, lees het abonnement en zet tweestapsverificatie aan.
- **Account:** Sign in → Abonnement bekijken → User settings → Security → Two-factor authentication
**Let op:** Je kunt bij het bedoelde hostingaccount en begrijpt de gebruiksvoorwaarden.
Hosting heeft een eigen account, kosten en herstelinformatie.
**Bereid je account voor**
1. Maak of open het Netlify-account dat je wilt behouden. Lees het huidige abonnement en de gebruiksvoorwaarden in plaats van aan te nemen dat elke functie gratis is.
2. Open in User settings Security en daarna Two-factor authentication. Volg de instelling met je authenticator-app.
3. Bewaar herstelcodes op een beschermde plek, zoals je wachtwoordmanager, apart van websitebestanden. Controleer of je ze kunt vinden.
**Dit zou je nu moeten zien:** Je hostingaccount is bereikbaar, beschermd en herstelbaar.
2. Kopieer de [publicatievoorbereidingsprompt](#publish-and-verify-prompts). Beoordeel de gebouwde website en controleresultaten vóór goedkeuring van publicatie.
**Beoordeel eerst de publicatie**
Voorbeeld ter illustratie: Illustratie: controleer de lokaal gebouwde site en het testverslag vóór toestemming voor uploaden.
- **In Codex:** Publicatieprompt kopiëren → Bouwen → Preview → Resultaten beoordelen
- **Beslissing:** Keur deze versie goed vóór uploaden.
**Let op:** Een beoordeelde build, controleverslag en vastgelegde versie, klaar voor jouw beslissing.
Keur de bestanden die worden geüpload goed, niet alleen de broncode.
**Bereid alles lokaal voor**
1. Kopieer de publicatievoorbereidingsprompt. Laat Codex de publicatie lokaal voorbereiden en wachten op jouw expliciete opdracht vóór uploaden of DNS wijzigen.
2. Maak een nieuwe build van de beoordeelde commit, open de productiepreview en herhaal belangrijke controles. Laat Codex de echte uitvoermap noemen; bij dit statische Astro-voorbeeld is dat meestal dist.
3. Bekijk die map op onafgemaakte privé-inhoud, toegangsgegevens en onbedoelde bronbestanden. Bewaar de beoordeelde commit, gebouwde uitvoer en het controleverslag voordat je over publicatie beslist.
**Dit zou je nu moeten zien:** Een beoordeeld publicatiepakket en controleverslag. Deze voorbereiding publiceert niets.
3. Na jouw goedkeuring upload je de gebouwde map met [Netlify Drop](https://app.netlify.com/drop). Controleer [projectzichtbaarheid](https://docs.netlify.com/manage/security/secure-access-to-sites/project-visibility/) vóór delen.
**Upload de goedgekeurde website**
Voorbeeld ter illustratie: Illustratie: de goedgekeurde dist-map gaat naar Netlify Drop; daarna controleer je wie de site kan openen.
- **Upload:** Aangemeld bij Netlify Drop → Goedgekeurde gebouwde map
- **Controleer toegang:** Project configuration → General → Visitor access → Project visibility
**Let op:** De goedgekeurde website is geüpload en je weet wie het adres kan openen.
Uploaden is een echte publicatiestap. Controleer eerst de toegangsinstellingen.
**Upload de juiste map**
1. Controleer de standaardzichtbaarheid van het team vóór uploaden. Nieuwe teams met een tegoedabonnement kunnen standaard privé zijn; oudere teams kunnen openbaar zijn. Kun je privétoegang niet bevestigen? Behandel de upload als mogelijk openbaar.
2. Meld je pas na jouw goedkeuring aan bij het bedoelde Netlify-team en open Netlify Drop. Upload de gebouwde uitvoermap, bijvoorbeeld dist, met de gegenereerde websitebestanden.
3. Bekijk Project configuration → General → Visitor access → Project visibility. Open het toegewezen adres in een privébrowservenster om te zien wat een bezoeker zonder jouw aanmelding kan openen. Upload niet de hele repository of toegangsgegevens.
**Dit zou je nu moeten zien:** Een publicatie van goedgekeurde gebouwde bestanden, met bevestigde echte zichtbaarheid.
4. Houd het aangeboden adres of volg optioneel de [domeininstructies](https://docs.netlify.com/manage/domains/get-started-with-domains/). Behoud bestaande e-mailrecords en controleer [HTTPS](https://docs.netlify.com/manage/domains/secure-domains-with-https/https-ssl/).
**Kies je webadres**
Voorbeeld ter illustratie: Illustratie: kies het aangeboden netlify.app-adres of een optioneel eigen domein en behoud e-mailrecords.
- **Houd het eenvoudig:** Gebruik het aangeboden netlify.app-adres.
- **Optioneel:** Eigen domein toevoegen → DNS instellen → HTTPS controleren
**Let op:** Het gekozen adres werkt via HTTPS; bestaande e-mailinstellingen zijn behouden.
Een eigen domein is optioneel. Je kunt het aangeboden adres houden.
**Kies het adres zonder e-mail te verstoren**
1. Heb je een domein dat je wilt gebruiken? Voeg het toe aan het Netlify-project en volg de instructies voor je DNS-aanbieder. Controleer vóór wijzigingen welke records zakelijke e-mail verzorgen.
2. Behoud e-mailrecords en volg de HTTPS-controle. Wacht de genoemde DNS-verwerkingstijd af; verander records niet steeds tijdens het wachten.
3. Gebruik het definitieve adres in canonieke en sitemapinstellingen. Bouw en controleer opnieuw en upload de bijgewerkte gebouwde map via Deploys van het bestaande project.
**Dit zou je nu moeten zien:** Het gekozen HTTPS-adres staat in site-instellingen en gebouwde bestanden; e-mailrecords zijn behouden.
5. Na jouw goedkeuring voor openbare toegang herhaal je de [livecontroles](#publish-and-verify-checks) op het definitieve HTTPS-adres. Noteer versie en resultaten.
**Test de openbare website**
Voorbeeld ter illustratie: Illustratie: keur zo nodig openbare toegang goed, open de website en test pagina’s en de Contact-actie.
- **Als nog privé:** Opnieuw beoordelen → Make public
- **Daarna:** Definitief HTTPS-adres openen → Alle pagina’s en Contact testen → Publicatie vastleggen
**Let op:** De echte openbare website doorstaat de uitgevoerde bezoekerscontroles en de resultaten zijn vastgelegd.
Een lokale controle toont niet alle verschillen door hosting.
**Controleer de echte openbare versie**
1. Is de goedgekeurde site nog privé? Gebruik Make public als je klaar bent. Is hij al openbaar? Begin direct met livecontroles.
2. Open het definitieve HTTPS-adres in een privébrowservenster. Voer elk pagina-adres rechtstreeks in. Controleer navigatie, ontbrekende pagina’s, beelden, telefoonindeling en de Contact-e-maillink. Heb je een formulier? Bevestig ontvangst van een nieuw testbericht.
3. Noteer openbaar adres, commit, publicatiecode, datum en resultaten. Controleer of canonieke URL’s en sitemap het definitieve adres gebruiken.
**Dit zou je nu moeten zien:** Een publicatieregistratie verbindt de livewebsite met de geüploade versie en echte controleresultaten.
6. Maak een [testsite met twee versies](#publish-and-verify-prompt-2). Oefen [een eerdere publicatie terugzetten](https://docs.netlify.com/deploy/manage-deploys/manage-deploys-overview/#rollbacks) en herstel daarna de nieuwste versie.
**Oefen teruggaan**
Voorbeeld ter illustratie: Illustratie: kies op een testsite een eerdere geslaagde publicatie, publiceer die en herstel daarna de nieuwste geslaagde versie.
- **Bereid voor:** Versie 1 → Nieuw testproject → Versie 2 in hetzelfde project
- **Op een testsite:** Deploys → Eerdere geslaagde publicatie → Publish Deploy
- **Rond af:** Nieuwste geslaagde versie herstellen → Herstelstappen vastleggen
**Let op:** Je hebt herstel op een testsite geoefend en je eigen publicatiekopie bewaard.
Maak eerst een tijdelijk oefenproject met twee versies. Gebruik voor deze oefening het aparte adres.
**Maak de testsite met twee versies**
1. Verstuur de [oefensiteprompt](#publish-and-verify-prompt-2) naar Codex. Open elke gemaakte index.html en controleer of de ene versie 1 en de andere versie 2 toont.
2. Meld je aan bij je bedoelde Netlify-team. Sleep onderaan de [Projects-pagina](https://docs.netlify.com/deploy/create-deploys/#drag-and-drop) de map version-1 om een nieuw project te maken. Controleer of het adres verschilt van je echte site; koppel je domein niet.
3. Open Deploys van dat testproject. Sleep de map version-2 naar het uploadvlak. Dit werkt hetzelfde project bij. Controleer of twee geslaagde publicaties verschijnen en het testadres nu versie 2 toont.
**Probeer het terugzetten**
1. Open in Deploys van het testproject de eerdere geslaagde publicatie en kies [Publish Deploy](https://docs.netlify.com/deploy/manage-deploys/manage-deploys-overview/#rollbacks). Bezoek het testadres en controleer of het nu versie 1 toont.
2. Publiceer de nieuwste geslaagde versie opnieuw. Controleer of hetzelfde adres versie 2 toont. Noteer deze herstelstappen voor je echte website.
3. Bewaar een onafhankelijke kopie van de echte websitepublicatie. Hostingversies kunnen verlopen of verdwijnen; een latere automatische publicatie kan een teruggezette versie vervangen.
**Dit zou je nu moeten zien:** Vastgelegde herstelstappen, geoefend op een testsite, plus een onafhankelijke kopie van de bekende werkende versie.
De basis uitgelegd
**Publicatie (deployment)**
Een bepaalde gebouwde websiteversie bij de hostingdienst publiceren.
**DNS**
De records die het internet vertellen waar de website, e-mail en andere diensten van een domein staan.
**HTTPS**
Een versleutelde verbinding tussen browser en site met een certificaat. Die beschermt de verbinding, maar bewijst niet dat de hele website veilig is.
**Terugzetten (rollback)**
Een eerdere werkende versie herstellen als de nieuwste een probleem heeft.
### Prompt: Bereid de publicatie voor mijn beoordeling voor
```text
Maak een publicatiechecklist voor deze statische Fieldnotes Studio-site met Netlify’s huidige instructies voor handmatig uploaden. Bevestig de beoordeelde commit, echte uitvoermap, geslaagde controles en afwezigheid van geheimen of onafgemaakte privé-inhoud in de uitvoer. Leg uit hoe ik dist upload, het openbare adres bekijk, mijn domein instel zonder e-mail-DNS te beschadigen, HTTPS controleer en een bewaarde eerdere publicatie terugzet. Noteer onbekende instellingen als vragen. Bereid alles lokaal voor en wacht op mijn expliciete opdracht vóór publicatie of DNS-wijzigingen.
```
### Prompt: Bereid een tijdelijke terugzettest voor
```text
Maak lokaal een kleine oefensite voor terugzetten. Maak twee aparte mappen version-1 en version-2 in een nieuwe tijdelijke map rollback-practice. Elke map bevat een zelfstandige index.html: de eerste toont duidelijk ‘Terugzetten oefenen — versie 1’; de tweede ‘Terugzetten oefenen — versie 2’. Gebruik alleen deze woorden en eenvoudige vormgeving, zonder website-inhoud, toegangsgegevens, formulieren, tracking, externe diensten of pakketten. Overschrijf geen bestaande bestanden en verander de echte website niet. Houd deze oefenbestanden buiten Git-commits. Vertel precies waar beide mappen staan en hoe ik elke index.html open om de labels te controleren. Maak alleen de bestanden; upload niets, maak geen hostingproject en wijzig geen domein.
```
### Controleer je werk
- [ ] Het definitieve HTTPS-adres opent zonder certificaatwaarschuwing en alle vier de pagina’s werken wanneer hun adressen rechtstreeks worden ingevoerd.
- [ ] Livebezoekersroutes, telefoonnavigatie, beelden en Contact werken; optionele formulieren hebben een nieuw ontvangen testbericht.
- [ ] Canonieke URL’s en sitemap gebruiken het gekozen openbare adres en de publicatieregistratie noemt de geüploade versie.
- [ ] Herstelinstructies zijn vastgelegd en geoefend op een testsite; een onafhankelijke publicatiekopie is bewaard.
Als er iets misgaat
**De geüploade site is leeg of mist pagina’s.**
Controleer of je de nieuwste gegenereerde uitvoermap met gebouwde HTML uploadde. Bekijk de lokale productiepreview en het hostinglogboek voordat je opnieuw bouwt en de upload vervangt.
**Het domein werkt wisselend of HTTPS is nog niet klaar.**
Controleer domeinbevestiging en DNS met de huidige hostinginstructies. Behoud e-mailrecords, wacht de genoemde DNS-verwerkingstijd en gebruik de HTTPS-probleemhulp van de host in plaats van records steeds te veranderen.
### Officiële links & verder lezen
- [Netlify: handmatige publicaties maken](https://docs.netlify.com/deploy/create-deploys/#drag-and-drop)
- [Netlify: een domein toevoegen en instellen](https://docs.netlify.com/manage/domains/get-started-with-domains/)
- [Netlify: HTTPS-certificaten](https://docs.netlify.com/manage/domains/secure-domains-with-https/https-ssl/)
- [Netlify: publicaties beheren en terugzetten](https://docs.netlify.com/deploy/manage-deploys/manage-deploys-overview/)
- [Netlify: projectzichtbaarheid en openbare toegang](https://docs.netlify.com/manage/security/secure-access-to-sites/project-visibility/)
- [Netlify: tweestapsverificatie](https://docs.netlify.com/manage/accounts-and-billing/user-settings/#enable-two-factor-authentication-2fa)
## 20. Houd je site werkend
Fase: Publiceren en onderhouden
De website vraagt af en toe onderhoud. Houd accounts, backups en controles op orde en herhaal dit proces bij elke wijziging.
GitHub bewaart je codegeschiedenis. Andere zaken, zoals domeininstellingen, originele beelden en optionele formulierberichten, kunnen aparte registraties of backups nodig hebben.
Waarschuwingen helpen problemen vinden, maar je moet ze nog beoordelen en het herstel testen. Houd een werkende versie die je kunt terugzetten.
### Doe dit
1. Kopieer de [onderhoudsprompt](#maintain-and-improve-prompts). Noem de verantwoordelijke persoon voor de site en elk account.
**Schrijf op wie wat beheert**
Voorbeeld ter illustratie: Illustratie: een onderhoudsnotitie koppelt de website en accounts aan een genoemde eigenaar.
- **In Codex:** Onderhoudsprompt kopiëren → Accounts noemen → Eigenaren noemen
**Let op:** Een notitie met de eigenaar van site, repository, hosting, domein en contactinbox.
Een korte onderhoudsnotitie helpt het juiste account vinden als iets verandert.
**Maak de eigenaarsnotitie**
1. Kopieer de onderhoudsprompt. Vul in wie de website, repository, hostingaccount, het domein en de contactinbox beheert.
2. Noteer waar je instellingen en hulp vindt. Houd wachtwoorden en herstelgegevens in je beveiligde wachtwoordmanager, apart van openbare websitebestanden.
3. Neem publicatieregistraties en herstelinstructies op. Noteer onbekende gegevens als vragen voor de verantwoordelijke persoon.
**Dit zou je nu moeten zien:** Een onderhoudsnotitie met genoemde eigenaren en genoeg informatie om belangrijke instellingen te vinden.
2. Kies een vaste controledatum en herhaal de [livecontroles](#publish-and-verify-checks). Neem verlengingen en accountwaarschuwingen mee.
**Kies een controledatum**
Voorbeeld ter illustratie: Illustratie: kies een datum, open de website en controleer de Contact-actie.
- **Routine:** Controledatum kiezen → Site openen → Belangrijke pagina’s en Contact controleren
- **Ook:** Bekijk verlengingen, gebruik en accountwaarschuwingen.
**Let op:** Een haalbare routine met extra controles na publicatie of een gemeld probleem.
Kies een routine die je echt kunt volhouden.
**Maak een praktisch controleschema**
1. Kies hoe vaak je belangrijke pagina’s, telefoonnavigatie en Contact controleert. Voeg controles toe na elke publicatie en bij een gemeld probleem.
2. Noteer verlengdatums van domein en diensten, hostinggebruik en belangrijke accountwaarschuwingen. Bekijk inhoud en pakketten regelmatig.
3. Bewaar de nieuwste publicatieregistratie en echte livecontroleresultaten bij de onderhoudsnotitie. Pas het schema aan als de site ingewikkelder wordt.
**Dit zou je nu moeten zien:** Een realistisch controleschema in plaats van een takenlijst die niemand bijhoudt.
3. Zet [Dependabot-waarschuwingen](https://docs.github.com/en/code-security/how-tos/secure-your-supply-chain/secure-your-dependencies/configure-dependabot-alerts) aan op GitHub. Beoordeel elke waarschuwing vóór software-updates.
**Zet pakketwaarschuwingen aan**
Voorbeeld ter illustratie: Illustratie: open GitHub-instellingen, zet Dependabot-waarschuwingen aan en beoordeel meldingen vóór een update.
- **Op GitHub:** Repository → Settings → Advanced Security → Dependabot alerts → Enable
- **Bij elke waarschuwing:** Beoordelen → Update op een branch → Testen → Controleren
**Let op:** Relevante waarschuwingen staan aan en iemand is verantwoordelijk voor beoordeling.
Een dependency is ondersteunende software die je website gebruikt.
**Zet waarschuwingen aan en verwerk een update**
1. Open op GitHub Settings van de repository. Kies in Security and quality Advanced Security en daarna Enable naast Dependabot alerts.
2. Staan waarschuwingen al aan? Laat ze aan. Controleer wie meldingen krijgt en verantwoordelijk is voor beoordeling.
3. Laat Codex bij een nieuwe waarschuwing beoordelen of het betrokken pakket wordt gebruikt. Maak een gerichte update op een branch en voer bestaande controles uit. Beoordeel vóór het accepteren of publiceren van de update.
**Dit zou je nu moeten zien:** Relevante waarschuwingen staan aan; updates worden vóór publicatie beoordeeld en getest.
4. Maak een onafhankelijke [repositorybackup](https://docs.github.com/en/repositories/archiving-a-github-repository/backing-up-a-repository). Test herstellen en de website daaruit openen.
**Test je backup**
Voorbeeld ter illustratie: Illustratie: bewaar een onafhankelijke backup, herstel die in een nieuwe map en open de herstelde website.
- **Hersteloefening:** Onafhankelijke backup → Nieuwe projectmap → Opnieuw bouwen → Preview openen
**Let op:** Een werkende preview hersteld uit je onafhankelijke backup.
Een backup telt pas als je eruit kunt herstellen.
**Bewaar en test een onafhankelijke kopie**
1. Volg GitHubs backupuitleg om project en geschiedenis onafhankelijk te bewaren. Laat Codex de backup- en herstelstappen uitleggen vóór gebruik.
2. Bewaar ook originele tekst en beelden, instellingsgegevens en een bekende werkende build. Neem apart opgeslagen formulier- of backendgegevens mee als je die toevoegde.
3. Herstel in een nieuwe map zodat het werkende project intact blijft. Bouw opnieuw, open de preview en controleer belangrijke pagina’s en Contact.
**Dit zou je nu moeten zien:** De hersteloefening levert een werkende preview op, inclusief belangrijke zaken buiten de repository.
5. Herhaal bij elke wijziging de [werkwijze in stappen](#implementation-plan). Test en beoordeel vóór publicatie; controleer daarna het liveresultaat.
**Herhaal de werkwijze**
Voorbeeld ter illustratie: Illustratie: plan een wijziging, bouw en test die, beoordeel vóór publicatie en controleer daarna de livesite.
- **Bij elke wijziging:** Brief → Plan → Branch → Bouwen → Testen → Beoordelen → Goedgekeurd publiceren → Livecontrole
**Let op:** Een beoordeelde publicatieregistratie en livecontroles voor de nieuwe versie.
Ook kleine wijzigingen verdienen dezelfde duidelijke werkcyclus.
**Maak de volgende wijziging**
1. Schrijf de brief en succescontroles en maak een nieuwe branch. Bouw en test de wijziging voordat je een nieuwe beoordeling vraagt.
2. Los ernstige bevindingen op en keur de afgeronde versie goed vóór publicatie. Noteer commit en publicatiecode.
3. Herhaal controles op de livesite en bewaar een vastgelegde route terug naar een bekende werkende versie.
**Dit zou je nu moeten zien:** Een beoordeelde wijziging, actuele publicatieregistratie en nieuwe livecontroleresultaten.
6. Bekijk [OpenAI-kosten](#openai-access) en [Netlify-gebruik](https://www.netlify.com/pricing/). Verwijder ongebruikte diensten en pas [werkafspraken](#working-agreements) aan bij proceswijzigingen.
**Bekijk kosten en instructies**
Voorbeeld ter illustratie: Illustratie: vergelijk OpenAI- en Netlify-gebruik, houd alleen nodige diensten en werk projectinstructies bij.
- **Controleer:** OpenAI-gebruik → Netlify-gebruik → Verwijderen wat niet meer nodig is
- **Daarna:** Werk AGENTS.md en skills bij wanneer de werkwijze verandert.
**Let op:** Accounts, kosten en werkinstructies passen bij de echte behoeften van de website.
Controleer of elk account en elke instructie nog een doel heeft.
**Bekijk gebruik en ruim de werkwijze op**
1. Bekijk je gekozen OpenAI-aanmeldroute en eventueel API-gebruik, plus huidige Netlify-abonnementen en gebruik. De behoeften van je website kunnen veranderen.
2. Verwijder toegangsgegevens of diensten die je niet meer gebruikt nadat je bevestigt dat de site er niet van afhangt. Beoordeel nieuwe functies vóór extra accounts of gegevensverzameling.
3. Werk AGENTS.md of skills bij wanneer de werkwijze verandert. Laat instructies overeenkomen met de echte controles en publicatiestappen.
**Dit zou je nu moeten zien:** Actuele accounts, kosten en instructies passen bij de site zonder ongebruikte toegang.
De basis uitgelegd
**Dependabot-waarschuwing**
Een GitHub-melding dat een pakket in je repository onder een bekende beveiligingswaarschuwing valt. Die helpt problemen vinden die beoordeling nodig hebben.
**Backup**
Een onafhankelijke kopie waarmee je belangrijke bestanden of gegevens herstelt als het origineel verloren gaat. Een backup is alleen nuttig als je eruit kunt herstellen.
**Publicatieregistratie**
Een korte notitie die een gepubliceerde websiteversie verbindt met commit, publicatie, datum, controleresultaten en herstelinstructies.
### Prompt: Bereid een haalbare onderhoudsroutine voor
```text
Maak een onderhoudsnotitie voor het echte Fieldnotes Studio-project. Noem account- en domeineigenaren, belangrijke bezoekerscontroles, pakketwaarschuwingen, gebruiksbeoordelingen, verlengdatums, onafhankelijke backups en herstelinstructies. Onderscheid repositorybestanden van apart opgeslagen instellingen of gegevens. Volg voor de volgende wijziging brief > plan > branch > bouwen > testen > beoordelen > publiceren > livecontrole. Markeer onbekende gegevens die ik moet invullen. Maak de notitie zonder taken te plannen, accounts te wijzigen of de site te publiceren.
```
### Controleer je werk
- [ ] De onderhoudsnotitie heeft genoemde eigenaren, een realistisch controleschema en informatie om repository-, hosting- en domeininstellingen te vinden.
- [ ] Relevante pakketwaarschuwingen staan aan en worden beoordeeld; updates slagen voor bestaande controles vóór publicatie.
- [ ] Een hersteloefening levert een werkende preview uit een onafhankelijke backup op, inclusief zaken buiten de repository.
- [ ] De nieuwste publicatieregistratie en livecontroles zijn actueel, met een vastgelegde route terug naar een bekende werkende versie.
Als er iets misgaat
**Een update breekt de lokale site.**
Houd de mislukte wijziging op de branch, noteer de fout en laat Codex die herstellen of aanpassen. Blijf de eerder gecontroleerde versie gebruiken tijdens onderzoek.
**Een oudere hostingpublicatie is niet meer beschikbaar.**
Herstel de bekende werkende commit en instellingen uit je eigen backup, maak en test de build opnieuw en gebruik het vastgelegde publicatieproces. Vertrouw niet volledig op hostinggeschiedenis.
### Officiële links & verder lezen
- [GitHub: een repository back-uppen](https://docs.github.com/en/repositories/archiving-a-github-repository/backing-up-a-repository)
- [GitHub: Dependabot-waarschuwingen](https://docs.github.com/en/code-security/concepts/supply-chain-security/dependabot-alerts)
- [Astro: het framework bijwerken](https://docs.astro.build/en/upgrade-astro/)
- [Netlify: publicaties bewaren en herstellen](https://docs.netlify.com/deploy/manage-deploys/manage-deploys-overview/)
- [GitHub: Dependabot-waarschuwingen aanzetten](https://docs.github.com/en/code-security/how-tos/secure-your-supply-chain/secure-your-dependencies/configure-dependabot-alerts)
## Startbestanden
Kopieer elk bestand naar je websiteproject op het exacte relatieve pad dat wordt getoond. Dit zijn aanpasbare startpunten. Lees de instructies, pas ze aan je project aan en zet geen API-sleutels in deze bestanden.
### AGENTS.md
```markdown
# Werkafspraken voor de website
Dit project volgt de websitebrief en acceptatiecriteria die met de eigenaar zijn afgesproken. Gebruik de bestaande technische keuzes, tenzij een concrete eis om een wijziging vraagt.
## Werkwijze
- Leg bij een grote functie vóór de bouw de voorgestelde wijzigingen en het controleplan uit. Rond toegestaan lokaal werk af in kleine stappen die de eigenaar kan beoordelen.
- Lees de bestanden die bij de taak horen. Houd andere pagina’s en instellingen intact.
- Leg nieuwe technische termen in gewone taal uit wanneer je aan de eigenaar rapporteert.
- Gebruik de skills website-design, clean-code, website-testing en website-security uit de repository wanneer hun werkwijzen van toepassing zijn.
- Leg belangrijke beslissingen en ontbrekende inhoud vast in de projectnotities. Verzin geen bedrijfsfeiten, aanbevelingen of publicatierechten.
## Controle
- Bekijk package.json om de echte commando’s voor bouwen, typecontrole en tests te vinden. Verzin geen geslaagde controle en maak geen betekenisloze test alleen om een commando te laten slagen.
- Voer controles uit die bij de wijziging passen. Lokale tests gebruiken tijdelijke testgegevens en hebben geen toegang tot productie; voer ze uit en herstel fouten door de gevraagde wijziging zonder bij elke stap toestemming te vragen.
- Controleer bezoekersinteracties in een browser wanneer browserhulpmiddelen beschikbaar zijn. Meld controles die onbeschikbaar of onvolledig blijven.
- Toon de eigenaar een werkende lokale preview en vat veranderd gedrag, bewijs en resterende beperkingen samen.
## Toegangsgegevens en publicatie
- Houd API-sleutels en andere geheimen buiten browsercode, prompts, logboeken en Git. Bewaar lokale geheimen in genegeerde bestanden of de gekozen beveiligde opslag.
- Lokaal bouwen en testen is toegestaan. De site publiceren, een echt bericht versturen, een betaling verwerken of productiegegevens wijzigen vereist toestemming van de eigenaar voor die handeling.
- Bewaar vóór publicatie een herstelbare werkende versie. Beschrijf hoe je die terugzet.
Dit zijn basisafspraken voor een nieuw oefenproject. Pas ze aan de echte eisen en al gegeven toestemming van de eigenaar aan.
```
### .agents/skills/website-design/SKILL.md
```markdown
---
name: website-design
description: Ontwikkel of verfijn de visuele richting en responsive interface van een website vanuit de brief, inhoud en het bestaande ontwerp. Gebruik voor paginaontwerp of visuele bouw.
---
Lees de websitebrief en bestaande ontwerpnotities voor de gevraagde pagina. Werk binnen de merkkeuzes, inhoud en technische keuzes van de gebruiker.
Stel bij een nieuwe richting letterkeuzes, een klein kleurenpalet, vaste afstanden en een voorbeeldpagina voor. Leg uit hoe deze keuzes de doelgroep en de hoofdactie van bezoekers ondersteunen. Gebruik echte inhoud om de volgorde van aandacht en regellengtes te beoordelen.
Maak herbruikbare onderdelen voor navigatie, koppen, knoppen en herhaalde inhoud. Geef hoofdacties een duidelijke visuele nadruk. Behoud zichtbare toetsenbordfocus, leesbaar contrast en bruikbare labels. Ontwerp smalle schermen naast desktopschermen; controleer lange koppen, navigatie en aanraakvlakken in een browser.
Gebruik betekenisvolle HTML voordat je aangepaste interactie toevoegt. Maak beweging optioneel en respecteer de voorkeur voor minder beweging. Gebruik materiaal waarvoor publicatierechten bekend zijn en noteer de bronnen. Verzin geen klantbeoordelingen, prestaties of bedrijfsfeiten.
Toon vóór uitbreiding naar alle pagina’s de eerste complete pagina op desktop- en telefoonbreedte. Beschrijf de belangrijkste ontwerpkeuzes en ontbrekende inhoud. Is een browserhulpmiddel onbeschikbaar? Meld dan dat visuele controle nog moet gebeuren.
```
### .agents/skills/clean-code/SKILL.md
```markdown
---
name: clean-code
description: Bouw of herstructureer websitecode tot begrijpelijke onderdelen met de bestaande techniek en afspraken van het project. Gebruik voor websitebouw of onderhoudbaarheid.
---
Lees de relevante bestanden en pakketscripts voordat je een aanpak kiest. Behoud werkend gedrag buiten de gevraagde wijziging. Gebruik bij voorkeur de bestaande techniek en pakketten als die aan de behoefte voldoen.
Houd pagina-inhoud apart van herhaalde opmaak wanneer dat bewerken makkelijker maakt. Geef onderdelen, variabelen en functies namen die hun doel beschrijven. Gebruik gedeelde onderdelen voor herhaalde navigatie en pagina-elementen; maak geen abstractie voor één eenvoudig gebruik.
Verwerk lege, ongeldige, ladende en fouttoestanden bij interacties die dat nodig hebben. Gebruik standaard browserbediening en betekenisvolle HTML wanneer die de interactie ondersteunen. Vermijd nep-formulierverzending, nagebootste succesmeldingen en dode links.
Gebruik typecontrole en de opmaak- of lintregels van het project waar die zijn ingesteld. Leg bij een nieuw pakket het doel en nieuwe onderhouds- of gebruikseisen uit. Houd gegenereerde bouwbestanden, geïnstalleerde pakketten en lokale omgevingsbestanden buiten versiebeheer.
Voer bestaande controles uit die bij de wijziging passen, inclusief een productiebuild wanneer het resultaat kan veranderen. Vat veranderd gedrag, controleresultaten en resterende beperkingen samen. Leg de belangrijkste bestanden in gewone taal uit, zodat een beginner de inhoud kan vinden en aanpassen.
```
### .agents/skills/website-testing/SKILL.md
```markdown
---
name: website-testing
description: Controleer websitewijzigingen met bezoekersroutes, passende automatische tests en browsercontroles. Gebruik bij websitetests, onderzoek naar fouten of voorbereiding op publicatie.
---
Begin met de brief en zichtbare acceptatiecriteria. Bekijk bestaande test- en bouwcommando’s; neem niet aan dat een script bestaat. Kies controles op basis van veranderd gedrag en de gevolgen van een fout.
Doorloop de hoofdroute voor bezoekers en betrokken links, navigatie en formulieren. Neem ongeldige invoer en relevante fouttoestanden mee. Controleer bij een contactformulier echte bezorging op de afgesproken testbestemming voordat je meldt dat het werkt. Leg bij een e-maillink uit dat die het ingestelde mailprogramma van de bezoeker opent en niet automatisch een bericht verstuurt.
Controleer smalle en brede schermen in een browser. Neem toetsenbordnavigatie, zichtbare focus, toegankelijke namen, zoom en horizontaal overlopen mee. Automatische toegankelijkheidsresultaten vullen deze handmatige controles aan en bewijzen geen volledige toegankelijkheidsnaleving.
Voeg automatische tests toe voor belangrijk gedrag of aangetoonde terugkerende fouten. Test zichtbare resultaten en betekenisvolle foutgevallen; vermijd tests die alleen de geschreven code herhalen of toevallige formuleringen vergelijken. Gebruik tijdelijke testgegevens en lokale testbestanden. Verstuur nooit echte berichten, voer geen betalingen uit en wijzig geen productiegegevens zonder toestemming van de gebruiker.
Reproduceer een fout, herstel de oorzaak en voer betrokken controles opnieuw uit. Meld uitgevoerde commando’s, resultaten, browsercontroles en alles wat niet is gecontroleerd. Een geslaagde build toont dat de site kan worden gemaakt; controleer bezoekersgedrag apart. Meld nooit dat een controle geslaagd is als die is overgeslagen of onbeschikbaar was.
```
### .agents/skills/website-security/SKILL.md
```markdown
---
name: website-security
description: Controleer geheimen, pakketten, invoer, toegang en publicatie-instellingen van een website en herstel bevindingen binnen de afgesproken taak. Gebruik voor gevraagde beveiligingscontrole of voorbereiding op publicatie.
---
Breng de relevante onderdelen van de site in kaart: statische pagina’s, formulieren, backend-routes, aanmelding, scripts van derden en opgeslagen gegevens. Beperk de controle tot de echte technische opzet en de toegestane omgeving.
Houd toegangsgegevens buiten browsercode, logboeken, prompts en Git. Maak onderscheid tussen openbare instellingen tijdens de build en servergeheimen. Is een sleutel als commit opgeslagen of blootgesteld? Gebruik hem niet meer, leg uit dat het bestand verwijderen de sleutel niet intrekt en laat de eigenaar hem vóór verder gebruik intrekken of vervangen. Toon de toegangsgegevens niet in je verslag.
Bekijk relevante beveiligingswaarschuwingen voor pakketten en beoordeel of het betrokken pakket en het kwetsbare gedrag worden gebruikt. Herstel binnen compatibele versies en voer de betrokken controles opnieuw uit. Vermijd automatische geforceerde upgrades die de website kunnen breken.
Controleer bij backend-interacties de invoer op de server, geef uitvoer passend gecodeerd weer en controleer aanmelding en toegangsrechten afzonderlijk. Overweeg misbruikbeperking voor openbare formulieren of AI-toegangspunten. Een OpenAI API-sleutel hoort op de server; een statische site publiceren biedt geen geheime serveromgeving.
Controleer HTTPS en relevante beveiligingsheaders bij de echte hosting. Verzamel alleen gegevens die de functie nodig heeft en leg hun bestemming en bewaartermijn uit. Claim geen wettelijke naleving op basis van een codescan.
Meld elke bevinding met locatie, aannemelijke impact, herstel en controle. Beschrijf de reikwijdte, gebruikte hulpmiddelen, openstaande bevindingen en ontoegankelijke onderdelen. Een schone scan is bewijs binnen het bereik van die scan, geen garantie dat de website geen kwetsbaarheden heeft. Scan geen systemen van derden en publiceer geen wijzigingen buiten de toegestane taak.
```