@nurix/etna 0.20.36 → 0.20.38

package/data/harnesses/etna/skills/workflow-mapper/SKILL.md

@@ -3,144 +3,120 @@ name: workflow-mapper
 description: "Use when mapping a codebase's major workflows — traces call chains from user action to database or external system and produces mermaid sequence diagrams + markdown. Triggers on 'map workflows', 'trace flows', 'sequence diagram', 'how does X work end-to-end'."
 ---
 
-# Workflow Mapper Skill
+# Workflow mapper
 
-Identify and document every major workflow in a codebase by tracing execution paths from trigger to terminal effect. Output is a single markdown file with mermaid sequence diagrams.
+Trace every major workflow in a codebase from trigger to terminal effect, and write one markdown file of mermaid sequence diagrams.
 
----
-
-## Decision Tree
+## Modes
 
-```
-User request
-    │
-    ├─ "Map all workflows" ────────────▶ Full Discovery (all phases)
-    │
-    ├─ "Map workflow for {feature}" ───▶ Targeted Discovery (skip Phase 1 broad scan)
-    │
-    ├─ "Update workflow map" ──────────▶ Incremental (diff against existing map)
-    │
-    └─ "How does X work end-to-end" ──▶ Single Workflow Trace (Phase 2-4 only)
-```
+| Request | Mode | Runs |
+| --- | --- | --- |
+| "Map all workflows" | Full discovery (default) | Phases 1–5 |
+| "Map workflow for {feature}" | Targeted discovery | Phases 2–5, from the feature's own entry points instead of the Phase 1 broad scan |
+| "Update workflow map" | Incremental | Re-traces only workflows whose files changed against the existing map |
+| "How does X work end-to-end" | Single workflow trace | Phases 2–4 only |
 
----
+Dispatch and per-mode procedure are § Execution strategy. Load [`references/patterns.md`](references/patterns.md) at the start of Phase 1 (or of a targeted search) — it carries framework detection and the full grep/glob patterns per stack; the patterns below are the summary.
 
-## Phase 1: Entry Point Discovery
+## Phase 1: Entry point discovery
 
-Find all places where a multi-step process begins. Use parallel sub-agents — one per technique.
+Find every place a multi-step process begins, one sub-agent per technique. Adapt each pattern to the framework detected.
 
-### Technique 1: Route Harvesting
+### Technique 1: Route harvesting
 
-Scan all API route definitions. These are the primary entry points for backend workflows.
+API route definitions are the primary backend entry points.
 
 ```
-Search patterns (adapt to framework):
-  Express:    router.(get|post|put|patch|delete)\(
-  Fastify:    fastify.(get|post|put|patch|delete)\(
-  Next.js:    export (async )?function (GET|POST|PUT|PATCH|DELETE)
-  Hono:       app.(get|post|put|patch|delete)\(
-  tRPC:       .query\(|.mutation\(
+Express:    router.(get|post|put|patch|delete)\(
+Fastify:    fastify.(get|post|put|patch|delete)\(
+Next.js:    export (async )?function (GET|POST|PUT|PATCH|DELETE)
+Hono:       app.(get|post|put|patch|delete)\(
+tRPC:       .query\(|.mutation\(
 ```
 
-For each route, record: `{ method, path, handler_function, file }`.
+Record each route as `{ method, path, handler_function, file }`. Drop trivial CRUD (one DB call plus a response); keep a route that:
 
-Filter out trivial CRUD (single DB call + response). Keep routes that:
+- calls `startWorkflow`, `addJob`, `enqueue`, `emit` or `publish` (async dispatch)
+- calls two or more service functions in sequence
+- opens a transaction (`$transaction`, `BEGIN`, `withTransaction`)
+- returns a job or workflow ID for polling
+- triggers WebSocket or SSE events
 
-- Call `startWorkflow`, `addJob`, `enqueue`, `emit`, `publish` (async dispatch)
-- Call 2+ service functions sequentially
-- Have transaction blocks (`$transaction`, `BEGIN`, `withTransaction`)
-- Return a job/workflow ID for polling
-- Trigger WebSocket/SSE events
+### Technique 2: Background job discovery
 
