erp/.claude/skills/dolibarr-sandbox-write/SKILL.md

---
name: dolibarr-sandbox-write
description: >-
  WRITE operations against the Arcodange Dolibarr SANDBOX (erp-sandbox.arcodange.lab)
  — the rehearsal environment where an AI agent records thirdparties, invoices and
  payments before any change is promoted to prod. Create client/supplier fiches
  (auto-coded), customer + supplier invoices with product/service lines and the
  supplier's own reference, validate them, and record règlements (payments). Every
  write goes through dol-write.sh, which REFUSES any host that is not the sandbox —
  the structural guarantee (ADR-0003) that this skill can never mutate production.
  Use when the user asks to "create a thirdparty / supplier / client fiche", "saisir
  une facture", "record an invoice with lines", "enregistrer un règlement / paiement",
  or to rehearse a write before promoting it to prod. SKIP for production writes
  (prod stays read-only via the `dolibarr` skill's `ai_agent` key; promotion is a
  separate, human-gated replay), and for credit notes/avoirs (a planned follow-up).
  Depends on the write-scoped `ai_agent_sandbox` Dolibarr user + its API key.
requires:
  bins: [bash, curl, python3]
  auth: ".env with DOLIBARR_SANDBOX_URL + DOLIBARR_SANDBOX_API_KEY (mode 600, gitignored)"
---

# dolibarr-sandbox-write

Write-capable companion to the read-only `dolibarr*` skills, scoped to the
**sandbox**. It exists so an AI agent can *rehearse* bookkeeping writes against a
faithful copy of prod (see ADR-0003 + the `ops/sandbox/` seed tooling), then a
human promotes the reviewed change to prod.

## The safety model (read this first)

- **Host guard.** `scripts/dol-write.sh` reads `DOLIBARR_SANDBOX_URL` from `.env`
  and refuses to send any request unless it matches `erp-sandbox.arcodange.lab`.
  Point it at `erp.arcodange.lab` (prod) and it exits non-zero *before* the
  request. This is the structural reason the skill cannot write prod.
- **Credential scope.** The key is `ai_agent_sandbox`'s — valid only on the
  sandbox host, with create+read rights on thirdparties / invoices / supplier
  invoices / products / contacts (+ `societe client voir`). Prod's `ai_agent`
  key is read-only and lives in a different skill's `.env`.
- **Resettable.** Anything written here is wiped by `ops/sandbox/sandbox-lifecycle.sh
  refresh-from-prod`, so mistakes cost a reset, not data.
- **Promotion to prod is gated, not automatic.** Rehearse here → review the
  change-set (`promote-plan.sh`) → replay it on prod (`promote-apply.sh --target
  prod`). The prod write key is supplied via the **environment at apply time**
  (`DOLIBARR_PROD_WRITE_KEY`), never stored in any `.env`, and `dol-prod-write.sh`
  refuses every prod write unless `ARCO_PROMOTE_CONFIRM=I-UNDERSTAND-THIS-WRITES-PROD`.
  See "Promote to prod" below.

## Setup

Create `.env` (mode 600, gitignored) next to `scripts/`:

```sh
cd .claude/skills/dolibarr-sandbox-write
umask 077
{ echo "DOLIBARR_SANDBOX_URL=https://erp-sandbox.arcodange.lab"
  printf 'DOLIBARR_SANDBOX_API_KEY=%s\n' "$(cat /path/to/.ai_agent_sandbox.key)"; } > .env
```

The key is produced by the Playwright provisioner in the repo's `test/`
(`provisionSandbox.ts` → `.ai_agent_sandbox.key`). Verify: `scripts/dol-write.sh
GET /status` should return HTTP 200 with `"environment":"non-production"`.

## Workflows

All three read a JSON object on **stdin** (or a file path as `$1`) and emit ids.

### 1 · Thirdparty (fiche client/fournisseur) — `scripts/thirdparty-create.sh`

```sh
echo '{"name":"KissMetrics","role":"client","tva_intra":"US.."}' | scripts/thirdparty-create.sh
echo '{"name":"OVH","role":"supplier","siret":"..."}'            | scripts/thirdparty-create.sh
```
`role`: `client` | `supplier` | `both`. Codes auto-assign from the mask
(`CL{0000}` / `FO{0000}`) via the `-1` sentinel; pass `client_code`/`supplier_code`
to override. Optional: `country_id` (default 1=FR), `siret`, `tva_intra`,
`address`, `zip`, `town`, `email`, `phone`, `idprof1`. Emits the new id.

