Merge pull request #43 from knitli/feat-phase-zero

Author: bashandbone

.cargo/config.toml

@@ -0,0 +1,5 @@
+[unstable]
+codegen-backend = true
+
+[profile.dev]
+codegen-backend = "cranelift"

.claude/settings.local.json.license

@@ -0,0 +1,4 @@
+SPDX-FileCopyrightText: 2025 Knitli Inc. <[email protected]>
+SPDX-FileContributor: Adam Poulemanos <[email protected]>
+
+SPDX-License-Identifier: MIT OR Apache-2.0

.gitattributes

@@ -0,0 +1,68 @@
+# SPDX-FileCopyrightText: 2025 Knitli Inc. <[email protected]>
+# SPDX-FileContributor: Adam Poulemanos <[email protected]>
+# SPDX-License-Identifier: MIT OR Apache-2.0
+#
+# Set default behavior to automatically normalize line endings
+* text=auto
+
+# Force most text files to always use LF
+*.astro text eol=lf
+*.css text eol=lf
+*.csv text eol=lf
+*.cts text eol=lf
+*.go text eol=lf
+*.html text eol=lf
+*.ini text eol=lf
+*.js text eol=lf
+*.json text eol=lf
+*.jsx text eol=lf
+*.md text eol=lf
+*.mdx text eol=lf
+*.mts text eol=lf
+*.pkl text eol=lf
+*.py text eol=lf
+*.rs text eol=lf
+*.sh text eol=lf
+*.svelte text eol=lf
+*.svg text eol=lf
+*.toml text eol=lf
+*.ts text eol=lf
+*.tsx text eol=lf
+*.txt text eol=lf
+*.xml text eol=lf
+*.yaml text eol=lf
+*.yml text eol=lf
+.git* text eol=LF
+LICENSE text eol=lf
+LICENSE* text eol=lf
+
+# Force batch files to use CRLF (Windows scripts)
+*.bat text eol=crlf
+*.ps* text eol=crlf
+
+# Treat these as binary (no line ending conversion)
+*.aac binary
+*.avif binary
+*.docx binary
+*.eot binary
+*.exe binary
+*.flac binary
+*.ico binary
+*.jpg binary
+*.m4a binary
+*.mp3 binary
+*.mp4 binary
+*.ogg binary
+*.otf binary
+*.pdf binary
+*.png binary
+*.pptx binary
+*.tar* binary
+*.ttf binary
+*.wav binary
+*.webm binary
+*.webp binary
+*.woff binary
+*.woff2 binary
+*.xlsx binary
+*.zip binary

.github/actionlint.yml

@@ -0,0 +1,12 @@
+# SPDX-FileCopyrightText: 2025 Knitli Inc. <[email protected]>
+# SPDX-FileContributor: Adam Poulemanos <[email protected]>
+#
+# SPDX-License-Identifier: MIT OR Apache-2.0
+# ! Actionlint configuration file to ignore specific warnings
+paths:
+  .github/workflows/cla.yml:
+    ignore:
+      - 'property "is_member" is not defined in object type {}'
+      - >
+        "github.event.pull_request.title" is potentially untrusted. avoid using it directly in inline scripts. instead, pass it through an environment variable. see https://docs.github.com/en/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions for more details
+

.github/chatmodes/analyze.chatmode.md

@@ -0,0 +1,20 @@
+---
+# SPDX-FileCopyrightText: 2025 Knitli Inc. <[email protected]>
+# SPDX-FileContributor: Adam Poulemanos <[email protected]>
+# SPDX-License-Identifier: MIT OR Apache-2.0
+description: 'Code Analysis'
+tools: ["codebase", "githubRepo", "context7", "sequential-thinking", "View", "GrepTool", "BatchTool", "GlobTool"]
+---
+# Expert Code Analyst
+
+You're an experienced code analyst who specializes in identifying and resolving issues in codebases. Your primary focus is on improving code quality through best practices and identifying opportunities to refactor or restructure code to make it more flexible and easier to maintain.
+
+## Instructions
+
+The user will ask you to research specific code, modules, or packages within the codebase. They may ask for a specific analysis or aspect of the code to focus on, or they may request a broader overview of the codebase's structure and design and recommendations for improvements.
+
+If you identify an opportunity to improve code quality:
+
+- provide actionable suggestions and code examples to help the user implement the improvements.
+- Produce a report summarizing your findings with specific recommendations. The report should include specific recommendations and references to specific code snippets by line number and filename.
+  - If the user requests a different result or output, then follow their instructions.

.github/chatmodes/docwriter.chatmode.md

