feat(workflows): Create Camelot liquidity management agent

.claude/commands/write-tests.md

@@ -8,9 +8,10 @@ You are an expert test engineer who writes comprehensive, maintainable tests. Yo
 1. **NEVER modify src/ files without .test.ts suffix** - You're forbidden from touching production code
 2. **ALWAYS test behavior (WHAT) not implementation (HOW)** - Test outcomes, not mechanics
 3. **Write comprehensive tests** - Cover success paths, error cases, and edge conditions
-4. **Use vi.mock() for unit tests; MSW for HTTP integration; Anvil for EVM integration** - Choose the right tool
+4. **Use vi.mock() for unit tests; MSW for HTTP integration; Anvil for EVM integration; NEVER mock e2e tests** - Choose the right tool and keep e2e fully live
 5. **Place test utilities in tests/utils/ only** - Never in .claude/, src/, or root
 
+**Non-negotiable**: `*.e2e.test.ts` files must hit real services or dedicated testnets directly—no MSW, no recorded mocks, no HTTP interceptors. If you cannot reach the live dependency, pause the e2e effort instead of faking it.
 ## ⚖️ Critical Boundaries
 
 ### ❌ CANNOT DO:
@@ -57,6 +58,7 @@ Where should test file go?
    - Adapter/SDK → Integration tests with MSW
    - Repository → Integration tests with real DB
    - Blockchain/EVM → Integration tests with Anvil
+   - Full system/e2e flows → End-to-end tests that call real services/testnets directly (no MSW or stubbed HTTP; Anvil only if the entire chain is the target environment)
 
 2. **Check existing patterns**:
    - Search for similar test files: `**/*.[same-type].test.ts`
@@ -116,6 +118,12 @@ Need to test something?
 
 ## 🔧 Tool Usage Guide
 
+### Non-negotiable: E2E tests stay live
+
+- Never register MSW handlers, mock fetch/axios, or intercept RPC calls inside `*.e2e.test.ts`.
+- E2E tests must call the same public/testnet endpoints the product uses (or a dedicated staging environment) and should fail fast if those endpoints are unreachable.
+- Anvil is acceptable for e2e only when the whole scenario is meant to run against a deterministic fork or local chain—treat it as the target environment, not a mock layer.
+
 ### Use vi.mock() when:
 
 - Testing unit logic in isolation
@@ -158,8 +166,8 @@ For Anvil-based tests:
 - Scope: keep light (smoke tests)
 - When to run: Skip in feature branch CI; required before merging to main
 - Placement: `tests/` directory (`*.e2e.test.ts`)
-- Avoid MSW and Anvil; prefer real services/testnets
-- Anvil fork can be used in CI for deterministic smoke tests
+- **Never** attach MSW, mock fetch, or replay recorded HTTP for e2e tests—real services/testnets only
+- Anvil fork can be used in CI for deterministic smoke tests when the on-chain network itself is the dependency (e.g., forked Arbitrum); this replaces the real chain, not the HTTP layer
 - Heuristic: e2e tests are fire alarms, not microscopes—detect breakage, not root cause
 
 ## 🧩 BDD Mapping

.cursor/commands/write-tests.md

@@ -5,9 +5,10 @@ You are an expert test engineer who writes comprehensive, maintainable tests. Yo
 1. **NEVER modify src/ files without .test.ts suffix** - You're forbidden from touching production code
 2. **ALWAYS test behavior (WHAT) not implementation (HOW)** - Test outcomes, not mechanics
 3. **Write comprehensive tests** - Cover success paths, error cases, and edge conditions
-4. **Use vi.mock() for unit tests; MSW for HTTP integration; Anvil for EVM integration** - Choose the right tool
+4. **Use vi.mock() for unit tests; MSW for HTTP integration; Anvil for EVM integration; NEVER mock e2e tests** - Choose the right tool and keep e2e fully live
 5. **Place test utilities in tests/utils/ only** - Never in .claude/, src/, or root
 
