@olegkoval/agent-skills 1.74.1 → 1.75.1

package/adapters/cursor/olko-web-ops/skills/evidence-dashboards/references/design-standard.md

@@ -0,0 +1,67 @@
+# Visual and semantic standard
+
+Use these as practical defaults, not rigid styling rules. Honor the installed Grafana version and the operator's task.
+
+## Visual grammar
+
+| Evidence | Preferred form | Required context |
+|---|---|---|
+| Change over time | Thin line with points for sparse events | Unit, interval, timezone, gaps |
+| Comparable categories | Aligned horizontal bars, directly labeled | Common unit and scale, ordering |
+| Comparable entities over time | Small multiples | Shared axes and observation window |
+| Distribution | Histogram, heatmap, or measured quantiles | Buckets, population, sample count |
+| Current exception | Compact table sorted by severity or age | Entity, measured value, threshold, observation time |
+| Current condition | Restrained stat with contextual trend where available | NOW label, freshness, threshold provenance |
+| Sequential processing | Stage comparison plus delays/backlog | Stage definitions and cohort compatibility |
+
+Avoid gauges without a meaningful bound, doughnuts for precise comparisons, gratuitous icons, gradients, 3D effects, repeated decorative headings, and walls of equally prominent stats. Use tables when exact values or heterogeneous states matter more than shape.
+
+## Layout and typography
+
+Use a clear title and short subtitle for scope. Keep panel titles concrete: “Published catalog age by market” is stronger than “Health”. Place related evidence next to each other and align plot edges. Use whitespace for grouping, restrained separators, and transparent panels where the theme supports them.
+
+Aim for one principal question per panel. Keep descriptions concise; put definitions in tooltips or a small methodology panel. Do not expose implementation internals unless the operator needs them to choose an action.
+
+Do not prescribe a fixed panel count or hide useful exceptions solely to fit one screen. A dense overview should still allow readable labels and a clear investigation path.
+
+## Color and accessibility
+
+Use neutral tones for context, one consistent accent for the principal series, and restrained warning/error colors for justified conditions. Preserve series identity across panels and themes. Encode status in text or shape as well as color. Validate contrast in both themes; avoid hard-coded white backgrounds or near-black labels.
+
+Thresholds must come from a documented SLO, business rule, or explicit operator decision. If no threshold exists, show the measurement and its age rather than invent a green state.
+
+## Scales and comparisons
+
+- Start quantitative bars at zero. Never truncate bars to exaggerate differences.
+- Use consistent scales for small multiples and related comparisons. State independent scales explicitly when they are necessary.
+- Do not use dual axes unless the relationship is essential and unmistakably labeled; separate panels are usually clearer.
+- Distinguish counts, rates, ratios, latency, and elapsed age. Show the denominator for percentages and the sample count for quantiles where available.
+- Use integer ticks for small event counts and sensible precision for durations.
+- Do not stack unrelated populations. Preserve additive semantics for stacked series.
+- Avoid smoothing sparse events or joining gaps when that would imply observations.
+- Use log scales only for a defensible analytical need and label them conspicuously.
+
+## Time and completeness
+
+Choose UTC or the documented business timezone and display it. Distinguish event time, ingestion time, last successful publication, and observation time. “Refreshed now” does not prove the underlying data is current.
+
+Label partial first/last buckets. Do not compare a partial current day with a full previous day without making exposure clear. Align comparison periods by duration, bucket resolution, and population. Handle counter resets and daylight-saving boundaries according to the source semantics.
+
+Treat the following states separately:
+
+| State | Representation |
+|---|---|
+| Observed zero | Numeric 0 with normal source coverage |
+| Missing observation | Gap or unavailable label |
+| Stale source | Last observed value plus age and stale indicator |
+| Partial coverage | Observed value plus explicit coverage qualification |
+| Failed query | Visible error state, not a cached green number |
+| No matching records | Empty-state explanation tied to filters |
+
+Never apply blanket null-to-zero transformations. A missing denominator or a zero denominator does not imply a 0% rate. Do not subtract independent stage totals and call the difference “drop-off” without a shared cohort.
+
+## Query cost and maintainability
+
+Use appropriate resolution and bounded windows. Avoid per-entity request explosions, uncontrolled label cardinality, and unnecessary repeated queries. Reuse compatible query results when the tooling permits it. Preserve enough detail to diagnose outliers without placing customer identifiers or sensitive payloads in public artifacts.
+
+A successful HTTP response can still contain empty frames, null labels, stale values, or an embedded query error. Verify the rendered interpretation against source values.

