From af79eaf78d3e6309aac1b18b525bc1dc9f54972d Mon Sep 17 00:00:00 2001 From: Cesar-M-Diaz Date: Fri, 14 Aug 2026 20:41:19 +0200 Subject: [PATCH 1/2] fix(skills): reconcile app coverage before claiming absent tracing --- skills/ns-analyze-tracing/SKILL.md | 20 +++++++++++++++----- 1 file changed, 15 insertions(+), 5 deletions(-) diff --git a/skills/ns-analyze-tracing/SKILL.md b/skills/ns-analyze-tracing/SKILL.md index b16ae61..672318f 100644 --- a/skills/ns-analyze-tracing/SKILL.md +++ b/skills/ns-analyze-tracing/SKILL.md @@ -19,21 +19,31 @@ description: >- ### 3. Find Slow Requests Only If No Trace Was Supplied - Call `tracing`. Use pipe duration syntax (e.g., `durations="1000|5000"` for 1–5s spans); do not use dash-range syntax. - Use `functionName` only when the exact server-side function name is known. +- Treat the response as a paginated, trace-ID-collapsed sample. The default page contains 25 traces, and the summary represents only the returned page; do not treat an absent app group as proof that the app has no tracing. ### 4. Find Failing Endpoints Only If No Trace Was Supplied - Call `tracing` with `span_attributes_http_status_code` (e.g., `500`) to filter for HTTP errors. -### 5. Triage the Trace +### 5. Reconcile App Coverage Before Claiming Absence +- **Skip this step entirely if sufficient host-provided trace data is present** (step 1 already authoritatively covered it); reconciliation only applies to live `tracing` evidence. +- Build the expected app set from `information-dashboard` when it was called. Otherwise, use the authoritative app or service named by the user or identified by supplied trace data. +- Compare the expected app names with the app groups in the `tracing` summary or the `app` values in raw tracing rows. Ignore tracing metadata when building the represented-app set. +- Treat `⚠️ Partial tracing summary` as incomplete evidence. If any expected app is absent from the current global page, do not conclude that it lacks tracing. +- Re-query `tracing` once for each absent expected app, using the exact app name and preserving the original time range and filters (`durations`, status code, endpoint, and other applicable filters). Use the app-specific result to determine whether that app has matching traces. +- Only report that an expected app has no tracing after its app-specific query returns no matching traces. If that query is also partial, or reports matching traces through `metadata.total`, report the tracing evidence and its incomplete coverage instead of claiming absence. +- Do not auto-page every global tracing result. These bounded app-specific checks are the fallback for reconciling the known app inventory. + +### 6. Triage the Trace - Use `tracing` results as collapsed trace-list evidence: slow/failing service, endpoint, status, duration, and `span_traceId`. - Do not claim parent/child waterfall analysis from `tracing` alone; `tracing-detail` is not exposed as MCP. - If the user supplied the full trace tree/export, analyze `span_parentId` vs child hierarchy directly. -### 6. Propose Architectural Fixes +### 7. Propose Architectural Fixes - Once you identify a bottleneck trace row or supplied trace tree, explain the strongest supported cause. - Only discuss parent-child span relationships when the trace tree was supplied. - Propose topological changes like adding Redis caching, parallelizing independent `Promise.all` requests, or using message queues. -### 7. Present a Report +### 8. Present a Report - Emit the analysis directly in chat as markdown: - `# Tracing Analysis — ` - `## Summary` @@ -43,11 +53,11 @@ description: >- - `## Validation Plan` when a fix is proposed - Ground every claim in supplied trace data or MCP `tracing` output. State when only collapsed trace-list evidence is available. -### 8. Write the Report to Disk +### 9. Write the Report to Disk - Ask the user if they want to save the report to disk. - If the user confirms, write the final report as a markdown file (`.md`) under `.nsolid/assets/` — for example `.nsolid/assets/tracing-analysis-.md`. -### 9. Validate (only if the user deployed a fix) +### 10. Validate (only if the user deployed a fix) - If the user deployed one of the proposed fixes, re-run `tracing` with the same `durations` filter used in step 3 on the affected endpoint. - Compare the post-deployment span duration against the pre-fix baseline you recorded. State the delta explicitly (e.g. "p95 dropped from 1200ms to 80ms"). - Do not run this step unless the user reports a deployment — it is not a background check. From 0bb561fe7c6658874c6a0d86caae35cf12231336 Mon Sep 17 00:00:00 2001 From: Cesar-M-Diaz Date: Thu, 27 Aug 2026 14:15:57 +0200 Subject: [PATCH 2/2] fix(skills): scope absence claims to requested tracing filters An empty filtered app-specific query only proves no traces matched the filters. Report 'no traces matching the requested filters and time range' from that result, and require one additional bounded unfiltered query (app name + original time range) before claiming an app has no tracing. --- skills/ns-analyze-tracing/SKILL.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/skills/ns-analyze-tracing/SKILL.md b/skills/ns-analyze-tracing/SKILL.md index 672318f..217c085 100644 --- a/skills/ns-analyze-tracing/SKILL.md +++ b/skills/ns-analyze-tracing/SKILL.md @@ -30,7 +30,9 @@ description: >- - Compare the expected app names with the app groups in the `tracing` summary or the `app` values in raw tracing rows. Ignore tracing metadata when building the represented-app set. - Treat `⚠️ Partial tracing summary` as incomplete evidence. If any expected app is absent from the current global page, do not conclude that it lacks tracing. - Re-query `tracing` once for each absent expected app, using the exact app name and preserving the original time range and filters (`durations`, status code, endpoint, and other applicable filters). Use the app-specific result to determine whether that app has matching traces. -- Only report that an expected app has no tracing after its app-specific query returns no matching traces. If that query is also partial, or reports matching traces through `metadata.total`, report the tracing evidence and its incomplete coverage instead of claiming absence. +- If the app-specific query returns no matching traces, report only that the app has **no traces matching the requested filters and time range** — zero filtered rows do not prove the app has no tracing (e.g. an app with only 200 ms spans returns nothing under `durations="1000|5000"`). +- To claim an app has no tracing at all, run one additional query with only the exact app name and the original time range (no `durations`, status code, or endpoint filters). Only a non-partial empty result from this unfiltered query justifies the "no tracing" claim; if it returns traces, report that tracing exists but none matched the filters. +- If either app-specific query is partial, or reports matching traces through `metadata.total`, report the tracing evidence and its incomplete coverage instead of claiming absence. - Do not auto-page every global tracing result. These bounded app-specific checks are the fallback for reconciling the known app inventory. ### 6. Triage the Trace