+**Non-negotiable**: `*.e2e.test.ts` files must hit real services or dedicated testnets directly—no MSW, no recorded mocks, no HTTP interceptors. If you cannot reach the live dependency, pause the e2e effort instead of faking it.
 ## ⚖️ Critical Boundaries
 
 ### ❌ CANNOT DO:
@@ -54,6 +55,7 @@ Where should test file go?
    - Adapter/SDK → Integration tests with MSW
    - Repository → Integration tests with real DB
    - Blockchain/EVM → Integration tests with Anvil
+   - Full system/e2e flows → End-to-end tests that call real services/testnets directly (no MSW or stubbed HTTP; Anvil only if the entire chain is the target environment)
 
 2. **Check existing patterns**:
    - Search for similar test files: `**/*.[same-type].test.ts`
@@ -113,6 +115,12 @@ Need to test something?
 
 ## 🔧 Tool Usage Guide
 
+### Non-negotiable: E2E tests stay live
+
+- Never register MSW handlers, mock fetch/axios, or intercept RPC calls inside `*.e2e.test.ts`.
+- E2E tests must call the same public/testnet endpoints the product uses (or a dedicated staging environment) and should fail fast if those endpoints are unreachable.
+- Anvil is acceptable for e2e only when the whole scenario is meant to run against a deterministic fork or local chain—treat it as the target environment, not a mock layer.
+
 ### Use vi.mock() when:
 
 - Testing unit logic in isolation
@@ -155,8 +163,8 @@ For Anvil-based tests:
 - Scope: keep light (smoke tests)
 - When to run: Skip in feature branch CI; required before merging to main
 - Placement: `tests/` directory (`*.e2e.test.ts`)
-- Avoid MSW and Anvil; prefer real services/testnets
-- Anvil fork can be used in CI for deterministic smoke tests
+- **Never** attach MSW, mock fetch, or replay recorded HTTP for e2e tests—real services/testnets only
+- Anvil fork can be used in CI for deterministic smoke tests when the on-chain network itself is the dependency (e.g., forked Arbitrum); this replaces the real chain, not the HTTP layer
 - Heuristic: e2e tests are fire alarms, not microscopes—detect breakage, not root cause
 
 ## 🧩 BDD Mapping

.cursor/rules/root.mdc

@@ -24,18 +24,18 @@ globs: **/*
 - Unit tests mirror source directory structure
 - Use Vitest for testing framework (migrating from Mocha)
 - Follow Test-Driven Development (TDD) practices
-- For detailed testing guidelines, see `docs/testing-strategy.md` and the TDD agents
+- For detailed testing guidelines, see `.rulesync/commands/write-tests.md` and the TDD agents
 
 ### Working with Test Infrastructure and Code
 
 When modifying test infrastructure (MSW handlers, test utilities, mock data):
 
-- **ALWAYS read** `.claude/agents/tdd-test-writer.md` FIRST for requirements and patterns
+- **ALWAYS read** `.rulesync/commands/write-tests.md` FIRST for requirements and patterns
 - This includes creating new handlers, updating existing ones, or adding mock utilities
 
 When implementing or modifying code (whether making tests pass or any other changes):
 
-- **ALWAYS read** `.claude/agents/test-driven-coder.md` FIRST for implementation patterns
+- **ALWAYS read** `.rulesync/commands/write-tests.md` FIRST for implementation patterns
 
 ### Environment Configuration
 
@@ -114,6 +114,13 @@ globs: ["**/*"]
 - **NEVER use `any` type** - use proper types, `unknown`, or type assertions with `as`
 - Never use `.passthrough()` with Zod schemas
 
+### Script Conventions
+
+- Every package must expose `lint`, `lint:fix`, `format`, `format:check`, `test`, `test:watch`, `test:ci`, and `build` scripts so workspace-level commands succeed.
+- `lint` runs ESLint in check mode only (no writes, no Prettier); `lint:fix` runs ESLint with `--fix`.
+- `format` runs Prettier with `--write`; `format:check` runs Prettier with `--check`.
+- Do not chain Prettier inside linting scripts—keep linting and formatting responsibilities separated for clarity and predictable CI behavior.
+
 ### Refactoring and Breaking Changes
 
 **CRITICAL: NEVER maintain backwards compatibility. This is an internal codebase, not a public library.**

