feat: v1->v2 migration rules, raw-HTTP support, and scan mode

[dani1005]

What

Adds the everos-cloud 0.4.x → 1.x (v2 Memory API) migration to the existing v0→v1 skill, and extends the skill to cover callers that speak HTTP directly instead of using the Python SDK.

Why the rules are split in two

File	Scope
migration/http/v1-to-v2.md (new, 17 rules)	Transport level — endpoints, payloads, responses. Language-agnostic, source of truth
migration/python/v1-to-v2.md (new, 15 rules)	Maps the Python SDK surface onto those rules

This migration is fundamentally an API-level change, not just an SDK rename. A customer calling /api/v1/memories from Go, TypeScript or curl hits every one of these breaking changes — and previously got zero help: Step 1 only grepped evermemos|everos_cloud, which never matches a raw caller. Detection now also matches /api/v1/memories, api.evermind.ai and the EverOS env vars.

SKILL.md changes

• Fixed version detection. It keyed on a client.vN. prefix — but 1.x removed that entirely (client.add(...), not client.v1.memories.add(...)). A migrated repo was misdetected and re-running the skill was not idempotent. Now keys on the dependency constraint plus bare facade verbs.
• Added --scan mode — produce an impact report, edit nothing. Useful for deciding whether to migrate.
• Added the blocker list that must always be flagged and never rewritten, plus an impact-report template that leads with those blockers rather than with the mechanical diff count.

Findings that contradict the current public migration guide

Verified against the published 0.4.1 / 1.0.0 / 1.1.0 wheels on PyPI, the v2 OpenAPI contract, and live prod calls (2026-09-04):

1. 1.x does NOT read EVEROS_API_KEY. api_key is a required argument; there is no os.environ/getenv reference anywhere in client.py. sdk-migration-1x.mdx states it "still reads EVEROS_API_KEY if omitted". This one fails loudly (TypeError), so it is the safe one.
2. 1.x does NOT read EVER_OS_BASE_URL either — and this fails silently. 0.4.x picked it up from the environment; 1.x only honours host=. A client that pointed at a dev or test gateway via the environment starts reading and writing production data after the upgrade, with no error. Flagged as the top-priority finding in the skill.
3. Also undocumented: AsyncEverOS is gone (no async client in 1.x at all), as are max_retries / http_client / default_headers — 0.4.x retried twice by default, 1.x does not retry.

The OpenAPI spec's own AddInput example uses "timestamp": 1700000000 (seconds), which the API rejects with 422 — worth fixing separately in the spec.

Capabilities with no v2 equivalent (flagged, never rewritten)

group memory (/memories/group, /groups, group_id filters), /senders, /settings, AsyncEverOS, delete(memory_id=), and memory_type="raw_message". The v2 contract has zero occurrences of group. These decide whether a given customer's migration can complete at all, so the skill counts them and reports the counts first.

Naming

Marketplace renamed everos-plugins → everos-tools. The GitHub repo rename is a separate manual step (needs admin), and docs.evermind.ai/api-reference/sdk-migration install commands need updating with it.

Testing

• claude plugin validate . → ✔ passes (same check as CI)
• examples/python/v2.py → py_compile clean
• End-to-end on a synthetic v1 customer repo (Python SDK + a TypeScript fetch caller + group usage + seconds timestamps + AsyncEverOS + EVER_OS_BASE_URL pointed at test): detection, scan report, and rewrites all behaved as specified — including catching Math.floor(Date.now()/1000) in the TS file.

⚠️ Not yet run against real customer code. Worth doing before this goes out in any customer-facing email.

🤖 Generated with Claude Code