Prompt-avusteinen sovelluksen käyttöönotto

Mitä ominaisuus tekee

Nykyinen prompt-to-app endpoint yhdistää kirjallisen briefin olemassa olevaan Git-mallirepositoryyn ja asettaa repositoryn jonoon tavallisen immutable app-deployment pipeline -putken kautta. Brief tallennetaan provenanceksi myöhempiä iterointeja varten.

Se ei luo uutta application repositorya briefistä. Template URL on pakollinen, ja ensimmäinen deployment sisältää template sourcen ratkaistussa revisiossa, ellei lähde jo toteuta pyyntöä.

Luo promptista ja mallista

POST /api/apps/from-prompt
Content-Type: application/json
 
{
  "brief": "A private reading-list app with a health endpoint",
  "template_git_url": "https://github.com/example/reviewed-template.git",
  "branch": "main",
  "visibility": "private"
}

Vastaus sisältää pysyvät app-, deployment- ja build-ID:t sekä build stream URL:n. Luonti on asynkronista. Seuraa deployment-tietuetta tai build streamia terminal stateen asti; älä lähetä kaksoiskappaletta deploymentista vain siksi, että edistyminen on hiljaista.

Ennen pyynnön lähettämistä:

• tarkista repository ja lisenssi;
• kiinnitä tai kirjaa deploymentin käyttämä tarkka source revision;
• varmista install, build, run, port ja health-käyttäytyminen; ja
• pidä secrets poissa promptista ja repositorysta.

Prompt on konteksti, ei todiste siitä, että syntynyt source täyttää sen. Testaa käyttöönotetun käyttäytyminen briefistä johdettuja acceptance criteria -vaatimuksia vasten.

Pyydä myöhempää muutosta

POST /api/apps/{app_id}/iterate
Content-Type: application/json
 
{
  "instruction": "Add an authenticated export endpoint and a regression test"
}

Tämä käynnistää asynkronisen repair-agent taskin appille, joka on sinun ja jolla on Git source. Pollaa:

GET /api/apps/{app_id}/agent-status?thread_id={thread_id}

Statusvastaus yhdistää viimeisimmän deployment staten iteration-thread stateen ja mahdolliseen raportoituun result evidenceen.

Tärkeä iterointiraja

Nykyinen repair-polku voi työskennellä sandboxissaan ja pyytää uutta deploymentia, mutta persistence takaisin kehittäjän Git repositoryyn ei ole vielä taattu vaihe. done agent thread ei siis itsessään todista, että:

• pyydetty muutos on upstream repositoryssä;
• tietty commit rakennettiin;
• testit menivät läpi;
• uusi deployment aktivoitui; tai
• vanha deployment voidaan palauttaa.

Kirjaa jokaisessa iteroinnissa erikseen upstream commit, deployment ID, build ID, health result ja acceptance-test evidence. Jos upstream repositorya ei päivitetty, säilytä patch operatorin tarkistaman source-control workflow’n kautta ennen kuin luotat muutokseen.

Turvallinen hyväksymisjärjestys

1. Muunna brief havaittaviksi acceptance criteria -vaatimuksiksi.
2. Tarkista valittu malli ja tarkka revisio.
3. Aseta yksi deployment jonoon ja seuraa sen pysyviä ID:itä.
4. Vahvista build, candidate health check ja route switch erikseen.
5. Koettele acceptance criteria -vaatimuksia deployed URL:ia vasten.
6. Vahvista, että source commit on repositoryssä, jota hallitset.
7. Säilytä evidence ja rollback target.

Katso Sovelluksen käyttöönotto immutable deployment stages -vaiheista ja failure handlingista.