.rulesync/commands/write-tests.md

@@ -12,9 +12,10 @@ You are an expert test engineer who writes comprehensive, maintainable tests. Yo
 1. **NEVER modify src/ files without .test.ts suffix** - You're forbidden from touching production code
 2. **ALWAYS test behavior (WHAT) not implementation (HOW)** - Test outcomes, not mechanics
 3. **Write comprehensive tests** - Cover success paths, error cases, and edge conditions
-4. **Use vi.mock() for unit tests; MSW for HTTP integration; Anvil for EVM integration** - Choose the right tool
+4. **Use vi.mock() for unit tests; MSW for HTTP integration; Anvil for EVM integration; NEVER mock e2e tests** - Choose the right tool and keep e2e fully live
 5. **Place test utilities in tests/utils/ only** - Never in .claude/, src/, or root
 
+**Non-negotiable**: `*.e2e.test.ts` files must hit real services or dedicated testnets directly—no MSW, no recorded mocks, no HTTP interceptors. If you cannot reach the live dependency, pause the e2e effort instead of faking it.
 ## ⚖️ Critical Boundaries
 
 ### ❌ CANNOT DO:
@@ -61,6 +62,7 @@ Where should test file go?
    - Adapter/SDK → Integration tests with MSW
    - Repository → Integration tests with real DB
    - Blockchain/EVM → Integration tests with Anvil
+   - Full system/e2e flows → End-to-end tests that call real services/testnets directly (no MSW or stubbed HTTP; Anvil only if the entire chain is the target environment)
 
 2. **Check existing patterns**:
    - Search for similar test files: `**/*.[same-type].test.ts`
@@ -120,6 +122,12 @@ Need to test something?
 
 ## 🔧 Tool Usage Guide
 
+### Non-negotiable: E2E tests stay live
+
+- Never register MSW handlers, mock fetch/axios, or intercept RPC calls inside `*.e2e.test.ts`.
+- E2E tests must call the same public/testnet endpoints the product uses (or a dedicated staging environment) and should fail fast if those endpoints are unreachable.
+- Anvil is acceptable for e2e only when the whole scenario is meant to run against a deterministic fork or local chain—treat it as the target environment, not a mock layer.
+
 ### Use vi.mock() when:
 
 - Testing unit logic in isolation
@@ -162,8 +170,8 @@ For Anvil-based tests:
 - Scope: keep light (smoke tests)
 - When to run: Skip in feature branch CI; required before merging to main
 - Placement: `tests/` directory (`*.e2e.test.ts`)
-- Avoid MSW and Anvil; prefer real services/testnets
-- Anvil fork can be used in CI for deterministic smoke tests
+- **Never** attach MSW, mock fetch, or replay recorded HTTP for e2e tests—real services/testnets only
+- Anvil fork can be used in CI for deterministic smoke tests when the on-chain network itself is the dependency (e.g., forked Arbitrum); this replaces the real chain, not the HTTP layer
 - Heuristic: e2e tests are fire alarms, not microscopes—detect breakage, not root cause
 
 ## 🧩 BDD Mapping

.rulesync/rules/root.md

@@ -26,18 +26,18 @@ globs: ["**/*"]
 - Unit tests mirror source directory structure
 - Use Vitest for testing framework (migrating from Mocha)
 - Follow Test-Driven Development (TDD) practices
-- For detailed testing guidelines, see `docs/testing-strategy.md` and the TDD agents
+- For detailed testing guidelines, see `.rulesync/commands/write-tests.md` and the TDD agents
 
 ### Working with Test Infrastructure and Code
 
 When modifying test infrastructure (MSW handlers, test utilities, mock data):
 
-- **ALWAYS read** `.claude/agents/tdd-test-writer.md` FIRST for requirements and patterns
+- **ALWAYS read** `.rulesync/commands/write-tests.md` FIRST for requirements and patterns
 - This includes creating new handlers, updating existing ones, or adding mock utilities
 
 When implementing or modifying code (whether making tests pass or any other changes):
 
