mcp-code-context 2.6.0 → 3.0.4

package/tsconfig.tests.json

@@ -0,0 +1,27 @@
+{
+  "compilerOptions": {
+    "target": "ES2022",
+    "module": "Node16",
+    "moduleResolution": "Node16",
+    "outDir": "./dist-tests",
+    "rootDir": ".",
+    "strict": true,
+    "esModuleInterop": true,
+    "skipLibCheck": true,
+    "forceConsistentCasingInFileNames": true,
+    "resolveJsonModule": true,
+    "declaration": true,
+    "sourceMap": true,
+    "baseUrl": ".",
+    "paths": {
+      "web-tree-sitter": ["node_modules/web-tree-sitter/web-tree-sitter.d.ts"]
+    }
+  },
+  "include": [
+    "tests/test-wasm-parsers.ts",
+    "tests/manual/**/*"
+  ],
+  "exclude": [
+    "node_modules"
+  ]
+}

package/.io/RULES.md

@@ -1,12 +0,0 @@
-# AURA RULES - antigravity-mcp-context
-
-## Project Principles
-- **Surgical Precision**: Never replace more code than necessary.
-- **Safety First**: Always use the Two-Phase Write Workflow.
-- **AST Over Regex**: Prefer AST parsing for code modification.
-- **Atomic Transactions**: Multi-file changes must be atomic or reversible.
-
-## Operational Constraints
-- Max file size for processing: 10MB.
-- Max files for repo map: 500.
-- All writes must generate a backup in `.mcp-backups/`.

package/CONTRIBUTING.md

