fix: browser wrapper permanent pour SingletonLock après redémarrage
- chrome-wrapper.sh : nettoie les lock files avant de lancer Chrome - openclaw.json : executablePath pointe vers le wrapper - start-chrome-cdp.sh : script de secours manuel - oc-up.sh : mis à jour (plus de démarrage manuel Chrome nécessaire) - MEMORY.md : documentation du fix
This commit is contained in:
@@ -0,0 +1,91 @@
|
||||
# Session: 2026-02-26 09:23:11 UTC
|
||||
|
||||
- **Session Key**: agent:main:main
|
||||
- **Session ID**: a938a79b-a20f-4f5a-a22a-7da2fc5bdb51
|
||||
- **Source**: telegram
|
||||
|
||||
## Conversation Summary
|
||||
|
||||
user: [Queued messages while agent was busy]
|
||||
|
||||
---
|
||||
Queued #1
|
||||
Conversation info (untrusted metadata):
|
||||
```json
|
||||
{
|
||||
"message_id": "921",
|
||||
"sender_id": "2037871620",
|
||||
"sender": "2037871620"
|
||||
}
|
||||
```
|
||||
|
||||
La commande clarify est optionnelle si jamais il y a besoin de clarifier des specs suite à secify est ce que cela doit être également entre crochet ?
|
||||
assistant: Bonne remarque, tu as raison — `clarify` est optionnel comme `analyze`, donc les deux doivent être entre crochets. Je corrige la page Anytype.
|
||||
assistant: Vérifions que c'est bien passé :
|
||||
assistant: [[reply_to_current]] ✅ Corrigé dans Anytype. Le workflow est maintenant cohérent :
|
||||
|
||||
```
|
||||
Nouveau projet → constitution → specify → [clarify] → plan → tasks → [analyze] → implement
|
||||
Nouvelle feature → specify → [clarify] → plan → tasks → [analyze] → implement
|
||||
Feature rapide → specify → plan → tasks → implement
|
||||
```
|
||||
|
||||
Les deux optionnels entre crochets — `[clarify]` et `[analyze]` — restent conseillés pour les features complexes, mais ne bloquent plus le flux visuellement.
|
||||
assistant: Bonne remarque, tu as raison — `clarify` est optionnel comme `analyze`, donc les deux doivent être entre crochets. Je corrige la page Anytype.
|
||||
assistant: Vérifions que c'est bien passé :
|
||||
assistant: ✅ Corrigé dans Anytype. Le workflow est maintenant cohérent :
|
||||
|
||||
```
|
||||
Nouveau projet → constitution → specify → [clarify] → plan → tasks → [analyze] → implement
|
||||
Nouvelle feature → specify → [clarify] → plan → tasks → [analyze] → implement
|
||||
Feature rapide → specify → plan → tasks → implement
|
||||
```
|
||||
|
||||
Les deux optionnels entre crochets — `[clarify]` et `[analyze]` — restent conseillés pour les features complexes, mais ne bloquent plus le flux visuellement.
|
||||
user: Conversation info (untrusted metadata):
|
||||
```json
|
||||
{
|
||||
"message_id": "925",
|
||||
"sender_id": "2037871620",
|
||||
"sender": "2037871620"
|
||||
}
|
||||
```
|
||||
|
||||
Il faut prendre en compte le fait que si la feature modifie la structure du projet comme les tables de la base de données, etc il faut modifier le fichier constitution.md il faut également l'incorporer dans le workflow. Fais une recherche sur ce que fait speckit.constitution pour bien comprendre ce que le fichier final attend comme donnée et ne pas le modifier pour rien également
|
||||
assistant: Je cherche le raw content et la structure réelle des templates.
|
||||
assistant: Bonne base. Maintenant je cherche le template exact de `speckit.constitution`.
|
||||
assistant: Je trouve le chemin du fichier constitution et son template.
|
||||
assistant: J'ai maintenant une vue claire. Le `constitution.md` est stocké dans `.specify/memory/constitution.md` et contient les **principes immuables du projet** : architecture, standards de code, conventions de nommage, sécurité, patterns de données. Je mets à jour la page Anytype.
|
||||
assistant: Anytype refuse les blocs de code imbriqués. Je vais nettoyer le contenu.
|
||||
assistant: Le PATCH avec un contenu aussi complexe bug. Je supprime l'ancienne page et je recrée.
|
||||
assistant: [[reply_to_current]] ✅ Page mise à jour dans Anytype : **📋 Spec-Kit — Skill Claude Code (v2)**
|
||||
|
||||
---
|
||||
|
||||
Voici ce que j'ai trouvé et intégré après recherche :
|
||||
|
||||
**constitution.md c'est quoi exactement :**
|
||||
- Fichier stocké dans `.specify/memory/constitution.md`
|
||||
- Lu **automatiquement** par Claude à chaque commande speckit
|
||||
- Contient les principes globaux : archi, conventions de données, sécurité, tests, nommage
|
||||
- Chaque principe a un **Rationale** (le pourquoi)
|
||||
|
||||
**La règle simple que j'ai intégrée dans le SKILL.md :**
|
||||
|
||||
| Situation | Action |
|
||||
|---|---|
|
||||
| Nouvelle table, suit les conventions existantes | ❌ Ne pas toucher constitution.md |
|
||||
| Soft delete sur TOUTES les tables → nouveau standard | ✅ Mettre à jour constitution.md |
|
||||
| Ajout Redis → devient le cache standard du projet | ✅ Mettre à jour constitution.md |
|
||||
| Migration vers UUIDs globalement | ✅ Mettre à jour constitution.md |
|
||||
| Feature isolée sans impact global | ❌ Ça va dans plan.md |
|
||||
|
||||
**Le workflow mis à jour avec une Phase 0 :**
|
||||
|
||||
```
|
||||
Phase 0 — Évaluation : cette feature change-t-elle des conventions globales ?
|
||||
→ Oui : constitution (MAJ ciblée) → specify → [clarify] → plan → tasks → [analyze] → implement
|
||||
→ Non : specify → [clarify] → plan → tasks → [analyze] → implement
|
||||
```
|
||||
|
||||
Et une instruction clé dans le SKILL.md pour éviter d'écraser constitution.md : toujours préciser **ce qu'on met à jour** et demander explicitement de **conserver les principes existants**.
|
||||
Reference in New Issue
Block a user