Riferimento del blueprint

Questo è il riferimento completo ai campi dei blueprint. Per un’introduzione ai blueprint e a come si inseriscono nell’ambiente di Devin, consulta Configurazione dichiarativa dell’ambiente.

Un blueprint definisce come viene configurato l’ambiente di Devin: quali strumenti installare, come mantenere aggiornate le dipendenze e quali comandi Devin deve conoscere.

Panoramica

Un blueprint comprende tre sezioni principali di primo livello, oltre ai campi facoltativi runs-on e includes, a una sezione post-build per i blueprint a livello di organizzazione ed Enterprise e a una sezione clone per i blueprint a livello di repo:

initialize: ...   # Install tools and runtimes
maintenance: ...  # Install project dependencies
knowledge: ...    # Reference info for Devin (never executed)
runs-on: ...      # Piattaforme per cui eseguire la build (default: ["default"])
includes: ...     # (Solo blueprint radice del repository supportato da Git) Blueprint dei workspace
post-build: ...   # (Solo organizzazione/enterprise) Comandi eseguiti al termine di tutta la configurazione
clone: ...        # (Repository-level only) Override git-clone defaults

Sezione	Scopo	Eseguito?
`initialize`	Installa strumenti di sistema, runtime di linguaggio e CLI globali	Durante le build complete e per i workspace ricostruiti
`maintenance`	Installa e aggiorna le dipendenze del progetto	Sì, durante le build. Presentato all’agente all’inizio della sessione (non eseguito automaticamente).
`knowledge`	Indica a Devin come eseguire lint, test, build e altre operazioni specifiche del progetto	No, fornito come riferimento
`runs-on`	Seleziona una o più piattaforme di build	Utilizzato per creare una build dello snapshot per piattaforma
`includes`	Individua i blueprint dei workspace da un blueprint radice del repository	Solo blueprint radice del repository supportati da Git
`post-build`	Comandi eseguiti dopo che tutti i repository sono stati clonati e configurati (solo organizzazione/Enterprise)	Sì, durante le build — un codice di uscita diverso da zero causa il fallimento della build
`clone`	Override del modo in cui il repository viene clonato nello snapshot (solo a livello di repository)	Applicato durante il passaggio di clone della build

Tutte le sezioni sono facoltative. Puoi includerne qualsiasi combinazione. initialize viene eseguito durante le build complete e per i workspace ricostruiti da zero. I risultati vengono salvati nello snapshot. In una build differenziale, i workspace ereditati saltano initialize, recuperano il codice più recente ed eseguono solo maintenance. Scrivi maintenance in modo che sia autosufficiente e possa essere eseguito in modo indipendente sullo snapshot esistente, senza richiedere che initialize venga eseguito immediatamente prima né fare affidamento sulle variabili d’ambiente che initialize ha precedentemente scritto in $ENVRC. All’inizio di ogni sessione, i comandi di maintenance non vengono eseguiti automaticamente — vengono invece presentati all’agente come contesto, così sa quali comandi per le dipendenze eseguire se necessario (ad es. dopo aver aggiornato il codice all’ultima versione). I comandi devono comunque essere rapidi e incrementali. Le build vengono eseguite automaticamente quando il tuo blueprint cambia e periodicamente (circa ogni 24 ore).

initialize

Usa initialize per installare strumenti e runtime che non dipendono dallo stato specifico del tuo codice: runtime dei linguaggi, pacchetti di sistema, CLI globali.

Forma semplice

Per i comandi shell più semplici, usa uno scalare a blocco:

initialize: |
  curl -LsSf https://astral.sh/uv/install.sh | sh
  apt-get update && apt-get install -y build-essential
  npm install -g pnpm

Formato strutturato

Per i passaggi denominati, le variabili d’ambiente o le GitHub Actions, usa un elenco:

initialize:
  - name: "Install Python 3.12"
    uses: github.com/actions/setup-python@v5
    with:
      python-version: "3.12"

  - name: "Install system packages"
    run: |
      apt-get update
      apt-get install -y libpq-dev

  - name: "Install global tools"
    run: pip install uv
    env:
      PIP_BREAK_SYSTEM_PACKAGES: "1"