@@ -1,243 +0,0 @@
-# Contributing to mcp-code-context
-
-Thank you for your interest in contributing! This document provides guidelines and instructions for contributing to this project.
-
-## 🌟 Ways to Contribute
-
-- **Bug Reports**: Found a bug? Open an issue with detailed reproduction steps
-- **Feature Requests**: Have an idea? Describe the use case and expected behavior
-- **Code Contributions**: Submit pull requests for bug fixes or new features
-- **Documentation**: Improve README, add examples, fix typos
-- **Testing**: Add test cases, report edge cases
-
-## 🚀 Getting Started
-
-### Prerequisites
-
-- Node.js >= 18
-- npm or yarn
-- Git
-
-### Setup Development Environment
-
-```bash
-# Clone the repository
-git clone https://github.com/achatainga/mcp-code-context.git
-cd mcp-code-context
-
-# Install dependencies
-npm install
-
-# Build the project
-npm run build
-
-# Run tests
-npm test
-```
-
-## 📝 Development Workflow
-
-### 1. Create a Branch
-
-```bash
-git checkout -b feature/your-feature-name
-# or
-git checkout -b fix/your-bug-fix
-```
-
-### 2. Make Changes
-
-- Write clean, readable code
-- Follow existing code style
-- Add comments for complex logic
-- Update documentation if needed
-
-### 3. Test Your Changes
-
-```bash
-# Build
-npm run build
-
-# Run existing tests
-npm test
-
-# Test manually with MCP client
-node dist/src/index.js
-```
-
-### 4. Commit Your Changes
-
-Use conventional commit messages:
-
-```bash
-git commit -m "feat: add new feature"
-git commit -m "fix: resolve bug in symbol extraction"
-git commit -m "docs: update README with examples"
-git commit -m "test: add tests for new tool"
-```
-
-**Commit Types:**
-- `feat`: New feature
-- `fix`: Bug fix
-- `docs`: Documentation changes
-- `test`: Adding or updating tests
-- `refactor`: Code refactoring
-- `perf`: Performance improvements
-- `chore`: Maintenance tasks
-
-### 5. Push and Create Pull Request
-
-```bash
-git push origin feature/your-feature-name
-```
-
-Then create a Pull Request on GitHub with:
-- Clear title and description
-- Reference any related issues
-- Screenshots/examples if applicable
-
-## 🧪 Testing Guidelines
-
-### Writing Tests
-
-Add tests in the `tests/` directory:
-
-```typescript
-// tests/test-your-feature.ts
-import { yourFunction } from "../src/your-module.js";
-
-console.log("🧪 Testing your feature...\n");
-
-const result = yourFunction({ /* test input */ });
-
-if (result.success) {
-  console.log("✅ PASS: Test description");
-} else {
-  console.error("❌ FAIL: Test description");
-}
-```
-
-### Running Tests
-
-```bash
-# Run all tests
-npm test
-
-# Run specific test
-npm run build && node dist/tests/test-your-feature.js
-```
-
-## 📚 Code Style
-
-### TypeScript
-
-- Use TypeScript for all new code
-- Define interfaces for complex types
-- Use `const` over `let` when possible
-- Prefer explicit return types
-
-### Naming Conventions
-
-- **Files**: `camelCase.ts` or `kebab-case.ts`
-- **Functions**: `camelCase`
-- **Classes**: `PascalCase`
-- **Constants**: `UPPER_SNAKE_CASE`
-- **Interfaces**: `PascalCase` (no `I` prefix)
-
-### Comments
-
-```typescript
-/**
- * Brief description of function
- * 
- * @param param1 - Description
- * @param param2 - Description
- * @returns Description of return value
- */
-export function myFunction(param1: string, param2: number): Result {
-  // Implementation
-}
-```
-
-## 🏗️ Project Structure
-
-```
-mcp-code-context/
-├── src/
-│   ├── index.ts              # Main MCP server
-│   ├── ast/                  # AST parsers and compressors
-│   │   ├── semanticCompressor.ts
-│   │   ├── dartCompressor.ts
-│   │   ├── phpCompressor.ts
-│   │   └── writers/          # Write tools
-│   ├── tools/                # New tools (read_file_lines, etc.)
-│   └── utils/                # Utilities
-├── tests/                    # Test files
-├── dist/                     # Compiled output (gitignored)
-└── docs/                     # Documentation
-```
-
-## 🐛 Reporting Bugs
-
-When reporting bugs, include:
-
-1. **Description**: Clear description of the issue
-2. **Steps to Reproduce**: Minimal steps to reproduce
-3. **Expected Behavior**: What should happen
-4. **Actual Behavior**: What actually happens
-5. **Environment**:
-   - OS (Windows/macOS/Linux)
-   - Node.js version
-   - mcp-code-context version
-6. **Code Sample**: Minimal reproducible example
-7. **Error Messages**: Full error output
-
-## 💡 Feature Requests
-
-When requesting features, include:
-
-1. **Use Case**: Why is this feature needed?
-2. **Proposed Solution**: How should it work?
-3. **Alternatives**: Other approaches considered
-4. **Examples**: Code examples of desired behavior
-
-## 🔍 Code Review Process
-
-All contributions go through code review:
-
-1. **Automated Checks**: Tests must pass
-2. **Code Quality**: Follows style guidelines
-3. **Documentation**: Updated if needed
-4. **Testing**: Adequate test coverage
-5. **Approval**: At least one maintainer approval
-
-## 📄 License
-
-By contributing, you agree that your contributions will be licensed under the MIT License.
-
-## 🙏 Recognition
-
-Contributors will be recognized in:
-- GitHub contributors page
-- Release notes (for significant contributions)
-- CHANGELOG.md
-
-## 📞 Questions?
-
-- Open a GitHub Discussion
-- Comment on related issues
-- Reach out to maintainers
-
-## 🎯 Priority Areas
-
-Current priority areas for contributions:
-
-1. **Language Support**: Add support for more languages (Ruby, Go, Rust, etc.)
-2. **Performance**: Optimize large repository scanning
-3. **Testing**: Increase test coverage
-4. **Documentation**: More examples and use cases
-5. **Error Handling**: Improve error messages
-
----
-
-Thank you for contributing to mcp-code-context! 🚀

package/TROUBLESHOOTING.md

