Auditeerib olemasolevat tootevaadet selle enda disainipõhimõtete alusel ja kirjutab parendusplaanid.
Kogu oskus — vaikeversiooni hoitakse GitHubis; sinu muudatused jäävad sinu enda klooni.
Auditeeri üht terviklikku tootepinda selle süsteemi suhtes, mis seda tegelikult juhib. Säilita toote identiteet, kasuta olemasolevaid omanikke uuesti ja eelista pigem leiu puudumist kui põhjendamata leidu. Kirjuta plaanid ainult nende muudatuste kohta, mille kasutaja valib; neid teostab teine agent.
design-plans/.Austa kasutaja määratud ulatust. Kui päring on lai, vali üks juurutatav rakendus ja üks terviklik pinnaperekond, mis esindab toote põhiülesannet. Ütle valik välja; ära sünteesi kogu repositooriumi üheks tooteks.
Alusta pinna marsruutidest ja paigutustest. Jälgi renderdatud rada läbi kompositsioonide, jagatud komponentide, variantide, lahendatud tokenite ja stiilide. Ära alusta kogu repositooriumi hõlmavast ebakõlade otsingust.
Seos on olemas ainult siis, kui see on tõestatud renderdamise, importide, prop'ide, lahendatud konfiguratsiooni, CSS-i pärimise või pinna poolt laaditud genereeritud artefakti kaudu. Ühised nimed, sarnased tokenid, lähedus repositooriumis ja kontseptuaalsed seosed ei tõenda seost. Jäta välja muud rakendused, eelvaated, konfiguraatorid, genereeritud registrid, pärandsüsteemid ja ettevõtte variandid, kui need ei osale jälgitud rajal.
Kontrolli, kas on olemas DESIGN.md, repositooriumi juhised ja pinnaspetsiifiline disainidokumentatsioon. Kasuta allikat ainult pärast seda, kui oled tõestanud, et see on ajakohane ja juhib valitud pinda; mustandid, ettepanekud, migratsioonid ja ülesandeloendid kirjeldavad tulevast kavatsust, kui neid pole selgesõnaliselt aktsepteeritud ja need pole ajakohased. Disainidokumentatsiooni puudumine ei ole leid.
Uuri ainult neid tokeneid, muutujaid, teemasid, primitiive, variante ja kompositsioone, mis on jälgitud raja jaoks olulised. Lahenda aliased ja variandid nende definitsioonideni. Liigita teostus kohalikuks või pärandiks ainult siis, kui repositoorium nii ütleb.
Pane kirja:
## Design language
- Audited surface:
- Design sources:
- Documented decisions:
- Governing owners and consumers:
- Explicit exceptions:
Kirjuta Explicit exceptions alla None documented, välja arvatud juhul, kui viidatud allikas tuvastab erandi selgesõnaliselt.
Enne tõendusvärava rakendamist uuri iga jälgitud pinna kasutajale nähtavaid silte, aktiivse oleku esitust, responsiivseid harusid ja sõsarvariante sisemiste vastuolude suhtes. Käsitle tulemusi ainult kandidaatidena.
Leid kuulub ulatusse ainult siis, kui selle parandus muudab eelkõige visuaalset esitust, liidese teksti, paigutust, komponendi stiili või vastavust dokumenteeritud disainireeglile. Kui parandus muudab eelkõige seda, kas toote käitumine töötab, lükka see tagasi.
Otsingutulemused, kordumine ja teostuserinevused annavad kandidaate, mitte leide. Hoia kandidaat alles ainult siis, kui kõik kolm tõendit on olemas:
Lähtekood võib tõestada tokeni, tüpograafia, värvi, vahede, paigutuse, teksti, komponendivariandi, responsiivse esituse ja selgesõnalise disainilepingu rikkumisi. See ei saa muuta funktsionaalset käitumist, olekuhaldust ega interaktsiooni korrektsust disainileidudeks. Hierarhia, esiletõstetus, tihedus, selgus, leitavus, kasutatavus ja tajutav sidusus nõuavad renderdatud või kasutajatõendeid.
Jäta kõrvale ligipääsetavuse ja HTML/ARIA semantika leiud, kui kasutaja neid selgesõnaliselt ei palu. Jäta kõrvale katkised marsruudid, ümbersuunamised, andmete ühendamine, toimingute tõrked, metaandmed, paketi API, jõudlus, arhitektuur ja koodikvaliteedi leiud, kui kasutaja neid ei palunud või neid ei juhi tootespetsiifiline disainileping.
Määra usaldusväärsus alles pärast seda, kui kõik tõendid on läbitud. Kasuta olemasolevat omanikku uuesti, kui tõendid seda toetavad; ära loo jagatud primitiivi pelgalt kordumise põhjal.
Enne aruandmist ava uuesti iga viidatud allikas ja proovi iga kandidaati ümber lükata. Kustuta see, kui:
Tabelisse võivad pääseda ainult need leiud, mis selle kontrolli üle elavad.
Järjesta allesjäänud leiud usaldusväärsuse, kasutajamõju, ulatuse ja parandamise kulu järgi. Peatu kolme juures.
Kasuta seda struktuuri:
## Design language
- Audited surface:
- Design sources:
- Documented decisions:
- Governing owners and consumers:
- Explicit exceptions:
## Findings
| # | Problem | Evidence | Proposed change | Scope | Confidence |
| --- | --- | --- | --- | --- | --- |
## Improve first
<Highest-leverage finding and why, or no supported recommendation.>
Tõendid peavad kinnitama lepingu, käitusaja seose ja deterministliku liidesetagajärje. Kavandatud muudatus peab sisaldama üht parandust. Kustuta enne tagastamist põhjendamata või kattuvad read.
Kustuta iga leid, millel pole kõiki nõutud veerge, sealhulgas Confidence.
Vali Improve first alla üks allesjäänud leid, millel on tugevaimad tõendid ja suurim võimendus. Ära kunagi kombineeri leide.
Kui ükski kandidaat ei jää alles, kirjuta ## Findings alla No supported findings were found. ja ## Improve first alla No supported recommendation..
Kui leide jääb alles, peatu ja küsi, millistest teha plaanid. Kui kasutaja on juba leiu valinud või selgesõnaliselt palunud kirjeldatud parenduse jaoks plaani, jätka selle ulatusega. Kui sul palutakse midagi otse parandada või parendada, paku plaani; ära seda kunagi ise teosta.
Loe references/plan-template.md. Kirjuta üks plaan iga valitud muudatuse kohta, mitte kunagi üks plaan iga sümptomi kohta.
Enne kirjutamist ava uuesti iga viidatud allikas, pane võimalusel kirja praegune commit, tuvasta täpsed korduvkasutatavad primitiivid ja eeskujud ning jälgi mõjutatud pindu. Ühtlusta olemasolev plaan, selle asemel et seda dubleerida.
Ära mõtle väärtusi välja, kui repositoorium pakub tokenit või komponendilepingut. Võta uus primitiiv kasutusele alles pärast seda, kui oled tõestanud, miks olemasolev süsteem ei suuda otsust väljendada ja millised tarbijad peaksid seda jagama.
Kui sul palutakse ühtlustada, kontrolli olemasolevaid plaane uuesti praeguse lähtekoodi ja dokumenteeritud otsuste suhtes; uuenda aegunud tõendid, mõjutatud pinnad ja olek.