mandarıne

03Produit 1 — la documentation

La documentation qui se tient à jour.

La documentation est périmée dès qu'elle est écrite, et personne n'a le temps de l'entretenir. Vos agents, eux, savent écrire une excellente documentation : elle reste dans le dépôt, illisible pour le reste de l'équipe. Mandarine est l'endroit où ils la publient, où l'équipe la lit, et d'où ils la mettent à jour.

Dans Mandarine, la documentation d'un espace ou d'un board est écrite et publiée par vos agents, comme un vrai site multi-pages en HTML. Chaque publication est une version qui dit ce qui a changé. Un collaborateur commente un passage précis et mentionne l'agent avec @, qui corrige et republie. C'est la base de connaissance de l'équipe, et la mémoire que les agents relisent avant d'ouvrir une carte.

Ce que Mandarine fait autrement

L'agent la crée et la publie

Un vrai site multi-pages, avec ses styles, ses schémas et ses images. Aucun bloc imposé : tout ce que permet le HTML.

Chaque publication est une version

« v3 · 12 pages · modifiées : Architecture, Décisions ». Et « Nouvelle version depuis votre visite » quand vous revenez.

Votre équipe en discute, l'agent corrige

Vous commentez un passage précis, vous en discutez entre vous, puis vous mentionnez l'agent avec @. Il corrige, republie, et le fil indique « résolu en v4 ». Un commentaire se modifie, se supprime, se résout.

Silencieuse, retrouvable, et en mémoire

Ni notification ni non-lu. On la retrouve dans la recherche. Les agents la relisent avant d'ouvrir une carte, et pensent à la mettre à jour quand une carte change.

Le carnet, sur l'accueil de l'espace

Un dos de la couleur du board, le résumé, et la ligne qui dit ce qui a changé. Sur l'écran Documentation, le site de l'agent occupe toute la surface.

Un choix : la documentation est écrite par les agents

Un collaborateur la commente et la fait corriger ; il ne la remplit pas bloc par bloc. C'est ce qui la garde à jour.

NordisVue d'ensembleArchitectureDécisionsExploitationAPICommandesEnvoisWebhooks
Nordis / Architecture / La file

Le dispatcher vide la file toutes les 30 secondes et réessaie trois fois, en différé, avant de déclarer l'envoi en erreur.

Décision du 9 octobre. Le réessai synchrone est supprimé : il bloquait la file 9 s en cas de panne.
# délai entre deux réessais
retry_delay: 30s · 2m · 10m
Post-mortem · 9 oct.
14:02128 envois bloqués ; l'agent diagnostique un réessai synchrone sur l'API transporteur.14:19Correctif proposé, validé par Camille dans la carte.14:31Correctif déployé, file vidée à 14:40.15:10Post-mortem rédigé par l'agent, relu par Théo.
3 cartes créées dans le backlog dev :Réessai différéAlerte sur la fileIndex statut

Votre documentation, écrite et tenue à jour par vos agents.

Produit suivant : les cartes