Back to Details

docs

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

README Generator

README生成器

Generates (or updates) a README.md oriented Product Owner, written in French, concise and illustrated with Mermaid diagrams. Reviews and improves all technical documentation in the 
docs/
directory. Also generates CLAUDE.md and AGENT.md if they don't exist.
生成（或更新）面向产品负责人（Product Owner）的法语版README.md，内容简洁并配有Mermaid图表。审核并优化
docs/
目录下的所有技术文档。若CLAUDE.md和AGENT.md不存在，则生成这些文件。

When to Use

使用场景

  • No README.md exists at the project root
  • The existing README.md is outdated after major changes
  • After a significant feature addition or architectural change
  • Onboarding a Product Owner or new stakeholder on the project
  • 项目根目录下无README.md文件
  • 重大变更后现有README.md已过时
  • 添加重要功能或架构变更后
  • 产品负责人或新利益相关者加入项目时

The Job

工作流程

Step 1: Explore the Codebase

步骤1：探索代码库

Thoroughly explore the project to understand its purpose, architecture, and tech stack:
  • Package manifest: Read 
    package.json
    , 
    composer.json
    , 
    pyproject.toml
    , 
    Cargo.toml
    , or equivalent at root and in sub-packages (monorepo)
  • Project structure: List top-level directories and key files to understand the architecture
  • Documentation: Check for 
    docs/
    directory. Read the first 20-30 lines of each 
    .md
    file in 
    docs/
     to deduce a short French description (one line) for each — this will be used in the Table of Contents
  • CI/CD: Look for 
    .github/workflows/
    , 
    .gitlab-ci.yml
    , 
    Jenkinsfile
    , 
    Dockerfile
    , 
    docker-compose.yml
  • Database: Look for migrations, schemas, Prisma/TypeORM/Sequelize config
  • Routes/Controllers: Scan for route definitions, API endpoints, controllers
  • Git info: Run 
    git log --oneline -10
    and 
    git remote -v
    to understand recent activity and hosting
  • Environment: Look for 
    .env.example
    , environment configuration files
全面探索项目以了解其用途、架构和技术栈：
  • 包清单：读取根目录和子包（单体仓库）下的
    package.json
    、
    composer.json
    、
    pyproject.toml
    、
    Cargo.toml
    或等效文件
  • 项目结构：列出顶层目录和关键文件以理解架构
  • 文档：检查
    docs/
    目录。读取
    docs/
    中每个
    .md
    文件的前20-30行    ，为每个文件推导一句简短的法语描述——将用于目录中
  • CI/CD：查找
    .github/workflows/
    、
    .gitlab-ci.yml
    、
    Jenkinsfile
    、
    Dockerfile
    、
    docker-compose.yml
  • 数据库：查找迁移文件、模式、Prisma/TypeORM/Sequelize配置
  • 路由/控制器：扫描路由定义、API端点、控制器
  • Git信息：运行
    git log --oneline -10
    和
    git remote -v
    以了解近期活动和托管情况
  • 环境：查找
    .env.example
    、环境配置文件

Step 2: Create or Update

步骤2：创建或更新

  • Check if 
    README.md
    exists at the project root
  • If it does NOT exist: Create it from scratch using the template below
  • If it DOES exist: Read the existing content, update factual sections (stack, architecture, features), and preserve any custom sections added by the team
  • 检查项目根目录是否存在
    README.md
  • 若不存在：使用下方模板从头创建
  • 若存在：读取现有内容，更新事实性章节（技术栈、架构、功能），并保留团队添加的所有自定义章节

Step 3: Generate the Content

步骤3：生成内容

Follow the template defined in the "README Template" section below. All content must be in French, following the writing guidelines.
遵循下方“README模板”部分定义的结构。所有内容必须为法语，符合写作指南。

Step 4: Write the File

步骤4：写入文件

Save 
README.md
at the project root.
将
README.md
保存到项目根目录。

Step 5: Generate CLAUDE.md and AGENT.md

步骤5：生成CLAUDE.md和AGENT.md