-- **ALWAYS read** `.claude/agents/test-driven-coder.md` FIRST for implementation patterns
+- **ALWAYS read** `.rulesync/commands/write-tests.md` FIRST for implementation patterns
 
 ### Environment Configuration
 

AGENTS.md

@@ -33,18 +33,18 @@ As this project's AI coding tool, you must follow the additional conventions bel
 - Unit tests mirror source directory structure
 - Use Vitest for testing framework (migrating from Mocha)
 - Follow Test-Driven Development (TDD) practices
-- For detailed testing guidelines, see `docs/testing-strategy.md` and the TDD agents
+- For detailed testing guidelines, see `.rulesync/commands/write-tests.md` and the TDD agents
 
 ### Working with Test Infrastructure and Code
 
 When modifying test infrastructure (MSW handlers, test utilities, mock data):
 
-- **ALWAYS read** `.claude/agents/tdd-test-writer.md` FIRST for requirements and patterns
+- **ALWAYS read** `.rulesync/commands/write-tests.md` FIRST for requirements and patterns
 - This includes creating new handlers, updating existing ones, or adding mock utilities
 
 When implementing or modifying code (whether making tests pass or any other changes):
 
-- **ALWAYS read** `.claude/agents/test-driven-coder.md` FIRST for implementation patterns
+- **ALWAYS read** `.rulesync/commands/write-tests.md` FIRST for implementation patterns
 
 ### Environment Configuration
 
@@ -123,6 +123,13 @@ globs: ["**/*"]
 - **NEVER use `any` type** - use proper types, `unknown`, or type assertions with `as`
 - Never use `.passthrough()` with Zod schemas
 
+### Script Conventions
+
+- Every package must expose `lint`, `lint:fix`, `format`, `format:check`, `test`, `test:watch`, `test:ci`, and `build` scripts so workspace-level commands succeed.
+- `lint` runs ESLint in check mode only (no writes, no Prettier); `lint:fix` runs ESLint with `--fix`.
+- `format` runs Prettier with `--write`; `format:check` runs Prettier with `--check`.
+- Do not chain Prettier inside linting scripts—keep linting and formatting responsibilities separated for clarity and predictable CI behavior.
+
 ### Refactoring and Breaking Changes
 
 **CRITICAL: NEVER maintain backwards compatibility. This is an internal codebase, not a public library.**

CLAUDE.md

@@ -22,18 +22,18 @@ Please also reference the following documents as needed:
 - Unit tests mirror source directory structure
 - Use Vitest for testing framework (migrating from Mocha)
 - Follow Test-Driven Development (TDD) practices
-- For detailed testing guidelines, see `docs/testing-strategy.md` and the TDD agents
+- For detailed testing guidelines, see `.rulesync/commands/write-tests.md` and the TDD agents
 
 ### Working with Test Infrastructure and Code
 
 When modifying test infrastructure (MSW handlers, test utilities, mock data):
 
-- **ALWAYS read** `.claude/agents/tdd-test-writer.md` FIRST for requirements and patterns
+- **ALWAYS read** `.rulesync/commands/write-tests.md` FIRST for requirements and patterns
 - This includes creating new handlers, updating existing ones, or adding mock utilities
 
 When implementing or modifying code (whether making tests pass or any other changes):
 
-- **ALWAYS read** `.claude/agents/test-driven-coder.md` FIRST for implementation patterns
+- **ALWAYS read** `.rulesync/commands/write-tests.md` FIRST for implementation patterns
 
 ### Environment Configuration
 
@@ -112,6 +112,13 @@ globs: ["**/*"]
 - **NEVER use `any` type** - use proper types, `unknown`, or type assertions with `as`
 - Never use `.passthrough()` with Zod schemas
 
