refactor spec OKF

docs/rules/DOCUMENTATION.md

@@ -1,24 +1,36 @@
 ---
-type: Reference
-title: IAgent Documentation Rules
-description: Rules and guidelines for documentation in the IAgent project, following OKF v0.2 specification
+type: Rule
+title: Documentation Rules
+description: Rules and guidelines for documentation in the WSG project, following OKF v0.2 specification
+resource: https://github.com/wsg-project/wsg/blob/main/docs/rules/DOCUMENTATION.md
 tags: [documentation, guidelines, standards]
-status: stable
-generated: { by: human:jerome, at: 2026-07-31T00:00:00Z }
+sources: [{ ref: SPEC.md }]
+verified: { by: "human:jerome", at: 2026-07-31T00:00:00Z }
+status: active
+stale_after: 2027-01-31T00:00:00Z
+generated: { by: "human:jerome", at: 2026-07-31T00:00:00Z }
 ---
 
-# IAgent Documentation Rules
+# Documentation Rules
 
-## Language
+## Schema
+
+All documentation follows the OKF v0.2 specification (see [SPEC.md](https://github.com/wsg-project/wsg/blob/main/docs/rules/SPEC.md)). This document defines project-specific rules for writing and maintaining code documentation.
+
+## Conventions
+
+### Language
 
 All documentation is written in English; as a convention, the code itself uses English for variable names, function names, etc.
 
-## Code Documentation
+### Code Documentation
 
 Every source file and configuration file must be systematically documented following the rules defined in this DOCUMENTATION.md file. Additionally, every directory must contain its own README.md file summarizing and explaining the module's organization at that level: what is the overall responsibility of the files grouped in this directory, which ones they are, and what each one does.
 
 We assume the reader has professional algorithmic knowledge but may not necessarily be a Rust specialist. The reader does know the project's domain — LLM logic, clients, and agents. Documentation should therefore be tailored for a professional developer who knows some programming languages (not necessarily Rust).
 
+## Examples
+
 ### General Rule
 
 Documentation must describe what is coded and what purpose it serves. A LLM reading the code and documentation should be able to verify whether:
@@ -29,7 +41,7 @@ Documentation must describe what is coded and what purpose it serves. A LLM read
 
 Each module or file must include documentation explaining the module's responsibility and how it interacts with other modules in the program, at least those within its own directory. This documentation must detail the main objects (Struct, Enum, Trait) manipulated in the module and the primary functions that carry the module's core logic.
 
-## Within a File's Code
+## Internal Steps
 
 ### Object and Function Headers
 
@@ -39,6 +51,6 @@ At the header of each object, describe what the object represents and its purpos
 
 If an object or function presents a particularity or specific technical point, then a descriptive comment is inserted directly into the code body or function body. If a point of attention or technical point was described in the function header, then a comment in the code body reminds where this point is located.
 
-## Documentation Maintenance
+## Maintenance
 
 The rules defined in this file are regularly applied across all code documentation to ensure consistency between code evolution and its documentation.