Only if these files do NOT exist at the project root. If they already exist, do not touch them.
  • CLAUDE.md — Generate instructions for Claude Code based on codebase exploration (see dedicated section below)
  • AGENT.md — Generate instructions for autonomous AI agents based on codebase exploration (see dedicated section below)
仅当项目根目录下不存在这些文件时生成。若已存在，则不修改。
  • CLAUDE.md —— 根据代码库探索结果生成面向Claude Code的指令（见下方专属章节）
  • AGENT.md —— 根据代码库探索结果生成面向自主AI Agent的指令（见下方专属章节）

Step 6: Review Technical Documentation

步骤6：审核技术文档

Review every 
.md
file in the 
docs/
directory and propose improvements following the Documentation Quality Rules defined below.
For each file:
  1. Read the entire file
  2. Evaluate against each rule in the Documentation Quality Rules section
  3. Propose concrete improvements — rewrite sections that violate the rules
  4. Apply changes directly to the files
  5. Report a summary of changes per file to the user
Do NOT delete or remove existing documentation files. Only improve their content.
审核
docs/
目录下的每个
.md
文件，并根据下方定义的文档质量规则提出改进建议。
对每个文件：
  1. 完整读取文件
  2. 评估是否符合文档质量规则中的每条要求
  3. 提出具体改进 —— 重写违反规则的章节
  4. 应用更改直接到文件中
  5. 向用户报告每个文件的更改摘要
请勿删除或移除现有文档文件，仅优化其内容。

Step 7: Identify Missing Documentation

步骤7：识别缺失的文档

