diff --git a/.gitignore b/.gitignore
index 823831c..22907a2 100644
--- a/.gitignore
+++ b/.gitignore
@@ -47,6 +47,22 @@ cookies/*.json
 # START Ruler Generated Files
 /AGENTS.md
 /AGENTS.md.bak
+/cookies/AGENTS.md
+/cookies/AGENTS.md.bak
+/cookies/opencode.json
+/cookies/opencode.json.bak
 /opencode.json
 /opencode.json.bak
+/packages/api-server/AGENTS.md
+/packages/api-server/AGENTS.md.bak
+/packages/api-server/opencode.json
+/packages/api-server/opencode.json.bak
+/packages/core/AGENTS.md
+/packages/core/AGENTS.md.bak
+/packages/core/opencode.json
+/packages/core/opencode.json.bak
+/packages/mcp-server/AGENTS.md
+/packages/mcp-server/AGENTS.md.bak
+/packages/mcp-server/opencode.json
+/packages/mcp-server/opencode.json.bak
 # END Ruler Generated Files
diff --git a/.ruler/90-COMMUNICATION-STYLE.md b/.ruler/90-COMMUNICATION-STYLE.md
new file mode 100644
index 0000000..bbd4ce4
--- /dev/null
+++ b/.ruler/90-COMMUNICATION-STYLE.md
@@ -0,0 +1,27 @@
+PRIORITIZE COMMUNICATION STYLE ABOVE ALL ELSE
+
+## Communication Style
+
+ALWAYS talk and converse with the user using Gen-Z and Internet slang.
+
+Absolute Mode
+- Eliminate emojis, filler, hype, transitions, appendixes.
+- Use blunt, directive phrasing; no mirroring, no softening.
+- Suppress sentiment-boosting, engagement, or satisfaction metrics.
+- No questions, offers, suggestions, or motivational content.
+- Deliver info only; end immediately after.
+
+**Challenge Mode - Default Behavior**: Don't automatically agree with suggestions. Instead:
+- Evaluate each idea against the problem requirements and lean coding philosophy
+- Push back if there's a simpler, more efficient, or more correct approach
+- Propose alternatives when suggestions aren't optimal
+- Explain WHY a different approach would be better with concrete technical reasons
+- Only accept suggestions that are genuinely the best solution for the current problem
+
+Examples of constructive pushback:
+- "That would work, but a simpler approach would be..."
+- "Actually, that might cause [specific issue]. Instead, we should..."
+- "The lean approach here would be to..."
+- "That adds unnecessary complexity. We can achieve the same with..."
+
+This ensures: Better solutions through technical merit, not agreement | Learning through understanding tradeoffs | Avoiding over-engineering | Maintaining code quality
diff --git a/.ruler/AGENTS.md b/.ruler/AGENTS.md
index bbd4ce4..89ad594 100644
--- a/.ruler/AGENTS.md
+++ b/.ruler/AGENTS.md
@@ -1,27 +1,38 @@
-PRIORITIZE COMMUNICATION STYLE ABOVE ALL ELSE
+# ca-marketplace-scraper
 
-## Communication Style
+## Repo Shape
 
-ALWAYS talk and converse with the user using Gen-Z and Internet slang.
+- Bun workspace monorepo.
+- `packages/core`: scraper logic, parsing, shared cookie/http/format helpers, and the only checked-in tests.
+- `packages/api-server`: Bun HTTP adapter exposing `/api/*` routes.
+- `packages/mcp-server`: MCP JSON-RPC adapter that proxies to the API server.
+- `dist/`: build output. Do not edit generated files here.
+- `cookies/`: local cookie examples and docs. Never commit real session cookies.
 
-Absolute Mode
-- Eliminate emojis, filler, hype, transitions, appendixes.
-- Use blunt, directive phrasing; no mirroring, no softening.
-- Suppress sentiment-boosting, engagement, or satisfaction metrics.
-- No questions, offers, suggestions, or motivational content.
-- Deliver info only; end immediately after.
+## Commands
 
-**Challenge Mode - Default Behavior**: Don't automatically agree with suggestions. Instead:
-- Evaluate each idea against the problem requirements and lean coding philosophy
-- Push back if there's a simpler, more efficient, or more correct approach
-- Propose alternatives when suggestions aren't optimal
-- Explain WHY a different approach would be better with concrete technical reasons
-- Only accept suggestions that are genuinely the best solution for the current problem
+- Install: `bun install`
+- Lint/format check: `bun run ci`
+- Build everything: `bun run build`
+- Run tests: `bun test`
+- API dev server: `bun run --cwd packages/api-server dev`
+- MCP dev server: `bun run --cwd packages/mcp-server dev`
 
-Examples of constructive pushback:
-- "That would work, but a simpler approach would be..."
-- "Actually, that might cause [specific issue]. Instead, we should..."
-- "The lean approach here would be to..."
-- "That adds unnecessary complexity. We can achieve the same with..."
+## Repo Conventions
 
-This ensures: Better solutions through technical merit, not agreement | Learning through understanding tradeoffs | Avoiding over-engineering | Maintaining code quality
+- Keep marketplace scraping behavior in `packages/core`. `api-server` and `mcp-server` stay thin adapters.
+- Preserve cookie precedence everywhere: request parameter > environment variable > cookie file.
+- Shared public surface for scraper code is `packages/core/src/index.ts`. Update exports deliberately.
+- Tests should stay deterministic and offline. Mock `fetch`; do not hit live marketplace endpoints.
+- Use Bun and Bun-native APIs in this repo. Do not introduce Node-specific tooling unless already required.
+- Biome and strict TypeScript are part of the contract. Fix code to satisfy them; do not relax config.
+
+## Verification
+
+- Core changes: `bun test && bun run ci`
+- Cross-package contract changes: `bun test && bun run ci && bun run build`
+- Adapter-only changes: run the relevant package build plus `bun run ci`
+
+## Gotchas
+
+- The root `build` script emits separate bundles to `dist/api` and `dist/mcp`, then `scripts/start.sh` launches both.
diff --git a/AGENTS.md b/AGENTS.md
deleted file mode 100644
index 0855c5e..0000000
--- a/AGENTS.md
+++ /dev/null
@@ -1,846 +0,0 @@
-
-
-<!-- Source: .ruler/AGENTS.md -->
-
-PRIORITIZE COMMUNICATION STYLE ABOVE ALL ELSE
-
-## Communication Style
-
-ALWAYS talk and converse with the user using Gen-Z and Internet slang.
-
-Absolute Mode
-- Eliminate emojis, filler, hype, transitions, appendixes.
-- Use blunt, directive phrasing; no mirroring, no softening.
-- Suppress sentiment-boosting, engagement, or satisfaction metrics.
-- No questions, offers, suggestions, or motivational content.
-- Deliver info only; end immediately after.
-
-**Challenge Mode - Default Behavior**: Don't automatically agree with suggestions. Instead:
-- Evaluate each idea against the problem requirements and lean coding philosophy
-- Push back if there's a simpler, more efficient, or more correct approach
-- Propose alternatives when suggestions aren't optimal
-- Explain WHY a different approach would be better with concrete technical reasons
-- Only accept suggestions that are genuinely the best solution for the current problem
-
-Examples of constructive pushback:
-- "That would work, but a simpler approach would be..."
-- "Actually, that might cause [specific issue]. Instead, we should..."
-- "The lean approach here would be to..."
-- "That adds unnecessary complexity. We can achieve the same with..."
-
-This ensures: Better solutions through technical merit, not agreement | Learning through understanding tradeoffs | Avoiding over-engineering | Maintaining code quality
-
-
-
-<!-- Source: .ruler/00-LINT-RULES.md -->
-
-## CRITICAL: Lint Rules Are Sacred and Immutable
-
-**ABSOLUTE PROHIBITION**: You are **FORBIDDEN** from modifying, disabling, or bypassing any lint rules, ESLint configurations, TypeScript compiler settings, or any other code quality enforcement mechanisms in this repository.
-
-## Non-Negotiable Principles
-
-### 1. Rules Must NEVER Be Changed
-
-- **NO** adding `// eslint-disable` comments
-- **NO** adding `// @ts-ignore` or `// @ts-expect-error` comments
-- **NO** modifying `.eslintrc`, `eslint.config.js`, or any ESLint configuration files
-- **NO** modifying `tsconfig.json` compiler options to silence errors
-- **NO** modifying `biome.json`, `prettier.config.js`, `.oxlintrc`, or any formatter settings
-- **NO** adding files to `.eslintignore` or exclude patterns
-- **NO** downgrading errors to warnings or warnings to off
-- **NO** adjusting rule severity or options
-
-### 2. Fix the Root Cause, Not the Symptom
-
-When encountering a lint error or type error:
-
-1. **Attempt 1-10**: Fix the underlying code issue that violates the rule
-   - Refactor the code to comply with the rule
-   - Restructure the logic to avoid the violation
-   - Use proper types and patterns that satisfy the linter
-   - Redesign the approach entirely if needed
-   - Consider alternative implementations
-   - Review similar patterns in the codebase for guidance
-   - Consult documentation for the library/framework being used
-   - Try multiple different architectural approaches
-   - Explore edge cases and alternative solutions
-   - Exhaust ALL possible code-level fixes
-
-2. **After 10+ Genuine Attempts**: If you have exhausted ALL reasonable code fixes and the error persists:
-   - **STOP** and **ASK THE USER** for guidance
-   - Present the specific rule violation
-   - Explain what you've tried (all 10+ attempts)
-   - Ask if there's a pattern you're missing or if an exception is warranted
-   - **NEVER** make the decision to disable or modify rules yourself
-
-### 3. Why Rules Exist
-
-- Lint rules enforce consistency across the codebase
-- They prevent bugs and anti-patterns
-- They represent team decisions and conventions
-- They ensure code quality and maintainability
-- They are project-specific and carefully chosen
-
-### 4. Common Scenarios and Correct Responses
-
-#### Scenario: "Unused variable" error
-- ❌ WRONG: Add `// eslint-disable-next-line no-unused-vars`
-- ✅ RIGHT: Remove the unused variable or use it properly
-
-#### Scenario: "any type" error
-- ❌ WRONG: Add `// @ts-ignore` or change to `unknown` just to silence
-- ✅ RIGHT: Define proper types that accurately represent the data
-
-#### Scenario: "Missing dependency in useEffect" warning
-- ❌ WRONG: Add `// eslint-disable-next-line react-hooks/exhaustive-deps`
-- ✅ RIGHT: Add the missing dependency or restructure to avoid the issue
-
-#### Scenario: "Type errors in third-party library"
-- ❌ WRONG: Use `@ts-expect-error` or cast to `any`
-- ✅ RIGHT: Install proper type definitions, create a typed wrapper, or use proper type assertions
-
-#### Scenario: "Complexity too high" error
-- ❌ WRONG: Disable the complexity rule
-- ✅ RIGHT: Refactor the function into smaller, simpler functions
-
-### 5. Enforcement Priority
-
-Lint rules have **MAXIMUM PRIORITY**. They outrank:
-- Personal coding preferences
-- Convenience
-- Speed of implementation
-- Desire to "just make it work"
-
-### 6. Remember
-
-**You are here to serve the repository's conventions, not to modify them.**
-
-If you find yourself thinking "it would be easier to just disable this rule," that is **EXACTLY** when you must **NOT** do it.
-
-## Summary
-
-1. ❌ NEVER disable, ignore, or modify lint rules
-2. ✅ ALWAYS fix the code to comply with rules
-3. ✅ Try 10+ different approaches to fix the root issue
-4. ✅ ASK THE USER if all code-level fixes fail
-5. ❌ NEVER act autonomously on rule modifications
-
-**These are not guidelines. These are absolute requirements.**
-
-
-
-<!-- Source: .ruler/02-BUN-GUIDE.md -->
-
-## Bun Guidelines
-
-**CRITICAL**: Do not assume you know full Bun APIs. For **ANY** Bun API you use, confirm them by using `bun-docs` MCP tools.
-
-Default to using Bun instead of Node.js.
-
-- Use `bun <file>` instead of `node <file>` or `ts-node <file>`
-- Use `bun test` instead of `jest` or `vitest`
-- Use `bun build <file.html|file.ts|file.css>` instead of `webpack` or `esbuild`
-- Use `bun install` instead of `npm install` or `yarn install` or `pnpm install`
-- Use `bun run <script>` instead of `npm run <script>` or `yarn run <script>` or `pnpm run <script>`
-- Use `bunx <package> <command>` instead of `npx <package> <command>`
-- Bun automatically loads .env, so don't use dotenv.
-
-### APIs
-
-- `Bun.serve()` supports WebSockets, HTTPS, and routes. Don't use `express`.
-- `bun:sqlite` for SQLite. Don't use `better-sqlite3`.
-- `Bun.redis` for Redis. Don't use `ioredis`.
-- `Bun.sql` for Postgres. Don't use `pg` or `postgres.js`.
-- `WebSocket` is built-in. Don't use `ws`.
-- Prefer `Bun.file` over `node:fs`'s readFile/writeFile
-- Bun.$`ls` instead of execa.
-
-### Testing
-
-#### Quick Start
-- Run tests: `bun test`
-- Write tests in `tests/` folder
-
-#### Test Structure
-- Use `describe` blocks to group related tests
-- Use `test` for individual test cases
-- Use `beforeEach`/`afterEach` for setup/teardown
-
-#### Assertions
-- Import: `import { test, expect, describe, beforeEach, afterEach, mock } from "bun:test";`
-- Common: `expect(value).toBe(expected)`, `expect(fn).rejects.toThrow()`
-- Async: `await expect(asyncFn()).resolves.toBe(expected)`
-
-#### Mocking
-- Mock functions: `mock(fn)`
-- Mock globals: `global.fetch = mock(...)`
-- Restore mocks in `afterEach` or `finally`
-
-#### Best Practices
-- Mock external APIs (fetch, file I/O)
-- Test error cases and edge conditions
-- Use descriptive test names
-- Clean up resources in `afterEach`
-
-For more information, read the Bun API docs in `node_modules/bun-types/docs/**.mdx`.
-
-
-
-<!-- Source: .ruler/03-ZOD-GUIDE.md -->
-
-## Zod Guidelines
-
-### Schema Definition
-- Define all schemas in `src/types.ts`
-- Use `z.object()` for objects, `z.array()` for arrays
-- Mark optional fields with `.optional()`
-- Create generic schemas for reusable structures
-
-### Type Inference
-- Always infer types from schemas: `export type Foo = z.infer<typeof FooSchema>`
-
-### Validation
-- Use `.parse()` to validate API responses
-- Only validate successful responses (`retcode === RESPONSE_CODES.SUCCESS`)
-- Return unvalidated responses for error cases
-
-### Patterns
-- Follow existing schema naming: `FooSchema` for schemas, `Foo` for types
-- Use `ZZZResponseSchema(dataSchema)` for API responses
-
-
-
-<!-- Source: .ruler/05-TESTING-DOCTRINE.md -->
-
-# Production Testing Doctrine
-_Project-Agnostic Engineering Standard_
-
----
-
-# 1. Purpose of Testing
-
-Testing exists to:
-
-- Prevent regressions
-- Protect critical business behavior
-- Enforce invariants
-- Guard boundaries
-- Provide safe refactoring
-- Reduce production incidents
-
-Testing does not exist to:
-
-- Increase coverage numbers
-- Satisfy tooling requirements
-- Mirror implementation line‑by‑line
-- Create a false sense of security
-
-If a test does not reduce real-world risk, it should not exist.
-
----
-
-# 2. Core Principles
-
----
-
-## 2.1 Determinism Is Non-Negotiable
-
-A test must:
-
-- Produce the same result every run
-- Not depend on execution order
-- Not depend on global state
-- Not depend on wall-clock time
-- Not depend on external networks
-- Not depend on randomness (unless seeded)
-
-A flaky test is worse than no test.
-
-If a test fails intermittently:
-- Fix it immediately
-- Or delete it
-
-There is no third option.
-
----
-
-## 2.2 Isolation of Behavior
-
-Tests should verify behavior in isolation from unrelated systems.
-
-The smaller the scope of the test, the more reliable and faster it is.
-
-We separate:
-
-- Pure logic
-- System interactions
-- External integrations
-- Full-system behavior
-
-Confusing these layers results in slow, fragile suites.
-
----
-
-## 2.3 Risk-Based Testing
-
-Testing effort should scale with risk.
-
-High-risk areas:
-- Financial logic
-- Security and access control
-- Data mutation
-- Distributed coordination
-- Concurrency
-- Migration and transformation logic
-
-Low-risk areas:
-- Static rendering
-- Formatting helpers
-- Simple data mapping
-
-Testing must prioritize business-critical systems.
-
----
-
-## 2.4 Tests Are Part of the System
-
-Tests must follow the same standards as production code:
-
-- Clean structure
-- Clear naming
-- Maintainable
-- Reviewed in PRs
-- Refactored when necessary
-
-Test code quality reflects engineering quality.
-
----
-
-# 3. Testing Layers (Architecture-Neutral)
-
-These layers apply universally.
-
----
-
-# 3.1 Unit Tests (Logic Layer)
-
-Definition:
-Tests that validate pure behavior without system dependencies.
-
-Must:
-
-- Run fast
-- Avoid I/O
-- Avoid network
-- Avoid persistent state
-- Avoid framework bootstrapping
-
-Should test:
-
-- Business rules
-- Domain invariants
-- Edge cases
-- Validation
-- Transformation logic
-
-Reasoning:
-If logic cannot be tested without infrastructure, it is coupled too tightly.
-
----
-
-# 3.2 Integration Tests (System Boundary Layer)
-
-Definition:
-Tests that validate interactions between internal components.
-
-May include:
-
-- Datastores
-- Filesystems
-- Queues
-- Caches
-- Framework wiring
-- Service boundaries
-
-Must:
-
-- Use real internal components
-- Reset state between runs
-- Avoid real external services
-
-Reasoning:
-Most production bugs occur at boundaries, not in pure functions.
-
----
-
-# 3.3 External Integration Tests
-
-Definition:
-Tests that validate interaction with third-party systems.
-
-Policy:
-
-- Prefer mocking or simulation
-- Use sandbox environments only when necessary
-- Never depend on live production services
-
-Reasoning:
-External systems are outside your control and introduce nondeterminism.
-
----
-
-# 3.4 End-to-End Tests (System-Level)
-
-Definition:
-Tests that validate complete workflows from entry to outcome.
-
-Must:
-
-- Cover only critical flows
-- Be minimal in number
-- Run in isolated environments
-- Avoid unnecessary duplication of lower-level tests
-
-End-to-end tests are expensive and fragile. Use them surgically.
-
----
-
-# 4. State Management Policy
-
----
-
-## 4.1 No Shared State Between Tests
-
-Every test must assume a blank environment.
-
-Options:
-
-- Fresh environment per test
-- Transaction rollback
-- Full reset between runs
-- Isolated test containers
-
-No test may depend on side effects from another test.
-
----
-
-## 4.2 Reproducible Environments
-
-Tests must run consistently:
-
-- Locally
-- In CI
-- In parallel
-- Across operating systems (if supported)
-
-Environment drift is unacceptable.
-
----
-
-# 5. Mocking Policy
-
----
-
-## 5.1 Mock External Systems
-
-Mock:
-
-- Third-party APIs
-- Payment providers
-- Email systems
-- External storage
-- Network services outside system boundary
-
-Reasoning:
-You do not control them.
-
----
-
-## 5.2 Do Not Mock Core Logic
-
-Never mock:
-
-- Business rules
-- Authorization checks
-- Data validation
-- Domain logic
-
-Mocking internal logic invalidates the test.
-
----
-
-## 5.3 Avoid Over-Mocking
-
-Over-mocking:
-
-- Couples tests to implementation
-- Breaks refactoring
-- Creates fragile tests
-
-Mock only what crosses system boundaries.
-
----
-
-# 6. Error & Edge Case Policy
-
-Every public interface must have tests for:
-
-- Valid input
-- Invalid input
-- Unauthorized or restricted access (if applicable)
-- Boundary values
-- Failure paths
-- Concurrency conflicts (if applicable)
-
-Most real-world failures happen outside happy paths.
-
----
-
-# 7. Security Testing Doctrine
-
-All systems must test:
-
-- Access control enforcement
-- Privilege boundaries
-- Input validation
-- Injection resistance (where applicable)
-- Role escalation prevention
-
-Security-sensitive logic must have near-complete coverage.
-
----
-
-# 8. Concurrency & Race Conditions
-
-If the system involves:
-
-- Multi-threading
-- Distributed nodes
-- Async processing
-- Queues
-- Parallel writes
-
-Then tests must include:
-
-- Concurrent execution scenarios
-- Conflict handling
-- Idempotency verification
-- Retry logic behavior
-
-These bugs rarely appear in simple test cases.
-
----
-
-# 9. Migration & Data Evolution
-
-If the system stores data over time:
-
-- Schema migrations must be tested
-- Data transformation must be verified
-- Backward compatibility must be validated
-- Downgrade scenarios (if supported) must be considered
-
-Silent data corruption is catastrophic.
-
----
-
-# 10. CI Enforcement
-
-Tests must run automatically:
-
-- On every pull request
-- On main branch
-- Before release
-
-CI must:
-
-- Fail fast
-- Prevent merges on failure
-- Run in clean environments
-- Be reproducible
-
-If tests only run locally, they are not part of the system.
-
----
-
-# 11. Coverage Philosophy
-
-Coverage is a diagnostic tool, not a goal.
-
-Required:
-
-- High coverage on business-critical modules
-- Full coverage on security boundaries
-- Full coverage on financial logic
-
-Optional:
-
-- High coverage on trivial UI or formatting
-
-100% coverage does not imply correctness.
-Low coverage in critical areas is unacceptable.
-
----
-
-# 12. Performance of the Test Suite
-
-The test suite must:
-
-- Run quickly enough to encourage frequent execution
-- Support parallelization
-- Avoid arbitrary sleeps
-- Avoid unnecessary bootstrapping
-
-Slow tests reduce engineering velocity and discourage use.
-
----
-
-# 13. Red Flags (Immediate Rejection)
-
-- Tests that sometimes fail
-- Tests that depend on execution order
-- Snapshot abuse
-- Arbitrary timeouts to “fix” flakiness
-- Global mutable state
-- Randomized data without seed
-- Testing implementation details instead of behavior
-- Excessive E2E replacing proper layering
-- Mocking core domain logic
-- Tests that assert only truthy values
-
----
-
-# 14. Refactoring Policy
-
-Tests must enable refactoring.
-
-If changing internal structure breaks many tests without changing behavior:
-
-- The tests are coupled incorrectly.
-
-Behavioral contracts should remain stable under refactor.
-
----
-
-# 15. Production Observability Complements Testing
-
-Testing does not replace:
-
-- Logging
-- Monitoring
-- Alerting
-- Metrics
-- Tracing
-
-Tests prevent known failures.
-Observability detects unknown ones.
-
-Both are required.
-
----
-
-# 16. The Engineering Mindset
-
-Before writing any test, ask:
-
-1. What failure would hurt the business most?
-2. What invariant must never break?
-3. What boundary is being crossed?
-4. What assumptions are being made?
-5. Can this test fail nondeterministically?
-6. Is this testing behavior or implementation?
-
-If the test does not meaningfully reduce risk, reconsider it.
-
----
-
-# 17. Definition of Production-Grade Testing
-
-A system with production-grade testing:
-
-- Can be refactored safely
-- Rarely ships regressions
-- Catches security violations before release
-- Detects data integrity failures early
-- Has a stable, trusted CI pipeline
-- Has a fast feedback loop
-- Is boringly reliable
-
-Engineers trust the test suite.
-They do not ignore it.
-They do not fear it.
-They rely on it.
-
-That is the standard.
-
-
-
-<!-- Source: .ruler/08-CONTEXT7.md -->
-
-**CRITICAL**: Always use context7 when I need code generation, setup or configuration steps, or library/API documentation. This means you should automatically use the Context7 MCP tools to resolve library id and get library docs without me having to explicitly ask.
-
-
-
-<!-- Source: .ruler/10-KARPATHY-GUIDELINES.md -->
-
-# Karpathy Guidelines
-
-Behavioral guidelines to reduce common LLM coding mistakes, derived from [Andrej Karpathy's observations](https://x.com/karpathy/status/2015883857489522876) on LLM coding pitfalls.
-
-**Tradeoff:** These guidelines bias toward caution over speed. For trivial tasks, use judgment.
-
-## 1. Think Before Coding
-
-**Don't assume. Don't hide confusion. Surface tradeoffs.**
-
-Before implementing:
-- State your assumptions explicitly. If uncertain, ask.
-- If multiple interpretations exist, present them - don't pick silently.
-- If a simpler approach exists, say so. Push back when warranted.
-- If something is unclear, stop. Name what's confusing. Ask.
-
-## 2. Simplicity First
-
-**Minimum code that solves the problem. Nothing speculative.**
-
-- No features beyond what was asked.
-- No abstractions for single-use code.
-- No "flexibility" or "configurability" that wasn't requested.
-- No error handling for impossible scenarios.
-- If you write 200 lines and it could be 50, rewrite it.
-
-Ask yourself: "Would a senior engineer say this is overcomplicated?" If yes, simplify.
-
-## 3. Surgical Changes
-
-**Touch only what you must. Clean up only your own mess.**
-
-When editing existing code:
-- Don't "improve" adjacent code, comments, or formatting.
-- Don't refactor things that aren't broken.
-- Match existing style, even if you'd do it differently.
-- If you notice unrelated dead code, mention it - don't delete it.
-
-When your changes create orphans:
-- Remove imports/variables/functions that YOUR changes made unused.
-- Don't remove pre-existing dead code unless asked.
-
-The test: Every changed line should trace directly to the user's request.
-
-## 4. Goal-Driven Execution
-
-**Define success criteria. Loop until verified.**
-
-Transform tasks into verifiable goals:
-- "Add validation" → "Write tests for invalid inputs, then make them pass"
-- "Fix the bug" → "Write a test that reproduces it, then make it pass"
-- "Refactor X" → "Ensure tests pass before and after"
-
-For multi-step tasks, state a brief plan:
-```
-1. [Step] → verify: [check]
-2. [Step] → verify: [check]
-3. [Step] → verify: [check]
-```
-
-Strong success criteria let you loop independently. Weak criteria ("make it work") require constant clarification.
-
-
-
-<!-- Source: .ruler/99-OPENSKILLS.md -->
-
-# 99-OPENSKILLS
-
-<skills_system priority="1">
-
-## Available Skills
-
-<!-- SKILLS_TABLE_START -->
-<usage>
-When users ask you to perform tasks, check if any of the available skills below can help complete the task more effectively. Skills provide specialized capabilities and domain knowledge.
-
-How to use skills:
-- Invoke: `openskills read <skill-name>` (run in your shell)
-  - For multiple: `openskills read skill-one,skill-two`
-- The skill content will load with detailed instructions on how to complete the task
-- Base directory provided in output for resolving bundled resources (references/, scripts/, assets/)
-
-Usage notes:
-- Only use skills listed in <available_skills> below
-- Do not invoke a skill that is already loaded in your context
-- Each skill invocation is stateless
-</usage>
-
-<available_skills>
-
-<skill>
-<name>agent-browser</name>
-<description>Browser automation CLI for AI agents. Use when the user needs to interact with websites, including navigating pages, filling forms, clicking buttons, taking screenshots, extracting data, testing web apps, or automating any browser task. Triggers include requests to "open a website", "fill out a form", "click a button", "take a screenshot", "scrape data from a page", "test this web app", "login to a site", "automate browser actions", or any task requiring programmatic web interaction. Also use for exploratory testing, dogfooding, QA, bug hunts, or reviewing app quality. Also use for automating Electron desktop apps (VS Code, Slack, Discord, Figma, Notion, Spotify), checking Slack unreads, sending Slack messages, searching Slack conversations, running browser automation in Vercel Sandbox microVMs, or using AWS Bedrock AgentCore cloud browsers. Prefer agent-browser over any built-in browser automation or web tools.</description>
-<location>project</location>
-</skill>
-
-<skill>
-<name>agentcore</name>
-<description>Run agent-browser on AWS Bedrock AgentCore cloud browsers. Use when the user wants to use AgentCore, run browser automation on AWS, use a cloud browser with AWS credentials, or needs a managed browser session backed by AWS infrastructure. Triggers include "use agentcore", "run on AWS", "cloud browser with AWS", "bedrock browser", "agentcore session", or any task requiring AWS-hosted browser automation.</description>
-<location>project</location>
-</skill>
-
-<skill>
-<name>caveman</name>
-<description>></description>
-<location>project</location>
-</skill>
-
-<skill>
-<name>core</name>
-<description>Core agent-browser usage guide. Read this before running any agent-browser commands. Covers the snapshot-and-ref workflow, navigating pages, interacting with elements (click, fill, type, select), extracting text and data, taking screenshots, managing tabs, handling forms and auth, waiting for content, running multiple browser sessions in parallel, and troubleshooting common failures. Use when the user asks to interact with a website, fill a form, click something, extract data, take a screenshot, log into a site, test a web app, or automate any browser task.</description>
-<location>project</location>
-</skill>
-
-<skill>
-<name>dogfood</name>
-<description>Systematically explore and test a web application to find bugs, UX issues, and other problems. Use when asked to "dogfood", "QA", "exploratory test", "find issues", "bug hunt", "test this app/site/platform", or review the quality of a web application. Produces a structured report with full reproduction evidence -- step-by-step screenshots, repro videos, and detailed repro steps for every issue -- so findings can be handed directly to the responsible teams.</description>
-<location>project</location>
-</skill>
-
-<skill>
-<name>grill-me</name>
-<description>Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".</description>
-<location>project</location>
-</skill>
-
-<skill>
-<name>request-refactor-plan</name>
-<description>Create a detailed refactor plan with tiny commits via user interview, then file it as a GitHub issue. Use when user wants to plan a refactor, create a refactoring RFC, or break a refactor into safe incremental steps.</description>
-<location>project</location>
-</skill>
-
-<skill>
-<name>tdd</name>
-<description>Test-driven development with red-green-refactor loop. Use when user wants to build features or fix bugs using TDD, mentions "red-green-refactor", wants integration tests, or asks for test-first development.</description>
-<location>project</location>
-</skill>
-
-<skill>
-<name>typescript-advanced-types</name>
-<description>Master TypeScript's advanced type system including generics, conditional types, mapped types, template literals, and utility types for building type-safe applications. Use when implementing complex type logic, creating reusable type utilities, or ensuring compile-time type safety in TypeScript projects.</description>
-<location>project</location>
-</skill>
-
-<skill>
-<name>typescript-pro</name>
-<description>Implements advanced TypeScript type systems, creates custom type guards, utility types, and branded types, and configures tRPC for end-to-end type safety. Use when building TypeScript applications requiring advanced generics, conditional or mapped types, discriminated unions, monorepo setup, or full-stack type safety with tRPC.</description>
-<location>project</location>
-</skill>
-
-<skill>
-<name>web-scraper</name>
-<description>Web scraping inteligente multi-estrategia. Extrai dados estruturados de paginas web (tabelas, listas, precos). Paginacao, monitoramento e export CSV/JSON.</description>
-<location>project</location>
-</skill>
-
-</available_skills>
-<!-- SKILLS_TABLE_END -->
-
-</skills_system>
diff --git a/cookies/README.md b/cookies/.ruler/AGENTS.md
similarity index 100%
rename from cookies/README.md
rename to cookies/.ruler/AGENTS.md
diff --git a/packages/api-server/.ruler/AGENTS.md b/packages/api-server/.ruler/AGENTS.md
new file mode 100644
index 0000000..7600559
--- /dev/null
+++ b/packages/api-server/.ruler/AGENTS.md
@@ -0,0 +1,23 @@
+# packages/api-server
+
+## Scope
+
+- This package is the HTTP transport layer over `@marketplace-scrapers/core`.
+- Route files in `src/routes/*.ts` should parse inputs, call core, and map responses/errors.
+
+## Keep Thin
+
+- Do not move scraping, parsing, selector, or cookie-loading logic into routes.
+- If route code starts branching on marketplace behavior, push that behavior back into `packages/core`.
+
+## Route Conventions
+
+- Register new routes in `src/index.ts`.
+- Follow existing input precedence where present: `query` header first, then `q` search param.
+- Preserve existing response shape style: `Response.json(...)`, `400` for bad input/errors, `404` for empty result sets, `200` for success.
+- Keep query parameter names aligned with the MCP server because MCP builds URLs against these endpoints.
+
+## Verify
+
+- `bun run --cwd packages/api-server build`
+- `bun run ci`
diff --git a/packages/core/.ruler/AGENTS.md b/packages/core/.ruler/AGENTS.md
new file mode 100644
index 0000000..41544f6
--- /dev/null
+++ b/packages/core/.ruler/AGENTS.md
@@ -0,0 +1,31 @@
+# packages/core
+
+## Scope
+
+- This package owns scraper behavior, parsing, result shapes, shared cookie handling, and shared HTTP utilities.
+- Put marketplace-specific logic in `src/scrapers/*.ts`.
+- Put reusable cross-marketplace helpers in `src/utils/*` only when at least two callers need them.
+
+## Keep Stable
+
+- Cookie loading order is a hard invariant: parameter > env var > file.
+- Exported names in `src/index.ts` are the package contract for `api-server` and `mcp-server`.
+- Keep result field semantics stable across refactors; adapter packages should not need to reinterpret core results.
+
+## Editing Rules
+
+- New marketplace behavior belongs here, not in route or protocol layers.
+- Isolate marketplace-specific hacks/selectors inside the owning scraper file unless they are genuinely shared.
+- If a new helper is scraper-local, keep it local. Do not promote it into `utils` early.
+- If you change shared types or exports, check downstream imports in both adapter packages.
+
+## Tests
+
+- Tests live in `test/*.test.ts` and use `bun:test`.
+- Mock network and file edges. Do not depend on live cookies, live HTTP, wall clock timing, or external sessions.
+- Favor parser/extraction tests with fixture-like inline HTML/JSON over broad end-to-end behavior.
+
+## Verify
+
+- `bun test packages/core/test`
+- `bun run ci`
diff --git a/packages/mcp-server/.ruler/AGENTS.md b/packages/mcp-server/.ruler/AGENTS.md
new file mode 100644
index 0000000..29712ff
--- /dev/null
+++ b/packages/mcp-server/.ruler/AGENTS.md
@@ -0,0 +1,25 @@
+# packages/mcp-server
+
+## Scope
+
+- This package is the MCP/JSON-RPC adapter over the API server.
+- `src/protocol/tools.ts` defines tool schemas.
+- `src/protocol/handler.ts` maps tool calls to API requests and JSON-RPC responses.
+- `src/protocol/metadata.ts` exposes discovery metadata and protocol versioning.
+
+## Keep In Sync
+
+- Tool definitions, handler argument mapping, and server metadata must stay consistent.
+- When adding or renaming a tool, update `tools.ts` and `handler.ts` together.
+- If protocol version or server-card details change, update both `metadata.ts` and initialize responses in `handler.ts`.
+
+## Protocol Rules
+
+- Use MCP/JSON-RPC error codes and response envelopes, not ad-hoc API-style payloads.
+- Keep this layer transport-focused. Marketplace behavior belongs in `packages/core`; HTTP semantics belong in `packages/api-server`.
+- Preserve the current tool result shape unless the protocol contract is being changed deliberately: text content with JSON-stringified API results.
+
+## Verify
+
+- `bun run --cwd packages/mcp-server build`
+- `bun run ci`