> ## Documentation Index
> Fetch the complete documentation index at: https://docs.devin.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Riferimento del blueprint

> Riferimento completo ai campi dei blueprint: sezioni, tipi di passaggio, GitHub Actions, variabili d'ambiente, segreti e file allegati.

<Info>
  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](/it/onboard-devin/environment/blueprints).
</Info>

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

<div id="overview">
  ## Panoramica
</div>

Un blueprint comprende tre sezioni principali di primo livello, oltre a una sezione `post-build` per i blueprint a livello di org ed enterprise e a una sezione `clone` facoltativa per i blueprint a livello di repo:

```yaml theme={null}
initialize: ...   # Install tools and runtimes
maintenance: ...  # Install project dependencies
knowledge: ...    # Reference info for Devin (never executed)
post-build: ...   # (Solo org/enterprise) Comandi eseguiti al termine di tutta la configurazione
clone: ...        # (Repo-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                                                                          |
| `post-build`  | Comandi eseguiti dopo che tutte le repo sono state clonate e configurate (solo org/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 repo)   | 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](/it/onboard-devin/environment/differential-builds), 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).

<div id="initialize">
  ## initialize
</div>

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

<div id="simple-form">
  ### Forma semplice
</div>

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

```yaml theme={null}
initialize: |
  curl -LsSf https://astral.sh/uv/install.sh | sh
  apt-get update && apt-get install -y build-essential
  npm install -g pnpm
```

<div id="structured-form">
  ### Formato strutturato
</div>

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

```yaml theme={null}
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`.

<div id="when-to-use-initialize-vs-maintenance">
  ### Quando usare initialize anziché maintenance
</div>

| 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`.

<div id="maintenance">
  ## maintenance
</div>

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.

```yaml theme={null}
maintenance: |
  npm install
  pip install -r requirements.txt
```

Oppure in formato strutturato:

```yaml theme={null}
maintenance:
  - name: "Install npm dependencies"
    run: npm install

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

<Info>
  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 (`~`).
</Info>

<div id="knowledge">
  ## knowledge
</div>

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.

```yaml theme={null}
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:

```yaml theme={null}
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
```

<div id="post-build">
  ## post-build
</div>

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ù repo 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 repo clonata e a ogni strumento installato dai blueprint di Enterprise, org e repo.

```yaml theme={null}
post-build: |
  # Verifica che l'environment assemblato sia integro
  node --version
  python --version
  test -d ~/repos/my-service
```

Oppure in forma strutturata:

```yaml theme={null}
post-build:
  - name: "Verify toolchain"
    run: |
      node --version
      uv --version

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

<Warning>
  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.
</Warning>

<Info>
  I passaggi `post-build` usano gli stessi [tipi di passaggio](#step-types) di `initialize` e `maintenance` (comandi shell `run` e GitHub Actions `uses`) e vengono eseguiti dalla home directory (`~`).
</Info>

<div id="clone">
  ## clone
</div>

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.

```yaml theme={null}
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.                 |

<Info>
  `clone` si applica solo ai blueprint **a livello di repo**: controlla come quello specifico repo viene clonato nello snapshot. Non ha alcun effetto nei blueprint a livello di org o enterprise-level.
</Info>

<div id="step-types">
  ## Tipi di passaggi
</div>

Ogni passaggio in `initialize`, `maintenance` o `post-build` usa uno di due tipi: comandi shell (`run`) o GitHub Actions (`uses`).

<div id="shell-commands-run">
  ### Comandi shell (`run`)
</div>

Esegui comandi shell personalizzati in bash:

```yaml theme={null}
- 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.

<div id="github-actions-uses">
  ### GitHub Actions (`uses`)
</div>

Esegui direttamente nel tuo blueprint le GitHub Actions basate su Node.js:

```yaml theme={null}
- 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"`                           |

<Warning>Sono supportate solo le GitHub Actions **basate su Node.js**. Le azioni composite e quelle basate su Docker non sono supportate.</Warning>

**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.

```yaml theme={null}
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`.

<div id="run-vs-uses-which-to-use">
  ### `run` vs `uses`: quale usare
</div>

| 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.

<div id="environment-variables-and-secrets">
  ## Variabili d'ambiente e segreti
</div>

<div id="step-level-environment-variables">
  ### Variabili d'ambiente a livello di singolo passaggio
</div>

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

```yaml theme={null}
- 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.

<div id="cross-step-environment-variables-envrc">
  ### Variabili d'ambiente tra i passaggi (`$ENVRC`)
</div>

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

```yaml theme={null}
- 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:

```yaml theme={null}
- 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.

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

`$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.

<script src="/anchor-scroll-fix.js" />

<div id="secrets">
  ### Segreti
</div>

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 **e** nuovamente all'inizio di ogni sessione. Vengono rimossi dall'immagine snapshot stessa, quindi le credenziali non vengono mai incorporate nelle immagini macchina salvate.

* **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**: Scritti in un file dedicato per repo in `/run/repo_secrets/{owner/repo}/.env.secrets`. Durante le build, i segreti del repo vengono caricati automaticamente prima dell'esecuzione dei passaggi del blueprint di quel repo. Durante la sessione, Devin li carica quando lavora nel repo. Configurali nella scheda **Secrets** dell'editor del blueprint del repository.

<Info>
  **Segreti solo build**: I segreti contrassegnati come "build only" sono disponibili durante le build snapshot, ma vengono rimossi prima che lo snapshot venga salvato. Usali per credenziali necessarie solo in fase di build (ad es.
  per scaricare artifact privati durante `initialize`).
</Info>

<Warning>
  `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.
</Warning>

<div id="file-attachments">
  ### File allegati
</div>

Puoi caricare file (come `.npmrc`, `settings.xml` e 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 e con il prefisso `FILE_`.

Usa file allegati nei passaggi del blueprint:

```yaml theme={null}
maintenance:
  - name: "Configure Maven"
    run: |
      mkdir -p ~/.m2
      cp "$FILE_SETTINGS_XML" ~/.m2/settings.xml
```

<div id="git-backed-blueprints">
  ## Blueprint basati su Git
</div>

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](/it/onboard-devin/environment/git-backed-blueprints) per le istruzioni di configurazione e i dettagli.

<div id="complete-example">
  ## Esempio completo
</div>

<Info>
  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](/it/onboard-devin/environment/blueprints#builds-and-sessions) nella pagina della configurazione dichiarativa.
</Info>

<div id="org-wide-blueprint">
  ### Blueprint per tutta l'org
</div>

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

```yaml theme={null}
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
```

<div id="repo-level-blueprint">
  ### Blueprint a livello di repo
</div>

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

```yaml theme={null}
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
```