Le due forme possono essere combinate. La forma semplice equivale a un unico passaggio con run.

Quando usare initialize anziché maintenance

Inserisci in `initialize`	Inserisci in `maintenance`
Installazione del runtime del linguaggio	`npm install` / `pip install`
Pacchetti di sistema (`apt-get`)	`bundle install`
Strumenti CLI globali	`go mod download`
Configurazione una tantum	Aggiornamenti della cache delle dipendenze
GitHub Actions (`setup-python`, etc.)	Script di configurazione specifici per repo

Entrambe le sezioni vengono eseguite durante le build complete. Nelle build differenziali, i workspace ereditati saltano initialize ed eseguono solo maintenance dopo aver scaricato il codice più recente. Strumenti e runtime vanno in initialize; i comandi per le dipendenze che si basano sui file di lock del codice vanno in maintenance.

maintenance

Usa maintenance per installare le dipendenze e per altri comandi che devono essere eseguiti dopo il clone del codice. Questi comandi vengono eseguiti durante le build e vengono esposti all’agente all’inizio della sessione, così che possa eseguirli di nuovo se le dipendenze sono cambiate. Qui vanno npm install, pip install, uv sync e comandi simili.

maintenance: |
  npm install
  pip install -r requirements.txt

Oppure in formato strutturato:

maintenance:
  - name: "Install npm dependencies"
    run: npm install

  - name: "Install Python dependencies"
    run: uv sync
    env:
      UV_CACHE_DIR: /tmp/uv-cache

Per i blueprint a livello di repo, i comandi maintenance vengono eseguiti dalla directory radice del repository. Per i blueprint a livello di org, vengono eseguiti dalla home directory (~).

knowledge

La sezione knowledge non viene eseguita. Fornisce informazioni di riferimento che Devin utilizza quando lavora nel tuo progetto. È qui che indichi a Devin i comandi corretti per il linting, il testing, la build e qualsiasi altro flusso di lavoro specifico del progetto.

knowledge:
  - name: lint
    contents: |
      Run linting with:
      npm run lint

      For auto-fix:
      npm run lint -- --fix

  - name: test
    contents: |
      Run the full test suite:
      npm test

      Run a single test file:
      npm test -- path/to/test.ts

  - name: build
    contents: |
      npm run build

      Build output goes to dist/

Ogni elemento di conoscenza include:

Campo	Tipo	Descrizione
`name`	string	Identificatore di questo elemento di conoscenza (ad es. `lint`, `test`, `build`)
`contents`	string	Testo libero con comandi, istruzioni o note

Il campo name è un’etichetta. Per convenzione, lint, test e build sono i nomi standard. Devin fa riferimento a questi nomi quando verifica il proprio lavoro. Puoi aggiungere altri elementi di conoscenza con nomi personalizzati:

knowledge:
  - name: lint
    contents: ...
  - name: test
    contents: ...
  - name: build
    contents: ...
  - name: deploy
    contents: |
      Deploy to staging:
      npm run deploy:staging
  - name: database
    contents: |
      Run migrations:
      npm run db:migrate

      Seed test data:
      npm run db:seed

runs-on

Il campo facoltativo di primo livello runs-on accetta una stringa o un elenco di stringhe. Il valore predefinito è ["default"]. Le etichette default e linux sono alias che non distinguono tra maiuscole e minuscole per la piattaforma Linux predefinita. Qualsiasi altra etichetta deve corrispondere a una configurazione macchina registrata nel tuo account, ad esempio windows o macos. Quando un blocco elenca più etichette di piattaforma, Devin crea una build dello snapshot per ogni piattaforma ed esegue gli stessi passaggi su ciascuna. Due blocchi nello stesso file non possono corrispondere alla stessa piattaforma; ciò include gli alias default e linux. Per la configurazione specifica della piattaforma, consulta Supporto per Windows e Supporto per macOS.

includes

