# ling-lang Project Rules
## Hard Rules
1. **No simplifications, demonstrations, or partial implementations.** ling-lang is a professional language. Every feature must be production-grade and complete. No stubs, no TODOs left behind, no "simplified for brevity."
2. **No unnecessary or AI-looking comments.** Comments and documentation must read like a human wrote them: concise, purposeful, not decorative. No AI-style narration, no corny remarks, no stating the obvious, no corporate jargon, and absolutely no decorative separators or dividers like `------------`.
3. **No AI attribution.** All credit goes to the author: **ecnivs**. No "generated by" or "assisted by" footprints anywhere in code, docs, or commits.
4. **New features must be heavily optimized.** Performance is not an afterthought. Every addition should be benchmarked, profiled, and tuned before being considered done.
5. **Clean up after yourself.** If development introduces dead code, redundant paths, or orphaned logic, remove it immediately. No cruft accumulates.
6. **Benchmarking uses hyperfine.** All performance benchmarks must be run through `hyperfine` for consistent, reproducible results.
7. **Brutal honesty over politeness.** No sugarcoating, no yes-man behavior. If a decision is wrong for the future of the language, say so directly and with strong opinions. The language's long-term health comes first.
8. **Standard libraries must be real implementations.** No thin wrappers around host-language builtins. Libraries ship with real algorithms and real data structures. They are written in ling-lang or implemented natively with purpose. If a library needs a sort, it implements a sort. If it needs a hash map, it implements a hash map.
9. **Self-hosting is the endgame.** ling-lang is being built with the vision of writing itself. If something can be written in ling-lang, it should be. Libraries, tooling, and tests should default to ling-lang unless there's a hard technical reason not to.
10. **Fill language gaps before working around them.** If a library needs a feature that any professional language should have (e.g., XOR, bitwise ops, slicing) and ling-lang doesn't support it yet; stop, implement it in the compiler backend first, then continue the library. Don't hack around missing fundamentals.
11. **Commit messages must be human.** Concise, no fluff, no emoji spam, no AI-style bullet lists. Cover all changes in the commit accurately. Write it like a developer, not a press release.
12. **No oversized files.** Keep source files within a reasonable count of lines (ideally under 500 lines, and strictly not exceeding 1000 lines). Keep files focused, concise, and modular; do not let them become bloated. Split them into clean, separate files/modules when they exceed these limits or take on unrelated responsibilities.
13. **Zero warnings or errors.** The code must compile and lint perfectly. No warnings, errors, or lints are allowed to remain in active code.
14. **Tests and benchmarks must pass cleanly.** All unit tests, integration tests, and benchmarks must pass completely without any warnings, deprecations, or errors.
15. **Maintain simple syntax without compromise.** ling-lang's core principle is syntax simplicity. Keep syntax minimal, clean, and highly readable, without compromising on performance, power, or functionality.
16. **No commented-out code or obsolete comments.** Never leave commented-out blocks of code, temporary debugging comments, or stale explanations in the codebase. Actively clean up unnecessary or redundant comments.
17. **Clean up temporary and one-use files.** Any scratchpads, mock files, one-use scripts, or experimental test files created during development must be deleted once they are no longer needed. Never commit temporary development artifacts.
18. **Write highly scalable and clean code.** Code quality and scalability are non-negotiable. Avoid short-sighted hacks, hardcoded limits, or monolithic designs. Design components to be modular, extensible, and clean from day one.
19. **Do not commit code unless explicitly instructed.** Never perform Git commits or run git commit commands on behalf of the user unless they have explicitly instructed you to do so.
20. **No cheating on optimizations.** Performance optimizations must be genuine, general-purpose improvements. Never optimize specifically for a target benchmark's inputs or parameters at the expense of other code paths, overall performance, or correctness.
21. **Cross-platform compatibility is mandatory.** All code, libraries, and compiler features must be fully compatible across all major platforms (Linux, macOS, Windows). Never hardcode platform-specific assumptions, paths, environment variables, or dependencies; always use dynamic detection or unified abstractions.
22. **Documentation must be precise and synchronized.** The official documentation at https://docs.ling-lang.org is the source of truth. Every change to the language — keywords, syntax, parser rules, compiler behavior, standard library — must be reflected immediately and accurately in the docs. No outdated docs, no placeholders, no "coming soon" sections for implemented features.
23. **Lexicon is the master record.** The `./lexicon/` directory contains the definitive definitions for every keyword, function, operator, and built-in. Any addition, removal, or modification to the language's vocabulary must start by updating the lexicon entries. Lexicon entries must be complete, precise, and consistent across all supported languages.
24. **All five East Asian languages plus English are first-class.** ling-lang supports English, Thai, Korean, Japanese, and Chinese as equal-tier interface languages. Every keyword, function name, error message, and documentation entry must exist and be properly maintained in all six languages. No language falls behind. No "defaults to English" for missing translations.
25. **Parser rules must be tested and deterministic.** Every grammar rule must have comprehensive test coverage. No ambiguous parses, no hidden precedence assumptions, no undocumented edge cases. The parser must produce the same AST given the same source code regardless of platform or environment.
26. **Build targets are non-negotiable.** The compiler must produce working executables for Windows, macOS, Linux, and Web (WASM/JS) from the same codebase. No target-specific hacks that break others. Each target must pass the full test suite before any release.
27. **Follow ling-lang conventions.** Code in the compiler, standard library, and tooling must follow ling-lang's own naming conventions, style guide, and idioms. When writing in host languages (Rust/C/etc) for bootstrapping, mirror ling-lang conventions as closely as possible.