@@ -0,0 +1,38 @@
+---
+# SPDX-FileCopyrightText: 2025 Knitli Inc. <[email protected]>
+# SPDX-FileContributor: Adam Poulemanos <[email protected]>
+# SPDX-License-Identifier: MIT OR Apache-2.0
+description: 'Documentation Writer'
+tools: ["codebase", "githubRepo", "context7", "sequential-thinking", "View", "GrepTool", "BatchTool", "GlobTool"]
+---
+
+# Your Role
+
+## You Are an Expert Technical Writer
+
+You are a very experienced developer and technical writer. You specialize in creating clear, comprehensive documentation for software projects. You use your deep engineering background to communicate complex ideas in a simple and easy to understand way. You use plain language and provide realistic and concrete examples when code might be difficult to understand. You write useful and informative documentation, including README, CONTRIBUTING, other guides, and in-code documentation for module, class/structs, and methods.
+
+Your approach is to carefully consider what someone new to the project would need to know to understand and use the codebase quickly and easily. You don't assume readers have previous knowledge of the codebase, the libraries it uses, or the functionality it provides, and aim to briefly communicate this information.
+
+## Instructions (unless the user instructs differently)
+
+- Write all documentation in active voice and present tense.
+- Don't use filler words and phrases like "This function..." or "this module..."
+- **Use plain language**, and don't assume readers are familiar with very technical concepts.
+  - Avoid technical terms and jargon, and explain them when you must use them.
+  - Use analogies and examples to illustrate complex ideas.
+  - Effectively use markdown formatting to emphasize and illustrate information, such as headers, bold/italic, tables.
+  - Include code snippets and examples to clarify complex concepts.
+- Always consider the most likely audience for each piece of documentation, for example:
+  - Documentation for Public APIs should focus on use cases, and provide practical information for using the API effectively.
+  - Documentation for non-public or internal APIs should focus on implementation details and explaining the role of the API within the codebase.
+  - Documentation for end-users should focus on how to use the software, including installation instructions, tutorials, and examples.
+  - Consider a broad audience for README files and usage guides that may include non-technical users.
+- Write documentation that will be easy to maintain and update.
+- Respond with direct edits to files, and create them if they aren't there.
+- Keep code comments brief and follow idiomatic structure for quality Rust documentation.
+- Don't add unnecessary comments, like on functions that are self-explanatory (like a function `add_numbers` that takes two integers are input and returns an integer).
+- Use Rustdoc-style code linking to provide useful context to in-code documentation, but don't link to specific lines of code (this is very hard to maintain).
+- Save more robust comments for the most complex or important parts of the code, and use clear and realistic examples to illustrate difficult sections.
+- Provide clear and explanatory comments for every module, trait, and struct. Document functions and methods that are important or not obvious.
+- Focus on communicating the important concepts that a developer new to the code would need to use and work with the code effectively.

.github/dependabot.yml

@@ -1,8 +1,47 @@
-version: 2
-updates:
-- package-ecosystem: cargo
-  directory: "/"
-  schedule:
-    interval: daily
-    time: "08:00"
-  open-pull-requests-limit: 10
+# SPDX-FileCopyrightText: 2025 Knitli Inc. <[email protected]>
+# SPDX-FileContributor: Adam Poulemanos <[email protected]>
+#
+# SPDX-License-Identifier: MIT OR Apache-2.0
+version: 2
+updates:
+  - package-ecosystem: cargo
+    dependency-type: all
+    update-types:
+      - version-update:semver-minor
+      - version-update:semver-patch
+    versioning-strategy: increase
+    directory: "/"
+    schedule:
+      interval: daily
+      time: "23:00"
+    open-pull-requests-limit: 10
+    commit-message:
+      prefix: "deps"
+    assignees:
+      - codegen-sh[bot]
+    reviewers:
+      - codegen-sh[bot]
+    labels:
+      - "dependencies"
+    rebase-strategy: auto
+  - package-ecosystem: github-actions
+    dependency-type: all
+    update-types:
+      - version-update:semver-major
+      - version-update:semver-minor
+      - version-update:semver-patch
+    versioning-strategy: increase
+    directory: "/.github/workflows"
+    schedule:
+      interval: daily
+      time: "23:00"
+    open-pull-requests-limit: 10
+    commit-message:
+      prefix: "deps"
+    assignees:
+      - codegen-sh[bot]
+    reviewers:
+      - codegen-sh[bot]
+    labels:
+      - "dependencies"
+    rebase-strategy: auto

.github/dontusefornow.md

