# RFC-001: The Cross-Repo Linking Paradox

**Status:** Accepted (Option B Selected)
**Date:** 2026-02-15
**Component:** `clew-engine` (Graph V2)
**Related ADRs:** `clew-platform/docs/adr/008-engine-platform-boundary.md`

## Decision
**Option B: The "Metadata-Only" Cloud Linker** was selected by the user on 2026-02-15.
-   **Engine Responsibility:** Extract "Signatures" (exported symbols, file paths) and send to Platform. NO SOURCE CODE.
-   **Platform Responsibility:** construct the cross-repo dependency graph using these signatures.
-   **Rationale:** Preserves the commercial boundary (linking is a paid cloud feature) while respecting the data boundary (code stays local).

## The Conflict

We have identified a critical architectural conflict between our **Commercial Strategy (ADR-008)** and our **Technical Security Model**.

### 1. The Commercial Rule (ADR-008)
**"Cross-Repo Search" and "Fleet Indexing" are paid features.**
To prevent the Open Source engine from cannibalizing the Team Tier, ADR-008 explicitly reserves multi-repo capabilities for the Platform.

### 2. The Technical Constraint (Data Boundary)
**The Platform cannot see source code.**
To verify our "Worker Trust Model," we guarantee that source code never leaves the user's network. The Platform only receives metadata (stats, health).

### 3. The Paradox (Graph V2)
To implement **Cross-Repo Linking** (e.g., finding that `import { Button } from 'shared-ui'` in Repo A maps to `export const Button` in Repo B), the system must analyze the **Abstract Syntax Trees (ASTs)** of both repositories simultaneously.

-   **If we implement this in the Cloud Platform:** We violate the Data Boundary (Platform needs code access). 🔴 **Security Fail.**
-   **If we implement this in the Local Engine:** We violate the Commercial Rule (Free engine gets multi-repo powers). 🔴 **Business Fail.**

## The Implication

We cannot simply "gate" this feature in the Engine because the code would be open-source. Anyone could fork `clew-engine` and enable the "Team Tier" linking logic for free.

## Proposed Solutions (For Discussion)

### Option A: The "Local-Only" Compromise
Allow `clew-engine` to link repos **locally** (on one developer's machine).
-   **Pros:** Solves the technical problem. Developer gets a "Personal Knowledge Graph."
-   **Cons:** Weakens the upsell. If every dev runs their own graph, why pay for the Team Tier?
-   **Mitigation:** The Team Tier adds **shared** context (e.g., "What does *Alice's* private branch affect?").

### Option B: The "Metadata-Only" Cloud Linker
The Engine sends **signatures** (e.g., function names, file paths, but no code) to the Platform. The Platform links them.
-   **Pros:** Preserves the business model. Keeps code private-ish.
-   **Cons:** Extremely complex. Signature collisions. "Metadata" is arguably still sensitive data.

### Option C: The proprietary "Enterprise Worker"
We ship a closed-source binary extension for the Worker that handles this logic.
-   **Pros:** Protects the IP.
-   **Cons:** Violates the "Open Source Worker" trust promise. Enterprises hate blobs.

## Recommendation

**Pause Task 3 (Cross-Repo Linking)** until this strategic impasse is resolved. Focus on **Clew-Bench (Task 2)** which is value-neutral and universally needed.