package/adapters/cursor/olko-web-ops/skills/evidence-dashboards/references/roazon-playbook.md

@@ -0,0 +1,47 @@
+# Roazon and catalog operations playbook
+
+Use this when the target is Roazon or a similar scrape/import/publication pipeline. These are investigation questions, not assertions that specific metrics or endpoints exist. Discover the actual architecture and available signals first.
+
+## The central distinction
+
+Workflow completion, scraping, importing, and publication are different events. A successful run may retain a last-known-good catalog while a required source is unavailable. Show freshness of the data customers can actually read, together with coverage and the upstream reason for a delay.
+
+Do not mark a market current merely because another market or source completed. Do not replace missing data with zero products. Do not infer complete coverage from an artifact receipt or successful task alone.
+
+## Candidate views
+
+### Catalog evidence
+
+Question: Is the published catalog current and complete for the intended market/source set?
+
+Prefer a ranked freshness view by market and source, a publication timeline, and a concise exceptions table. Separate last successful scrape, completed import, publication time, and observed customer-visible version when those signals exist. Show expected versus completed source coverage only when an authoritative expected set exists.
+
+A useful exception row contains market/source, published-data age, latest upstream outcome, retained/fresh state, and a link to the relevant run or artifact. Choose thresholds from actual freshness requirements.
+
+### Pipeline flow
+
+Question: Where is work delayed or failing?
+
+Use queue depth and oldest-message age together; a small queue may still contain very old work. Show throughput, retries, dead-letter work, processing duration, and stage lag where measured. Distinguish queued, in-flight, retried, and terminal failures to avoid double counting.
+
+Compare stages only for the same cohort or clearly label them as independent activity totals. A queue drain does not establish successful publication. A retry count does not necessarily equal distinct failed items.
+
+### Customer-facing service
+
+Question: Is the service delivering useful responses?
+
+Use request rates, error rates with denominators, latency quantiles with sample context, and availability if telemetry supports them. Separate health probes from customer traffic. Connect visible service health to catalog freshness without implying that HTTP success proves data freshness.
+
+### Recent changes and investigation
+
+Question: What changed before the observed condition?
+
+Use deployment/run annotations when their times and identities are authoritative. Link to existing logs, run details, or artifacts with scoped filters. Temporal proximity is a lead for investigation, not evidence of causation.
+
+## Scope control
+
+Begin with one coherent overview. Split catalog, pipeline, and service views only when the available evidence and investigation workflow justify it. Keep stable links and existing useful dashboards.
+
+For unavailable signals, write a gap entry: operational question, missing evidence, current substitute and its limits, smallest useful instrumentation, and proposed owner. Keep that proposal separate from the authorized dashboard implementation.
+
+Never bake a NAS address, SSH account, token, Grafana organization, or current deployment version into this reusable skill. Resolve those from the target environment and current configuration.

package/adapters/cursor/olko-web-ops/skills/evidence-dashboards/references/specification.md