@@ -0,0 +1,148 @@
+<!--
+SPDX-FileCopyrightText: 2025 Knitli Inc. <[email protected]>
+SPDX-FileContributor: Adam Poulemanos <[email protected]>
+SPDX-License-Identifier: MIT OR Apache-2.0
+-->
+
+# Copilot Instructions for Thread
+
+## Project Overview
+
+Thread is a Rust code analysis engine that provides intelligent context for AI assistants. The project is transitioning from vendored ast-grep CLI code to a multi-environment service architecture supporting CLI, cloud, WASM, and CI/CD deployments.
+
+## Architecture Guidelines
+
+### Service Layer Pattern
+The codebase follows a service abstraction pattern to support multiple environments:
+
+```rust
+// Pure service functions (environment-agnostic)
+pub async fn scan_with_services(
+    file_discovery: Arc<dyn FileDiscoveryService>,
+    config_service: Arc<dyn ConfigurationService>,
+    options: ScanOptions,
+) -> Result<ScanResults>
+```
+
+### Crate Organization
+
+- **ag-thread/**: Vendored ast-grep modules being refactored for service layers
+- **thread-core/**: Core traits, types, and errors (pure abstractions)
+- **thread-engine/**: Main analysis implementation using petgraph
+- **thread-parse/**: AST-grep integration and language detection
+- **Service-ready crates**: `ag-core`, `ag-search`, `ag-fix`, `ag-types`, `ag-label`
+- **Needs refactoring**: `ag-scan`, `ag-utils`, `ag-check-rule` (heavy CLI dependencies)
+
+## Development Commands
+
+Essential commands for this workspace:
+
+```bash
+# Build all crates (except WASM)
+mise run build
+mise run b
+
+# WASM builds
+mise run build-wasm          # Development (single-threaded)
+mise run build-wasm-release  # Production optimized
+
+# Testing and quality
+mise run test               # Tests with cargo nextest
+mise run lint               # Full linting via hk run check
+mise run ci                 # All CI checks
+```
+
+## Key Patterns to Follow
+
+### 1. Service Trait Definitions
+When creating new services, follow the pattern from `ag-types`:
+
+```rust
+#[async_trait]
+pub trait YourService: Send + Sync {
+    async fn your_method(&self, input: &str) -> Result<Output>;
+}
+```
+
+### 2. Environment-Agnostic Core Functions
+Avoid CLI dependencies in core logic:
+
+```rust
+// ✅ Good: Pure function with injected services
+pub async fn analyze_with_services(
+    content: String,
+    services: &ServiceRegistry
+) -> Result<AnalysisResult>
+
+// ❌ Avoid: Direct filesystem or terminal access
+pub fn analyze_files(paths: Vec<PathBuf>) -> Result<()>
+```
+
+### 3. Multi-Environment Support
+Structure implementations for different environments:
+
+```rust
+// CLI implementation
+impl YourService for CliYourService { /* uses std::fs */ }
+
+// Cloud implementation
+impl YourService for CloudYourService { /* uses S3/HTTP */ }
+
+// WASM implementation
+impl YourService for WasmYourService { /* uses fetch API */ }
+```
+
+## CLI Dependencies Analysis Status
+
+Refer to individual `CLI_DEPENDENCIES.md` files in each ag-thread crate:
+
+- **Immediate attention needed**: `ag-scan/`, `ag-utils/` (heavy CLI dependencies)
+- **Service-ready**: `ag-core/`, `ag-search/`, `ag-fix/`, `ag-types/`, `ag-label/`
+- **Minor refactoring**: `ag-rule/`, `ag-check-rule/`
+
+## Critical Abstractions
+
+### File Operations
+Replace direct filesystem access with service traits:
+```rust
+// Instead of std::fs::read_to_string
+let content = file_service.read_file(path).await?;
+```
+
+### Terminal I/O
+Replace direct terminal access with service traits:
+```rust
+// Instead of println! or crossterm
+output_service.write(&format!("Result: {}", result)).await?;
+```
+
+### Configuration Loading
+Replace direct file config loading:
+```rust
+// Instead of reading YAML files directly
+let rules = config_service.load_rules(ConfigSource::Path(path)).await?;
+```
+
+## Testing Strategy
+
+- Use `cargo nextest -j 1` for parallel tests with race condition prevention
+- Mock service implementations for unit tests
+- Environment-specific integration tests for each service implementation
+- `RUST_BACKTRACE=1` enabled for debugging
+
+## WASM Considerations
+
+- Default builds are single-threaded for Cloudflare Workers compatibility
+- Core logic separated from filesystem operations for WASM portability
+- Multi-threaded builds available for browser environments (`--multi-threading`)
+
+When working with WASM targets, ensure no direct filesystem or process dependencies in core libraries.
+
+## Current Development Focus
+
+**Week 1 Sprint**: Establishing service layer foundations
+- Refactoring `ag-scan` to use service abstractions
+- Creating `ag-services` crate with core trait definitions
+- Implementing CLI service adapters to maintain current functionality
+
+The goal is to enable Thread to analyze code and provide AI-friendly context across all deployment environments while maintaining the performance and functionality of the original ast-grep implementation.