### 2 · Invoice (facture) — `scripts/invoice-create.sh`

```sh
echo '{"socid":42,"kind":"customer","validate":true,
       "lines":[{"desc":"Conseil","qty":2,"price_ht":500,"tva":20,"type":"service"},
                {"desc":"Licence","qty":1,"price_ht":100,"tva":20,"type":"product"}]}' \
  | scripts/invoice-create.sh
# supplier invoice carrying the supplier's own reference:
echo '{"socid":7,"kind":"supplier","ref_supplier":"INV-2026-042","validate":true,
       "lines":[{"desc":"Hosting","qty":1,"price_ht":80,"tva":20,"type":"service"}]}' \
  | scripts/invoice-create.sh
```
`kind`: `customer` (`/invoices`) | `supplier` (`/supplierinvoices`). Lines carry
`desc, qty, price_ht, tva, type` (product|service) and optional `product_id`
(`fk_product`) to link a catalogue product. Totals + TVA are computed by Dolibarr.
`validate:true` turns the draft (`PROV…`) into a final numbered invoice; omit it
to leave a draft. Emits `{id, ref, ref_supplier, total_ht, total_ttc, statut}`.

### 3 · Payment (règlement) — `scripts/payment-record.sh`

```sh
echo '{"invoice_id":19,"mode":"VIR","account_id":1,"transaction_id":"2159468139"}' | scripts/payment-record.sh
echo '{"invoice_id":13,"kind":"supplier","mode":"VIR","account_id":1,"amount":96,
       "transaction_id":"arcodange-1246-1-transaction-019f14c5-e254-7ac9-9e9f-307ed9-d55f44"}' \
  | scripts/payment-record.sh   # stores num 019f14c5-e254-7ac9-9e9f-307ed9-d55f44
```
The invoice must be **validated** first. `mode`: `VIR|CB|CHQ|LIQ`. Customer
payments settle the full remaining amount and mark the invoice paid; **supplier**
payments require an explicit `amount`. `account_id` is the bank account id — list
them with `scripts/bank-accounts.sh` (`ai_agent_sandbox` now holds `banque lire`).

**Always pass `transaction_id`** — the originating bank transaction id (the
Qonto/Wise tx id from the feed). It is the first-class way to tie a règlement to
the real bank movement: stored on the payment's bank line (`llx_bank.num_chq`), so
reconciliation matches **by id** rather than by fuzzy amount/date. (`num` is a
back-compat alias for the same field.) Recording without it prints a warning — the
payment still posts, but it won't auto-reconcile.

**Canonical short form — the varchar(50) constraint.** Dolibarr stores
`num_payment` in **varchar(50)** columns (`llx_paiement.num_paiement`,
`llx_paiementfourn.num_paiement`) while Qonto transaction ids run ~67 chars
(`<org>-<n>-<n>-transaction-<uuid>`) — POSTing one raw fails with HTTP 400
"value too long for type character varying(50)". The script therefore normalizes
before POST: everything through `transaction-` is stripped and the **UUID suffix**
(globally unique, ~37 chars) is what gets stored. Wise ids (short numerics) pass
through unchanged. An id still >50 chars after normalization is **refused** with
an explicit error — never truncated silently. `arcodange-bank-reco`'s bank-match
normalizes feed ids the same way, so short-form nums keep reconciling by id
(historical long-form nums too). Pass the raw feed id; the script does the rest.

Emits **`{id, bank_transaction_id, transaction_id}`**. `bank_transaction_id` is the
Dolibarr bank line (`llx_bank.fk_bank_line`) the payment created — the id the
reconciliation (`arcodange-bank-reco`) keys on. `transaction_id` echoes the
**normalized** num actually stored. Both ends are captured at write time.

### 4 · Credit note (avoir) — `scripts/creditnote-create.sh`