@@ -0,0 +1,59 @@
+# Dashboard specification and evidence record
+
+Create a concise task artifact using this template. Include only relevant sections; do not copy sensitive raw payloads into the document.
+
+## Task binding
+
+- Operator and decisions:
+- Repository / worktree / source revision:
+- Delivery boundary: specification / local implementation / pushed source / live deployment
+- Target Grafana instance, organization, folder, and discovered version:
+- Existing dashboards and stable UIDs:
+- Baseline faults and screenshots:
+
+## Panel contract
+
+Complete before implementing each panel.
+
+| Field | Required answer |
+|---|---|
+| Question | What decision does the operator make? |
+| Evidence | Exact observed metric, source, or query definition |
+| Population | Market, source, entity set, exclusions, denominator |
+| Measurement | Event counter, gauge, snapshot, histogram, or derived value |
+| Time | Event/observation timestamp, timezone, window, bucket, cadence |
+| Semantics | Unit, aggregation, reset handling, partial periods |
+| Completeness | Expected coverage, missingness, freshness rule |
+| Presentation | Chart type, series identity, scale, ordering, labels |
+| Interaction | Variables, range control, links, drill-down |
+| Failure | Zero, null, no records, stale data, query error |
+| Cost | Window limits, cardinality, query frequency |
+| Acceptance | Concrete result and evidence location |
+
+## Verification matrix
+
+| Check | Expected result | Actual result | Evidence |
+|---|---|---|---|
+| Generated source | Reproducible and current | | |
+| Panel queries | Valid frames and meaningful values | | |
+| Time controls | Query and displayed interval agree | | |
+| Scoped filters | Intended population only | | |
+| Sparse/zero/null/error | Semantics remain distinct | | |
+| Partial/stale data | Coverage and age visible | | |
+| Light/dark browser | Readable, no clipping or errors | | |
+| Laptop/desktop | Main questions remain legible | | |
+| Live definition | Matches intended deployed source | | |
+
+Use PASS, FAIL, UNAVAILABLE, or NOT_APPLICABLE. Distinguish fixture results from production observations. Record exact commands and source revisions where available.
+
+## Delivery and rollback
+
+- Changed source and generated files:
+- Tests and build:
+- Pushed commit, branch, PR, and CI if in scope:
+- Deployment method and actual live verification:
+- Backup location and exact restore method:
+- Dashboard links and sanitized screenshots:
+- Telemetry gaps and limitations:
+- Human acceptance, if performed:
+- Smallest remaining action:

package/adapters/grok/olko-web-ops/skills/evidence-dashboards/SKILL.md

