|
| 1 | +# KiteSQL Agent Guide |
| 2 | + |
| 3 | +This document defines the engineering principles, code style, and contribution expectations |
| 4 | +for the KiteSQL project. |
| 5 | + |
| 6 | +KiteSQL is a lightweight, simple, low-dependency OLTP database. |
| 7 | +All code contributions (human or AI-generated) must follow the rules below. |
| 8 | + |
| 9 | +--- |
| 10 | + |
| 11 | +## 1. Project Philosophy |
| 12 | + |
| 13 | +KiteSQL prioritizes: |
| 14 | + |
| 15 | +- Lightweight design |
| 16 | +- Simple and explicit logic |
| 17 | +- Low dependency footprint |
| 18 | +- High correctness through testing |
| 19 | +- Readable code over clever code |
| 20 | + |
| 21 | +This is an OLTP-oriented system. |
| 22 | +Predictability, correctness, and maintainability are more important than micro-optimizations. |
| 23 | + |
| 24 | +--- |
| 25 | + |
| 26 | +## 2. Testing Requirements (MANDATORY) |
| 27 | + |
| 28 | +### 2.1 Makefile Is the Source of Truth |
| 29 | + |
| 30 | +All test commands must be defined and discoverable in the Makefile. |
| 31 | + |
| 32 | +This includes (but is not limited to): |
| 33 | + |
| 34 | +- Unit tests |
| 35 | +- Integration tests |
| 36 | +- SQL behavior tests |
| 37 | +- Regression tests |
| 38 | + |
| 39 | +If a test cannot be triggered via make, it is considered incomplete. |
| 40 | + |
| 41 | +Examples: |
| 42 | +``` |
| 43 | +make test |
| 44 | +make test-unit |
| 45 | +make test-integration |
| 46 | +``` |
| 47 | + |
| 48 | +PRs must not introduce hidden, ad-hoc, or undocumented test commands. |
| 49 | + |
| 50 | +--- |
| 51 | + |
| 52 | +### 2.2 Tests Are Not Optional |
| 53 | + |
| 54 | +- Every PR must include sufficient unit tests |
| 55 | +- New functionality must be covered by tests |
| 56 | +- Bug fixes must include regression tests |
| 57 | + |
| 58 | +If logic is complex, tests are preferred over comments. |
| 59 | + |
| 60 | +Untested code is considered incomplete code. |
| 61 | + |
| 62 | +--- |
| 63 | + |
| 64 | +### 2.3 Expand Test Coverage When Touching Code |
| 65 | + |
| 66 | +When modifying existing functionality, contributors are expected to: |
| 67 | + |
| 68 | +- Identify related edge cases or failure modes |
| 69 | +- Add unit tests for behaviors that were previously untested |
| 70 | +- Strengthen coverage around logic affected by the change |
| 71 | + |
| 72 | +This applies even if the original change request does not explicitly ask for new tests. |
| 73 | + |
| 74 | +If you are already touching the code, it is the best time to fix missing tests. |
| 75 | + |
| 76 | +PRs that modify logic but leave obvious test gaps untouched may be rejected. |
| 77 | + |
| 78 | +--- |
| 79 | + |
| 80 | +## 3. Code Simplicity Rules |
| 81 | + |
| 82 | +### 3.1 Prefer Simple Code |
| 83 | + |
| 84 | +- Prefer straightforward control flow |
| 85 | +- Avoid unnecessary abstractions |
| 86 | +- Avoid premature generalization |
| 87 | +- Avoid clever tricks that reduce readability |
| 88 | + |
| 89 | +If something can be written clearly using fewer concepts, do that. |
| 90 | + |
| 91 | +--- |
| 92 | + |
| 93 | +### 3.2 Low Comments, High Signal |
| 94 | + |
| 95 | +- Do not comment obvious code |
| 96 | +- Do not restate what the code already expresses |
| 97 | +- Prefer self-explanatory naming |
| 98 | + |
| 99 | +However, the following must include short, precise comments: |
| 100 | + |
| 101 | +- Complex logic |
| 102 | +- Non-obvious invariants |
| 103 | +- Encoding, ordering, or correctness-sensitive behavior |
| 104 | + |
| 105 | +Comments should explain why, not what. |
| 106 | + |
| 107 | +Example: |
| 108 | +```rust |
| 109 | +// Keys are encoded in mem-comparable form to preserve lexicographical ordering |
| 110 | +``` |
| 111 | + |
| 112 | +--- |
| 113 | + |
| 114 | +## 4. Code Reuse & Structure |
| 115 | + |
| 116 | +### 4.1 Reuse Over Duplication |
| 117 | + |
| 118 | +- Prefer extracting shared logic over copy-pasting |
| 119 | +- Shared behavior should live in a single place |
| 120 | +- Avoid near-duplicate implementations with small differences |
| 121 | + |
| 122 | +If code looks similar in multiple places, it probably wants to be reused. |
| 123 | + |
| 124 | +--- |
| 125 | + |
| 126 | +### 4.2 Minimal APIs |
| 127 | + |
| 128 | +- Public APIs should be minimal and intentional |
| 129 | +- Avoid exposing internal details |
| 130 | +- Keep modules small, focused, and cohesive |
| 131 | + |
| 132 | +--- |
| 133 | + |
| 134 | +## 5. Dependency Policy |
| 135 | + |
| 136 | +- Dependencies are costly |
| 137 | +- Every new dependency must be justified |
| 138 | +- Prefer standard library solutions where possible |
| 139 | +- Avoid heavy frameworks or macro-heavy crates unless strictly necessary |
| 140 | + |
| 141 | +KiteSQL aims to stay easy to build, easy to audit, and easy to understand. |
| 142 | + |
| 143 | +--- |
| 144 | + |
| 145 | +## 6. PR Expectations |
| 146 | + |
| 147 | +A valid PR should: |
| 148 | + |
| 149 | +- Compile cleanly |
| 150 | +- Pass all tests via make |
| 151 | +- Include new tests if behavior changes |
| 152 | +- Improve or extend test coverage when touching existing code |
| 153 | +- Keep code simple and readable |
| 154 | +- Reuse existing abstractions where possible |
| 155 | +- Follow the spirit of KiteSQL: simple, lightweight, correct |
| 156 | + |
| 157 | +PRs that increase complexity without clear benefit may be rejected. |
| 158 | + |
| 159 | +--- |
| 160 | + |
| 161 | +## 7. Final Principle |
| 162 | + |
| 163 | +If the code is hard to understand, it is probably wrong. |
| 164 | + |
| 165 | +Clarity is a feature. |
0 commit comments