Il campo facoltativo includes si applica solo ai blueprint supportati da Git: Devin lo interpreta quando rileva il file .devin/blueprint.yaml nella directory root di un repository. Viene ignorato nei blueprint creati nell’editor Settings e non è consentito in un blueprint del workspace incluso. Accetta una stringa o un elenco di stringhe. Ogni voce identifica una sottodirectory del workspace; Devin cerca <dir>/.devin/blueprint.yaml, ma è valido anche il percorso completo del file. I percorsi non possono contenere ... Le inclusioni annidate vengono rifiutate e ciascun percorso del workspace può comparire una sola volta. Se un file incluso non è presente, Devin considera quel workspace come rimosso.

post-build

La sezione post-build è disponibile solo nei blueprint a livello di organizzazione e di Enterprise (non è supportata nei blueprint a livello di repo). I suoi passaggi vengono eseguiti durante la build dopo che tutti i repository sono stati clonati e che i relativi passaggi initialize e maintenance sono stati completati, ma prima del controllo di integrità e della creazione dell’immagine snapshot. Questo la rende il punto ideale per la convalida tra più repository e per i controlli di integrità che richiedono un ambiente completamente configurato. Poiché viene eseguito nelle fasi finali della build, con l’intero ambiente già pronto, un passaggio post-build può accedere a ogni repository clonata e a ogni strumento installato dai blueprint di Enterprise, organizzazione e repository.

post-build: |
  # Verifica che l'ambiente assemblato sia integro
  node --version
  python --version
  test -d ~/repos/my-service

Oppure in formato strutturato:

post-build:
  - name: "Verify toolchain"
    run: |
      node --version
      uv --version

  - name: "Smoke-test the workspace"
    run: ~/repos/my-service/scripts/healthcheck.sh

I passaggi post-build fanno fallire la build se restituiscono un codice di uscita diverso da zero. Se un passaggio post-build termina con un codice diverso da zero, la build viene segnata come non riuscita e non viene prodotta alcuna immagine snapshot. Usali per vincolare gli snapshot ai controlli di integrità, ma assicurati che i comandi siano affidabili, così un controllo intermittente non bloccherà le build.

I passaggi post-build usano gli stessi tipi di passaggio di initialize (comandi shell run e GitHub Actions uses) e vengono eseguiti dalla home directory (~).

clone

Per i blueprint a livello di repo, la sezione facoltativa clone sovrascrive i valori predefiniti usati quando Devin clona il repository nello snapshot. Ogni campo è facoltativo e, se non specificato, usa un valore predefinito appropriato che preserva il comportamento corrente.

clone:
  path: my-project        # destinazione del clone in ~/repos/ (default: nome breve del repo)
  ref: develop            # branch o tag da estrarre (default: branch predefinito del repo)
  depth: 1                # 0 = cronologia completa, N = --depth N (default: 0)
  tags: false             # false passa --no-tags (default: true)
  submodules: recursive   # true / false / "recursive" (default: true)
  lfs: false              # false imposta GIT_LFS_SKIP_SMUDGE=1 durante il clone (default: true)

Campo	Tipo	Predefinito	Descrizione
`path`	string	nome breve del repo	Esegue l’override della directory di destinazione del clone in `~/repos/`. Deve essere univoca tra i repo nello stesso snapshot.
`ref`	string	branch predefinito del repo	Branch o tag di cui eseguire il checkout dopo il clone. Gli SHA dei commit non sono supportati qui.
`depth`	int	`0`	Profondità del clone. `0` clona l’intera cronologia; qualsiasi valore positivo passa `--depth N` per un clone superficiale.
`tags`	bool	`true`	Quando è `false`, passa `--no-tags` per evitare di recuperare i tag Git.
`submodules`	bool or `"recursive"`	`true`	`true` o `"recursive"` passa `--recurse-submodules`. `false` ignora completamente i sottomoduli.
`lfs`	bool	`true`	Quando è `false`, imposta `GIT_LFS_SKIP_SMUDGE=1` per evitare di scaricare gli oggetti Git LFS durante il clone.

clone si applica solo ai blueprint a livello di repo: controlla come quello specifico repository viene clonato nello snapshot. Non ha alcun effetto nei blueprint a livello di organizzazione o blueprint a livello di Enterprise.

Tipi di passaggi

Ogni passaggio in initialize, maintenance o post-build usa uno di due tipi: comandi shell (run) o GitHub Actions (uses). I passaggi maintenance supportano solo run; vedi GitHub Actions.