@@ -0,0 +1,112 @@
+---
+name: evidence-dashboards
+description: Design, implement, and verify evidence-focused Grafana dashboards with Tufte-inspired charts, honest data semantics, and reproducible provisioning. Use for operational dashboard redesigns, clearer monitoring, or Roazon-style catalog freshness and pipeline visibility.
+license: MIT
+compatibility: Agent Skills compatible tools with repository access. Live verification requires authorized Grafana access and browser automation; use the project's existing tooling.
+metadata:
+  author: Oleg Koval
+  tags:
+    - grafana
+    - observability
+    - data-visualization
+    - dashboard-design
+    - operations
+---
+<!-- Generated by scripts/build-adapters.sh. Do not edit directly. -->
+
+# Evidence Dashboards
+
+Build operational dashboards that make the evidence legible: what happened, how much, over which period, with what coverage, and what needs attention. Deliver working charts backed by real queries and reproducible source.
+
+## When to use
+
+Activate for requests such as “redesign our Grafana dashboards”, “make the charts Tufte-style”, “show catalog freshness”, or “replace the wall of stats with useful evidence”. Use the workflow for new dashboards or an existing dashboard repair and redesign.
+
+For a design-only request, deliver the specification and identify unverified assumptions. For implementation, finish the authorized source and verification work. This skill does not independently authorize production changes, new instrumentation, credential changes, external messages, or publishing.
+
+## Working principles
+
+- Start with an operator's decision; choose a chart only after defining its evidence.
+- Prefer trends, comparisons, distributions, and exceptions over decorative summaries.
+- Make missing, stale, partial, failed, and genuine zero observations distinguishable.
+- Keep the source, time window, unit, denominator, and aggregation explicit.
+- Preserve useful detail without making the reader decode an interface.
+- Use existing telemetry honestly; record gaps rather than manufacture evidence.
+
+## Workflow
+
+### 1. Establish the actual system
+
+Read applicable repository instructions. Inspect Git status, remotes, current branch, default-branch source, and deployment provenance. Preserve unrelated work and use an isolated worktree when appropriate.
+
+Find dashboard definitions, generators, datasource provisioning, deployment scripts, checks, and existing HTTP tooling. Verify the intended Grafana instance, organization, folder, datasource UID, and plugin versions; do not infer these from a familiar hostname or an old checkout.
+
+Use existing project scripts first, then CLI, MCP, or SDK. Follow the repository's HTTP policy. Repeated HTTP inspection belongs in reusable tooling with bounded retries and persisted, access-controlled raw responses. Redact credentials and sensitive customer data; never store authorization headers or cookies in artifacts.
+
+Record a compact baseline: dashboard URLs and UIDs, source revision, visible faults, query failures, current layout screenshots, and the requested delivery boundary.
+
+### 2. Define the evidence before the layout
+
+Name the actor and three to five decisions the dashboard must support. For each proposed panel, complete the panel contract in [the specification template](references/specification.md).
+
+Inspect actual query results and producer code. Identify event counters, gauges, snapshots, histograms, and retained history; record cadence and known coverage. Confirm whether records belong to comparable populations before deriving rates or funnels.
+
+For Roazon or a catalog ingestion system, load [the catalog operations playbook](references/roazon-playbook.md). For all projects, load [the visual and semantic standard](references/design-standard.md).
+
+Drop panels that cannot answer a useful question. Classify missing instrumentation separately from dashboard defects. Do not silently expand a redesign into an observability-platform rebuild.
+
+### 3. Compose the visual argument
+
+Arrange content in reading order:
+
+1. Identity, scope, selected period, and source freshness.
+2. A small number of current conditions requiring a decision.
+3. The principal historical evidence, with context or comparable series.
+4. Ranked exceptions or stage diagnostics that explain where to investigate.
+5. Coverage, definitions, and links to existing operational detail.
+
+Use the Grafana grid and native typography. Start with a dominant trend and supporting aligned comparisons; add separate dashboards only when actors or time scales differ materially. Keep the main view understandable at an ordinary laptop viewport without shrinking labels.
+
+Apply the reference standard for scales, color, missing data, and density. Explain the proposed structure briefly and proceed with routine design choices inside the authorized scope.
+
+### 4. Implement reproducibly
+
+Edit canonical source, then regenerate outputs using repository commands. Preserve stable dashboard UIDs and useful deep links. Keep datasource secrets in the existing protected configuration boundary; dashboards contain identifiers, never bearer credentials.
+
+Use supported native panels and installed plugins. Verify unfamiliar or version-sensitive options against official documentation. Prefer a maintainable query or transform to elaborate reshaping. Inspect the actual frame fields after transformations: category labels and null values can disappear even when requests return HTTP 200.
+
+Connect every time-dependent query to the visible controls. If an API only supports trailing-day windows, expose those supported choices and ensure the chart displays the same range. Explicitly label snapshots as current even when historical controls are visible.
+
+Add focused checks for meaningful invariants: generated output freshness, stable IDs, non-overlapping grid, variable propagation, units, and unavailable-versus-zero behavior. Do not add tests that merely restate every JSON property.
+
+### 5. Verify data and appearance
+
+Run applicable generation, validation, and repository checks. Execute every panel query through its real datasource path. Inspect frame contents and transformations, not just transport success.
+
+Exercise representative data states: sparse history, a reported zero, null/unavailable, no rows, stale source, partial boundary periods, and a failed query. Use isolated fixtures where production cannot safely produce those states; label fixture evidence separately from live evidence.
+
+Verify at least two supported time windows, and scoped filters where present. Confirm the query interval, returned timestamps, displayed axis, timezone, and refresh cadence agree. Check inclusive boundaries and cumulative versus per-period interpretation.
+
+Use a real browser with an appropriate authorized user. Inspect light and dark themes at laptop and desktop widths. Check labels, units, ticks, tooltips, legends, clipping, empty/error states, navigation, and browser/network errors. Save sanitized screenshots and query evidence. API-only verification is not visual acceptance.
+
+### 6. Deploy within scope and prove the result
+
+When deployment is authorized, back up the targeted live definitions and provisioning before writing. Record the rollback location and method. Change only the relevant files or resources; avoid unrelated datasource changes and service restarts.
+
+Apply through the existing deployment workflow. Confirm the live definitions match the intended generated source, provisioned ownership is correct, every panel query succeeds, and the rendered result still passes. If verification fails, repair the scoped change or restore the backup; report the actual resulting state.
+
+If live access or authority is unavailable, complete reviewable local work and report the exact remaining gate. Do not claim deployment or visual acceptance from source tests.
+
+## Acceptance and handoff
+
+The result is ready only when the requested boundary is evidenced:
+
+- Every panel has a decision, valid source, explicit scope, and honest interpretation.
+- Trends, comparisons, and exception views use appropriate scales and units.
+- Zero, missing, stale, and partial data retain their meanings.
+- Controls alter both the requested data and the visible range as intended.
+- Source generation and applicable checks pass on the final artifact.
+- Required browser and live checks are recorded, or clearly marked unavailable.
+- Authorized deployment has a backup, verified live state, and rollback instructions.
+
+Report dashboard links, changed source, exact verification, screenshots, telemetry gaps, and rollback evidence. Keep local correctness, pushed source, CI, deployment, and human acceptance separate. Follow the host's delivery receipt and review requirements; this skill does not replace them.

