323 lines
12 KiB
HTML
323 lines
12 KiB
HTML
<!doctype html>
|
|
<html lang="fr">
|
|
<head>
|
|
<meta charset="utf-8">
|
|
<title>Structure documentaire Markdown - purchase_trade</title>
|
|
<style>
|
|
@page {
|
|
size: A4;
|
|
margin: 18mm 16mm;
|
|
}
|
|
body {
|
|
color: #172033;
|
|
font-family: "Segoe UI", Arial, sans-serif;
|
|
font-size: 11px;
|
|
line-height: 1.42;
|
|
margin: 0;
|
|
}
|
|
h1 {
|
|
color: #0f2742;
|
|
font-size: 25px;
|
|
line-height: 1.1;
|
|
margin: 0 0 6px;
|
|
}
|
|
h2 {
|
|
border-bottom: 2px solid #d8e2ef;
|
|
color: #18466f;
|
|
font-size: 16px;
|
|
margin: 22px 0 8px;
|
|
padding-bottom: 4px;
|
|
}
|
|
h3 {
|
|
color: #1f5c8f;
|
|
font-size: 13px;
|
|
margin: 13px 0 4px;
|
|
}
|
|
p {
|
|
margin: 5px 0;
|
|
}
|
|
code {
|
|
background: #eef3f8;
|
|
border-radius: 3px;
|
|
color: #0f3a5f;
|
|
font-family: Consolas, monospace;
|
|
font-size: 10px;
|
|
padding: 1px 3px;
|
|
}
|
|
table {
|
|
border-collapse: collapse;
|
|
margin: 8px 0 12px;
|
|
width: 100%;
|
|
}
|
|
th, td {
|
|
border: 1px solid #d4dde8;
|
|
padding: 6px 7px;
|
|
text-align: left;
|
|
vertical-align: top;
|
|
}
|
|
th {
|
|
background: #eaf2fb;
|
|
color: #14395a;
|
|
font-weight: 650;
|
|
}
|
|
ul {
|
|
margin: 5px 0 10px 18px;
|
|
padding: 0;
|
|
}
|
|
li {
|
|
margin: 3px 0;
|
|
}
|
|
.subtitle {
|
|
color: #5b6b7f;
|
|
font-size: 12px;
|
|
margin-bottom: 16px;
|
|
}
|
|
.callout {
|
|
background: #f4f8fc;
|
|
border-left: 4px solid #2d78b7;
|
|
margin: 9px 0 12px;
|
|
padding: 8px 10px;
|
|
}
|
|
.warning {
|
|
background: #fff7e8;
|
|
border-left-color: #d98718;
|
|
}
|
|
.ok {
|
|
background: #edf8f0;
|
|
border-left-color: #329c50;
|
|
}
|
|
.tree {
|
|
background: #f7f9fb;
|
|
border: 1px solid #dce5ee;
|
|
border-radius: 4px;
|
|
font-family: Consolas, monospace;
|
|
font-size: 10px;
|
|
padding: 9px 11px;
|
|
white-space: pre-wrap;
|
|
}
|
|
.page-break {
|
|
break-before: page;
|
|
}
|
|
.small {
|
|
color: #5b6b7f;
|
|
font-size: 10px;
|
|
}
|
|
</style>
|
|
</head>
|
|
<body>
|
|
<h1>Structure documentaire Markdown - purchase_trade</h1>
|
|
<p class="subtitle">Document recapitulatif de la structure mise en place pour les regles metier, bugs, backlogs et gestion documentaire.</p>
|
|
|
|
<div class="callout">
|
|
<strong>Objectif general.</strong>
|
|
La documentation est organisee pour separer les regles metier, les bugs, les backlogs d'implementation et les conventions de gestion. L'objectif est de garder un contexte lisible pour les humains et chargeable a la demande pour les agents.
|
|
</div>
|
|
|
|
<h2>1. Arborescence Markdown</h2>
|
|
<div class="tree">modules/purchase_trade/docs/
|
|
business-rules.md
|
|
documentation-management.md
|
|
bugs.md
|
|
template-rules.md
|
|
business rules/
|
|
lot-quantity.md
|
|
lot-navigation.md
|
|
invoice-freight.md
|
|
market-price-import.md
|
|
backlog/
|
|
market-price-import-backlog.md</div>
|
|
|
|
<h2>2. Role et description des fichiers</h2>
|
|
<table>
|
|
<thead>
|
|
<tr>
|
|
<th>Fichier</th>
|
|
<th>Role</th>
|
|
<th>Description</th>
|
|
</tr>
|
|
</thead>
|
|
<tbody>
|
|
<tr>
|
|
<td><code>business-rules.md</code></td>
|
|
<td>Catalogue des regles metier</td>
|
|
<td>Point d'entree des regles <code>purchase_trade</code>. Contient le scope, le glossaire, le catalogue des IDs <code>BR-PT-xxx</code> et les liens vers les fiches detaillees.</td>
|
|
</tr>
|
|
<tr>
|
|
<td><code>documentation-management.md</code></td>
|
|
<td>Regles de gestion documentaire</td>
|
|
<td>Decrit le workflow: creation de regles, questions ouvertes <code>Q:</code>/<code>A:</code>, backlogs, bugs, statuts, commits de reference et discipline de scope.</td>
|
|
</tr>
|
|
<tr>
|
|
<td><code>bugs.md</code></td>
|
|
<td>Registre des bugs</td>
|
|
<td>Lieu d'enregistrement initial des bugs avec ID stable <code>BUG-PT-xxx</code>. Chaque bug doit etre relie a une entree backlog.</td>
|
|
</tr>
|
|
<tr>
|
|
<td><code>template-rules.md</code></td>
|
|
<td>Regles specifiques aux templates</td>
|
|
<td>Guide de correction et d'analyse des templates Relatorio/FODT, notamment les ponts Python, les placeholders XML et le cache des reports facture.</td>
|
|
</tr>
|
|
<tr>
|
|
<td><code>business rules/lot-quantity.md</code></td>
|
|
<td>Regle detaillee BR-PT-001</td>
|
|
<td>Specifie l'ajustement de <code>quantity_theorical</code>, la synchronisation du lot virtuel et des quantites ouvertes <code>lot.qt</code>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td><code>business rules/lot-navigation.md</code></td>
|
|
<td>Regle detaillee BR-PT-002</td>
|
|
<td>Documente le lot physique comme pont stable entre purchase, sale, shipment et facture.</td>
|
|
</tr>
|
|
<tr>
|
|
<td><code>business rules/invoice-freight.md</code></td>
|
|
<td>Regle detaillee BR-PT-003</td>
|
|
<td>Definit que le <code>FREIGHT VALUE</code> des factures vient du fee de shipment <code>Maritime freight</code>, via le lot physique.</td>
|
|
</tr>
|
|
<tr>
|
|
<td><code>business rules/market-price-import.md</code></td>
|
|
<td>Regle detaillee BR-PT-004</td>
|
|
<td>Specifie l'import de prix marche depuis Excel: colonnes attendues, parsing, creation d'index, resultats, edge cases et questions tranchees.</td>
|
|
</tr>
|
|
<tr>
|
|
<td><code>backlog/market-price-import-backlog.md</code></td>
|
|
<td>Backlog feature Market Price Import</td>
|
|
<td>Liste les travaux issus de BR-PT-004 et des bugs associes, avec statut, priorite, source, impact code, tests attendus et commit d'implementation si applicable.</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<h2>3. Workflow recommande</h2>
|
|
<h3>Nouvelle regle metier</h3>
|
|
<ul>
|
|
<li>Ajouter une ligne dans <code>business-rules.md</code>.</li>
|
|
<li>Creer une fiche dediee dans <code>business rules/</code> si la regle a des impacts code, tests, edge cases ou questions.</li>
|
|
<li>Utiliser des questions <code>Q:</code> et reponses <code>A:</code>; ajouter <code>Comment:</code> si la decision implique un changement code.</li>
|
|
</ul>
|
|
|
|
<h3>Nouveau bug</h3>
|
|
<ul>
|
|
<li>Creer une entree dans <code>bugs.md</code> avec un ID stable <code>BUG-PT-xxx</code>.</li>
|
|
<li>Creer une entree backlog correspondante, soit dans un backlog existant, soit dans un nouveau fichier sous <code>backlog/</code>.</li>
|
|
<li>Lier le bug au backlog et le backlog au bug.</li>
|
|
</ul>
|
|
|
|
<h3>Implementation</h3>
|
|
<ul>
|
|
<li>Passer le backlog de <code>open</code> a <code>in-progress</code>, puis <code>to-be-tested</code> apres implementation.</li>
|
|
<li>Documenter le travail realise et le statut de validation.</li>
|
|
<li>Apres commit, enregistrer le hash du commit dans l'entree backlog.</li>
|
|
</ul>
|
|
|
|
<h2>4. Avantages</h2>
|
|
<ul>
|
|
<li><strong>Traçabilite.</strong> Les decisions metier, bugs, backlogs, tests et commits sont relies.</li>
|
|
<li><strong>Scope clair.</strong> Un agent peut charger seulement le fichier pertinent au lieu de tout lire.</li>
|
|
<li><strong>Meilleure maintenance.</strong> Les regles lourdes vivent dans des fiches dediees; le catalogue reste court.</li>
|
|
<li><strong>Priorisation explicite.</strong> Le backlog garde statut, priorite, tests attendus et validation.</li>
|
|
<li><strong>Historique de decision.</strong> Les sections <code>Open Questions</code> gardent les arbitrages <code>Q:</code>/<code>A:</code>.</li>
|
|
<li><strong>Support bug propre.</strong> Chaque bug a un ID stable et une entree backlog obligatoire.</li>
|
|
</ul>
|
|
|
|
<h2>5. Inconvenients / points de vigilance</h2>
|
|
<ul>
|
|
<li><strong>Discipline necessaire.</strong> Il faut maintenir les liens et les statuts, sinon la structure perd de sa valeur.</li>
|
|
<li><strong>Risque de fragmentation.</strong> Trop de petits fichiers peuvent ralentir la comprehension si le catalogue n'est pas tenu a jour.</li>
|
|
<li><strong>Noms avec espaces.</strong> Le dossier <code>business rules/</code> est lisible, mais les liens Markdown doivent utiliser <code>business%20rules</code> dans les URLs.</li>
|
|
<li><strong>Backlog a synchroniser.</strong> Une correction code doit etre reportee dans le backlog, notamment le statut et le commit.</li>
|
|
<li><strong>Duplication possible.</strong> Certaines informations peuvent apparaitre dans regle, bug et backlog; il faut garder chaque fichier dans son role.</li>
|
|
</ul>
|
|
|
|
<div class="page-break"></div>
|
|
<h2>6. Estimation de consommation tokens</h2>
|
|
<p>Estimation basee sur la regle pratique de l'image fournie: <strong>1 KB ≈ 200 tokens</strong>.</p>
|
|
|
|
<table>
|
|
<thead>
|
|
<tr>
|
|
<th>Fichier</th>
|
|
<th>Taille approx.</th>
|
|
<th>Tokens approx.</th>
|
|
<th>Usage conseille</th>
|
|
</tr>
|
|
</thead>
|
|
<tbody>
|
|
<tr>
|
|
<td><code>backlog/market-price-import-backlog.md</code></td>
|
|
<td>4.70 KB</td>
|
|
<td>~939</td>
|
|
<td>Charger pour prioriser ou coder un item Market Price Import.</td>
|
|
</tr>
|
|
<tr>
|
|
<td><code>bugs.md</code></td>
|
|
<td>1.67 KB</td>
|
|
<td>~333</td>
|
|
<td>Charger au moment de declarer ou suivre un bug.</td>
|
|
</tr>
|
|
<tr>
|
|
<td><code>business rules/invoice-freight.md</code></td>
|
|
<td>1.49 KB</td>
|
|
<td>~298</td>
|
|
<td>Charger pour les sujets freight/facture.</td>
|
|
</tr>
|
|
<tr>
|
|
<td><code>business rules/lot-navigation.md</code></td>
|
|
<td>1.84 KB</td>
|
|
<td>~369</td>
|
|
<td>Charger pour les chemins achat/vente/shipment.</td>
|
|
</tr>
|
|
<tr>
|
|
<td><code>business rules/lot-quantity.md</code></td>
|
|
<td>2.87 KB</td>
|
|
<td>~574</td>
|
|
<td>Charger pour les changements de quantite theorique.</td>
|
|
</tr>
|
|
<tr>
|
|
<td><code>business rules/market-price-import.md</code></td>
|
|
<td>6.21 KB</td>
|
|
<td>~1 242</td>
|
|
<td>Charger pour comprendre la specification complete de l'import.</td>
|
|
</tr>
|
|
<tr>
|
|
<td><code>business-rules.md</code></td>
|
|
<td>2.21 KB</td>
|
|
<td>~441</td>
|
|
<td>Charger comme index de depart.</td>
|
|
</tr>
|
|
<tr>
|
|
<td><code>documentation-management.md</code></td>
|
|
<td>4.47 KB</td>
|
|
<td>~893</td>
|
|
<td>Charger quand on gere docs, bugs, statuts ou backlog.</td>
|
|
</tr>
|
|
<tr>
|
|
<td><code>template-rules.md</code></td>
|
|
<td>6.14 KB</td>
|
|
<td>~1 227</td>
|
|
<td>Charger uniquement pour les sujets templates/reporting.</td>
|
|
</tr>
|
|
<tr>
|
|
<th>Total des 9 fichiers</th>
|
|
<th>31.58 KB</th>
|
|
<th>~6 316</th>
|
|
<th>Faible a modere si charge ensemble; meilleur en chargement a la demande.</th>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<h3>Evaluation</h3>
|
|
<div class="callout ok">
|
|
<strong>Consommation estimee: faible a moderee.</strong>
|
|
A environ 6 300 tokens pour tout le dossier Markdown <code>purchase_trade/docs</code>, la structure reste tres raisonnable par rapport a un budget conseille de 60k-80k tokens. Le risque principal n'est pas un fichier unique, mais l'accumulation avec l'historique de conversation, les diffs, les logs et les sorties de tests.
|
|
</div>
|
|
|
|
<div class="callout warning">
|
|
<strong>Bonne pratique.</strong>
|
|
Charger <code>business-rules.md</code> comme index, puis seulement la fiche detaillee, le bug ou le backlog utile. Eviter de charger tous les fichiers docs plus de gros logs ou des diffs complets dans la meme interaction.
|
|
</div>
|
|
|
|
<h2>7. Recommandation finale</h2>
|
|
<p>La structure est pertinente et peu couteuse en tokens si elle est utilisee comme une documentation modulaire. Elle donne une bonne base pour travailler avec des agents: contexte court au depart, approfondissement a la demande, liens explicites entre bug, regle, backlog, tests et commit.</p>
|
|
|
|
<p class="small">Document genere le 2026-05-08 pour le module <code>purchase_trade</code>.</p>
|
|
</body>
|
|
</html>
|