-### Technique 2: Background Job Discovery
-
-Find all registered background jobs, workflows, and queues.
+Find every registered background job, workflow and queue.
 
 ```
-Search patterns:
-  Temporal:   export async function .*Workflow|workflowModules|startChild\(
-  BullMQ:     new Queue\(|new Worker\(|.add\(|.process\(
-  Celery:     @app.task|@shared_task
-  Inngest:    createFunction\(|inngest.send\(
-  Cron:       cron.schedule\(|@Cron\(|node-cron
-  EventEmitter: .on\(|.emit\(|EventEmitter
+Temporal:     export async function .*Workflow|workflowModules|startChild\(
+BullMQ:       new Queue\(|new Worker\(|.add\(|.process\(
+Celery:       @app.task|@shared_task
+Inngest:      createFunction\(|inngest.send\(
+Cron:         cron.schedule\(|@Cron\(|node-cron
+EventEmitter: .on\(|.emit\(|EventEmitter
 ```
 
-For Temporal specifically, also check:
-
-- `temporal/config/workflowModules.js` — workflow registry with queues and dependencies
-- `temporal/config/activityModules.js` — activity aggregation
+For Temporal, also read `temporal/config/workflowModules.js` (the workflow registry, with queues and dependencies) and `temporal/config/activityModules.js` (activity aggregation).
 
-### Technique 3: Frontend Action Tracing
+### Technique 3: Frontend action tracing
 
 Find UI-initiated multi-step flows.
 
 ```
-Search patterns:
-  Redux thunks:   createAsyncThunk\(|dispatch\(
-  API calls:      api\.(post|put|patch|delete)\(|axios\.(post|put|patch|delete)\(|fetch\(
-  Form submits:   onSubmit|handleSubmit
-  Custom hooks:   use[A-Z].*\(\) that contain API calls
+Redux thunks:  createAsyncThunk\(|dispatch\(
+API calls:     api\.(post|put|patch|delete)\(|axios\.(post|put|patch|delete)\(|fetch\(
+Form submits:  onSubmit|handleSubmit
+Custom hooks:  use[A-Z].*\(\) that contain API calls
 ```
 
-Focus on actions that:
+Keep actions that:
 
-- POST/PUT/PATCH/DELETE to backend (not just GETs)
-- Dispatch multiple Redux actions in sequence
-- Start polling loops (`setInterval`, recursive `setTimeout`, retry patterns)
-- Open WebSocket connections or listen for server-sent events
+- POST, PUT, PATCH or DELETE to the backend — **never** a GET alone
+- dispatch several Redux actions in sequence
+- start a polling loop (`setInterval`, recursive `setTimeout`, retry patterns)
+- open a WebSocket connection or listen for server-sent events
 
-### Technique 4: Event & Message Tracing
+### Technique 4: Event and message tracing
 
 Find event-driven workflows (WebSocket, pub/sub, SSE).
 
 ```
-Search patterns:
-  WebSocket:  socket.on\(|io.on\(|ws.on\(
-  SSE:        EventSource|text/event-stream
-  Redis pub:  .publish\(|.subscribe\(
-  Message:    .sendMessage\(|.postMessage\(
+WebSocket:  socket.on\(|io.on\(|ws.on\(
+SSE:        EventSource|text/event-stream
+Redis pub:  .publish\(|.subscribe\(
+Message:    .sendMessage\(|.postMessage\(
 ```
 
-### Technique 5: Scheduled & Lifecycle Workflows
+### Technique 5: Scheduled and lifecycle workflows
 
 ```
-Search patterns:
-  App startup:    app.listen|bootstrap|onModuleInit|main\(\)
-  Shutdown:       SIGTERM|SIGINT|gracefulShutdown|onModuleDestroy
-  Migrations:     migrate|seed|up\(\)|down\(\)
-  Health checks:  /health|/ping|/ready|/live
+App startup:    app.listen|bootstrap|onModuleInit|main\(\)
+Shutdown:       SIGTERM|SIGINT|gracefulShutdown|onModuleDestroy
+Migrations:     migrate|seed|up\(\)|down\(\)
+Health checks:  /health|/ping|/ready|/live
 ```
 
----
-
-## Phase 2: Call Chain Tracing
+## Phase 2: Call chain tracing
 
-For each discovered entry point, trace the full execution path. Use one sub-agent per workflow for parallelism.
+Trace each entry point's full execution path, one sub-agent per workflow.
 
-### Tracing Algorithm
+### Tracing algorithm
 