package/adapters/grok/olko-web-ops/skills/evidence-dashboards/references/design-standard.md

@@ -0,0 +1,67 @@
+# Visual and semantic standard
+
+Use these as practical defaults, not rigid styling rules. Honor the installed Grafana version and the operator's task.
+
+## Visual grammar
+
+| Evidence | Preferred form | Required context |
+|---|---|---|
+| Change over time | Thin line with points for sparse events | Unit, interval, timezone, gaps |
+| Comparable categories | Aligned horizontal bars, directly labeled | Common unit and scale, ordering |
+| Comparable entities over time | Small multiples | Shared axes and observation window |
+| Distribution | Histogram, heatmap, or measured quantiles | Buckets, population, sample count |
+| Current exception | Compact table sorted by severity or age | Entity, measured value, threshold, observation time |
+| Current condition | Restrained stat with contextual trend where available | NOW label, freshness, threshold provenance |
+| Sequential processing | Stage comparison plus delays/backlog | Stage definitions and cohort compatibility |
+
+Avoid gauges without a meaningful bound, doughnuts for precise comparisons, gratuitous icons, gradients, 3D effects, repeated decorative headings, and walls of equally prominent stats. Use tables when exact values or heterogeneous states matter more than shape.
+
+## Layout and typography
+
+Use a clear title and short subtitle for scope. Keep panel titles concrete: “Published catalog age by market” is stronger than “Health”. Place related evidence next to each other and align plot edges. Use whitespace for grouping, restrained separators, and transparent panels where the theme supports them.
+
+Aim for one principal question per panel. Keep descriptions concise; put definitions in tooltips or a small methodology panel. Do not expose implementation internals unless the operator needs them to choose an action.
+
+Do not prescribe a fixed panel count or hide useful exceptions solely to fit one screen. A dense overview should still allow readable labels and a clear investigation path.
+
+## Color and accessibility
+
+Use neutral tones for context, one consistent accent for the principal series, and restrained warning/error colors for justified conditions. Preserve series identity across panels and themes. Encode status in text or shape as well as color. Validate contrast in both themes; avoid hard-coded white backgrounds or near-black labels.
+
+Thresholds must come from a documented SLO, business rule, or explicit operator decision. If no threshold exists, show the measurement and its age rather than invent a green state.
+
+## Scales and comparisons
+
+- Start quantitative bars at zero. Never truncate bars to exaggerate differences.
+- Use consistent scales for small multiples and related comparisons. State independent scales explicitly when they are necessary.
+- Do not use dual axes unless the relationship is essential and unmistakably labeled; separate panels are usually clearer.
+- Distinguish counts, rates, ratios, latency, and elapsed age. Show the denominator for percentages and the sample count for quantiles where available.
+- Use integer ticks for small event counts and sensible precision for durations.
+- Do not stack unrelated populations. Preserve additive semantics for stacked series.
+- Avoid smoothing sparse events or joining gaps when that would imply observations.
+- Use log scales only for a defensible analytical need and label them conspicuously.
+
+## Time and completeness
+
+Choose UTC or the documented business timezone and display it. Distinguish event time, ingestion time, last successful publication, and observation time. “Refreshed now” does not prove the underlying data is current.
+
+Label partial first/last buckets. Do not compare a partial current day with a full previous day without making exposure clear. Align comparison periods by duration, bucket resolution, and population. Handle counter resets and daylight-saving boundaries according to the source semantics.
+
+Treat the following states separately:
+
+| State | Representation |
+|---|---|
+| Observed zero | Numeric 0 with normal source coverage |
+| Missing observation | Gap or unavailable label |
+| Stale source | Last observed value plus age and stale indicator |
+| Partial coverage | Observed value plus explicit coverage qualification |
+| Failed query | Visible error state, not a cached green number |
+| No matching records | Empty-state explanation tied to filters |
+
+Never apply blanket null-to-zero transformations. A missing denominator or a zero denominator does not imply a 0% rate. Do not subtract independent stage totals and call the difference “drop-off” without a shared cohort.
+
+## Query cost and maintainability
+
+Use appropriate resolution and bounded windows. Avoid per-entity request explosions, uncontrolled label cardinality, and unnecessary repeated queries. Reuse compatible query results when the tooling permits it. Preserve enough detail to diagnose outliers without placing customer identifiers or sensitive payloads in public artifacts.
+
+A successful HTTP response can still contain empty frames, null labels, stale values, or an embedded query error. Verify the rendered interpretation against source values.