```sh
# customer avoir
echo '{"socid":42,"source_invoice":19,"validate":true,
       "lines":[{"desc":"Avoir partiel conseil","qty":1,"price_ht":100,"tva":20,"type":"service"}]}' \
  | scripts/creditnote-create.sh
# supplier avoir (avoir fournisseur)
echo '{"socid":12,"kind":"supplier","source_invoice":17,"ref_supplier":"AV-2026-77","validate":true,
       "lines":[{"desc":"Avoir hosting","qty":1,"price_ht":120,"tva":20,"type":"service"}]}' \
  | scripts/creditnote-create.sh
```
An invoice of `type=2` referencing `source_invoice` (`fk_facture_source`); amounts
come out negative. `kind:"supplier"` targets `/supplierinvoices` (carry
`ref_supplier`); default `customer` targets `/invoices`. `validate:true` numbers it
(`AVC…` for customer, `AVF…` for supplier). Emits `{id, ref, ref_supplier, total_ht,
total_ttc, fk_facture_source, statut}`.

## Promote to prod (rehearse → review → replay)

The ADR-0003 capstone: take a change rehearsed in the sandbox and apply the **same
operations** to prod, with a human in the loop. The unit is a **manifest** — a JSON
array of write ops using **symbolic refs** (`@name`) instead of ids, so it is
portable from sandbox to prod (an invoice references `@tp1`, the thirdparty created
earlier in the run). See `examples/promote-manifest.json`.

```sh
scripts/promote-plan.sh  change.json                      # 1. human-readable review
scripts/promote-apply.sh change.json --target sandbox     # 2. rehearse the replay (safe)
# 3. promote — writes PROD; the key is env-only and the confirm flag is mandatory:
DOLIBARR_PROD_WRITE_KEY="<prod write key>" \
ARCO_PROMOTE_CONFIRM=I-UNDERSTAND-THIS-WRITES-PROD \
  scripts/promote-apply.sh change.json --target prod
```

`promote-apply` resolves each `@ref` to the id actually created during the run, so
dependent ops wire up on the target. `--target sandbox` writes via `dol-write.sh`;
`--target prod` writes via `dol-prod-write.sh`, which reads `DOLIBARR_PROD_WRITE_KEY`
**from the environment only** (never a stored `.env`) and refuses any write unless
`ARCO_PROMOTE_CONFIRM` is set exactly. Pair it with `dolibarr-data-snapshot` (prod
before/after) to confirm only the intended records changed.

A manifest value can reference another entity two ways, both resolved against the
**target** so the same file is portable sandbox↔prod:

- **`@ref`** — an entity **created earlier in this manifest** (resolves to the id
  just created on the target). For new records.
- **`#entity:field=value`** — a **pre-existing** entity, looked up on the target by
  business key, e.g. `#thirdparty:name=KissMetrics` or `#thirdparty:code=CL0007`.
  Supports `thirdparty` (name/code/supplier_code) and `invoice`/`supplierinvoice`
  (ref/ref_supplier). A lookup matching **nothing or more than one** record **aborts
  the run** — it never guesses, so it can't write to the wrong entity.

So a real change like "invoice the existing client KissMetrics and record its
payment" is `{"socid":"#thirdparty:name=KissMetrics", ...}` — it resolves to the
sandbox KissMetrics on `--target sandbox` and the prod one on `--target prod`.

## Gotchas

- **Validate before paying.** A draft (`statut=0`, ref `PROV…`) cannot be paid.
- **Codes.** The thirdparty code module is `mod_codeclient_elephant` (auto). The
  REST create needs `code_client`/`code_fournisseur = "-1"` to trigger it — the
  script does this; without it the API errors `ErrorCustomerCodeRequired`.
- **Dates** are sent as Unix epochs; pass `date:"YYYY-MM-DD"` or omit for today.
- **Qonto tx ids don't fit varchar(50).** `payment-record.sh` strips the
  `<org>-<n>-<n>-transaction-` prefix and stores the UUID suffix (see workflow 3);
  ids still >50 chars after that are refused. Offline proof: `tests/run-tests.sh`
  (stubbed `dol-write.sh` via the `DOL_WRITE` hook — writes nothing anywhere).
- **`banque lire`** (rights id 111) is granted → `scripts/bank-accounts.sh` lists
  accounts (id/label/bank) so a payment can pick its `account_id`. It's in the
  provisioner's `WRITE_IDS`, so a fresh `provisionSandbox.ts` run includes it.
- **Avoirs (credit notes)** → `creditnote-create.sh` (customer invoice `type=2`
  referencing `source_invoice`; amounts negative, ref `AVC…`). Supplier avoirs
  are a follow-up.
- **CLI:** all of these are also `arcodange sandbox {thirdparty|invoice|payment|creditnote|write}`
  (JSON on stdin) — `arcodange sandbox help` for the list.