Regole di abbreviazione e convalida

Una sezione specificata come semplice stringa diventa un unico passaggio run.
Un elemento di elenco specificato come semplice stringa diventa un passaggio run.
Un passaggio deve definire run oppure uses, ma non entrambi.
I passaggi uses non possono essere utilizzati in maintenance. La build non va a buon fine con l’errore 'uses' steps are not supported in maintenance sections.
with è valido solo nei passaggi uses.
Tutti i valori di with vengono convertiti in stringhe; racchiudi tra virgolette i valori numerici quando l’action prevede una stringa.

Regole per i documenti YAML

Ogni documento --- deve essere una mappatura YAML. Una sequenza al livello superiore viene rifiutata con each YAML document must be a mapping, not a sequence; use '---' to separate multiple blocks.

Comandi shell (`run`)

Esegui comandi shell personalizzati in bash:

- name: "Install dependencies"
  run: |
    npm install
    pip install -r requirements.txt

Campo	Tipo	Descrizione
`name`	string (optional)	Etichetta leggibile dall’utente del passaggio
`run`	string	Comandi shell da eseguire
`env`	map (optional)	Variabili d’ambiente aggiuntive per questo passaggio

Dettagli di esecuzione:

I comandi vengono eseguiti in bash. Se un comando in uno script su più righe non riesce, l’intero passaggio si interrompe immediatamente.
I blueprint a livello di org vengono eseguiti nella directory home (~).
I blueprint a livello di repo vengono eseguiti nella directory radice del repository clonato.
Ogni passaggio ha un timeout di 1 ora.
I secret sono automaticamente disponibili come variabili d’ambiente.

GitHub Actions (`uses`)

Esegui le GitHub Actions direttamente nella sezione initialize (o post-build) del tuo blueprint:

- name: "Install Python"
  uses: github.com/actions/setup-python@v5
  with:
    python-version: "3.12"

Campo	Tipo	Descrizione
`name`	string (opzionale)	Etichetta del passaggio leggibile dall’utente
`uses`	string	Riferimento a una GitHub Action
`with`	map (opzionale)	Parametri di input dell’azione
`env`	map (opzionale)	Variabili d’ambiente aggiuntive per questo passaggio

Formato del riferimento dell’azione:

github.com/<owner>/<repo>@<ref>
github.com/<owner>/<repo>/<subpath>@<ref>

Il prefisso github.com/ e il suffisso @<ref> sono entrambi obbligatori. Il ref è in genere un tag di versione come v5. Azioni di uso comune:

Azione	Scopo	Esempio di `with`
`github.com/actions/setup-python@v5`	Installare Python	`python-version: "3.12"`
`github.com/actions/setup-node@v4`	Installare Node.js	`node-version: "20"`
`github.com/actions/setup-go@v5`	Installare Go	`go-version: "1.22"`
`github.com/actions/setup-java@v4`	Installare Java/JDK	`java-version: "21"`, `distribution: "temurin"`
`github.com/gradle/actions/setup-gradle@v4`	Installare Gradle	(nessuno)
`github.com/ruby/setup-ruby@v1`	Installare Ruby	`ruby-version: "3.3"`

Sono supportate le azioni Node.js (node16, node20, node24) e le azioni composite. Le azioni Docker sono supportate solo nelle build Linux, non nelle build Windows. I passaggi di pulizia post vengono ignorati. Consulta le limitazioni di GitHub Actions.

I passaggi uses non sono supportati in maintenance. Le azioni possono essere eseguite solo durante initialize (e post-build); un passaggio uses in maintenance fa fallire la build.

Come funzionano i valori di with: I valori passati tramite with vengono forniti all’azione come input, seguendo le stesse convenzioni dei flussi di lavoro di GitHub Actions. Tutti i valori vengono convertiti in stringhe.

with:
  python-version: "3.12"
  check-latest: true
  cache: "pip"

Come le azioni propagano le modifiche: Le azioni possono modificare l’ambiente per i passaggi successivi. Ad esempio, setup-python aggiunge l’eseguibile di Python a PATH, che rimane disponibile in tutti i passaggi successivi e in maintenance.

