Katselmointi, auditointi ja korjaus
Viimeinen vaihe DSDA-prosessissa on auditointi. Tämä oppitunti käsittelee 6-kierroksen katselmoinnin, auditointiportin ja systemaattisen korjaustyönkulun — sekä miten oppimiset tallennetaan tiimin hyödyksi.
6-kierroksen katselmointi
Jokainen muutos käy läpi kuusi fokusaluetta:
6-kierroksen katselmointi
6-kierroksen katselmointi on systemaattinen laaduntarkistus, jossa jokainen kierros keskittyy yhteen aspektiin: speksien noudattaminen, testikattavuus, turvallisuus, arkkitehtuuri, suorituskyky ja lopullinen tuomio. Kierrokset estävät "näyttää hyvältä" -arvioinnin korvaamasta perusteellisen analyysin.
Kierros 1: Speksien noudattaminen
Kysymys: Täyttyvätkö kaikki hyväksymiskriteerit?
- Käy läpi jokainen AC erikseen
- Merkitse: ✅ Täytetty / ❌ Puuttuu / ⚠️ Osittain
- Jos yksikin AC puuttuu → FAIL
Kierros 2: Testikattavuus
Kysymys: Onko jokaiselle AC:lle testi?
- Vertaa speksin AC:t → todelliset testit
- Tarkista edge caset ja virhetilanteet
- Mittaa kattavuus numeerisesti
Kierros 3: Turvallisuus
Kysymys: Input-validointi, autentikointi, salaisuudet?
- Onko käyttäjäsyöte validoitu?
- Onko autentikointi ja autorisaatio tarkistettu?
- Onko salaisuuksia koodissa tai lokeissa?
- Onko SQL-injektio, XSS tai CSRF huomioitu?
Kierros 4: Arkkitehtuuri
Kysymys: Noudatetaanko projektimalleja?
- Noudattaako koodi olemassa olevia arkkitehtuurimalleja?
- Ovatko riippuvuudet oikeansuuntaisia?
- Onko koodia duplikoitu?
Kierros 5: Suorituskyky
Kysymys: Kyselyt, välimuisti, bundle-koko?
- N+1 kyselyt?
- Tarpeettomat renderöinnit?
- Bundle-koon kasvu?
- Indeksit tietokantakyselyille?
Kierros 6: Tuomio
Vaihtoehdot:
| Tuomio | Merkitys | Jatkotoimenpide |
|---|---|---|
| HYVÄKSY | Kaikki OK | Merge / deploy |
| PYYDÄ MUUTOKSIA | Pieniä korjauksia | Fix → uusi katselmointi |
| ESTÄ | Vakavia ongelmia | Palaa speksivaiheeseen |
Auditointiportti
Auditointiportti on viimeinen tarkistuspiste ennen kuin muutos hyväksytään tuotantoon.
## Audit Gate
### Completeness
- [ ] All ACs met (from Spec)
- [ ] No partial implementations
### Quality
- [ ] 6-pass review completed
- [ ] All issues resolved
- [ ] No BLOCK findings remaining
### Documentation
- [ ] Docs updated to reflect changes
- [ ] content-plan.md updated
- [ ] Code comments adequate
### Testing
- [ ] All tests passing
- [ ] Coverage meets target
- [ ] No skipped tests
### Final
- [ ] PASS / FAIL
- [ ] Sign-off: [reviewer]Korjaustyönkulku
Kun katselmointi löytää ongelmia, seuraa systemaattista korjausprosessia:
Kerää konteksti → Muodosta hypoteesi → Validoi → Korjaa → Dokumentoi3 yrityksen sääntö
Älä koskaan luuppaa saman ongelman kanssa yli 3 kertaa ilman ihmisen syötettä.
Jos korjaus ei toimi 3 yrityksellä:
- Pysähdy
- Dokumentoi mitä yritit
- Pyydä ihmiseltä ohjausta
- Kirjaa ratkaisu
learnings.md:iin
Pro-vinkki
3 yrityksen sääntö estää AI:ta (ja kehittäjiä) hukkaamasta aikaa väärään suuntaan. Jokainen yritys pitäisi olla merkittävästi erilainen — ei sama asia uudestaan pienellä muutoksella.
learnings.md — Tiimin muisti
learnings.md on projektin oppimispäiväkirja. Tarkista se AINA ENSIMMÄISENÄ kun kohtaat virheen.
## [Päivämäärä]: [Lyhyt kuvaus]
### Konteksti
[Milloin/missä tämä tapahtui]
### Oire
[Mitä näit]
### Juurisyy
[Miksi se tapahtui]
### Ratkaisu
[Miten korjattiin]
### Ennaltaehkäisy
[Miten estetään jatkossa]Esimerkkejä
## 2026-03-15: Supabase RLS-politiikka esti admin-pääsyn
### Konteksti
Guild admin -toiminnot eivät toimineet testausympäristössä.
### Oire
403 Forbidden kaikille admin API-kutsuille.
### Juurisyy
RLS-politiikka tarkisti 'admin' roolin guild_memberships-taulusta,
mutta testidata ei sisältänyt admin-roolia.
### Ratkaisu
Lisättiin admin-rooli seed_test_data.sql-tiedostoon.
### Ennaltaehkäisy
Lisätty tarkistuslista: varmista testidata kattaa kaikki roolit.learnings.md
learnings.md on projektin kollektiivinen muisti — dokumentti johon kirjataan opitut asiat, ratkotut ongelmat ja niiden juurisyyt. Se on ensimmäinen paikka johon katsotaan kun kohdataan ongelma. Ajan myötä siitä tulee korvaamaton resurssi, joka estää saman virheen toistamisen.
Katselmointiagentin rooli
| Saa | Ei saa |
|---|---|
| Lukea kaikkea (koodi, testit, dokumentaatio) | Muokata toteutuskoodia |
| Kirjoittaa katselmointiraportteja | Ohittaa auditoinnin kierroksia |
| Antaa tuomion (HYVÄKSY/PYYDÄ/ESTÄ) | Hyväksyä ilman perusteluja |
Miksi '3 yrityksen sääntö' on tärkeä AI-avusteisessa korjaustyössä?
Suorita 6-kierroksen katselmointi
Valitse äskettäinen muutoksesi (tai avoimen lähdekoodin PR) ja suorita täysi 6-kierroksen katselmointi: 1) Speksien noudattaminen, 2) Testikattavuus, 3) Turvallisuus, 4) Arkkitehtuuri, 5) Suorituskyky, 6) Tuomio. Kirjoita 1-sivuinen raportti.
Moduulin yhteenveto
Brownfield-moduulissa opit:
- Greenfield vs. Brownfield — 80 % työkuormasta on brownfieldiä
- DSDA-prosessi — Document → Spec → Develop → Audit
- 3-tasoinen dokumentaatio — T1 → T2 → T3 + content-plan.md
- Perustellut speksit — Jokainen väite viittaa todelliseen lähteeseen
- Katselmointi ja auditointi — 6 kierrosta + portti + learnings.md
Seuraavassa moduulissa siirrymme AI-agentteihin: miten suunnitella ja rakentaa autonomisia agentteja, jotka käyttävät työkaluja, muistia ja tiedonhakua.