Les gardes

Une garde est une politique évaluée avant qu'une action soit réservée — ou lue (voir Politiques : tout est politique). Les gardes forment une liste ordonnée, déclarée sur la skill et, en plus, sur une tâche de playbook. Une tâche peut ajouter des gardes ; elle n'en retire jamais.

garde	fait	exemple
form	des valeurs que la personne donne (des données, pas une politique). Un champ marqué identifies: true identifie aussi la room (identifiant déclaré)	{address: {type: text, required: true}, phone: {type: phone, identifies: true}}
check	le tenant valide	check: checkFormationEligibility
update	une donnée fixée après les gardes précédentes (idem)	update: {price: quoteFormation}
require	une condition qui doit tenir	{require: "$item.fields.amount <= $params.max_amount"}
permission	qui peut prendre cette action	{permission: {profiles: [manager, rh]}}
policy	une politique réutilisable : rule (une condition, un budget) ou smart	{policy: fraude}, {policy: remboursements-du-jour}
approval	une personne valide, d'un clic, avant la réservation	{approval: {role: support-manager}, when: "$item.fields.amount > 50"}

step_open — l'ordre du playbook — n'est pas déclaré : le playbook l'applique de lui-même.

Chaque garde peut porter when: (quand elle s'applique), et les attributs de toute politique : name, effect, mode, reason.

L'ordre d'évaluation

Fixé par la plateforme. À l'intérieur d'une phase, l'ordre que vous avez déclaré.

phase	contenu	pourquoi à ce rang
1	identité, profils, permission, sous-identité	rapide, déterministe
2	l'ordre du playbook (step_open)	idem
3	la provenance des arguments (set_by), form, require	idem
4	les budgets (rule, à compteur), les politiques smart	plus coûteux, mais ne touche pas les outils du tenant
5	check	appelle le tenant : jamais pour une action déjà refusée
6	update	la donnée finale (le prix)
7	approval	en dernier : la personne approuve l'action finale, avec son prix
8	réservée

Une lecture passe par les phases 1 à 4.

Trois réponses

Le point de décision répond toujours l'une des trois :

• permis — l'action est réservée (ou lue) ;
• refusé, avec une raison lisible par la personne et par l'agent (« choisissez d'abord les plats ») ;
• un humain doit décider — l'action passe en attente, dans la boîte du rôle concerné.

Chaque réponse est écrite au journal, avec les règles évaluées.

Une politique smart ne peut que resserrer

Une politique smart peut demander un humain. Elle ne peut jamais transformer un refus en accord. Un refus métier n'est jamais décidé par le modèle seul : seules les classes sécurité (injection, destinataire hors périmètre) peuvent refuser directement. Voir Politiques.