@@ -1,38 +0,0 @@
-# Troubleshooting Guide: Surgical Editing Edge Cases
-
-This document covers known edge cases and behaviors for the Antigravity MCP surgical tools. These insights are derived from real-world usage scenarios.
-
-## 1. `write_file_surgical` - False Brace Imbalance
-**Problem:** The server rejects a code change, claiming the resulting file has unbalanced braces, even if the code provided is syntactically valid.
-**Cause:** 
-- Discrepancies between character counting and line endings (CRLF vs LF).
-- Braces found inside string literals or comments being counted as structural braces.
-- Braces in method parameters (e.g., `{int? cart}`) being counted as method body braces.
-**Solution (Internal):** 
-- v2.1.2: State-aware brace counting that ignores literals and comments.
-- v2.1.3: CRLF normalization and parameter brace detection. **RESOLVED**.
-**Workaround:** No longer needed as of v2.1.3.
-
-## 2. `rename_symbol` - Dependents Not Updating
-**Problem:** The symbol is renamed in the definition file, but imports and references in other files are unchanged.
-**Cause:** The tool was previously looking for the *definition* of the symbol in every file.
-**Solution (Internal):** The tool now separates definition renaming from reference updating. It will update any whole-word match of the symbol in files that are detected as dependents.
-**Workaround:** Run `analyze_impact` first to verify the server detects the dependencies. If missed, perform a manual surgical replace on the import line.
-
-## 3. `insert_symbol` - Ambiguous Positioning
-**Problem:** Using `position: "after"` on a method sometimes inserts the new code *inside* the closing brace of that method.
-**Cause:** Ambiguity in block-end detection when the closing brace is on a line with other content or when braces are presence in strings inside the body.
-**Solution (Internal):** Improved block detection in v2.1.2.
-**Best Practice:** For inserting new members inside a class, prefer using `position: "inside_end"` with the `className` as the anchor, rather than `after` on the last method.
-
-## 4. `remove_symbol` - False Positive Dependency Check
-**Problem:** The tool refuses to remove a symbol because it "might be used" in another file, but the reference is actually a comment or a different symbol with the same name.
-**Cause:** To stay fast, the dependency check uses a whole-word regex search rather than a full cross-file AST index.
-**Solution:**
-1. Run `analyze_impact` to verify the actual blast radius.
-2. If you confirm the "matches" are false positives, use the `force: true` parameter to bypass the check.
-
----
-
-> [!TIP]
-> **Always use the Two-Phase Workflow.** Review the `diff` provided in the first response carefully before providing the `confirmationToken`. This is your strongest guard against edge-case misbehavior.

package/dist/src/ast/dartCompressor.d.ts

@@ -1,27 +0,0 @@
-/**
- * dartCompressor — Regex + brace-counting Dart semantic compressor.
- *
- * Dart has no npm AST parser, so we use a high-fidelity regex engine combined
- * with precise brace-counting to extract structural signatures from Dart source.
- * This approach handles all real-world Flutter/Dart patterns including generics,
- * factory constructors, mixins, extensions, and enum members.
- *
- * Design principles:
- *   1. Brace-counting for block boundaries — never fails on nested blocks
- *   2. Regex for signature detection — generics-aware, handles multi-line
- *   3. Preserve doc comments (///) for semantic context
- *   4. Preserve annotations (@override, @visibleForTesting, etc.)
- *   5. Preserve field declarations (they ARE the structural contract)
- */
-/**
- * Compress a Dart file into its semantic skeleton.
- * Returns only structural signatures — no function/method bodies.
- */
-export declare function compressDart(content: string): string;
-/**
- * Extract the full source code of a named symbol from a Dart file.
- * Supports classes, mixins, extensions, enums, functions, and methods.
- * When className is provided, scopes method search to within that class only.
- * Returns null if the symbol is not found.
- */
-export declare function extractDartSymbol(content: string, symbolName: string, className?: string): string | null;