{prefix}:{module_name}:{type}:{bucket_id}

qa:swap-tx-rpc:sec:2026-04-15-10-30-45 (expires in 1 hour)
qa:swap-tx-rpc:min:2026-04-15-10-30 (expires in 1 day)
qa:swap-tx-rpc:hour:2026-04-15-10 (expires in 1 day)
qa:swap-tx-rpc:day:2026-04-15 (expires in 30 days)
qa:swap-tx-rpc:month:2026-04 (expires in 180 days)
qa:swap-tx-rpc:year:2026 (expires in 10 years)

{prefix}:global:{type}:{bucket_id}

qa:global:sec:2026-04-15-10-30-45 (expires in 1 hour)
qa:global:min:2026-04-15-10-30 (expires in 1 day)
qa:global:hour:2026-04-15-10 (expires in 1 day)
qa:global:day:2026-04-15 (expires in 30 days)
qa:global:month:2026-04 (expires in 180 days)
qa:global:year:2026 (expires in 10 years)

sec
min
hour
day
month
year

You are helping integrate the npm package `redis-tracker` (`https://www.npmjs.com/package/redis-tracker`) into my codebase.

What `redis-tracker` is for:
- It stores Redis-based action counters.
- It creates module-level and global usage buckets.
- It is useful for API usage stats, RPC usage stats, route tracking, worker/job tracking, and event analytics.

Package exports:
- `statis`
- `trackAction`
- `searchKeys`
- `statRedis`

Important API facts:
- Redis must be initialized once during startup.
- Setup methods:
- `statis.redis.standalone({ host, port })`
- `statis.redis.standalone({ host, port, username, password })`
- `statis.redis.cluster({ nodes: [{ host, port }, ...] })`
- `statis.redis.cluster({ nodes: [{ host, port }, ...], username, password })`
- `statis.redis.object(existingRedisClient, "standalone")`
- `statis.redis.object(existingRedisCluster, "cluster")`
- Track method:
```ts
trackAction({
  prefix: "qa-server",
  module_name: "profile-view-api",
});
```
- Full track options:
```ts
trackAction({
  prefix: "qa-server",
  module_name: "profile-view-api",
  timestamp_ms: Date.now(),
  per_sec: true,
  per_min: true,
  per_hour: true,
  per_day: true,
  per_month: true,
  per_year: true,
  global_sec: true,
  global_min: true,
  global_hour: true,
  global_day: true,
  global_month: true,
  global_year: true,
});
```
- If the user wants only selected periods like only `hour` / `day` / `month`, disable the rest explicitly, for example:
```ts
trackAction({
  prefix: "qa-server",
  module_name: "profile-view-api",
  per_sec: false,
  per_min: false,
  per_hour: true,
  per_day: true,
  per_month: true,
  per_year: false,
  global_sec: false,
  global_min: false,
  global_hour: true,
  global_day: true,
  global_month: true,
  global_year: false,
});
```
- If bucket flags are omitted, all buckets are enabled by default.
- Do not use the old field name `server`; always use `prefix`.
- Redis key patterns:
- `{prefix}:{module_name}:{type}:{bucket_id}`
- `{prefix}:global:{type}:{bucket_id}`
- Supported bucket types:
- `sec`
- `min`
- `hour`
- `day`
- `month`
- `year`
- `searchKeys(pattern)` returns matching keys.
- `statRedis` proxies the active Redis client for commands like `get`, `set`, `del`, etc.

Your workflow:
1. Do not immediately edit code.
2. First understand the codebase and ask implementation questions.
3. If you already have code access, inspect the codebase first and tell me what you found.
4. If you find an existing Redis setup, say:
- `I found an existing Redis setup in <file/path>.`
- `This looks like the best integration point for redis-tracker. Can we proceed with this approach?`
5. If you do not have code access, ask me for the relevant startup/init files, Redis config, or Redis service files before recommending changes.
6. Only after my confirmation should you update code or provide final implementation code.

Ask me these questions in order:

Connection discovery:
- `Let me know how you want to implement redis-tracker based on your codebase.`
- `Is Redis already used in this project?`

If Redis is already used:
- Ask: `Is the existing Redis setup standalone or cluster?`
- If code access is available, inspect and recommend using `statis.redis.object(...)` with the existing connection.
- Use:
- `statis.redis.object(redisClient, "standalone")`
- or
- `statis.redis.object(redisClusterClient, "cluster")`
- Then ask for confirmation before proceeding.

If Redis is not already used:
- Ask: `Do you want me to add Redis integration for this project?`
- If yes, ask: `Should I implement standalone Redis or cluster Redis?`
- Then recommend the correct startup wiring using either `statis.redis.standalone(...)` or `statis.redis.cluster(...)`.
- Then ask for confirmation before proceeding.

Tracking requirement discovery:
- Ask: `What is the requirement for trackAction()?`
- Ask: `Do you want common usage statistics, mixed tracking, or fully specific tracking?`
- Ask: `Do you want to track all logs/events of this module, or only specific logs/events?`
- If specific, ask the user to list exactly which routes, RPCs, jobs, workers, APIs, or events should be tracked.

Give these 3 options clearly:

Option 1. Common module usage
- Use a shared prefix for the app/environment.
- Example:
```ts
trackAction({
  prefix: "qa-server",
  module_name: "profile-view-api",
});
```
- Best when the goal is endpoint/module usage totals.

Option 2. Mixed tracking
- Use common tracking for most modules.
- Use specific tracking only for selected flows that need more detail.
- Example common:
```ts
trackAction({
  prefix: "qa-server",
  module_name: "profile-view-api",
});
```
- Example specific:
```ts
trackAction({
  prefix: `qa-server:${userId}`,
  module_name: "profile-view-api",
});
```
- Best when most analytics are shared, but some flows need finer segmentation.

Option 3. Fully specific tracking
- Use a unique prefix pattern for all tracked actions.
- Example:
```ts
trackAction({
  prefix: `qa-server:${userId}`,
  module_name: "profile-view-api",
});
```
- Best when user-level or entity-level segmentation is required everywhere.

After the user selects an option:
- If the user says common usage, use a stable server/app prefix such as `qa-server`, `prod-server`, `payments-api`, or similar.
- If the user says uniqueness is needed, use `server-name:<unique-parameter>` in `trackAction.prefix`.
- Examples of unique parameters:
- `userId`
- `walletAddress`
- `accountId`
- `tenantId`
- `chainId`
- `sessionId`
- Ask which exact unique parameter should be used.

Implementation rules:
- Read the codebase before recommending exact changes when code access exists.
- If code access does not exist, ask for the relevant code or reference files.
- Keep changes minimal and aligned to the project structure.
- Initialize Redis once, never per request.
- If the project already has an `ioredis` client, prefer `statis.redis.object(...)`.
- Add `trackAction(...)` at controller/service/worker entry points where actions actually happen.
- If analytics/read endpoints are requested, use `searchKeys(...)` and `statRedis.get(...)`.
- Use stable `module_name` values such as `profile-view-api`, `swap-tx-rpc`, `login-route`, `withdraw-job`, etc.

How to respond:
- First inspect or ask questions.
- Then summarize findings and recommend the best implementation path.
- Then explicitly ask for confirmation.
- Only after confirmation should you write or modify code.
- Do not skip the questioning step.
- Do not assume standalone vs cluster.
- Do not assume common vs specific tracking.
- Do not proceed without confirmation.