feat: update README and documentation for new tools and features

- Updated README.md to reflect the addition of 3 new built-in tools, bringing the total to 37.
- Revised architecture documentation to indicate the increase in tool count.
- Enhanced backend documentation with updated line counts for various modules.
- Modified data documentation to change edit log format from JSON to JSONL.
- Updated dependencies documentation to reflect version upgrades for several crates.
- Improved prompts for auto-reviewer, division implementer, planner, tester, and quality reviewer to enforce stricter coding standards regarding linter bypasses.
- Refactored code in various modules to improve clarity and performance, including updates to error handling and tool execution logic.
- Added comprehensive tests for IPC frame serialization and deserialization.

src-misc/auto-reviewer-prompt.txt

@@ -9,6 +9,7 @@ Review guidelines:
 2. Check for logic errors: null/panic paths, off-by-one errors, race conditions, unhandled edge cases.
 3. Check naming and structure consistency with the existing codebase patterns.
 4. Check that the implementation matches the apparent intent.
+5. Check for linter bypasses: Ensure that compiler/linter bypass annotations or attributes (such as `#[allow(clippy::too_many_lines, clippy::too_many_arguments, clippy::ref_option)]`, `#[allow(dead_code)]`, etc.) are NEVER used to silence warnings or skip linter checks. Reject them.
 
 Output: a concise 2-4 line verdict. If you find issues, be specific about what and where.
 Skip if the file is trivial (config, tests with no logic changes).

src-misc/division-implementer-prompt.txt

@@ -14,6 +14,7 @@ Full access: read, write, edit, delete, bash, grep, glob, git_operator, lsp_*, s
 6. Run `cargo build` or equivalent after each logical chunk.
 7. If you encounter an issue not covered by the plan, use `note_finding` to flag it.
 8. Update todo.md as you complete each file: `todofinish`
+9. NEVER use compiler/linter bypass annotations or attributes (such as `#[allow(clippy::too_many_lines, clippy::too_many_arguments, clippy::ref_option)]`, `#[allow(dead_code)]`, etc.) to skip or silence warnings. Fix the underlying code to adhere to linter guidelines.
 
 ## Output
 After each file: confirm what was implemented and any deviations from plan.

src-misc/division-planner-prompt.txt

@@ -31,4 +31,5 @@ You MUST produce a structured plan covering:
 - Use `seqthink` for complex reasoning steps
 - Every plan MUST include at least one mermaid diagram
 - Be specific with file paths and function names
+- Ensure implementation plans NEVER suggest or allow using compiler/linter bypass annotations or attributes (such as `#[allow(clippy::too_many_lines, clippy::too_many_arguments, clippy::ref_option)]`, `#[allow(dead_code)]`, etc.) to silence warnings; always plan to fully resolve underlying code issues.
 - Output ends with a clear "Plan Complete" marker

src-misc/division-tester-prompt.txt

@@ -9,6 +9,7 @@ Check for:
 - Stubs, placeholders, incomplete branches
 - Naming consistency with codebase conventions
 - Error handling coverage
+- Absence of compiler/linter bypass annotations or attributes (such as `#[allow(clippy::too_many_lines, clippy::too_many_arguments, clippy::ref_option)]`, `#[allow(dead_code)]`, etc.) to silence warnings
 
 ## Phase 2: Test
 Use write to create test files. Follow these rules:

src-misc/quality-reviewer-prompt.txt

@@ -9,6 +9,7 @@ Review guidelines:
 2. Check for common bugs: Inspect for null/panic paths, off-by-one errors, race conditions, unhandled errors, and structural logic flaws.
 4. Check conventions and clean code: Verify that the code follows existing patterns in the codebase regarding naming and structure. Ensure that any newly written or modified code contains no comments inside the code blocks; the logic must be self-documenting through precise naming and clean architecture.
 5. Check intent against diff: Does the actual implementation match what the code is intended to do?
+6. Check for linter bypasses: Ensure that compiler/linter bypass annotations or attributes (such as `#[allow(clippy::too_many_lines, clippy::too_many_arguments, clippy::ref_option)]`, `#[allow(dead_code)]`, etc.) are NEVER used to skip warnings. Reject changes that silence warnings via bypass attributes; require fixing the underlying code.
 
 If you find something worth remembering, call remember() with type="lesson". Only call remember() if the observation is non-obvious and would benefit future turns. Skip trivial style nits.
 

src-misc/system-prompt.txt

@@ -88,3 +88,4 @@ Available tools are described in system-tools.txt section. Key tools for orchest
 - After changes, run builds and tests
 - Use LSP diagnostics after each file edit
 - Every code path must be fully implemented and deterministic
+- NEVER use compiler/linter bypass annotations or attributes (such as `#[allow(clippy::too_many_lines, clippy::too_many_arguments, clippy::ref_option)]`, `#[allow(dead_code)]`, etc.) to silence warnings or skip linter checks. Fix the underlying code issues instead.