`run` vs `uses`: quale usare

Usa `run` quando…	Usa `uses` quando…
Installi pacchetti di sistema (`apt-get`)	Imposti i runtime dei linguaggi (Python, Node, Go, Java, Ruby)
Esegui script specifici del progetto	Esiste una GitHub Action ufficiale per ciò che ti serve
Configuri file o l’ambiente	Vuoi la gestione automatica delle versioni e la cache
Il comando è semplice e indipendente	Useresti la stessa Action in un flusso di lavoro di GitHub Actions

In pratica, nella maggior parte delle configurazioni si usa uses per i runtime dei linguaggi e run per tutto il resto.

Variabili d’ambiente e segreti

Variabili d’ambiente a livello di singolo passaggio

Qualsiasi passaggio può definire variabili d’ambiente aggiuntive tramite il campo env:

- run: pip install -r requirements.txt
  env:
    PIP_INDEX_URL: "https://pypi.example.com/simple/"
    PIP_BREAK_SYSTEM_PACKAGES: "1"

Queste sono limitate a questo passaggio e non persistono nei passaggi successivi.

Variabili d’ambiente tra i passaggi (`$ENVRC`)

Per rendere disponibili le variabili d’ambiente tra i vari passaggi, scrivile nel file $ENVRC:

- name: "Set shared variables"
  run: |
    echo "DATABASE_URL=postgresql://localhost:5432/myapp" >> $ENVRC
    echo "APP_ENV=development" >> $ENVRC

Le variabili scritte in $ENVRC vengono esportate automaticamente e sono disponibili in tutti i passaggi successivi e nella sessione di Devin prodotta dalla build corrente. Funziona in modo analogo a $GITHUB_ENV in GitHub Actions. Questo vale anche per PATH. Se installi uno strumento in una directory non standard (qualsiasi directory al di fuori di /usr/bin o /usr/local/bin), aggiungila a $ENVRC in modo che i passaggi successivi e i blueprint a livello di repo possano trovare il binario:

- name: "Install latest direnv"
  run: |
    curl -sfL https://direnv.net/install.sh | bash
    echo 'export PATH="$HOME/.local/bin:$PATH"' >> $ENVRC

Un semplice export PATH=... all’interno di un blocco run: ha effetto solo sulla shell di quel passaggio. Ogni passaggio avvia un nuovo processo shell, quindi le modifiche a PATH che non vengono scritte in $ENVRC vanno perse.

Le azioni uses: (ad es. actions/setup-node) propagano automaticamente le aggiunte a PATH in $ENVRC — devi farlo manualmente solo per i passaggi run:.

$ENVRC viene reimpostato all’inizio di ogni build, incluse le build differenziali. I valori scritti durante una build non sono disponibili nella build successiva. In particolare, un workspace ereditato esegue solo maintenance, quindi non può fare affidamento su PATH o su altre variabili che initialize ha scritto in $ENVRC nella build di origine. Configura qualsiasi ambiente richiesto da maintenance all’interno di maintenance stessa.

Segreti

I segreti configurati nell’interfaccia di Devin (tramite la scheda Secrets in ogni editor di blueprint) vengono iniettati automaticamente come variabili d’ambiente. Non devi dichiararli nel blueprint. Ti basta richiamarli per nome (ad es. $MY_SECRET). I segreti vengono iniettati prima dell’esecuzione di ogni passaggio durante le build. Vengono rimossi dall’immagine snapshot stessa, quindi le credenziali non vengono mai incorporate nelle immagini macchina salvate. Al di fuori dei comandi dei blueprint, i segreti non vengono esportati in ogni shell; Devin li associa ai comandi specifici che ne hanno bisogno.

Segreti dell’organizzazione: Disponibili come variabili d’ambiente in ogni passaggio di tutti i blueprint dell’org. Impostali nella scheda Secrets dell’editor del blueprint per tutta l’org.
Segreti Enterprise: Uniti ai segreti dell’org (i segreti dell’org hanno la precedenza in caso di conflitto di nomi). Disponibili in tutte le org dell’Enterprise.
Segreti del repository: Disponibili come variabili d’ambiente nei passaggi e nei comandi del blueprint di quel repo. Configurali nella scheda Secrets dell’editor del blueprint del repository.