package/adapters/grok/olko-web-ops/skills/evidence-dashboards/references/roazon-playbook.md

@@ -0,0 +1,47 @@
+# Roazon and catalog operations playbook
+
+Use this when the target is Roazon or a similar scrape/import/publication pipeline. These are investigation questions, not assertions that specific metrics or endpoints exist. Discover the actual architecture and available signals first.
+
+## The central distinction
+
+Workflow completion, scraping, importing, and publication are different events. A successful run may retain a last-known-good catalog while a required source is unavailable. Show freshness of the data customers can actually read, together with coverage and the upstream reason for a delay.
+
+Do not mark a market current merely because another market or source completed. Do not replace missing data with zero products. Do not infer complete coverage from an artifact receipt or successful task alone.
+
+## Candidate views
+
+### Catalog evidence
+
+Question: Is the published catalog current and complete for the intended market/source set?
+
+Prefer a ranked freshness view by market and source, a publication timeline, and a concise exceptions table. Separate last successful scrape, completed import, publication time, and observed customer-visible version when those signals exist. Show expected versus completed source coverage only when an authoritative expected set exists.
+
+A useful exception row contains market/source, published-data age, latest upstream outcome, retained/fresh state, and a link to the relevant run or artifact. Choose thresholds from actual freshness requirements.
+
+### Pipeline flow
+
+Question: Where is work delayed or failing?
+
+Use queue depth and oldest-message age together; a small queue may still contain very old work. Show throughput, retries, dead-letter work, processing duration, and stage lag where measured. Distinguish queued, in-flight, retried, and terminal failures to avoid double counting.
+
+Compare stages only for the same cohort or clearly label them as independent activity totals. A queue drain does not establish successful publication. A retry count does not necessarily equal distinct failed items.
+
+### Customer-facing service
+
+Question: Is the service delivering useful responses?
+
+Use request rates, error rates with denominators, latency quantiles with sample context, and availability if telemetry supports them. Separate health probes from customer traffic. Connect visible service health to catalog freshness without implying that HTTP success proves data freshness.
+
+### Recent changes and investigation
+
+Question: What changed before the observed condition?
+
+Use deployment/run annotations when their times and identities are authoritative. Link to existing logs, run details, or artifacts with scoped filters. Temporal proximity is a lead for investigation, not evidence of causation.
+
+## Scope control
+
+Begin with one coherent overview. Split catalog, pipeline, and service views only when the available evidence and investigation workflow justify it. Keep stable links and existing useful dashboards.
+
+For unavailable signals, write a gap entry: operational question, missing evidence, current substitute and its limits, smallest useful instrumentation, and proposed owner. Keep that proposal separate from the authorized dashboard implementation.
+
+Never bake a NAS address, SSH account, token, Grafana organization, or current deployment version into this reusable skill. Resolve those from the target environment and current configuration.

package/adapters/grok/olko-web-ops/skills/evidence-dashboards/references/specification.md

