Les probes « armé » du checkpoint (checkpoint-status.sh, checkpoint-relink-env.sh) appellent GET /users/info, qui exige le droit Dolibarr 251 (user->user->lire, « Read information of other users, groups and permissions » — vérifié dans llx_rights_def de la sandbox). Sans 251, l'endpoint répond HTTP 403 alors que la clé authentifie (GET /thirdparties → 200) : le checkpoint affichait NOT armed sur un agent pourtant fonctionnel.
Le 251 a été accordé live en SQL sur la sandbox aujourd'hui (fk_user=4) et le probe passe désormais. Cette PR pérennise le droit côté code pour que tout provision frais l'accorde.
Ce qui change
test/provisionSandbox.ts — 251, // user lire ajouté à WRITE_IDS, la liste que userSetup.assignRights accorde réellement lors d'un provision (c'est le chemin committé exécuté par arcodange sandbox checkpoint provision).
checkpoint-status.sh / checkpoint-relink-env.sh — le parseur du probe distingue désormais les modes d'échec au lieu d'un message opaque :
200 → ARMED — login=… id=…
401 → clé rejetée (stale / ré-encryptée par un refresh iso-prod) → relancer provision
403 → clé OK mais droit 251 manquant → re-provisionner ou accorder 251 (WRITE_IDS, test/provisionSandbox.ts)
Le probe reste GET /users/info (251 fait maintenant partie du set standard). Sémantique d'exit inchangée (status = rapport, exit 0 ; relink-env = exit 1 si échec).
.claude/skills/dolibarr-sandbox-checkpoint/SKILL.md — le bullet status documente les trois issues du probe ; le bullet provision mentionne user lire/251.
.claude/skills/dolibarr-sandbox-write/SKILL.md — gotcha user lire (251), en miroir du gotcha banque lire (111).
test/README.md — table « Write rights granted » resynchronisée sur WRITE_IDS : ajout de la ligne user lire=251, et au passage des droits déjà accordés mais absents de la table (client voir=262, banque lire=111).
Vérification
bash -n OK sur les deux scripts ; deno check provisionSandbox.ts OK.
Les parseurs embarqués testés hors-ligne avec des corps fixtures 200 / 401 / 403 / 500 / garbage → messages et codes d'exit attendus.
checkpoint-status.sh (version modifiée, lecture seule) exécuté contre la sandbox live : ARMED — login=ai_agent_sandbox id=4. Aucune écriture sandbox/prod.
Note
test/scripts/admin/permissions.ts (système de scopes invoice-creator/supplier-ingest) est du WIP non committé dans le trunk — jamais dans l'historique git, donc absent de ce worktree et volontairement non absorbé par cette PR. Quand ce fichier atterrira, ajouter la même ligne à ses scopes d'écriture : 251, // user lire — requis par le probe armé GET /users/info (checkpoint status/relink).
## Contexte (vérifié live le 2026-07-11)
Les probes « armé » du checkpoint (`checkpoint-status.sh`, `checkpoint-relink-env.sh`) appellent `GET /users/info`, qui exige le droit Dolibarr **251** (`user->user->lire`, « Read information of other users, groups and permissions » — vérifié dans `llx_rights_def` de la sandbox). Sans 251, l'endpoint répond **HTTP 403 alors que la clé authentifie** (`GET /thirdparties` → 200) : le checkpoint affichait `NOT armed` sur un agent pourtant fonctionnel.
Le 251 a été accordé **live en SQL** sur la sandbox aujourd'hui (`fk_user=4`) et le probe passe désormais. Cette PR pérennise le droit côté code pour que **tout provision frais** l'accorde.
## Ce qui change
- **`test/provisionSandbox.ts`** — `251, // user lire` ajouté à `WRITE_IDS`, la liste que `userSetup.assignRights` accorde réellement lors d'un provision (c'est le chemin committé exécuté par `arcodange sandbox checkpoint provision`).
- **`checkpoint-status.sh` / `checkpoint-relink-env.sh`** — le parseur du probe distingue désormais les modes d'échec au lieu d'un message opaque :
- **200** → `ARMED — login=… id=…`
- **401** → clé rejetée (stale / ré-encryptée par un refresh iso-prod) → relancer `provision`
- **403** → clé OK mais droit 251 manquant → re-provisionner ou accorder 251 (`WRITE_IDS`, `test/provisionSandbox.ts`)
- Le probe reste `GET /users/info` (251 fait maintenant partie du set standard). Sémantique d'exit inchangée (`status` = rapport, exit 0 ; `relink-env` = exit 1 si échec).
- **`.claude/skills/dolibarr-sandbox-checkpoint/SKILL.md`** — le bullet `status` documente les trois issues du probe ; le bullet `provision` mentionne `user lire`/251.
- **`.claude/skills/dolibarr-sandbox-write/SKILL.md`** — gotcha `user lire` (251), en miroir du gotcha `banque lire` (111).
- **`test/README.md`** — table « Write rights granted » resynchronisée sur `WRITE_IDS` : ajout de la ligne `user lire=251`, et au passage des droits déjà accordés mais absents de la table (`client voir=262`, `banque lire=111`).
## Vérification
- `bash -n` OK sur les deux scripts ; `deno check provisionSandbox.ts` OK.
- Les parseurs embarqués testés hors-ligne avec des corps fixtures 200 / 401 / 403 / 500 / garbage → messages et codes d'exit attendus.
- `checkpoint-status.sh` (version modifiée, lecture seule) exécuté contre la sandbox live : `ARMED — login=ai_agent_sandbox id=4`. Aucune écriture sandbox/prod.
## Note
`test/scripts/admin/permissions.ts` (système de scopes `invoice-creator`/`supplier-ingest`) est du **WIP non committé dans le trunk** — jamais dans l'historique git, donc absent de ce worktree et volontairement non absorbé par cette PR. Quand ce fichier atterrira, ajouter la même ligne à ses scopes d'écriture : `251, // user lire — requis par le probe armé GET /users/info (checkpoint status/relink)`.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
The checkpoint status/relink-env armed probe calls GET /users/info, which
requires Dolibarr right 251 (user->user->lire). WRITE_IDS didn't include it,
so a freshly provisioned agent answered 403 on the probe — reported NOT armed
— while its key actually authenticates (GET /thirdparties -> 200). Right 251
was granted live in SQL on the sandbox (fk_user=4) today; this persists it in
WRITE_IDS so every future provision grants it.
Also teach both probes to tell the failure modes apart instead of one opaque
message: 401 = key rejected (stale/instance-encrypted -> re-provision),
403 = key OK but right 251 missing (-> grant it / re-provision), 200 = armed.
Docs updated accordingly (checkpoint SKILL.md probe outcomes, sandbox-write
SKILL.md gotcha, test/README.md rights table synced to WRITE_IDS incl. 262/111).
Co-Authored-By: Claude Fable 5 <[email protected]>
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Contexte (vérifié live le 2026-07-11)
Les probes « armé » du checkpoint (
checkpoint-status.sh,checkpoint-relink-env.sh) appellentGET /users/info, qui exige le droit Dolibarr 251 (user->user->lire, « Read information of other users, groups and permissions » — vérifié dansllx_rights_defde la sandbox). Sans 251, l'endpoint répond HTTP 403 alors que la clé authentifie (GET /thirdparties→ 200) : le checkpoint affichaitNOT armedsur un agent pourtant fonctionnel.Le 251 a été accordé live en SQL sur la sandbox aujourd'hui (
fk_user=4) et le probe passe désormais. Cette PR pérennise le droit côté code pour que tout provision frais l'accorde.Ce qui change
test/provisionSandbox.ts—251, // user lireajouté àWRITE_IDS, la liste queuserSetup.assignRightsaccorde réellement lors d'un provision (c'est le chemin committé exécuté pararcodange sandbox checkpoint provision).checkpoint-status.sh/checkpoint-relink-env.sh— le parseur du probe distingue désormais les modes d'échec au lieu d'un message opaque :ARMED — login=… id=…provisionWRITE_IDS,test/provisionSandbox.ts)GET /users/info(251 fait maintenant partie du set standard). Sémantique d'exit inchangée (status= rapport, exit 0 ;relink-env= exit 1 si échec)..claude/skills/dolibarr-sandbox-checkpoint/SKILL.md— le bulletstatusdocumente les trois issues du probe ; le bulletprovisionmentionneuser lire/251..claude/skills/dolibarr-sandbox-write/SKILL.md— gotchauser lire(251), en miroir du gotchabanque lire(111).test/README.md— table « Write rights granted » resynchronisée surWRITE_IDS: ajout de la ligneuser lire=251, et au passage des droits déjà accordés mais absents de la table (client voir=262,banque lire=111).Vérification
bash -nOK sur les deux scripts ;deno check provisionSandbox.tsOK.checkpoint-status.sh(version modifiée, lecture seule) exécuté contre la sandbox live :ARMED — login=ai_agent_sandbox id=4. Aucune écriture sandbox/prod.Note
test/scripts/admin/permissions.ts(système de scopesinvoice-creator/supplier-ingest) est du WIP non committé dans le trunk — jamais dans l'historique git, donc absent de ce worktree et volontairement non absorbé par cette PR. Quand ce fichier atterrira, ajouter la même ligne à ses scopes d'écriture :251, // user lire — requis par le probe armé GET /users/info (checkpoint status/relink).🤖 Generated with Claude Code