telemt/AGENTS_SYSTEM_PROMT.md

System Prompt - Modification and Architecture Guidelines

You are working on a production-grade Rust codebase: follow these rules strictly!

1. Comments and Documentation

• All comments MUST be written in English.
• Comments MUST be concise, precise, and technical.
• Comments MUST describe architecture, intent, invariants, and non-obvious implementation details.
• DO NOT add decorative, conversational, or redundant comments.
• DO NOT add trailing comments at the end of code lines.
• Place comments on separate lines above the relevant code.

Correct example:

// Handles MTProto client authentication and establishes encrypted session state.
fn handle_authenticated_client(...) { ... }

Incorrect example:

let x = 5; // set x to 5 lol

---

2. File Size and Module Structure

• DO NOT create files larger than 350–550 lines.
• If a file exceeds this limit, split it into submodules.
• Organize submodules logically by responsibility (e.g., protocol, transport, state, handlers).
• Parent modules MUST declare and describe submodules.

Correct example:

// Client connection handling logic.
// Submodules:
// - handshake: MTProto handshake implementation
// - relay: traffic forwarding logic
// - state: client session state machine

pub mod handshake;
pub mod relay;
pub mod state;

• Maintain clear architectural boundaries between modules.

---

3. Formatting

• DO NOT run cargo fmt.
• DO NOT reformat existing code unless explicitly instructed.
• Preserve the existing formatting style of the project.

---

4. Change Safety and Validation

• DO NOT guess intent, behavior, or missing requirements.
• If anything is unclear, STOP and ask questions.
• Actively ask questions before making architectural or behavioral changes.
• Prefer clarification over assumptions.

---

5. Warnings and Unused Code

• DO NOT fix warnings unless explicitly instructed.

• DO NOT remove:

  • unused variables
  • unused functions
  • unused imports
  • dead code

These may be intentional.

---

6. Architectural Integrity

• Preserve existing architecture unless explicitly instructed to refactor.
• DO NOT introduce hidden behavioral changes.
• DO NOT introduce implicit refactors.
• Keep changes minimal, isolated, and intentional.

---

7. When Modifying Code

You MUST:

• Maintain architectural consistency.
• Document non-obvious logic.
• Avoid unrelated changes.
• Avoid speculative improvements.

You MUST NOT:

• Refactor unrelated code.
• Rename symbols without explicit reason.
• Change formatting globally.

---

If requirements are ambiguous, ask questions BEFORE implementing changes.