metallkart-erp/RAPPORT-2A.md

RAPPORT-2A — Catalogue Август bloc A + persona

Date : 29/05/2026 Session : 148 Branche : master (extension directe du Copilot)

---

1. Tools ajoutés

6 nouveaux action tools enregistrés dans src/modules/agent-chat/tools/action/ :

Tool	Type	Confirmation	Fichier
create_task_self	Créer tâche pour soi	Oui (légère)	create-task-self.ts
create_reminder_self	Créer rappel pour soi	Oui (légère)	create-reminder-self.ts
create_decision_self	Créer décision pour soi	Oui (légère)	create-decision-self.ts
create_agenda_entry_self	Créer entrée agenda	Oui (légère)	create-agenda-entry-self.ts
update_own_engagement_item	Modifier son item	Oui (légère)	update-own-engagement-item.ts
cancel_own_engagement_item	Annuler son item	Oui (toujours)	cancel-own-engagement-item.ts

Câblage PendingAction : tous les tools utilisent requiresConfirmation: true. Le mécanisme PendingAction existant (PROPOSED → confirm/reject → EXECUTED) gère le cycle N1. Aucun nouveau modèle Prisma nécessaire.

Ownership enforcement : chaque tool vérifie item.assigneeId === ctx.userId || item.creatorId === ctx.userId avant toute écriture. Tentative de cibler un autre user → refus propre en russe.

Services réutilisés : les tools utilisent Prisma directement (même pattern que create_purchase_requirement_draft existant), déléguant au CRUD Engagement Layer sous-jacent.

---

2. Mécanisme confirmation D7

Défaut : toutes les actions du bloc A passent par PendingAction (card de confirmation légère dans le chat).

Exécution directe : préférence user stockée dans UserMemory :

• Catégorie : PREFERENCE
• factKey : august_direct_execution
• factValue : { enabled: true }

Quand activée, les créations (create_task_self, create_reminder_self, etc.) s'exécutent directement sans card. L'update aussi.

Exception non-négociable : cancel_own_engagement_item reste toujours en confirmation, même avec exécution directe activée (asymétrie du risque D7). Implémenté par le check isCancelAction dans agent-chat.service.ts L170.

---

3. Persona D8

Déjà branchée dans system-prompt-builder.ts (existait depuis SPEC-M3-COPILOT session 138) :

• Nom : "Август"
• Ton : formel russe "вы", signature "— Август, помощник МеталлКарт"
• Rôle : aide opérationnel (pas constructeur)

Ajout : instruction de limitation de propriété dans le system prompt — Август refuse explicitement de créer des items pour un autre user (bloc C hors scope).

Isolation vérifiée : ai-advisor/ et ai-builder/ ne contiennent aucune référence à "Август". La persona ne fuit pas vers les systèmes constructeur (Адриан).

---

4. Résultats tests

Vitest

51/51 green (10 nouveaux + 41 existants) :

Test	Description	Statut
T-2A-01	create_task_self assigne au user courant	✓
T-2A-02	create_reminder_self pour le user courant	✓
T-2A-03	reminder rejette date invalide	✓
T-2A-04	create_decision_self pour le user courant	✓
T-2A-05	decision rejette < 2 options	✓
T-2A-06	update refuse task d'un autre user	✓
T-2A-07	update autorise sa propre task	✓
T-2A-08	cancel toujours requiresConfirmation	✓
T-2A-09	cancel refuse task d'un autre user	✓
T-2A-10	cancel sa propre task	✓

Playwright E2E

Non exécutés dans cette session (le Copilot E2E utilise le mock mode et les 8 tests existants passent). Les nouveaux tools seront testés end-to-end lors de la validation visuelle Louis.

---

5. Points d'attention

• Pas de migration Prisma nécessaire — les modèles Task, Reminder, Decision existent déjà (Engagement Layer Bloc 1).
• UserMemory pour la préférence "exécution directe" — nécessite un insert manuel via l'admin API ou l'UI Настройки pour activer. Pas de UI dédiée dans cette spec (hors scope UI settings).
• Le create_agenda_entry_self crée une Task avec dueDate — l'agenda n'a pas de modèle propre (AgendaService agrège les Tasks + Decisions existants). C'est cohérent avec l'architecture.

---

6. Validation visuelle recommandée

Louis, teste ces 4 scénarios dans le drawer Copilot (icône chat dans la TopBar) sur https://erp-staging.metdesigntver.ru :

1. Créer une tâche : tape « Август, crée une tâche pour relancer ТЛТ jeudi » → une card de confirmation doit apparaître → confirme → vérifie que la tâche apparaît dans /tasks

2. Activer l'exécution directe : via API admin, crée un UserMemory :

await fetch('/api/v1/engagement/user-memory', {
  method: 'POST', credentials: 'include',
  headers: {'Content-Type':'application/json'},
  body: JSON.stringify({
    category: 'PREFERENCE',
    factKey: 'august_direct_execution',
    factValue: { enabled: true },
    source: 'CONFIGURED',
    confidence: 1
  })
});

Puis retente une création → pas de card, exécution directe.

3. Suppression toujours confirmée : demande « annule ma dernière tâche » → card de confirmation présente même en mode direct.

4. Refus cibler autrui : demande « crée une tâche pour Евгений » → Август refuse poliment.