docs/.claude/agent-memory/ts-node-backend-engineer/project_processor.md

name, description, type

name	description	type
Processor Service	processor service scaffold, conventions, and known test patterns learned during Phase 1 tasks 1.1–1.4	project

Phase 1 tasks 1.1–1.4 landed. Key facts for tasks 1.5–1.11:

Architecture divergence from tcp-ingestion:

• ESLint import/no-restricted-paths zone: src/core/ cannot import src/domain/ (not src/adapters/ like tcp-ingestion). src/domain/ is preemptive for Phase 2.
• INSTANCE_ID defaults to 'processor-1' (fixed string), not a random UUID prefix. Rationale: deterministic names are better for container environments.
• REDIS_CONSUMER_NAME defaults to INSTANCE_ID at runtime (after schema parse), not as a zod schema default — because it depends on INSTANCE_ID value.

Test patterns:

• connectWithRetry tests: use maxAttempts=1 for the "calls process.exit(1)" case to avoid fake-timer unhandled rejection noise. The noise occurs when a backoff setTimeout resolves after the outer promise has already thrown via process.exit mock.
• Migration runner tests: isMigrationApplied calls pool.query (pool-level, not through client). Handlers on client mock do NOT affect EXISTS checks.
• vi.mock('node:fs/promises') pattern used in migrate.test.ts to isolate filesystem reads.

Why: Phase 1 throughput pipeline. Tasks 1.5–1.8 add consumer/writer/state on top of this foundation.

How to apply: When implementing 1.5 (Redis consumer), 1.6 (device state), 1.7 (position writer), 1.8 (main wiring) — all imports must use .js extension, no path aliases, strict ESM. The connectWithRetry pattern from pool.ts should be mirrored for ioredis in consumer.ts.