-```
-1. Start at the entry point function
-2. Read the function body
-3. For each function call or await:
-   a. Is it a DB operation? → Record as "Database" participant action
-   b. Is it an external API call? → Record as "{ServiceName}" participant action
-   c. Is it a queue/workflow dispatch? → Record as "{QueueSystem}" participant, then recurse into the dispatched handler
-   d. Is it a Redux dispatch? → Record as "Redux" participant action
-   e. Is it an internal function in the same service? → Recurse (but cap depth at 4)
-   f. Is it a WebSocket emit? → Record as "WebSocket" participant action
-4. Record branching (if/else, try/catch, switch) as alt/opt blocks
-5. Record loops (polling, retry, pagination) as loop blocks
-6. Stop when you hit: a return to the caller, a terminal DB write, or an external system response
-7. If a workflow trace exceeds the configured depth cap, stop tracing and note the overflow point with a comment like "→ [continues deeper, capped at depth N]". Do not silently truncate.
-```
+1. Start at the entry point function and read its body.
+2. Classify each function call or `await`:
+   1. DB operation → a `Database` action.
+   2. External API call → a `{ServiceName}` action.
+   3. Queue or workflow dispatch → a `{QueueSystem}` action, then recurse into the dispatched handler.
+   4. Redux dispatch → a `Redux` action.
+   5. Internal function in the same service → recurse, up to depth 4 unless the user sets another cap.
+   6. WebSocket emit → a `WebSocket` action.
+3. Record branching (`if`/`else`, `try`/`catch`, `switch`) as `alt` or `opt` blocks.
+4. Record loops (polling, retry, pagination) as `loop` blocks.
+5. Stop at a return to the caller, a terminal DB write, or an external system's response.
+6. When a trace hits the depth cap, stop and mark the overflow point — `→ [continues deeper, capped at depth N]`. **Never** truncate silently.
 
-### Participant Identification
+### Participant identification
 
-Map code actors to diagram participants using this hierarchy:
-
-| Code Pattern | Participant Name |
+| Code pattern | Participant |
 | --- | --- |
 | React component, hook, event handler | `User` + `Frontend` |
 | Express/API route handler | `API` |
@@ -155,27 +131,25 @@ Map code actors to diagram participants using this hierarchy:
 | Email/SMS send | `Notifications` |
 | Auth provider (Keycloak, Better Auth, Auth0) | `Auth` |
 
-### Branching Detection
+### Branching detection
 
-Look for conditional logic that represents meaningful workflow forks:
+Draw a block only for conditional logic that forks the workflow:
 
-```
-- Version conflicts (optimistic locking)     → alt block
-- Permission/auth checks                      → opt block
-- Feature flags                               → opt block
-- Error handling with different outcomes       → alt block
-- Retry with backoff                          → loop block
-- Polling for completion                      → loop block
-- Batch processing                            → loop block
-```
-
----
+| Condition | Block |
+| --- | --- |
+| Version conflict (optimistic locking) | `alt` |
+| Error handling whose outcomes differ | `alt` |
+| Permission or auth check | `opt` |
+| Feature flag | `opt` |
+| Retry with backoff | `loop` |
+| Polling for completion | `loop` |
+| Batch processing | `loop` |
 
-## Phase 3: Classification & Filtering
+## Phase 3: Classification and filtering
 
-Not every API route is a "workflow". Classify and filter.
+Not every route is a workflow.
 
-### Workflow Categories
+### Workflow categories
 
 | Category | Criteria | Include? |
 | --- | --- | --- |
@@ -189,22 +163,21 @@ Not every API route is a "workflow". Classify and filter.
 | **Static Serving** | File serving, asset delivery | Skip |
 | **Health/Config** | Health checks, config endpoints | Skip |
 
-### Complexity Scoring
+### Complexity scoring
 
-Score each workflow to determine diagram detail level:
+The score sets the diagram's detail: a simple workflow gets a compact diagram, a complex one full detail with `alt`/`opt`/`loop` blocks.
 
-- **Steps**: Count distinct operations (DB calls, API calls, dispatches). 1-2 = simple, 3-5 = moderate, 6+ = complex
-- **Participants**: Count distinct systems involved. 2 = simple, 3-4 = moderate, 5+ = complex
-- **Branching**: Count alt/opt blocks. 0 = linear, 1-2 = moderate, 3+ = complex
-- **Async**: Has polling, callbacks, child workflows? +1 complexity level
+| Axis | Simple | Moderate | Complex |
+| --- | --- | --- | --- |
+| Steps — distinct operations (DB calls, API calls, dispatches) | 1–2 | 3–5 | 6+ |
+| Participants — distinct systems | 2 | 3–4 | 5+ |
+| Branching — `alt`/`opt` blocks | 0 (linear) | 1–2 | 3+ |
 