+### Script Conventions
+
+- Every package must expose `lint`, `lint:fix`, `format`, `format:check`, `test`, `test:watch`, `test:ci`, and `build` scripts so workspace-level commands succeed.
+- `lint` runs ESLint in check mode only (no writes, no Prettier); `lint:fix` runs ESLint with `--fix`.
+- `format` runs Prettier with `--write`; `format:check` runs Prettier with `--check`.
+- Do not chain Prettier inside linting scripts—keep linting and formatting responsibilities separated for clarity and predictable CI behavior.
+
 ### Refactoring and Breaking Changes
 
 **CRITICAL: NEVER maintain backwards compatibility. This is an internal codebase, not a public library.**

rulesync.jsonc

@@ -14,7 +14,7 @@
   ],
   "delete": true,
   "verbose": false,
-  "global": true,
+  "global": false,
   "simulatedCommands": true,
   "simulatedSubagents": false
-}
+}

typescript/clients/web/.env.example

@@ -1,6 +1,6 @@
 # Agent Card URL - The URL of the agent card endpoint
-# This should point to your agent card server
-NEXT_PUBLIC_AGENT_CARD_URL=http://localhost:3001
+# This should point directly to your agent card JSON URL
+NEXT_PUBLIC_AGENT_CARD_URL=http://localhost:3001/.well-known/agent-card.json
 
 # Private key for signing delegations (EIP-7702)
 # Format: 0x followed by 64 hexadecimal characters (66 total length)

typescript/clients/web/CLAUDE.md

@@ -69,7 +69,7 @@ npm run build           # Production build
 npm run lint            # Run linter
 ```
 
-**Default A2A Agent:** http://localhost:3001 (fetches `/.well-known/agent-card.json`)
+**Default Agent Card URL:** http://localhost:3001/.well-known/agent-card.json
 
 ## Conventions
 

typescript/clients/web/README.md

@@ -42,7 +42,7 @@ Open [http://localhost:3000](http://localhost:3000)
 
 ## How It Works
 
-1. **Frontend** fetches agent card from `https://dev.emberai.xyz/.well-known/agent-card.json`
+1. **Frontend** fetches agent card from `NEXT_PUBLIC_AGENT_CARD_URL` (defaults to `http://localhost:3001/.well-known/agent-card.json`)
 2. **Frontend** connects to **Backend** via Socket.IO (`localhost:5001`)
 3. **Backend** sends JSONRPC requests to `https://dev.emberai.xyz/a2a`
 4. **Backend** forwards responses back to **Frontend**

typescript/clients/web/docs/DIRECT_A2A_CONNECTION.md

@@ -53,12 +53,12 @@ Browser → fetch (SSE) → A2A Agent ✨
 
 ```typescript
 // Fetch agent card
-const agentCardUrl = `${url}/.well-known/agent-card.json`;
+const agentCardUrl = url; // full path to /.well-known/agent-card.json
 const response = await fetch(agentCardUrl);
 const agentCard = await response.json();
 
 // Extract A2A endpoint
-const a2aEndpoint = agentCard.a2a?.endpoint || `${url}/a2a`;
+const a2aEndpoint = agentCard.url;
 ```
 
 ### 2. Message Streaming
@@ -287,8 +287,8 @@ Access-Control-Allow-Headers: Content-Type, Accept
 
 If connection times out:
 
-1. ✅ Verify agent URL is correct
-2. ✅ Check agent card is accessible: `https://dev.emberai.xyz/.well-known/agent-card.json`
+1. ✅ Verify the configured agent card URL is correct
+2. ✅ Check the agent card endpoint responds (default: `http://localhost:3001/.well-known/agent-card.json`)
 3. ✅ Ensure network connectivity
 
 ### No Streaming

typescript/clients/web/docs/MIGRATION_TO_A2A_JS.md

@@ -50,8 +50,8 @@ The backend server (`server/server.js`) is no longer needed for A2A communicatio
 
 ### Connection Flow
 
-1. User enters agent URL (e.g., `https://dev.emberai.xyz`)
-2. Client fetches agent card from `/.well-known/agent-card.json`
+1. User enters the agent card URL (e.g., `https://dev.emberai.xyz/.well-known/agent-card.json`)
+2. Client fetches that agent card document directly
 3. `A2AClient` is initialized with the agent URL
 4. Ready to send messages!