@@ -0,0 +1,59 @@
+# Dashboard specification and evidence record
+
+Create a concise task artifact using this template. Include only relevant sections; do not copy sensitive raw payloads into the document.
+
+## Task binding
+
+- Operator and decisions:
+- Repository / worktree / source revision:
+- Delivery boundary: specification / local implementation / pushed source / live deployment
+- Target Grafana instance, organization, folder, and discovered version:
+- Existing dashboards and stable UIDs:
+- Baseline faults and screenshots:
+
+## Panel contract
+
+Complete before implementing each panel.
+
+| Field | Required answer |
+|---|---|
+| Question | What decision does the operator make? |
+| Evidence | Exact observed metric, source, or query definition |
+| Population | Market, source, entity set, exclusions, denominator |
+| Measurement | Event counter, gauge, snapshot, histogram, or derived value |
+| Time | Event/observation timestamp, timezone, window, bucket, cadence |
+| Semantics | Unit, aggregation, reset handling, partial periods |
+| Completeness | Expected coverage, missingness, freshness rule |
+| Presentation | Chart type, series identity, scale, ordering, labels |
+| Interaction | Variables, range control, links, drill-down |
+| Failure | Zero, null, no records, stale data, query error |
+| Cost | Window limits, cardinality, query frequency |
+| Acceptance | Concrete result and evidence location |
+
+## Verification matrix
+
+| Check | Expected result | Actual result | Evidence |
+|---|---|---|---|
+| Generated source | Reproducible and current | | |
+| Panel queries | Valid frames and meaningful values | | |
+| Time controls | Query and displayed interval agree | | |
+| Scoped filters | Intended population only | | |
+| Sparse/zero/null/error | Semantics remain distinct | | |
+| Partial/stale data | Coverage and age visible | | |
+| Light/dark browser | Readable, no clipping or errors | | |
+| Laptop/desktop | Main questions remain legible | | |
+| Live definition | Matches intended deployed source | | |
+
+Use PASS, FAIL, UNAVAILABLE, or NOT_APPLICABLE. Distinguish fixture results from production observations. Record exact commands and source revisions where available.
+
+## Delivery and rollback
+
+- Changed source and generated files:
+- Tests and build:
+- Pushed commit, branch, PR, and CI if in scope:
+- Deployment method and actual live verification:
+- Backup location and exact restore method:
+- Dashboard links and sanitized screenshots:
+- Telemetry gaps and limitations:
+- Human acceptance, if performed:
+- Smallest remaining action:

package/adapters/hermes/olko-web-ops/README.md

@@ -9,3 +9,4 @@ into the active Hermes profile. The canonical packages are:
 - `plugins/olko-web-ops/skills/search-console-indexing-audit/SKILL.md`
 - `plugins/olko-web-ops/skills/docs-index-keeper/SKILL.md`
 - `plugins/olko-web-ops/skills/website-analytics-bootstrap/SKILL.md`
+- `plugins/olko-web-ops/skills/evidence-dashboards/SKILL.md`

package/adapters/pi/olko-web-ops/README.md

@@ -5,3 +5,4 @@
 Use the canonical skills directly:
 
 - `plugins/olko-web-ops/skills/search-console-indexing-audit/SKILL.md`
+- `plugins/olko-web-ops/skills/evidence-dashboards/SKILL.md`

package/catalog/skills.json

@@ -1513,6 +1513,27 @@
             "grok",
             "hermes"
           ]
+        },
+        {
+          "name": "evidence-dashboards",
+          "lookupName": "olko:evidence-dashboards",
+          "path": "plugins/olko-web-ops/skills/evidence-dashboards",
+          "description": "Build and verify evidence-focused Grafana dashboards: honest metrics, clear charts, reproducible provisioning, and catalog operations visibility.",
+          "tags": [
+            "grafana",
+            "observability",
+            "data-visualization",
+            "dashboard-design",
+            "operations"
+          ],
+          "adapters": [
+            "claude",
+            "codex",
+            "cursor",
+            "grok",
+            "pi",
+            "hermes"
+          ]
         }
       ]
     }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@olegkoval/agent-skills",