-Simple workflows get a compact diagram. Complex workflows get full detail with alt/opt/loop blocks.
+Async behaviour — polling, callbacks, child workflows — raises the score one level.
 
----
+## Phase 4: Mermaid diagram generation
 
-## Phase 4: Mermaid Diagram Generation
-
-### Diagram Template
+### Diagram template
 
 ````markdown
 ### {Workflow Name}
@@ -233,22 +206,22 @@ sequenceDiagram
 - {Known edge cases or failure modes}
 ````
 
-### Diagram Rules
+### Diagram rules
 
-1. **Arrow types**: Solid (`->>`) for calls/requests, dashed (`-->>`) for returns/responses
-2. **Activation bars**: Use `activate`/`deactivate` only for long-running operations (Temporal workflows, polling loops)
-3. **Alt blocks**: Use for real workflow branching (conflict vs success), not for error handling
-4. **Loop blocks**: Use for polling, retry, batch processing — include the condition
-5. **Opt blocks**: Use for conditional steps (feature flags, optional integrations)
-6. **Notes**: Use `Note over` for context that doesn't fit in arrow labels
-7. **Participant order**: Left-to-right follows the data flow direction (User → Frontend → API → Backend → Database)
-8. **Label brevity**: Arrow labels should be ≤8 words. Use the action, not the implementation detail
-9. **Max participants**: 7 per diagram. If more, split into sub-diagrams or collapse internal services
-10. **Max steps**: 15 visible interactions per diagram. For longer workflows, group related steps or use `rect` blocks
+1. **Arrow types:** solid (`->>`) for calls and requests, dashed (`-->>`) for returns and responses.
+2. **Activation bars:** `activate`/`deactivate` **only** for long-running operations (Temporal workflows, polling loops).
+3. **Alt blocks:** for a real workflow branch whose outcomes differ (conflict vs success) — **never** for generic error handling such as a catch that rethrows.
+4. **Loop blocks:** for polling, retry and batch processing, with the condition in the label.
+5. **Opt blocks:** for conditional steps (feature flags, optional integrations).
+6. **Notes:** `Note over` for context that does not fit an arrow label.
+7. **Participant order:** left to right along the data flow — `User`, `Frontend`, `API`, backend, `Database`.
+8. **Label brevity:** arrow labels of 8 words or fewer, naming the action rather than the implementation detail.
+9. **Max participants:** 7 per diagram. Past that, split into sub-diagrams or collapse internal services.
+10. **Max steps:** 15 visible interactions per diagram. Past that, group related steps or use `rect` blocks.
 
-### Grouping Related Steps
+### Grouping related steps
 
-For workflows with many sequential same-type operations, collapse them:
+Collapse a run of same-type sequential operations into one `rect`:
 
 ```mermaid
 sequenceDiagram
@@ -259,13 +232,11 @@ sequenceDiagram
     end
 ```
 
----
-
-## Phase 5: Output Assembly
+## Phase 5: Output assembly
 
-### Output File Structure
+### Output file structure
 
-Write to the user-specified path, or default to `docs/architecture/workflows.md`. Before writing output files, ensure the target directory exists. Create it with `mkdir -p` if needed.
+Write to the user-specified path, defaulting to `docs/architecture/workflows.md`; create the target directory if it is missing.
 
 ```markdown
 ---
@@ -333,99 +304,93 @@ Auto-generated workflow map. Traces execution paths from user action to terminal
 {...}
 ```
 
-### Section Ordering
+### Section ordering
 
-1. Orchestration (the core business logic — save, publish, deploy)
-2. Authentication & Session
-3. Real-time (WebSocket, SSE)
-4. Event-driven (pub/sub, webhooks)
-5. Scheduled (cron, recurring)
-6. Data Pipeline (import/export, sync, migration)
+Sections follow the template's order — Orchestration, Authentication & Session, Real-time, Event-driven, Scheduled, Data Pipeline. Skip an empty section.
 
-Skip empty sections.
+## Execution strategy
 
----
-
-## Execution Strategy
+### Full discovery (default)
 