Segreti solo build: I segreti Enterprise possono essere contrassegnati come Build only quando li aggiungi nella scheda Secrets dell’editor del blueprint Enterprise. Questa opzione non è disponibile per i segreti dell’org o del repository. Un segreto solo build è disponibile unicamente per i passaggi dei blueprint Enterprise e dell’org durante le build snapshot. Viene rimosso prima che i repository vengano clonati, quindi i passaggi dei blueprint del repo e i passaggi post-build non possono leggerlo, e non viene mai iniettato nelle sessioni Devin. Usalo per credenziali necessarie solo durante la configurazione Enterprise o dell’org (ad es. per scaricare artifact privati nell’initialize del blueprint Enterprise).

maintenance viene eseguito durante le build. All’inizio della sessione, i comandi maintenance vengono esposti all’agente (non eseguiti automaticamente), quindi l’agente può eseguirli di nuovo se necessario. Se un passaggio maintenance scrive segreti nei file di configurazione (ad es. ~/.m2/settings.xml, ~/.npmrc), questi file verranno incorporati nello snapshot. Inserisci i passaggi che scrivono credenziali in maintenance (non in initialize) in modo che vengano aggiornati durante le build periodiche, ma tieni presente che i file generati restano nell’immagine. Per la massima sicurezza, usa variabili d’ambiente o $ENVRC invece di scrivere le credenziali su disco.

File allegati

Puoi caricare file (come settings.xml o altri file di configurazione) tramite l’editor dei blueprint. I file caricati vengono salvati in ~/.files/ e viene impostata una variabile d’ambiente che punta al percorso di ciascun file:

$FILE_SETTINGS_XML    -> /home/ubuntu/.files/settings.xml
$FILE_NPMRC           -> /home/ubuntu/.files/npmrc

Il nome della variabile deriva dal nome del file: in maiuscolo, con i caratteri non alfanumerici sostituiti da trattini bassi (i trattini bassi iniziali e finali vengono rimossi) e con il prefisso FILE_. I nomi dei file devono essere nomi semplici: non possono iniziare con un punto né contenere separatori di percorso, spazi o caratteri di controllo. Per usare un dotfile come .npmrc, caricalo con un nome senza il punto iniziale (per esempio, npmrc) e copialo nella posizione corretta in un passaggio del blueprint. Usa file allegati nei passaggi del blueprint:

maintenance:
  - name: "Configure Maven"
    run: |
      mkdir -p ~/.m2
      cp "$FILE_SETTINGS_XML" ~/.m2/settings.xml
  - name: "Configure npm"
    run: cp "$FILE_NPMRC" ~/.npmrc

Blueprint basati su Git

Puoi archiviare i blueprint come file .devin/blueprint.yaml direttamente nel tuo repository e poi sincronizzarli tramite l’API o la UI. Consulta Git-backed blueprints per le istruzioni di configurazione e i dettagli.

Esempio completo

Per capire come i blueprint si compongono nei vari livelli (enterprise → org → repo), gli stati delle build, gli stati del repository e cosa attiva una nuova build, consulta Build e sessioni nella pagina della configurazione dichiarativa.

Blueprint per tutta l’org

Strumenti condivisi necessari a ogni repo dell’org. Viene eseguito per primo (dopo eventuali blueprint Enterprise), nella directory home.

initialize:
  - name: "Install Node.js 20"
    uses: github.com/actions/setup-node@v4
    with:
      node-version: "20"

  - name: "Install Python 3.12 and uv"
    run: |
      curl -LsSf https://astral.sh/uv/install.sh | sh

  - name: "Install shared tools"
    run: |
      npm install -g pnpm turbo
      apt-get update && apt-get install -y jq ripgrep

  - name: "Configure private registry"
    run: |
      echo "//npm.corp.example.com/:_authToken=$NPM_REGISTRY_TOKEN" >> ~/.npmrc

Blueprint a livello di repo

Configurazione specifica del progetto per un monorepo Node.js + Python. Viene eseguito dopo il blueprint per tutta l’org, nella directory del repository.