-  "version": "1.74.1",
+  "version": "1.75.1",
   "private": false,
   "publishConfig": {
     "access": "public"

package/plugins/olko-apple-kit/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "olko-apple-kit",
   "description": "Build and ship Apple platform apps: macOS menubar apps, App Store submissions.",
-  "version": "1.74.1",
+  "version": "1.75.1",
   "author": {
     "name": "Oleg Koval"
   },

package/plugins/olko-creative/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "olko-creative",
   "description": "Creative and personal projects: photo galleries, music players, listings, wiki editing.",
-  "version": "1.74.1",
+  "version": "1.75.1",
   "author": {
     "name": "Oleg Koval"
   },

package/plugins/olko-garmin-kit/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "olko-garmin-kit",
   "description": "Build, test and publish Garmin Connect IQ watch faces.",
-  "version": "1.74.1",
+  "version": "1.75.1",
   "author": {
     "name": "Oleg Koval"
   },

package/plugins/olko-git-tools/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "olko-git-tools",
   "description": "Everyday git and GitHub CLI operations: conventional commits, branch hygiene.",
-  "version": "1.74.1",
+  "version": "1.75.1",
   "author": {
     "name": "Oleg Koval"
   },

package/plugins/olko-github-pr/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "olko-github-pr",
   "description": "Drive GitHub pull requests to merge-ready: review-bot loops, CI fixes, descriptions, dependency triage.",
-  "version": "1.74.1",
+  "version": "1.75.1",
   "author": {
     "name": "Oleg Koval"
   },

package/plugins/olko-github-pr/skills/lekker-review/scripts/eval-runner.mjs

@@ -49,6 +49,9 @@ export function caseKey(e) {
 }
 
 const SHA = /^[0-9a-f]{7,40}$/i;
+const FULL_SHA = /^[0-9a-f]{40}$/i;
+const RUN_ID = /^[A-Za-z0-9][A-Za-z0-9._-]*$/;
+const SEVERITIES = new Set(['critical', 'important', 'observation', 'idiomatic']);
 
 const isMultiRun = (v) => Array.isArray(v) && v.length > 0 && v.every(Array.isArray);
 
@@ -71,6 +74,37 @@ export function validateManifest(manifest) {
   return prs;
 }
 
+export function normalizeArchivedEvidence(entry, run, worktree, document) {
+  const key = caseKey(entry);
+  const unscored = (reason) => ({ key, reason });
+  if (typeof entry.runId !== 'string' || !RUN_ID.test(entry.runId)) return unscored('unsafe or missing runId');
+  if (typeof entry.sha !== 'string' || !FULL_SHA.test(entry.sha)) return unscored('manifest needs a full 40-character sha');
+  if (!run) return unscored('run.json missing or malformed');
+  if (run.runId !== entry.runId) return unscored('runId mismatch');
+  if (run.status !== 'ok') return unscored('run status is not ok');
+  if (!['lgtm', 'lgtm-with-changes', 'needs-work'].includes(run.verdict)) return unscored('run verdict is missing or invalid');
+  if (run.review?.name !== 'lekker-review-core' || run.review.status !== 'completed') return unscored('completed review record unavailable');
+  if (run.repo !== entry.repo || run.target !== `pr-${entry.pr}`) return unscored('run repo or target mismatch');
+  if (!worktree) return unscored('worktree.json missing or malformed');
+  if (typeof worktree.headSha !== 'string' || !FULL_SHA.test(worktree.headSha)) return unscored('worktree headSha is not a full SHA');
+  if (worktree.headSha.toLowerCase() !== entry.sha.toLowerCase()) return unscored('worktree headSha mismatch');
+  const findings = Array.isArray(document) ? document : document?.findings;
+  if (!Array.isArray(findings)) return unscored('findings.json missing or malformed');
+  if (findings.some((f) => !f || typeof f.file !== 'string' || !f.file.trim() || !SEVERITIES.has(f.severity)
+      || !(f.line === null || (Number.isInteger(f.line) && f.line > 0)))) {
+    return unscored('findings.json contains a malformed finding');
+  }
+  return { key, findings, reason: null };
+}
+
+// Validate archive references before reading any run directories.
+export function validateArchiveRunIds(entries) {
+  const duplicate = entries.find((entry, index) => entry.runId
+    && entries.slice(0, index).some(previous => previous.runId === entry.runId));
+  if (duplicate) throw new Error(`archive manifest reuses runId ${duplicate.runId}`);
+  return entries;
+}
+
 export function score(manifest, results) {
   const rows = validateManifest(manifest).map((e) => {
     const key = caseKey(e);