-### Full Discovery (default)
+1. Launch 5 parallel sub-agents for Phase 1, one per technique.
+2. Collect their results and deduplicate the entry points.
+3. Launch parallel sub-agents for Phase 2, one per workflow, at most 8 concurrent.
+4. Run Phases 3–5 sequentially in the main agent.
 
-Launch 5 parallel sub-agents for Phase 1 (one per technique). Collect results, deduplicate entry points, then launch parallel sub-agents for Phase 2 (one per workflow, max 8 concurrent). Run Phase 3-5 sequentially in the main agent.
+### Targeted discovery
 
-### Targeted Discovery
+The user names a feature; skip the Phase 1 broad scan.
 
-User specifies a feature name. Skip broad Phase 1 scan. Instead:
+1. Find the feature's directories and files — grep for the feature name in routes, components and workflows.
+2. Trace from those entry points only.
+3. Write a single-feature workflow document.
 
-1. Find the feature's directory/files (grep for feature name in routes, components, workflows)
-2. Trace from those entry points only
-3. Output a single-feature workflow document
+### Incremental update
 
-### Incremental Update
+1. Read the existing workflow map.
+2. For each workflow it lists, check whether its key files changed (`git diff`).
+3. Re-trace only the changed workflows; keep unchanged sections as they are.
 
-Read the existing workflow map file. For each workflow listed, check if the key files have changed (git diff). Re-trace only changed workflows. Preserve unchanged sections.
-
----
+## Advanced techniques
 
-## Advanced Techniques
+### Payload storage detection
 
-### Payload Storage Detection
-
-Look for patterns where large payloads are stored separately and referenced by ID:
+A large payload stored separately and referenced by ID:
 
 ```
 storePayload|savePayload|workflow_payload|jobData
 → then: retrievePayload|fetchPayload|getPayload (in the worker/activity)
 ```
 
-Note this in the diagram as a "Store payload → reference by ID" pattern.
+Mark it in the diagram as a "Store payload → reference by ID" pattern.
 
-### Optimistic Locking Detection
+### Optimistic locking detection
 
-Look for version comparison patterns:
+Version comparisons:
 
 ```
 version.*!==|version.*conflict|StaleObjectError|OptimisticLock
 if.*serverVersion.*localVersion|if.*version.*mismatch
 ```
 
-These indicate conflict branching that should appear as `alt` blocks.
+Each is a conflict branch — an `alt` block.
 
-### Polling Loop Detection
+### Polling loop detection
 
-Look for patterns where the frontend waits for async completion:
+The frontend waiting on async completion:
 
 ```
 setInterval|setTimeout.*recursive|poll|retry.*status
 GET.*status\?.*workflowId|GET.*status\?.*jobId
 ```
 
-Note the polling interval and timeout in the diagram.
+Put the polling interval and timeout in the diagram.
 
-### Child Workflow / Sub-job Detection
+### Child workflow / sub-job detection
 
-Look for spawned sub-processes:
+Spawned sub-processes:
 
 ```
 startChild\(|spawnChild|fork\(|.add\(.*queue
 Promise\.all.*map.*startWorkflow
 ```
 
-These should appear as nested sequences or separate linked diagrams.
+Draw them as nested sequences or separate linked diagrams.
 
-### Transaction Boundary Detection
+### Transaction boundary detection
 
-Look for explicit transaction markers:
+Explicit transaction markers:
 
 ```
 \$transaction|\$executeRaw|BEGIN|COMMIT|ROLLBACK
 withTransaction|runInTransaction|atomic
 ```
 
-Group operations within a transaction using `rect` blocks in the diagram.
+Group the operations inside a transaction in a `rect` block.
 
-### Rate Limiting & Middleware Detection
+### Rate limiting and middleware detection
 
-Look for middleware applied to route groups:
+Middleware applied to route groups:
 
 ```
 rateLimit|rateLimiter|throttle
@@ -433,19 +398,17 @@ authenticate|authorize|requireAuth|requireRole
 validate|validateBody|validateParams
 ```
 
-Note these as guards in the diagram using `opt` blocks or notes.
-
----
+Show each as a guard — an `opt` block or a note.
 
-## Quality Checks
+## Quality checks
 
-Before outputting, verify:
+Before writing the output, verify:
 