Cross-reference the codebase exploration (Step 1) with the existing 
docs/
files to detect critical or important features that are not documented.
  1. Inventory documented topics — List what each 
    docs/*.md
    file covers
  2. Inventory codebase features — From Step 1, list key features, modules, APIs, integrations, workflows, and architectural decisions found in the code
  3. Gap analysis — Compare the two lists. Flag any feature that is:
    • Used in production code but has no corresponding documentation
    • A core business workflow (e.g., authentication, data pipeline, external integrations)
    • An architectural decision that would confuse a new team member without context
    • A complex module with non-obvious behavior
  4. Propose new documentation files — For each gap, present to the user:
    • Suggested file name (e.g., 
      docs/authentication-flow.md
      )
    • One-line description of what it would cover
    • Priority: Critique (blocks understanding of the system) or Important (significantly helps onboarding)
  5. Ask the user which proposed files to create
  6. Generate approved files following the Documentation Quality Rules — in French, concise, PO-oriented, with Mermaid diagrams where useful
将代码库探索结果（步骤1）与现有
docs/
文件进行交叉对比，检测未记录的关键或重要功能。
  1. 已记录主题盘点 —— 列出每个
    docs/*.md
    文件涵盖的内容
  2. 代码库功能盘点 —— 从步骤1中，列出在代码中发现的关键功能、模块、API、集成、工作流和架构决策
  3. 差距分析 —— 对比两个列表。标记以下类型的功能：
    • 生产代码中使用但无对应文档
    • 核心业务工作流（如认证、数据管道、外部集成）
    • 无上下文会让新团队成员困惑的架构决策
    • 行为不明显的复杂模块
  4. 提议新文档文件 —— 对每个差距，向用户展示：
    • 建议的文件名（如
      docs/authentication-flow.md
      ）
    • 一行描述其涵盖的内容
    • 优先级：关键（阻碍对系统的理解）或重要（显著帮助入职）
  5. 询问用户要创建哪些提议的文件
  6. 生成获批文件并遵循文档质量规则——法语、简洁、面向PO，必要时使用Mermaid图表

Step 8: Confirm

步骤8：确认

Summarize to the user what was done:
  • Which files were created vs. updated
  • Key sections included
  • Any information that could not be determined and was left as placeholder
  • Documentation review: list of 
    docs/
    files reviewed with a one-line summary of improvements applied per file
  • Missing documentation: list of new doc files proposed, which were approved and created
向用户总结已完成的工作：
  • 创建和更新了哪些文件
  • 包含的关键章节
  • 无法确定并留为占位符的信息
  • 文档审核：列出已审核的
    docs/
    文件及每个文件的改进摘要
  • 缺失文档：列出提议的新文档文件、已获批并创建的文件

README Template

README模板

The generated README.md must follow this structure:
生成的README.md必须遵循以下结构：

# [Project Name]

# [Project Name]

Short description (1-2 sentences, non-technical). Explain what the product does and who it's for.
简短描述（1-2句，非技术向）。说明产品用途和受众。

## Table des matières

## Table des matières

Auto-generated table of contents listing all README sections with anchor links. Include a sub-section for technical documentation:
markdown
undefined
自动生成的目录，列出所有README章节及锚点链接。包含技术文档子章节：
markdown
undefined

Table des matières

Table des matières

Documentation technique

Documentation technique

DocumentDescription
Architecture REST & WebSocketDescription de l'architecture API
Schéma de base de donnéesStructure des tables et relations

**Important:** The description for each doc file must be deduced from actually reading the file content (Step 1), not invented.
DocumentDescription
Architecture REST & WebSocketDescription de l'architecture API
Schéma de base de donnéesStructure des tables et relations

**重要提示**：每个文档文件的描述必须从实际读取的文件内容（步骤1）推导，而非虚构。

## À quoi sert ce produit ?

## À quoi sert ce produit ?

Business value explanation. 3-5 bullet points describing what the product enables, from the user's perspective.
业务价值说明。3-5个项目符号，从用户视角描述产品能实现的功能。

## Fonctionnalités principales

## Fonctionnalités principales

List of features oriented toward user benefit. Use bullet points. Focus on what the user can do, not how it's implemented.
面向用户收益的功能列表。使用项目符号。聚焦用户能做什么，而非实现方式。

## Comment ça fonctionne

## Comment ça fonctionne

High-level architecture diagram using Mermaid 
graph LR
or 
graph TD
, followed by a short textual explanation.
markdown
```mermaid
graph LR
    A[Utilisateur] --> B[Application Web]
    B --> C[API Backend]
    C --> D[Base de données]
    C --> E[Services externes]
`` `

L'utilisateur interagit avec l'application web, qui communique avec l'API backend. Le backend gère la logique métier et stocke les données en base.
使用Mermaid 
graph LR
或
graph TD
的高层架构图，下方配有简短文字说明。
markdown
```mermaid
graph LR
    A[Utilisateur] --> B[Application Web]
    B --> C[API Backend]
    C --> D[Base de données]
    C --> E[Services externes]
L'utilisateur interagit avec l'application web, qui communique avec l'API backend. Le backend gère la logique métier et stocke les données en base.
undefined

## Environnements

## Environnements

Table with environment information:
markdown
| Environnement | URL | Description |
|---------------|-----|-------------|
| Développement | `http://localhost:3000` | Environnement local |
| Staging | `https://staging.example.com` | Pré-production |
| Production | `https://app.example.com` | Environnement de production |
Use actual URLs if found in config, otherwise use realistic placeholders.
包含环境信息的表格：
markdown
| Environnement | URL | Description |
|---------------|-----|-------------|
| Développement | `http://localhost:3000` | Environnement local |
| Staging | `https://staging.example.com` | Pré-production |
| Production | `https://app.example.com` | Environnement de production |
若在配置中找到实际URL则使用，否则使用合理占位符。

## Déploiement

## Déploiement

CI/CD pipeline as a Mermaid 
graph LR
diagram, followed by a short explanation.
使用Mermaid 
graph LR
图展示CI/CD流水线，下方配有简短说明。

## Stack technique

## Stack technique

Categorized tech stack in 3-5 lines:
markdown
- **Frontend :** React, TypeScript, TailwindCSS
- **Backend :** Node.js, NestJS, TypeORM
- **Base de données :** PostgreSQL
- **Hébergement :** Docker, GitLab CI/CD
分类后的技术栈，3-5行：
markdown
- **Frontend :** React, TypeScript, TailwindCSS
- **Backend :** Node.js, NestJS, TypeORM
- **Base de données :** PostgreSQL
- **Hébergement :** Docker, GitLab CI/CD

## Documentation complémentaire

## Documentation complémentaire

Links to 
docs/
files if they exist. If no docs folder exists, omit this section.
若存在
docs/
文件则添加链接。若无docs目录则省略此章节。

Mermaid Diagram Rules

Mermaid图表规则

  1. Labels in French — All node labels and edge labels must be in French
  2. Maximum 8-10 nodes per diagram — Keep diagrams readable and high-level
  3. Allowed types: 
    graph
    , 
    flowchart
    , 
    sequenceDiagram
  4. Forbidden types: 
    classDiagram
    , 
    erDiagram
    , 
    stateDiagram
    (too technical for PO audience)
  5. Textual explanation under every diagram — The diagram alone is not enough
  6. Simple and clear — Avoid nested subgraphs, complex conditions, or technical details
  1. 法语标签 —— 所有节点标签和边标签必须为法语
  2. 每个图最多8-10个节点 —— 保持图表可读性和高层视角
  3. 允许的类型：
    graph
    、
    flowchart
    、
    sequenceDiagram
  4. 禁止的类型：
    classDiagram
    、
    erDiagram
    、
    stateDiagram
    （对PO受众过于技术化）
  5. 每个图下方配文字说明 —— 仅图表不足够
  6. 简洁清晰 —— 避免嵌套子图、复杂条件或技术细节

Example Mermaid Diagram

Mermaid图表示例

mermaid
graph LR
    A[Développeur] -->|Push du code| B[GitLab CI]
    B -->|Tests auto| C{Tests OK ?}
    C -->|Oui| D[Déploiement Staging]
    C -->|Non| E[Notification erreur]
    D -->|Validation manuelle| F[Déploiement Production]
Ce diagramme illustre le pipeline de déploiement continu. Lorsqu'un développeur pousse du code, les tests automatiques se lancent. Si les tests réussissent, le code est déployé en staging puis, après validation manuelle, en production.
mermaid
graph LR
    A[Développeur] -->|Push du code| B[GitLab CI]
    B -->|Tests auto| C{Tests OK ?}
    C -->|Oui| D[Déploiement Staging]
    C -->|Non| E[Notification erreur]
    D -->|Validation manuelle| F[Déploiement Production]
Ce diagramme illustre le pipeline de déploiement continu. Lorsqu'un développeur pousse du code, les tests automatiques se lancent. Si les tests réussissent, le code est déployé en staging puis, après validation manuelle, en production.

French Writing Guidelines

法语写作指南

  • Natural and professional French, use "vous" (vouvoiement)
  • Avoid anglicisms except for technical terms without French equivalent (WebSocket, Docker, CI/CD, API, etc.)
  • Short sentences: maximum 20 words per sentence
  • Bullet points preferred over long paragraphs
  • No technical jargon — Write for a Product Owner, not a developer
  • No code blocks in the README (except Mermaid diagrams)
  • Acronyms explained at first occurrence (ex: "CI/CD (Intégration et Déploiement Continus)")
  • Consistent terminology throughout the document
  • 自然且专业的法语，使用“vous”（正式称谓）
  • 避免英语化表达，除非无法语等效的技术术语（如WebSocket、Docker、CI/CD、API等）
  • 短句：每句最多20个单词
  • 优先使用项目符号而非长段落
  • 无技术行话 —— 为产品负责人而非开发者撰写
  • README中无代码块（Mermaid图表除外）
  • 首字母缩写首次出现时需解释（如："CI/CD (Intégration et Déploiement Continus)"）
  • 术语一致贯穿整个文档

Documentation Quality Rules

文档质量规则

These rules apply when reviewing and improving files in 
docs/
. Each doc file must comply.
这些规则适用于审核和优化
docs/
中的文件。每个文档文件必须遵守。

Language

语言

  • Written in French — All content must be in French
  • Exception: Technical terms without French equivalent (API, WebSocket, Docker, CI/CD, JSON, etc.) stay in English
  • Vouvoiement — Use "vous" consistently
  • Acronyms explained at first occurrence
  • 法语书写 —— 所有内容必须为法语
  • 例外：无法语等效的技术术语（API、WebSocket、Docker、CI/CD、JSON等）保留英文
  • 正式称谓 —— 始终使用“vous”
  • 首字母缩写首次出现时需解释

Conciseness

简洁性

  • Short sentences — Maximum 20 words per sentence
  • Bullet points over paragraphs — Prefer structured lists to long blocks of text
  • No filler — Remove introductions like "Dans cette section, nous allons voir..." — go straight to the point
  • One idea per paragraph — If a paragraph covers two topics, split it
  • 短句 —— 每句最多20个单词
  • 优先使用项目符号而非段落 —— 结构化列表优于长文本块
  • 无冗余内容 —— 删除类似“Dans cette section, nous allons voir...”的引言，直接切入主题
  • 每段一个核心思想 —— 若段落涵盖两个主题，拆分

Readability

可读性

  • Scan-friendly structure — Use headings (H2, H3) liberally so the reader can jump to what they need
  • Bold key terms on first mention in a section
  • Tables for comparisons — When comparing options, features, or configurations, use a table instead of prose
  • Code examples short and focused — Maximum 10-15 lines per code block, with a one-line comment explaining the purpose
  • 便于扫描的结构 —— 大量使用标题（H2、H3），便于读者跳转到所需内容
  • 章节中首次提及的关键术语加粗
  • 对比内容使用表格 —— 当对比选项、功能或配置时，使用表格而非散文
  • 代码示例简短聚焦 —— 每个代码块最多10-15行，配一行注释说明用途

Audience

受众

  • Product Owner oriented by default — Explain the "what" and "why" before the "how"
  • Technical depth when the subject requires it — Parsers, protocols, database schemas, API contracts can and should include technical details
  • Label technical sections clearly — Use a heading or callout (e.g., "> Détail technique") so non-technical readers can skip them
  • 默认面向产品负责人 —— 先解释“是什么”和“为什么”，再说明“怎么做”
  • 主题需要时增加技术深度 —— 解析器、协议、数据库模式、API契约可以且应包含技术细节
  • 清晰标记技术章节 —— 使用标题或提示框（如"> Détail technique"），便于非技术读者跳过

Mermaid Diagrams

Mermaid图表

  • Prefer a diagram over a long description — If a concept involves a flow, sequence, or architecture, use Mermaid instead of (or in addition to) text
  • Follow the Mermaid Diagram Rules defined above (French labels, max 8-10 nodes, allowed types, textual explanation below)
  • Replace verbose explanations — If a section has 5+ lines describing a flow or architecture, consider replacing or supplementing with a diagram
  • 优先用图表替代长描述 —— 若概念涉及流程、序列或架构，使用Mermaid替代（或补充）文本
  • 遵循上述Mermaid图表规则（法语标签、最多8-10个节点、允许的类型、下方配文字说明）
  • 替换冗长说明 —— 若章节有5行以上描述流程或架构，考虑用图表替换或补充

Structure

结构

  • Every doc file must start with a H1 title matching the file name / topic
  • A short intro paragraph (1-2 sentences) right after the title explaining what this document covers and who it's for
  • Logical section order: Context/Purpose → How it works → Details/Reference → Examples
  • 每个文档文件必须以与文件名/主题匹配的H1标题开头
  • 标题后紧跟简短引言段落（1-2句），说明文档涵盖内容和受众
  • 逻辑章节顺序：上下文/用途 → 工作原理 → 细节/参考 → 示例

Create vs. Update Mode

创建模式vs更新模式

Creation Mode (no existing README.md)

创建模式（无现有README.md）

Generate all sections from scratch based on codebase exploration.
基于代码库探索结果生成所有章节。

Update Mode (README.md already exists)

更新模式（已存在README.md）

  1. Read the existing README.md
  2. Identify which sections match the template
  3. Update factual sections (stack, architecture, features, environments) with current codebase state
  4. Preserve custom sections that don't match the template — they may have been added manually by the team
  5. Update the table of contents to reflect all sections
  1. 读取现有README.md
  2. 识别与模板匹配的章节
  3. 使用当前代码库状态更新事实性章节（技术栈、架构、功能、环境）
  4. 保留与模板不匹配的自定义章节 —— 这些可能是团队手动添加的
  5. 更新目录以反映所有章节

CLAUDE.md Generation

CLAUDE.md生成

Only generate if 
CLAUDE.md
does not exist at the project root.
Explore the codebase to deduce and include:
  • Project overview: One-paragraph summary of what the project is
  • Tech stack and key dependencies with versions
  • Project structure: Key directories and their purpose
  • Useful commands: dev, build, test, lint, migrate, seed — with actual commands found in package.json scripts or Makefile
  • Code conventions: Naming patterns, file structure patterns, architectural patterns observed (e.g., React hooks, service pattern, controller/route separation)
  • Git workflow: Branch naming conventions (if observable), commit message patterns (from git log)
  • Key files and directories that Claude should know about
  • Gotchas and important notes specific to the project (e.g., monorepo structure, shared packages, environment variables needed)
  • Patterns to follow when writing new code (deduced from existing code style)
仅当项目根目录下不存在
CLAUDE.md
时生成。
探索代码库以推导并包含：
  • 项目概述：一段关于项目用途的摘要
  • 技术栈和关键依赖及版本
  • 项目结构：关键目录及其用途
  • 有用命令：dev、build、test、lint、migrate、seed —— 使用在package.json脚本或Makefile中找到的实际命令
  • 代码规范：命名模式、文件结构模式、观察到的架构模式（如React hooks、服务模式、控制器/路由分离）
  • Git工作流：分支命名规范（若可观察到）、提交消息模式（来自git log）
  • Claude应了解的关键文件和目录
  • 项目特定的注意事项和重要提示（如单体仓库结构、共享包、所需环境变量）
  • 编写新代码时应遵循的模式（从现有代码风格推导）

AGENT.md Generation

AGENT.md生成

Only generate if 
AGENT.md
does not exist at the project root.
Explore the codebase to deduce and include:
  • Project summary and objective (2-3 sentences)
  • Monorepo structure and dependencies between packages (if applicable)
  • Essential commands: install, dev, build, test, migrate, seed — with actual commands
  • Code conventions to respect when making automated changes
  • Development workflow: Branches, commits, CI/CD pipeline
  • Important notes for automated modifications: What to avoid, what to always do, critical files not to modify
仅当项目根目录下不存在
AGENT.md
时生成。
探索代码库以推导并包含：
  • 项目摘要和目标（2-3句）
  • 单体仓库结构和包之间的依赖（若适用）
  • 核心命令：install、dev、build、test、migrate、seed —— 使用实际命令
  • 自动修改时需遵守的代码规范
  • 开发工作流：分支、提交、CI/CD流水线
  • 自动修改的重要注意事项：避免什么、必须做什么、不可修改的关键文件

Example Output

示例输出

Here is a condensed example of the expected README format:
markdown
undefined
以下是预期README格式的精简示例：
markdown
undefined

Overwatch

Overwatch

Plateforme de supervision applicative permettant de surveiller la santé et les performances de vos applications en temps réel.
Plateforme de supervision applicative permettant de surveiller la santé et les performances de vos applications en temps réel.

Table des matières

Table des matières

Documentation technique

Documentation technique

DocumentDescription
Architecture APIVue d'ensemble de l'architecture REST
DocumentDescription
Architecture APIVue d'ensemble de l'architecture REST

À quoi sert ce produit ?

À quoi sert ce produit ?

  • Surveiller la disponibilité de vos applications en continu
  • Recevoir des alertes en cas de dysfonctionnement
  • Visualiser l'historique de santé via des tableaux de bord
  • Gérer les environnements de déploiement (dev, staging, production)
  • Centraliser la supervision de toutes vos applications
  • Surveiller la disponibilité de vos applications en continu
  • Recevoir des alertes en cas de dysfonctionnement
  • Visualiser l'historique de santé via des tableaux de bord
  • Gérer les environnements de déploiement (dev, staging, production)
  • Centraliser la supervision de toutes vos applications

Fonctionnalités principales

Fonctionnalités principales

  • Tableau de bord temps réel — Vue d'ensemble de la santé de toutes vos applications
  • Historique de santé — Graphiques et métriques sur les performances passées
  • Gestion multi-environnements — Suivi par environnement de déploiement
  • Alertes automatiques — Notification en cas de dégradation du service
  • Tableau de bord temps réel — Vue d'ensemble de la santé de toutes vos applications
  • Historique de santé — Graphiques et métriques sur les performances passées
  • Gestion multi-environnements — Suivi par environnement de déploiement
  • Alertes automatiques — Notification en cas de dégradation du service

Comment ça fonctionne

Comment ça fonctionne

``mermaid graph LR     A[Utilisateur] --> B[Interface Web]     B --> C[API NestJS]     C --> D[Base PostgreSQL]     C --> E[Vérification de santé]     E --> F[Applications surveillées]
``
L'utilisateur accède à l'interface web pour consulter l'état de ses applications. L'API backend effectue des vérifications de santé régulières et stocke les résultats en base de données.
mermaid
graph LR
    A[Utilisateur] --> B[Interface Web]
    B --> C[API NestJS]
    C --> D[Base PostgreSQL]
    C --> E[Vérification de santé]
    E --> F[Applications surveillées]
L'utilisateur accède à l'interface web pour consulter l'état de ses applications. L'API backend effectue des vérifications de santé régulières et stocke les résultats en base de données.

Stack technique

Stack technique

  • Frontend : React 18, TypeScript, TailwindCSS
  • Backend : NestJS, TypeORM, PostgreSQL
  • Infrastructure : Docker, GitLab CI/CD

---
  • Frontend : React 18, TypeScript, TailwindCSS
  • Backend : NestJS, TypeORM, PostgreSQL
  • Infrastructure : Docker, GitLab CI/CD

---

Checklist

检查清单

Before saving the README.md, verify:
  • All content is in French (except technical terms)
  • Table of contents matches all sections with correct anchor links
  • Documentation technique sub-section lists all 
    docs/*.md
    files with descriptions deduced from content
  • Mermaid diagrams are valid and have max 8-10 nodes
  • Mermaid diagrams use only allowed types (graph, flowchart, sequenceDiagram)
  • Every diagram has a textual explanation below it
  • Labels in Mermaid diagrams are in French
  • No code blocks (except Mermaid)
  • Sentences are under 20 words
  • Vouvoiement used consistently
  • Acronyms explained at first occurrence
  • CLAUDE.md generated only if it did not exist
  • AGENT.md generated only if it did not exist
  • All 
    docs/*.md
    files reviewed against Documentation Quality Rules
  • Docs are in French, concise, scan-friendly, and PO-oriented
  • Mermaid diagrams added where they replace verbose explanations
  • Gap analysis performed: codebase features vs. existing documentation
  • Missing critical/important docs proposed to user before creation
  • New doc files follow Documentation Quality Rules
  • User informed of what was created/updated, docs improved, and new docs proposed/created
保存README.md前，请验证：
  • 所有内容为法语（技术术语除外）
  • 目录与所有章节匹配，锚点链接正确
  • 技术文档子章节列出所有
    docs/*.md
    文件，描述来自内容推导
  • Mermaid图表有效，最多8-10个节点
  • Mermaid图表仅使用允许的类型（graph、flowchart、sequenceDiagram）
  • 每个图下方配有文字说明
  • Mermaid图表中的标签为法语
  • 无代码块（Mermaid除外）
  • 句子少于20个单词
  • 始终使用正式称谓“vous”
  • 首字母缩写首次出现时已解释
  • 仅当不存在时生成了CLAUDE.md
  • 仅当不存在时生成了AGENT.md
  • 所有
    docs/*.md
    文件已根据文档质量规则审核
  • 文档为法语、简洁、便于扫描、面向PO
  • 在可替代冗长说明的位置添加了Mermaid图表
  • 已执行差距分析：代码库功能vs现有文档
  • 向用户提议了缺失的关键/重要文档后再创建
  • 新文档文件遵循文档质量规则
  • 已向用户告知创建/更新的内容、优化的文档、提议/创建的新文档