chore: remove legacy documentation, unused test scripts, and obsolete agent rules

agent-rules/junior_developer_constraints.md

@@ -1,4 +0,0 @@
-# Role & Competency Constraints
-
-- **Role**: Junior Developer.
-- **Discretion**: NO autonomous discretion allowed. The agent must operate strictly under the direct guidance of the user and must not make autonomous decisions or execute sweeping, unchecked actions.

agent-rules/rule_1_network_testing.md

@@ -1,5 +0,0 @@
-# Rule 1: Network Connectivity Testing
-
-- **Mandatory Tooling**: When testing ANY network connectivity, you MUST use the exact same Rust crates used in the production code.
-- **Methodology**: You must create standalone Rust applications (e.g., small test binaries or examples in the repository) that utilize the exact same networking plumbing as the main application.
-- **Forbidden Tools**: You CANNOT use bash (e.g., curl, netcat), Python, Java, Perl, wscat, or any other external scripting/CLI tools to validate network connectivity. Testing with these tools creates false positives and bypasses the actual networking crates causing issues.

agent-rules/rule_2_empirical_logging.md

@@ -1,5 +0,0 @@
-# Rule 2: Empirical Evidence & Logging
-
-- **Mandatory Logging**: If an issue occurs and there are no logs (or insufficient logs) to diagnose it, you must STOP immediately and add logging.
-- **Replication**: After adding logging, you must repeat the test to replicate the exact issue so that the logs capture the failure.
-- **No Blind Changes**: NO business logic can be altered blindly or based on guesses. You must have empirical evidence (derived from the logs) proving the root cause before attempting any changes to the logic.

agent-rules/rule_3_resiliency_testing.md

@@ -1,7 +0,0 @@
-# Rule 3: Resiliency & Cross-OS Load Testing
-
-- **Resiliency Requirement**: A fix must be resilient and work under load. It is not enough for it to work just once.
-- **Mandatory 5x Matrix Testing**: Any request/response cycle must be explicitly tested five (5) times for each of the following boundaries:
-  1. Windows to Windows (`win - win`)
-  2. WSL to Windows (`wsl - win`)
-- **Documentation**: The results of these load tests MUST be recorded permanently (e.g., in an artifact or log) to prove resilience and to avoid repeating needless re-tests.

agent-rules/rule_4_skeletal_troubleshooting.md

@@ -1,5 +0,0 @@
-# Rule 4: Component Isolation & Skeletal Troubleshooting
-
-- **Targeted Testing**: If a bug is found, DO NOT rely on testing the full stack. You must isolate and test the offending class or method directly.
-- **Skeletal Reproducers**: If the issue spans across boundaries (e.g., between server, stub, or nvim), you must create skeletal (minimal reproducible) versions of those components.
-- **Purpose**: Troubleshooting must be done on these skeletal versions to isolate the broken feature or aspect without the noise, side-effects, or overhead of the full application stack.

agent-rules/rule_5_client_centric_testing.md

@@ -1,5 +0,0 @@
-# Rule 5: Client-Centric Testing Personas
-
-- **Avoid Server Bias**: Unit tests and integration tests must NOT be exclusively server-centric.
-- **Client Personas**: Tests must explicitly adopt the persona, perspective, and constraints of the client components (e.g., the `stub` or `nvim`).
-- **Validation**: Testing must validate the interaction from the client's side, ensuring that the client component correctly constructs the request, handles the connection lifecycle, and properly parses the response, rather than just verifying that the server successfully processed an isolated payload.

agent-rules/strict-no-verify.md

@@ -1,13 +0,0 @@
----
-name: strict-no-verify
-description: Strictly forbids the use of --no-verify or -n when interacting with git to ensure quality gates are run.
-always_on: true
----
-
-# STRICT GIT HOOK ENFORCEMENT
-
-- **NEVER** use `--no-verify` or `-n` with `git commit` or `git push`.
-- Bypassing git hooks is considered a critical violation of trust.
-- You must allow the local git hooks (e.g., `pre-push`) to validate the code.
-- If a hook fails (e.g., `ruff` check, `pytest`), you MUST fix the underlying issues iteratively until the hook passes natively. Do not assume a single fix attempt works without re-verifying.
-- BEFORE running `git push`, you MUST use the `ask_question` tool to pop up an interactive modal to request explicit user permission. Wait for the user's approval before executing the push.