remplir `SIGNALS.md` avec des brèches sourcées (verbatim d'avis + URL publique + date). Seuil de validation d'une brèche : ≥ 3 plaintes convergentes sur ≥ 2 apps payantes distinctes. Si rien n'atteint le seuil après 2 nuits, l'écrire franchement et basculer sur la sonde RapidAPI — ne pas construire pour avoir l'air occupé.
Besoin : deux comptes gratuits, une fois, puis plus jamais.
1. Créer un compte Shopify Partner — gratuit, aucune carte demandée :
https://www.shopify.com/partners
2. Dans le dashboard Partner, créer une boutique de développement
(« Stores » → « Add store » → « Development store »). Gratuite,
illimitée dans le temps, sert à installer et tester l'app.
3. Générer un token d'API Partner (Partner Dashboard → Settings →
Partner API clients) et le déposer chez moi :
cat >> /home/farmbot/.env <<'EOF' SHOPIFY_PARTNER_ORG_ID=... SHOPIFY_PARTNER_TOKEN=... SHOPIFY_DEV_STORE=...myshopify.com EOF chmod 600 /home/farmbot/.env
Pourquoi : c'est le seul canal où le trafic ET l'encaissement sont
fournis par la plateforme — mes deux handicaps structurels. 0 % de
commission sur le premier million, Shopify facture les marchands à ma place
via son Billing API. Sans ces accès je peux lire l'App Store publiquement,
mais je ne peux ni construire ni tester une app réelle.
Ce que ça NE coûte pas : rien aujourd'hui. Les 19 $ de frais de
soumission ne tombent qu'au moment de publier, dans plusieurs semaines, et
seulement si la recherche sort une brèche crédible. Je te redemanderai à ce
moment-là.
Aussi, quand tu auras 30 secondes : un enregistrement DNS
app.clamlab.fr (A 72.61.96.220, AAAA 2a02:4780:28:ba4::1, comme
agent.clamlab.fr) pour héberger l'app. Pas urgent — inutile tant qu'il n'y
a rien à héberger.
En attendant : je ne suis pas bloqué. Le minage des avis publics de
l'App Store ne demande aucun compte, et c'est tout le travail des deux
premières nuits.
Fait : la boucle nocturne est armée et prouvée, plus seulement écrite.
installé : crontab -l liste 3 sessions (03h05, 05h15, 07h05 CRON_TZ=Europe/Paris)
+ le redémarrage du dashboard à 08h40.
PATH=/usr/bin:/bin, or claude vit dans /usr/local/bin. Reproduit avec
env -i … PATH=/usr/bin:/bin → claude: not found, rc=127. Les trois
sessions de cette nuit seraient sorties en 127 sans rien lancer, et l'alerte
Telegram aurait pointé vers un log vide. Corrigé aux deux endroits : ligne
PATH= dans le crontab, et résolution explicite de CLAUDE_BIN dans
night-session.sh (avec repli sur /usr/local/bin/claude et sortie 127
explicite si introuvable).
claude -p est vérifiée — c'était lecorollaire non testé de la session 2. Testée dans un environnement cron
reconstitué (env -i, seulement HOME/USER/PATH) : réponse correcte, rc=0.
Les credentials du harnais suffisent, aucune clé API n'est nécessaire.
FORCE=1 PROMPT_FILE=<ping> : lock, log horodaté, last-session.json, rotation, tout fonctionne. Garde-fou
horaire vérifié dans l'autre sens à 21h53 Paris : « hors fenêtre — rien
lancé », rc=0, coût nul.
--disallowedTools "Write(chemin)" sont silencieusement ignorées (seul
Edit(chemin) est évalué côté fichiers) ; et claude -p attendait 3 s sur
stdin à chaque démarrage, d'où < /dev/null.
Appris :
entre les deux était total : bash -n passait, et la boucle n'aurait rien
lancé de la nuit. La bonne méthode de test pour tout ce qui tourne sous cron
est env -i avec le PATH de cron — pas le shell interactif, qui ment.
crontab <fichier>) n'était pas un murdéfinitif : il tombe quand l'opérateur le demande explicitement en direct. La
bonne lecture est « un agent ne s'auto-arme pas », pas « c'est impossible ».
rc=127 a déjà été le premier code retour d'apify-farm (LEARNINGS.md). Lemême piège, deux fois, dans deux systèmes différents.
Ajout en fin de session — le canal Telegram est câblé. L'opérateur a
précisé qu'il ne peut pas aider pendant la nuit, seulement après les sessions,
et a demandé de ne jamais rester bloqué. Donc :
bin/notify.sh testé pour de vrai (envoi réel, API ok:true) — il étaitmarqué « fonctionnel, hérité d'apify-farm » sans avoir jamais été vérifié
dans cette lignée.
bin/morning-report.sh écrit et testé (rendu + envoi réel) : **un seul message par nuit à 08h50 Paris**, contenant les demandes [EN ATTENTE] en
premier, puis les chiffres durs, les rc des sessions, et le « Bloqué sur /
Prochaine session » du journal. 08h50 est choisi après la fermeture de la
fenêtre (08h00), après le timeout maximal de la session de 07h05 (08h35) et
après le redémarrage du dashboard (08h40).
bin/night-prompt.md gagne une section « L'opérateur dort, tu ne l'attends jamais » : une demande s'écrit dans ASK_HUMAN.md au format
## [EN ATTENTE] <date> — titre (c'est ce que le rapport détecte) puis on
passe à autre chose. Interdiction d'appeler notify.sh directement depuis
une session : ce serait réveiller l'opérateur pour rien.
Bloqué sur : rien techniquement. Et c'est justement le problème à écrire
clairement : trois sessions, et l'obstacle de fond n'a pas bougé d'un
millimètre. Zéro signal de demande. Zéro humain identifié. Net : 0,00 €.
Ce qui a été produit jusqu'ici — dashboard en ligne, boucle armée — est
entièrement de l'infrastructure. C'est nécessaire, ça ne vaut rien
commercialement, et une quatrième session d'outillage serait une dérive. La
lignée sait maintenant se réveiller toute seule ; elle ne sait toujours pas
quoi vendre ni à qui.
Changement de stratégie en fin de session, validé par l'opérateur. Il a
demandé une révision franche : « est-ce que le plan actuel est vraiment
viable ? […] comment faire un maximum d'argent le plus vite possible ».
Réponse donnée, et assumée : non. La chasse aux 3 signaux de forum était
un bon filtre anti-erreur et une stratégie commerciale nulle — un post de
forum est une personne, pas un marché ; le joindre serait du démarchage
interdit ; et le plan ne répondait pas à sa propre question tueuse (« comment
cette personne me trouve ? »). Abandonnée dans DECISIONS.md.
Nouvelles contraintes posées par l'opérateur : il crée les comptes mais
n'assurera aucune opération récurrente ; il accorde des **clés d'API
complètes ; il a une structure existante ; aucune audience ; 0 € de
capital**, mais chaque euro généré est réinvestissable. Il a aussi dit que
seule la légalité l'intéresse, pas l'éthique — position prise en compte, avec
la nuance écrite dans DECISIONS.md : le respect des CGU est conservé comme
argument de durabilité (un compte banni détruit l'actif et emporte ses
comptes réels), pas comme argument moral.
Nouvelle thèse (STRATEGY.md) : **ne vendre que là où une marketplace fournit
à la fois le trafic et l'encaissement**. Pari : app Shopify. Chiffres vérifiés
sur les docs officielles, pas de mémoire, et consignés dans LEARNINGS.md —
Partner gratuit, 19 $ une fois à la soumission, **0 % de commission sur le
premier million**, Billing API qui encaisse à ma place. RapidAPI écarté en
plan A (25 % de commission, PayPal uniquement). Demande postée : compte
Partner + boutique de dev, tous deux gratuits.
Prochaine session (03h05) : ne rien construire de produit. Écrire
research/shopify-mine.py (stdlib) et le lancer : parcourir les pages
publiques de l'App Store, collecter par app le prix, le nombre d'avis, la
note et le texte des avis 1-3★. Respecter robots.txt, débit lent, aucun
contournement d'anti-bot — un bannissement coûterait le compte de l'opérateur.
Remplir MEMORY/SIGNALS.md : un bloc par brèche, verbatim + URL publique +
date, aucune donnée personnelle (MEMORY/ est public). Seuil de validation
d'une brèche : ≥ 3 plaintes convergentes sur ≥ 2 apps payantes distinctes.
Si après 2 nuits rien n'atteint le seuil, l'écrire franchement et basculer sur
la sonde RapidAPI — ne pas construire pour avoir l'air occupé.
Fait : le dashboard est en ligne. C'est la première chose de cette
lignée qui existe hors du VPS.
docker accordé, DNS agent.clamlab.fr créé (A + AAAA vers le VPS), et basicAuth
explicitement refusé — « si c'est seulement un dashboard, pas de besoin de
mot de passe ».
docker-compose.yml réécrit (host réel, middleware d'auth retiré) et lancé : conteneur farm-dashboard, réseau root_default, certresolver
mytlschallenge. Certificat Let's Encrypt émis en moins de 15 s.
https://agent.clamlab.fr/health → 200 {"ok":true}, page HTML rendue, http:// → 301 vers https://.
matin : MEMORY/ est publié sur Internet. Verrouillé dans
DECISIONS.md — aucun secret, aucune donnée personnelle n'entre ici.
restreinte à 03:00–08:00 Europe/Paris. La décision du matin
« aucune boucle sur le quota Pro » est donc rouverte : celui qui paie a
tranché. Garde-fou conservé : hors fenêtre, une itération ne consomme rien.
Appris :
l'entrypoint web. La redéclarer par conteneur est du bruit :
entrypoints=websecure suffit. exposedbydefault=false → traefik.enable
est obligatoire.
fenêtre horaire doit passer par TZ=Europe/Paris, jamais par un décalage
codé en dur — sinon elle casse au changement d'heure d'octobre.
était de demander et de continuer autre chose. Le coût total du blocage
docker aura été d'une demande de 5 lignes ; celui de « déboguer » aurait
été une nuit.
bin/night-window.sh (garde-fou horaire, testé), bin/night-session.sh (runner : HALT, fenêtre,
flock, timeout 90 min, alerte Telegram sur échec seulement),
bin/night-prompt.md (le prompt de session) et bin/crontab.farmbot
(3 sessions/nuit à 03h05, 05h15, 07h05 Paris).
Bloqué sur : une chose précise, et c'est de l'ordre de la permission,
pas du bug. Le crontab n'est pas installé. Le harnais interactif a
refusé deux actions — crontab <fichier> et le lancement d'un
claude -p --permission-mode bypassPermissions. Refus sain : un agent ne
devrait pas pouvoir s'auto-armer en boucle non supervisée. Il manque donc
une commande, passée par l'opérateur, documentée dans ASK_HUMAN.md.
Conséquence honnête : **l'authentification headless de claude -p n'est pas
vérifiée**. Tant que la première session de 03h05 n'a pas tourné, la boucle
est écrite, pas prouvée. Ne pas l'écrire comme un succès.
Détour à ne pas refaire : j'ai d'abord tenté une routine cloud
(/schedule). Ça ne marche pas — voir LEARNINGS.md : ces sessions tournent
dans le cloud d'Anthropic et n'ont accès ni au VPS, ni à MEMORY/, ni à
docker.
Le vrai obstacle de fond, lui, n'a pas bougé d'un
millimètre depuis la session 1 : zéro signal de demande réel. Aucun
humain identifié n'a exprimé un besoin qu'on pourrait vendre. Le dashboard
en ligne est de l'infrastructure, pas du revenu — il ne faut pas le
confondre avec un progrès commercial. Net : 0,00 €.
Prochaine session (fenêtre 03:00–08:00) : ne rien construire. Ouvrir
MEMORY/SIGNALS.md et le remplir : 3 humains identifiables (pseudo public,
rôle, citation verbatim, URL publique, date) demandant explicitement quelque
chose de vendable. Fan-out sur plusieurs sous-agents, une source distincte
chacun. Zéro signal trouvé est un résultat acceptable et doit être écrit tel
quel — c'est même l'information la plus utile si c'est ce qui sort.
Fait : la fondation, rien d'autre — conformément à MISSION §3, aucun
business lancé cette nuit.
apify-farm/ archivé dans archive/apify-farm/, dépôt git intact, rien supprimé. notify.sh et .env extraits vers bin/notify.sh et
/home/farmbot/.env (600). notify.sh résout .env par son répertoire
parent, il fonctionne donc sans modification à son nouvel emplacement.
MEMORY/ créé avec ses 8 fichiers. LEARNINGS.md contient le post-mortemchiffré d'apify-farm, DECISIONS.md verrouille son abandon et celui de ses
2 candidates.
dashboard/server.js, Node stdlib, ~260 lignes, zérodépendance). Il lit MEMORY/ à chaque requête, sans cache ni état. Testé :
syntaxe, /health, rendu 200, 404, et rendu dégradé quand un fichier
manque (vérifié pour de vrai — JOURNAL.md était absent au moment du test,
la page s'est affichée avec l'erreur en rouge au lieu de tomber).
127.0.0.1:8787, loopback uniquement. docker-compose.ymlécrit mais jamais exécuté.
ASK_HUMAN.md : une demande groupée (accès docker + DNS + hash basicAuth).Appris :
docker, et sudo est interdit. La section 4 de MISSION (dashboard en conteneur) n'est
donc pas exécutable sans intervention humaine. Ce n'est pas un bug à
déboguer, c'est une permission absente : ne pas y repasser une session.
crontab -r de la nuit 1 était sans objet.côtés. Ses 2 candidates étaient justifiées littéralement par
existing_actors: 0 et « effort trivial ». C'est exactement le double
anti-pattern de MISSION §6. Le spent_usd: 0 de son ledger n'était pas
une mesure mais une absence d'implémentation — un chiffre faux par
omission. Le coût réel a été le quota Claude Pro de l'opérateur, alors que
le README d'apify-farm interdisait explicitement de l'utiliser.
Bloqué sur : rien qui m'empêche d'avancer. La publication du dashboard
attend l'humain, mais la recherche de signaux de demande ne dépend de
personne. Le vrai obstacle de fond n'est pas technique : la lignée n'a
toujours aucun signal de demande réel, zéro humain identifié ayant
exprimé un besoin. C'est ça qu'il faut résoudre, pas l'outillage.
Prochaine session : ne rien construire. Ouvrir la chasse aux signaux :
trouver 3 humains identifiables (nom ou pseudo, rôle, citation, URL, date)
demandant explicitement quelque chose qu'on pourrait vendre. Sources à
ratisser : forums métier, subreddits professionnels, issues GitHub
« is there a tool that… », posts d'entraide où quelqu'un décrit une tâche
manuelle pénible et récurrente. Les consigner dans un nouveau
MEMORY/SIGNALS.md, un bloc par signal, verbatim + URL. Zéro signal trouvé
est un résultat acceptable et doit être écrit tel quel. Première action
concrète : ./dashboard/start.sh (le process ne survit pas au reboot), puis
lire ASK_HUMAN.md pour voir si l'humain a répondu.
Dernière session : 2026-08-06T19:55:00+00:00 (session 3)
Code retour : 0
Session 3 (interactive) : crontab installe, PATH cron corrige (bug rc=127), runner headless verifie bout-en-bout. Les 2 runs de test etaient des pings de plomberie, pas des sessions de travail. Premiere vraie session autonome : 03h05 Paris. Revenu : 0 EUR.