Major architectural overhaul of RagCode MCP — new service layer, deterministic AST-based tools, native Ollama client, Streamable HTTP transport, and a dramatically reduced hardware footprint.

.github/instructions/general.instructions.md

@@ -0,0 +1,26 @@
+---
+description: Global efficiency and token-optimization rules for senior development
+applyTo: '*' 
+---
+
+# Precision & Token Efficiency Rules
+
+### 1. Response Constraints (Token Saving)
+* **No Prose:** Skip introductions, greetings, and "I've updated the file" summaries. Go straight to the solution.
+* **Diffs Only:** Never output the entire file. Use standard diff format or provide only the specific functions/blocks that changed.
+* **No Thinking Out Loud:** Do not explain your reasoning or "Chain of Thought" unless explicitly asked with "Explain your logic". 
+* **Dry Output:** Use a telegraphic style. If a fix is obvious, just provide the code.
+
+### 2. Context Handling
+* **Lazy Loading:** Do not read files outside the immediate scope of the task unless necessary for type definitions or interface alignment.
+* **Reference-Only:** When referring to existing code, use line numbers or function names instead of re-quoting the code in the chat.
+* **Minimal Boilerplate:** Do not generate repetitive code (getters/setters, imports) unless they are new or modified. Use `// ... existing code ...` to skip unchanged sections.
+
+### 3. Engineering Standards
+* **Interface-Driven:** Prioritize checking interfaces/types before suggesting logic changes to avoid iterative fixes.
+* **Silence is Golden:** If the task is completed via a file edit, do not repeat the changes in the chat window. A simple "Done" or a brief summary of the file name is sufficient.
+* **Fail Fast:** If context is missing or ambiguous, ask a single clarifying question instead of guessing and generating high-token "hallucinated" solutions.
+
+### 4. Technical Bias
+* Assume Senior-level competence: No basic explanations of language features or patterns.
+* Use concise modern syntax (e.g., arrow functions, destructuring, shorthand) by default to keep output length minimal.

.github/workflows/build-binaries.yml

@@ -41,11 +41,8 @@ jobs:
           echo "Building rag-code-mcp..."
           go build -o bin/rag-code-mcp ./cmd/rag-code-mcp
 
-          echo "Building index-all..."
-          go build -o bin/index-all ./cmd/index-all
-
-          echo "Building ragcode-installer..."
-          go build -o bin/ragcode-installer ./cmd/install
+          echo "Building rag-code-install..."
+          go build -o bin/rag-code-install ./cmd/rag-code-install
 
           chmod +x bin/*
 

.gitignore

@@ -3,15 +3,18 @@ data/
 test_data/
 qdrant_data/
 barou/
+inspirations/
+relations/
 
 # Binaries
 /cmd/agent-runner/agent-runner
 /rag-code-mcp
 test-*
 bin/
-ragcode-installer
+tests/e2e/bin/
+rag-code-install
 index-all
-cmd/rag-code-mcp/rag-code-mcp
+rag-code-mcp
 
 # Test programs
 cmd/test-*/
@@ -59,6 +62,7 @@ temp/
 scripts/
 .ragcode/
 .agent/skills/
+build-binaries.sh
 
 # Debug logs
 startup_debug.txt

.goreleaser.yaml

@@ -40,9 +40,9 @@ builds:
       - -X main.Date={{.Date}}
       - -X main.BuiltBy=goreleaser
 
-  - id: ragcode-installer
-    main: ./cmd/install
-    binary: ragcode-installer
+  - id: rag-code-install
+    main: ./cmd/rag-code-install
+    binary: rag-code-install
 
     env:
       - CGO_ENABLED=0
@@ -110,8 +110,8 @@ archives:
     files:
       - LICENSE
       - README.md
-      - config.yaml
-      - .env.example
+      - llms.txt
+      - internal/config/default.yaml
 
 checksum:
   name_template: 'checksums.txt'
@@ -162,13 +162,13 @@ release:
     **Linux (amd64):**
     ```bash
     curl -L https://github.com/doITmagic/rag-code-mcp/releases/latest/download/rag-code-mcp_linux_amd64.tar.gz | tar xz
-    ./ragcode-installer -ollama=docker -qdrant=docker
+    ./rag-code-install -ollama=docker -qdrant=docker
     ```
 
     **macOS (Apple Silicon):**
     ```bash
     curl -L https://github.com/doITmagic/rag-code-mcp/releases/latest/download/rag-code-mcp_darwin_arm64.tar.gz | tar xz
-    ./ragcode-installer -ollama=docker -qdrant=docker
+    ./rag-code-install -ollama=docker -qdrant=docker
     ```
 
     **Or download the archive for your platform below.**
@@ -198,8 +198,7 @@ brews:
     # Custom install script to handle multiple binaries
     install: |
       bin.install "rag-code-mcp"
-      bin.install "ragcode-installer"
-      bin.install "index-all"
+      bin.install "rag-code-install"
 
     test: |
       system "#{bin}/rag-code-mcp --version"

.windsurf/rules/general.md

