Adopt a repo tuo codebase'n 1DesignTooliin: sovellus rekisteröi
projektin sovelluksen omistamalle worktreelle — 1design/<slug>
-haaralle app-data-hakemistosi alla — niin, että agentti suunnittelee
oikean käyttöliittymäsi sisällä kirjoittamatta koskaan checkoutiisi.
Se on silta "suunnittele jotain" -tilasta "suunnittele minun
asiassani" -tilaan.
Adoptointi
Kotisivulta Open folder… valitsee repon ja avaa adopt-arkin: se
lukee kansion, kysyy, haluatko suunnitella sen sisällä, ja Design
inside this codebase rekisteröi projektin codebase-projektiksi.
Sovellus luo worktree'n — 1design/<slug>-haaran, joka on checkout
-app-data:n alla — ja projekti avautuu siihen, ei checkoutiisi.
Reposi pysyy koskemattomana: kirjoitukset laskeutuvat sovelluksen worktree'en, luet tulevat oikeista tiedostoistasi sen kautta. Adopt- arkki näyttää myös eristyshuomion — mitä worktree on ja miksi checkoutisi ei ole työkopio.
Worktree-malli
Codebase-projekti elää 1design/<slug>-haaralla — sovelluksen
omistamalla haaralla, joka on checkout app-data:n alla:
- Luet — agentti näkee oikean käyttöliittymäsi worktree'n läpi
- Kirjoitukset — turnin diffit laskeutuvat haaralle, koskaan ei checkoutiisi
- Esikatselu — sovelluksen esikatselu worktree'sta tai oma dev-serverisi
- Checkoutisi — koskaan ei kirjoiteta; host-hallitut polut
(
.1design/, skill-hakemistot) piilottuvat.git/info/exclude:n kautta, eivät.gitignoressasi
Branch bar projektissa näyttää kaistan — 1design/<slug> mainista,
ahead-commit-määrän ja tiedostot, joita turnit muuttivat.
Suunnittelu codebasen sisällä
Adoptoituna se ohjautuu kuten mikä tahansa projekti — mutta briefi koskee sinun käyttöliittymääsi: "tee headerista sticky", "lisää settings-näyttö profiilin viereen". Agentti muokkaa oikeita tiedostoja worktree'n kautta; esikatselu näyttää sovelluksen ajossa omalla dev-serverilläsi tai sovelluksen esikatselulla.
Diff-scoped gate
Codebase-projektit eivät aja täyttä design kit -gatea — reposi
ei ole generoitu artefakti, joten sen tarkistaminen sellaisena
liputtaisi koodia, jota turn ei koskenut. Sen sijaan tarkistukset
ovat diff-scoped: turnin muuttuneet tiedostot verifioidaan
(tells.mjs diffillä), ja branch barin review-toiminto näyttää
tarkalleen, mitä turn teki.
Review ja merge
Kun turnin työ näyttää oikealta, branch barin Review changes
näyttää turnin tuottaman diffin; Copy merge command tai
Merge into main tuo haaran työn takaisin repoon. Discard
heitttää worktree-tilan pois. Checkoutisi main on se, mikä
mergee — worktree on sandbox.
Build- ja Sketch-moodit
Codebase-projekti kantaa kaksi ylimääräistä moodia live-esikatselun päälle:
- Build mode — muokkaa ajossa olevan sovelluksen käyttöliittymää visuaalisesti, ja muutokset kirjoittuvat takaisin koodiin (katso Build mode)
- Sketch mode —
.1d-luonnokset, jotka kartoittuvat komponentteihin (katso Sketch mode)
Direct mode
Worktree-malli on oletus, koska se on turvallinen — sovellus kirjoittaa omaan haaraansa app-data:n alla, koskaan ei checkoutiisi. Direct mode — vaihtoehto adopt-arkilla — osoittaa projektin suoraan checkoutiisi; agentti muokkaa oikeita tiedostoja paikallaan. Se on nopeampi, mutta työ laskeutuu työkopioosi, joten worktree- oletus on olemassa syystä.
Missä se on hyvä
- Suunnittelu oikean sovelluksesi sisällä — jo olemassa oleva näyttö, uudelleen tyylitettynä
- Feature-työ — uusi näyttö tai virta, paikallaan
- UI-kierrokset — koko sovelluksen visuaalinen kierros, diffattuna
- Onboarding codebaseen — agentti lukee repon, jossa sen täytyy elää
Eristyshuomio
Worktree on olemassa, jotta agentin työ ei voi koskea checkoutiisi
ennen kuin merget — rekisteröity projektijuuri on sovelluksen
haara, luet ja kirjoitukset menevät sen kautta, ja host-hallitut
tiedostot, joita projekti tarvitsee, piilottuvat
.git/info/exclude:n kautta niin, että git statussi pysyy
puhtaana. Hinta on yksi askel: kun työ on oikein, mergeet haaran.
Vinkki: Pidä worktree, kunnes merge on puhdas — haaran poistaminen ennen kuin työ on varmistettu maksaa diffin. Merge-painike tekee siitä yhden toiminnon; tarkista ennen kuin klikkaat.