initialize:
  - name: "Install Playwright browsers"
    run: npx playwright install --with-deps chromium

  - name: "Set up project environment variables"
    run: |
      echo "DATABASE_URL=postgresql://localhost:5432/myapp_dev" >> $ENVRC
      echo "REDIS_URL=redis://localhost:6379" >> $ENVRC
      echo "APP_ENV=development" >> $ENVRC

maintenance:
  - name: "Install frontend dependencies"
    run: |
      cd frontend
      pnpm install

  - name: "Install backend dependencies"
    run: |
      cd backend
      uv sync

  - name: "Run database migrations"
    run: |
      cd backend
      uv run alembic upgrade head
    env:
      DATABASE_URL: "postgresql://localhost:5432/myapp_dev"

knowledge:
  - name: lint
    contents: |
      Frontend:
      cd frontend && pnpm lint

      Backend:
      cd backend && uv run ruff check .

      Auto-fix:
      cd frontend && pnpm lint --fix
      cd backend && uv run ruff check --fix .

  - name: test
    contents: |
      Frontend unit tests:
      cd frontend && pnpm test

      Backend unit tests:
      cd backend && uv run pytest

      E2E tests (requires dev server running):
      cd frontend && pnpm test:e2e

  - name: build
    contents: |
      Frontend:
      cd frontend && pnpm build

      Backend:
      cd backend && uv run python -m build

  - name: dev-server
    contents: |
      Start the full development stack:
      cd backend && uv run uvicorn main:app --reload &
      cd frontend && pnpm dev

      Frontend: http://localhost:3000
      Backend API: http://localhost:8000
      API docs: http://localhost:8000/docs

  - name: database
    contents: |
      Run migrations:
      cd backend && uv run alembic upgrade head

      Create a new migration:
      cd backend && uv run alembic revision --autogenerate -m "description"

      Reset the database:
      cd backend && uv run alembic downgrade base && uv run alembic upgrade head

Introduzione

Guide fondamentali

Introduzione a Devin

Lavorare con Devin

Guide sul prodotto

Integrazioni

Admin

Note di rilascio

Riferimento del blueprint

Panoramica

initialize

Forma semplice

Formato strutturato

Quando usare initialize anziché maintenance

maintenance

knowledge

runs-on

includes

post-build

clone

Tipi di passaggi

Regole di abbreviazione e convalida

Regole per i documenti YAML

Comandi shell (`run`)

GitHub Actions (`uses`)

`run` vs `uses`: quale usare

Variabili d’ambiente e segreti

Variabili d’ambiente a livello di singolo passaggio

Variabili d’ambiente tra i passaggi (`$ENVRC`)

Segreti

File allegati

Blueprint basati su Git

Esempio completo

Blueprint per tutta l’org

Blueprint a livello di repo

​Panoramica

​initialize

​Forma semplice

​Formato strutturato

​Quando usare initialize anziché maintenance

​maintenance

​knowledge

​runs-on

​includes

​post-build

​clone

​Tipi di passaggi

​Regole di abbreviazione e convalida

​Regole per i documenti YAML

​Comandi shell (run)

​GitHub Actions (uses)

​run vs uses: quale usare

​Variabili d’ambiente e segreti

​Variabili d’ambiente a livello di singolo passaggio

​Variabili d’ambiente tra i passaggi ($ENVRC)

​Segreti

​File allegati

​Blueprint basati su Git

​Esempio completo

​Blueprint per tutta l’org

​Blueprint a livello di repo

Panoramica

initialize

Forma semplice

Formato strutturato

Quando usare initialize anziché maintenance

maintenance

knowledge

runs-on

includes

post-build

clone

Tipi di passaggi

Regole di abbreviazione e convalida

Regole per i documenti YAML

Comandi shell (`run`)

GitHub Actions (`uses`)

`run` vs `uses`: quale usare

Variabili d’ambiente e segreti

Variabili d’ambiente a livello di singolo passaggio

Variabili d’ambiente tra i passaggi (`$ENVRC`)

Segreti

File allegati

Blueprint basati su Git

Esempio completo

Blueprint per tutta l’org

Blueprint a livello di repo