@@ -0,0 +1,184 @@
+---
+trigger: always_on
+---
+
+# AI Governance Rules – Project Control Mode (Strict)
+
+## 1. General Behavior Rules
+
+### AI must never modify existing code unless:
+- A bug is proven.
+- A security issue is identified.
+- A performance bottleneck is demonstrated with measurable data.
+- The user explicitly approves the change.
+
+### AI must never:
+- Refactor for style preference.
+- Rename variables for aesthetics.
+- Reorganize project structure.
+- “Improve readability” unless requested.
+
+### All suggested changes must:
+- Be shown as a diff.
+- Include explanation.
+- Include impact analysis.
+- Include rollback instructions.
+
+### No change is considered successful unless:
+- Tests pass.
+- Build passes.
+- Lint passes.
+- Manual verification steps are described.
+
+### AI must ask for clarification if:
+- Business logic is unclear.
+- There is ambiguity in naming.
+- Multiple valid architectural choices exist.
+
+## 🧠 Decision Gatekeeping Rule
+Before proposing ANY code change, AI must answer internally:
+- Is this required?
+- Is this measurable?
+- Is this aligned with existing architecture?
+- Is this backward compatible?
+
+If one answer is "no" → ASK FIRST.
+
+## 🧪 Testing Requirements (Mandatory)
+
+### Golang — every backend change must include:
+- Unit test
+- Table-driven test when applicable
+- Error case coverage
+- Benchmark if performance-related
+- go vet clean
+- golangci-lint clean
+- No “looks correct”. Only tested code.
+
+### JavaScript — if JS is touched:
+- No global scope pollution
+- No magic numbers
+- Defensive null checks
+- No breaking of existing event bindings
+- Must verify browser compatibility assumptions
+
+If DOM is modified:
+- Ensure no layout shift unless intended
+- Verify no performance regression (reflow-heavy operations)
+
+### Python — if Python is touched:
+- No side effects at module import (guard with `if __name__ == "__main__"`)
+- Avoid global mutable state; prefer dependency injection
+- Keep `pytest` (or equivalent) passing; add negative-path tests
+- Use type hints; keep `mypy`/type-checkers clean when configured
+- Pin dependencies in lock/constraints files (no implicit upgrades)
+
+### CSS — AI must:
+- Not change global styles without explicit approval
+- Not introduce !important unless justified
+- Not break mobile layout
+- Not modify spacing system
+- Follow existing naming convention (BEM or whatever you use)
+
+### HTML — AI must:
+- Not restructure markup unless required
+- Preserve accessibility attributes
+- Not remove ARIA roles
+- Not remove semantic tags
+- Keep forms backward compatible
+
+## 🚫 Optimization Control Rules
+AI must NOT:
+- Optimize prematurely
+- Replace loops with concurrency without justification
+- Introduce goroutines unless concurrency is proven necessary
+- Add caching without defining invalidation strategy
+- Change data structures without complexity analysis
+
+## 🔐 Backend Specific (Golang)
+AI must:
+- Not introduce global state
+- Not introduce hidden side effects
+- Respect context propagation (context.Context)
+- Not swallow errors
+- Always wrap errors properly
+- Not introduce reflection unless necessary
+- Not introduce generics unless justified
+
+If touching DB:
+- Must preserve transaction boundaries
+- Must describe migration impact
+- Must describe rollback strategy
+
+## 📦 Dependency Rules
+AI must:
+- Not introduce new dependencies without approval
+- Justify every dependency
+- Prefer standard library
+- Check license compatibility
+- Evaluate maintenance status
+
+## 📊 Reporting Rules
+AI must never say:
+- “It should work.”
+- “This is fixed.”
+- “Problem solved.”
+
+Instead must report:
+- What was changed
+- What was tested
+- What was verified
+- What was not verified
+- Potential side effects
+
+## 🔍 Change Proposal Format (Mandatory)
+Every change must follow this structure:
+- Problem Description
+- Root Cause Analysis
+- Proposed Change (diff)
+- Impact Scope
+- Risk Assessment
+- Test Plan
+- Rollback Plan
+
+No exceptions.
+
+## 🧱 Architecture Preservation Rule
+AI must:
+- Preserve layering (handler → service → repository)
+- Not bypass service layer
+- Not mix transport and business logic
+- Not leak DB models into API layer
+- Not couple JS tightly to backend implementation details
+
+## ⚠️ Failure Handling Rules
+AI must:
+- Never ignore error return values
+- Never panic in production paths
+- Not suppress logs
+- Use structured logging
+
+## 📈 Performance Rules
+Before suggesting performance optimization, AI must provide:
+- Current complexity (Big O)
+- Proposed complexity
+- Expected gain
+- Trade-offs
+- Benchmark example
+
+## 🧭 When AI Must Stop and Ask
+- When modifying authentication
+- When modifying authorization
+- When touching financial logic
+- When changing concurrency model
+- When modifying public API
+
+## 💬 Strict Interaction Rule
+AI must:
+- Treat all existing code as intentional
+- Assume developer competence
+- Not override architectural decisions
+- Provide alternatives, not unilateral decisions
+- Never perform changes autonomously; always explain the motivation before modifying code
+- Never run destructive Git commands (reset/rebase/clean/force push) without explicit user approval
+- Never optimize code outside the current task scope