-- [ ] Every diagram has ≥3 participants (otherwise it's probably too simple to document)
+- [ ] Every diagram has at least 3 participants — fewer is too simple to document
 - [ ] Every diagram has both request and response arrows (no dangling calls)
-- [ ] Participant names are consistent across all diagrams (same DB = same name everywhere)
-- [ ] Alt/opt/loop blocks have clear conditions written in the block label
-- [ ] Key files listed actually exist in the codebase (verify with glob)
-- [ ] No workflow is documented twice under different names
-- [ ] Mermaid syntax is valid (no unclosed blocks, balanced activate/deactivate)
-- [ ] Table of contents anchors match actual heading anchors
+- [ ] Participant names match across all diagrams (the same DB carries the same name everywhere)
+- [ ] Every `alt`/`opt`/`loop` block states its condition in the block label
+- [ ] Every listed key file exists in the codebase (verify with glob)
+- [ ] No workflow appears twice under different names
+- [ ] Mermaid syntax is valid (no unclosed blocks, balanced `activate`/`deactivate`)
+- [ ] Table of contents anchors match the actual heading anchors

package/data/harnesses/etna/skills/workflow-mapper/references/patterns.md

@@ -1,12 +1,12 @@
-# Search Pattern Reference
+# Search patterns
 
-Concrete grep/glob patterns for each discovery technique. Agents should adapt these to the actual framework detected in the codebase.
+Load when: Phase 1 starts, or a targeted discovery searches for its feature's entry points.
 
----
+Grep and glob patterns per discovery technique. Run framework detection first, then adapt each pattern to the stack it finds.
 
-## Framework Detection (run first)
+---
 
-Identify the tech stack to select the right patterns:
+## Framework detection (run first)
 
 | Check | Pattern | Means |
 | --- | --- | --- |
@@ -22,7 +22,7 @@ Identify the tech stack to select the right patterns:
 
 ---
 
-## Route Harvesting Patterns
+## Route harvesting
 
 ### Express
 
@@ -58,7 +58,7 @@ grep: (register|plugin).*routes
 
 ---
 
-## Temporal Workflow Patterns
+## Temporal workflows
 
 ```
 # Workflow definitions
@@ -92,7 +92,7 @@ grep: continueAsNew\(
 
 ---
 
-## BullMQ Patterns
+## BullMQ
 
 ```
 # Queue definitions
@@ -112,7 +112,7 @@ grep: \.process\(|processor:
 
 ---
 
-## Redux / Frontend Action Patterns
+## Redux and frontend actions
 
 ```
 # Async thunks (dispatched actions that call APIs)
@@ -129,7 +129,7 @@ grep: dispatch\(.*Actions?\.|dispatch\(.*thunk
 
 ---
 
-## WebSocket Patterns
+## WebSocket
 
 ```
 # Socket.IO server
@@ -146,7 +146,7 @@ grep: new WebSocket\(|ws\.on\(
 
 ---
 
-## Database Patterns
+## Database
 
 ```
 # Prisma
@@ -163,7 +163,7 @@ grep: \.query\(|\.execute\(|BEGIN|COMMIT|ROLLBACK
 
 ---
 
-## External Service Patterns
+## External services
 
 ```
 # Outbound HTTP (to other services)
@@ -183,16 +183,16 @@ grep: s3\.upload|s3\.putObject|uploadToS3|writeFile.*storage
 
 ---
 
-## Workflow Complexity Indicators
+## Workflow complexity indicators
 
-Patterns that suggest a route is a real workflow (not simple CRUD):
+Patterns marking a route as a real workflow rather than simple CRUD:
 
 ```
 # Async dispatch (work happens later)
 grep: startWorkflow\(|\.add\(.*queue|emit\(|publish\(
 
 # Multi-step (sequential calls)
-# Look for functions with 3+ await statements to different services
+# Look for functions with 2+ sequential awaits to different services
 
 # Transaction blocks
 grep: \$transaction|\$executeRaw|BEGIN.*COMMIT|withTransaction

package/data/harnesses/hr/harness.json

@@ -1,7 +1,7 @@
 {
   "harness": "hr",
   "name": "hr",
-  "version": "0.1.15",
+  "version": "0.1.16",
   "files": [
     ".prettierignore",
     ".prettierrc.json",
@@ -14,5 +14,5 @@
     "origin": "https://cdn.nustack.io",
     "track": "latest"
   },
-  "digest": "fe37b9cbe966"
+  "digest": "1e97c1e90de1"
 }