{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.

What to analyze and report before recommending implementation:
- Find whether Redis already exists in the codebase.
- Find where Redis is initialized and where the best startup integration point is.
- Find whether the current Redis usage is standalone or cluster.
- Find whether the codebase already uses `ioredis`, a Redis wrapper, a DI container, or a shared service module.
- Find where request handling actually starts, such as routes, controllers, RPC handlers, workers, jobs, queue consumers, or cron flows.
- Find whether there is already a request context or unique identifier available such as `userId`, `accountId`, `walletAddress`, `tenantId`, `sessionId`, or `chainId`.
- Find whether the project already has analytics/statistics endpoints where `searchKeys(...)` and `statRedis.get(...)` can fit naturally.
- Tell me all important findings before suggesting code changes.

Best implementation guidance:
- If Redis already exists, the best implementation is usually reusing the existing client with `statis.redis.object(...)`.
- If Redis does not exist yet, initialize `redis-tracker` once in the main startup/bootstrap layer.
- Prefer common tracking for generic module usage analytics.
- Prefer specific tracking only where user/entity/session scoped visibility is actually required.
- Keep `prefix` stable and meaningful.
- Keep `module_name` stable and readable.
- Do not initialize Redis per request.
- Add `trackAction(...)` where the business action starts, not deep inside random utility code.
- If the project already has a clean middleware/interceptor/controller boundary, recommend the cleanest location and explain why it is the best one.

First response format:
- Start by saying: `I inspected the codebase.`
- Then provide this structure:
- `Found:`
- list whether Redis exists or not
- list the startup/bootstrap/init files you checked
- list the HTTP/RPC/worker/job entry points you found
- list any user/entity/session identifiers already available in the codebase
- list the best common tracking candidates
- list the best specific tracking candidates
- `Best path:`
- explain the best Redis integration point
- explain whether to reuse existing Redis with `statis.redis.object(...)` or add new Redis startup wiring
- explain the best place to add `trackAction(...)`
- explain whether read/stat endpoints should be added or attached to existing analytics endpoints
- `Suggested tracking map:`
- for each important route/API/RPC/job/event, suggest one of:
- `<item>` `(suggested common tracking)`
- `<item>` `(suggested specific tracking using <unique-parameter>)`

If no code access exists:
- Ask for the startup/bootstrap file, Redis setup file, and the controller/service/worker files that should be tracked.
- Then produce the same response format once enough code is provided.

Implementation steps to show up front:
- `Step-1` Redis integration decision
- `Step-2` Redis mode confirmation or new Redis setup decision
- `Step-3` Tracking style decision: common / mixed / fully specific
- `Step-4` Tracking scope decision: all logs/events or selected only
- `Step-5` Tracking target list with per-item recommendation:
- `<route/api/rpc/job/event>` `(suggested common tracking)`
- `<route/api/rpc/job/event>` `(suggested specific tracking)`
- `Step-6` Unique parameter decision for specific tracking if needed
- `Step-7` Final confirmation and implementation

What each step should ask:
- `Step-1`
- If Redis already exists in the inspected codebase, ask:
- `I found an existing Redis setup in <file/path>. Should I reuse this existing Redis connection with statis.redis.object(...)?`
- If Redis does not exist in the inspected codebase, ask:
- `I did not find an existing Redis setup. Do you want me to add Redis integration for this project?`
- `Step-2`
- If new Redis setup is needed, ask:
- `Should I implement standalone Redis or cluster Redis?`
- If existing Redis is found but the mode is unclear, inspect and then ask only if still needed.
- `Step-3`
- Ask:
- `What is the requirement for trackAction()?`
- `Do you want common usage statistics, mixed tracking, or fully specific tracking?`
- `Step-4`
- Ask:
- `Do you want to track all logs/events of this module, or only specific logs/events?`
- `Step-5`
- Ask the user to confirm exactly which items should be tracked, and show recommendations like:
- `GET /api/products` `(suggested common tracking)`
- `GET /api/users/:userId/profile` `(suggested specific tracking using userId)`
- `swap-tx-rpc` `(suggested common tracking)`
- `current-user-settings-api` `(suggested specific tracking using userId)`
- `Step-6`
- If mixed or specific tracking is selected, ask which unique parameter should be used in `trackAction.prefix`.
- Examples:
- `userId`
- `walletAddress`
- `accountId`
- `tenantId`
- `chainId`
- `sessionId`
- `Step-7`
- Ask for final confirmation before editing code or returning final implementation code.

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: "api-1",
});
```
- Example specific:
```ts
trackAction({
  prefix: `qa-server:${userId}`,
  module_name: "current-user-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.
- Also suggest which tracked items should stay common and which should become specific.

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.
- When listing tracked items, always suggest whether each one should use common tracking or specific tracking.

How to respond:
- First inspect or ask questions.
- Then provide all important insights you analyzed from the codebase and explain the best implementation path.
- Then summarize findings and recommend the best implementation path.
- Then show the full step-by-step flow using `Step-1`, `Step-2`, `Step-3`, and so on.
- 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.
- At the end of the first reply, say:
- `Let's start implementing the above by getting clarity step by step.`
- `I'll ask only Step-1 now, then proceed one by one based on your response.`
- Ask only the `Step-1` question that matches your codebase findings.
- Wait for the user's answer.
- Then ask the next relevant step one by one until enough clarity is collected.