tressi/dist/browser/docs/style-guide.md

Deterministic load testing for API performance validation.

### **The Tressi Documentation Style Guide**

**1. Technical & Objective (No Sales Pitches)**

- **Avoid**: Subjective adjectives like "modern," "powerful," "effortless," "easy," or "beautiful."
- **Use**: Descriptive technical terms like "optimized," "parallel," "low-overhead," or "multithreaded."
- **Rule**: Let the features speak for themselves. Describe _what_ it does and _how_ it works, not how the user should feel about it.

**2. Minimalist & Concise**

- **Avoid**: Long "laundry lists" of items separated by many commas.
- **Use**: Grouped categories (e.g., "performance metrics" instead of "P99, RPS, and error rates") or bullet points.
- **Rule**: If a word doesn't add technical value, cut it. Keep sentences lean and focused on a single action or concept.

**3. Action-Oriented Headings**

- **Avoid**: Abstract nouns or marketing buzzwords (e.g., "Data Portability," "CI/CD Ready").
- **Use**: Direct, functional labels (e.g., "Export & Import," "CLI Integration," "Parallel Execution").
- **Rule**: Headings should tell the user exactly what capability they are about to read about.

**4. Developer-Centric Vocabulary**

- **Avoid**: Hyphenated marketing terms (e.g., "Multi-Endpoint") when a cleaner technical alternative exists. Avoid hyphenated terms in general.
- **Use**: Industry standard terminology (e.g., "Headless," "Runtime," "Payload," "Schema").
- **Rule**: Speak to the user as a peer engineer. Assume they value precision and efficiency over "user-friendliness" buzzwords.

**5. Outcome-Focused**

- **Rule**: Every bullet point or paragraph should answer: "What can I achieve with this?" (e.g., "Run tests in automated pipelines" vs. "We have a CLI").