Saturivo

Find the limits. Fix the bottlenecks.

Local-first load testing and evidence-driven concurrency diagnostics inside Visual Studio Code.

by ArmoTuSitio

Overview · Capabilities · Quick start · Go diagnostics · Security · Español

---

Published stable version: 0.3.1. Source version Saturivo 0.4.1 ships the 0.4.0 correctness, privacy and first-run diagnostics improvements plus a release-pipeline fix; 0.4.0 was tagged but never published. It is not published until exact-SHA PR CI, squash merge and the protected release pipeline complete. The icon, branding, Control Center layout and visual styling are preserved. No third-party certification is claimed.

Saturivo 0.4.0 — reliability and onboarding (candidate)

• History integrity: malformed or truncated reports no longer consume valid retention slots or hide valid evidence behind a fixed scan cutoff. Corrupt files remain untouched until explicitly deleted.
• Strict HTTP evidence: when status-class counters exist, they must reconcile with the observed request count; invalid or contradictory counters and dropped-iteration values fail closed.
• Private WebSocket diagnostics: URL query parameters are redacted from Markdown reports and the extension's output channel, without changing the actual authorized target.
• New opt-in Check setup action: detects local k6 and optional Go versions, checks URL policy and provides an ES/EN setup report without contacting the target or launching a load test.
• Compatibility: historical JSON schemas, scenario semantics and all prior user-facing actions are preserved. A local setup check does not verify the remote environment or service health.

First-run diagnostic (no traffic)

Open Control Center → Check setup (Spanish: Verificar instalación), or use the command Saturivo: Check Local Setup (No Load). The report shows local tool availability, the configured target's safety-policy status, official installation guidance and any missing prerequisite. After setup, run Smoke manually against an authorized disposable service. Go is optional; k6 is needed for load tests.

Read the technical audit, upgrade roadmap and 0.4.0 verification checklist.

Saturivo 0.3.0 — engineering upgrade

The 0.3.0 candidate strengthens execution correctness and release governance without changing the observed load-testing semantics:

• Exclusive execution lifecycle: the run slot is reserved synchronously before modal dialogs, preventing concurrent k6 / Go operations and allowing cancellation to release it deterministically.
• Typed cancellation: cancellation is independent of the literal error message, including subprocess aborts.
• Consistent safety bounds: scenario input, validation and persisted evidence share the same workload limits.
• Evidence hardening: WebSocket summary reads use bounded, single-link, file-identity-checked access.
• Accurate identification: k6 and WebSocket probes derive their User-Agent version from the packaged manifest.
• Release safety: executable paths cannot be overridden by workspace settings; automated publication validates protected main and the exact seven green PR CI jobs without depending on a second human deployment reviewer. All seven CI job names are versioned in the branch ruleset.
• Verification: deterministic property tests, explicit lifecycle regression tests and measured coverage thresholds for the core and lifecycle.

0.3.1 is already published. The 0.4.0 candidate adds one setup action using existing Control Center button styles; current 0.3.0 screenshots remain historical, explicitly synthetic UI evidence. There are no logo, color, typography or layout redesigns.

Control Center — Saturivo 0.3.0

Saturivo opens its Control Center in a full editor tab, with a workspace for scenario design, recorded performance evidence, comparisons and Go concurrency diagnostics.

These screenshots were captured in headless Chromium from the extension's actual production dashboard renderer (src/ui/html.ts) at version 0.3.0, using a deterministic synthetic documentation fixture. Metrics are illustrative; they are not results of a real benchmark. The screenshot process never starts a load test or contacts a remote target. The four 1480 × 960 PNGs are checked into the PR as versioned assets. Capture and browser-check evidence.

Overview — inspection at a glance

Explore the other Control Center views — Scenario Studio, History and Go diagnostics

Scenario Studio — bounded workload design and live preview

History — saved evidence, comparisons and run inspection

Go diagnostics — opt-in runtime investigation

Reproduce the images: npm ci --ignore-scripts && npm run build && npm run screenshots:readme. The capture generator runs browser interaction checks before writing screenshots. It produces control-center-{overview,load,history,diagnostics}.png locally; the screenshots committed for 0.3.0 use versioned filenames to avoid mixing them with older releases.

A workflow designed for developers

The Control Center is more than a set of commands: it guides setup, bounded execution, comparison and investigation. The Scenario Studio provides a live workload preview, readable safety budgets, interactive ramp editing, and preset cards that can be customized without starting traffic. Results include an accessible exact-value table and clear evidence limitations.

The dashboard uses VS Code theme tokens, responsive layouts, keyboard navigation, and reduced-motion support. Preview and selection are local interactions; only an explicit run action can begin a workload.

Why Saturivo?

Load generators can tell you that latency increased. Saturivo helps keep the evidence needed to investigate what changed: the workload, latency distribution, failure rate, server-side Go behavior, and baseline.

Instead of replacing mature load engines, Saturivo orchestrates Grafana k6, selected Go tooling, and locally stored measurements in one developer workflow.

Question	What Saturivo provides
Is my API behaving well under controlled traffic?	Manual, bounded HTTP load scenarios with P50/P95/P99, requests/sec, error rate and dropped iterations
Did my change degrade performance?	Scenario fingerprints, local history, descriptive comparisons and optional repeated-trial P95 uncertainty
Are goroutines or locks involved?	Opt-in Go pprof capture, observed goroutine states and go tool pprof output
Does my code exhibit an observed data race?	go test -race, source-linked VS Code diagnostics and SARIF export
Can I reproduce and share the measurement?	Stored JSON evidence, Markdown reports and explicit workload/environment metadata

Capabilities

Area	Implemented in source (0.3.1 release candidate)	Important boundary
Load testing	k6 presets, ramping VUs, and a bilingual editor for bounded v2 HTTP GET/HEAD workloads	HTTP(S) GET/HEAD only; local target by default
Metrics & SLOs	RPS, failures, P50/P95/P99, dropped iterations; configurable P95 SLO	Single-run status is not a statistical confidence guarantee
Comparisons & capacity pilot	Workload SHA-256, explicit baseline choice, 3-vs-3 P95 bootstrap, bounded literal-loopback arrival-rate pilot	Evidence is local and scenario-specific; not a production capacity guarantee
WebSocket probe	Explicit local ws:// loopback handshake/message probe backed by k6, with a fixture-backed E2E gate	Session duration is not HTTP latency; 5 seconds, 1 VU, 100 attempts; remote WebSocket targets are blocked
Go concurrency	Race detection, benchmarks, CPU/heap/goroutine/mutex/block profiles, Go runtime trace and before/during/after stack observations	Tests only inspect executed paths; no automated root-cause proof
Evidence	Markdown/JSON export; SARIF for observed Go race findings	Profiling files and reports may contain sensitive project information
Developer experience	Full editor-tab Control Center launched from Activity Bar, ES/EN interface, scenario form persistence, explicit cancellation and history deletion	No background stress testing; trusted workspaces only

Experimental bounded capacity pilot: up to three explicitly authorized loopback arrival-rate steps with a P95 SLO; passing rates do not certify production capacity. Saturivo includes isolated warm-up/measurement/cool-down for v2, 3×3 regressions with uncertainty, Go race source evidence, pprof/trace/GC observations, real fixture-backed HTTP Go/Node/Python and bounded RFC6455 WebSocket. Not implemented or not verified: general gRPC/ghz, language-specific profilers Node/Java/Python, WSL/SSH/Dev Containers E2E and BYO AI. See roadmap.

Quick start

Prerequisites

• Visual Studio Code 1.99+ (development and integration baseline).
• Grafana k6 installed and available on your PATH. See the official installation guide.
• Go (optional) for race detection, benchmarks and pprof analysis.
• Node.js 22+ and npm for building this extension from source.
• Git access to the public Saturivo source repository.

Build and install the 0.4.0 candidate from source

git clone https://github.com/Drako01/saturivo.git
cd saturivo
git switch feat/saturivo-0.4.0-reliability-onboarding
npm ci --ignore-scripts
npm run verify
npm run package:vsix

Open VS Code → Extensions: Install from VSIX… → select saturivo.vsix. To debug the extension instead, open the repository in VS Code and press F5 to launch an Extension Development Host.

First measurement in five steps

1. Start a disposable, authorized local API (for example, http://127.0.0.1:8080/health).
2. Click the Saturivo Activity Bar icon. The Control Center opens; opening the view never starts traffic.
3. Choose Configure Target. Set the explicit local endpoint.
4. Run Smoke (1 virtual user), Bounded Stress (up to 20 VUs) or Arrival Rate (25 attempted iterations/sec, bounded by available VUs). Each operation is user-initiated and can be cancelled.
5. Inspect P95/P99, RPS, failures, dropped iterations and run history. Repeat comparable scenarios, choose Compare Runs and select an explicit baseline before exporting evidence.

Custom scenarios: the Load Testing section includes a v2 editor for bounded GET/HEAD traffic (constant VUs, arrivals and ramp stages), with the current authorized target, per-run request limit and an optional P95 objective. Optional warm-up/cool-down windows exclude setup and recovery requests from the measured P50/P95/P99, HTTP error rate, RPS and SLO, while request budgets still apply across the whole run. Input is validated again inside the extension. WebSocket: the separate local-only probe explicitly asks for a ws:// loopback endpoint and confirmation; its report shows session and handshake metrics, not HTTP request latency.

Experimental local capacity pilot: first configure a P95 SLO, keep the target on a literal loopback HTTP address (for example http://127.0.0.1:8080/health), then explicitly choose Local Capacity Pilot. It attempts 10, 20 and 40 arrivals/s at most, with three 10-second stages, resource budgets and stop-on-SLO/inconclusive behavior. Review the evidence in the output channel and run history. This is not a production capacity benchmark.

For more reproducible before/after analysis, keep hardware, runtime, target configuration and scenario identical across runs. A scenario SHA-256 identifies the workload; it is not a substitute for matching every environmental factor.

Configuration

Use Settings → Extensions → Saturivo or settings.json:

{
  "saturivo.target": "http://127.0.0.1:8080/health",
  "saturivo.k6Path": "k6",
  "saturivo.durationSeconds": 10,
  "saturivo.maxVirtualUsers": 100,
  "saturivo.maxRequests": 10000,
  "saturivo.sloMaxP95Ms": 250,
  "saturivo.allowRemoteTargets": false,
  "saturivo.goProfilerOrigin": "http://127.0.0.1:6060/"
}

Setting	Default	Behavior
saturivo.target	http://127.0.0.1:8080/	HTTP(S) target. Prefer a disposable local endpoint
saturivo.k6Path	k6	Executable resolved from PATH or an explicit path
saturivo.durationSeconds	10	5–120 seconds
saturivo.maxVirtualUsers	100	Hard ceiling, 1–100; built-in stress presets use up to 20
saturivo.maxRequests	10000	Hard request budget, 100–100000; capacity interpretation becomes inconclusive if hit
saturivo.sloMaxP95Ms	0	Optional P95 objective; 0 disables the objective
saturivo.allowRemoteTargets	false	Remote traffic is disabled unless explicitly enabled and confirmed for each run
saturivo.goProfilerOrigin	http://127.0.0.1:6060/	Local literal-loopback net/http/pprof endpoint; profiling always opt-in

Interpreting the results

• P95 / P99 describe measured request latencies, not an unconditional production SLO guarantee.
• RPS is achieved HTTP throughput for the measured workload.
• Dropped iterations indicate a failure to sustain the requested arrival rate; do not confuse them with server-side errors.
• PASS / FAIL / INCONCLUSIVE evaluate configured objectives and evidence quality. A request budget hit or insufficient sample count can make a result inconclusive.
• Repeated trials: after at least three compatible runs per group, Saturivo can estimate uncertainty for the change in median run-level P95 using a deterministic bootstrap. This is useful evidence, not a causality proof.

See Performance measurement methodology.

Go diagnostics

Saturivo uses the local Go toolchain and runtime evidence, not AI guesses.

Data races. Choose Go Race Detector to run go test -race ./... after explicit confirmation. Observed race locations appear in Problems and can be exported as SARIF. No findings means no race was observed in exercised paths, not that the program is race-free.

Benchmarks. Choose Go Benchmarks to execute go test -run ^$ -bench . -benchmem ./.... Running project tests can execute arbitrary project code; Saturivo always asks first.

Runtime profiling. Expose net/http/pprof only on a local loopback listener for an explicitly authorized development service. In Saturivo, set the origin, select Capture Go Profile, choose CPU, heap, goroutine, mutex or block, and confirm. Captured artifacts are saved locally. Binary profiles can be summarized with go tool pprof; goroutine stack snapshots show observed states but do not certify leaks.

Privacy note: pprof dumps, stack traces, diagnostic paths and exported run metadata may reveal internal code or system information. Do not publish them without review and redaction.

Security & privacy

Saturivo is built local-first and permission-first:

• No implicit load generation or background profiling.
• Local/loopback HTTP targets by default; remote load requires an explicit setting and per-run confirmation.
• HTTP load supports read-only methods, redirects are disabled and test duration, VUs and request counts are bounded.
• Bounded subprocess output, cancellation, deadlines and process termination; no shell expansion for external tool arguments.
• Go profiling is restricted to literal loopback origins, without credentials or redirects, and with time/size limits.
• Untrusted/virtual workspaces are not supported; the Control Center Webview has a Content Security Policy.
• No built-in telemetry, automatic cloud upload or AI data transfer. Publication uses the auditable .github/workflows/publish.yml pipeline and must pass independent deployment-environment gates.

Never stress a third-party or production service without explicit authorization. Even bounded load can impact a local database or downstream systems; use synthetic data and isolated dependencies.

Read the security policy and privacy policy.

Architecture

Visual Studio Code / Control Center (ES/EN)
            |
       explicit action + consent
            |
  target validation / workload bounds
            |
   +--------+--------------------+
   |                             |
Grafana k6 runner            Go toolchain / pprof
   |                             |
HTTP metrics / SLO       Race findings / profiles
   |                             |
   +-----------+-----------------+
               |
      local evidence & history
               |
      compare / JSON / MD / SARIF

• src/extension.ts — VS Code lifecycle, commands, consent and diagnostics
• src/ui/ — Webview Control Center and translations
• src/core/ — validated scenarios, bounded execution, k6/Go adapters, statistics and evidence formats
• test/ and scripts/ — deterministic unit tests, isolated local k6/Go fixtures and real VS Code host checks

Design decisions and limitations are in ARCHITECTURE.md.

Engineering quality

Saturivo's quality gates combine strict TypeScript, Node unit/property tests, real k6 HTTP/WebSocket fixtures, Go race/pprof tests, real VS Code Extension Host 1.99, Chromium interactions, and Windows/macOS/Linux VSIX installation and upgrades. The candidate enforces measured coverage thresholds (core ≥90% and RunLifecycle ≥80%) and binds releases to a single exact commit tree.

Verified historical baseline: CI #42431627015 and release CI #42431868619 validate the previously published 0.2.2 tree, not the present 0.3.0 candidate.

Current source candidate: 0.4.0 on feat/saturivo-0.4.0-reliability-onboarding — consult the new PR and its exact-head CI before merging. The 0.4.0 evidence checklist separates unexecuted manual, remote-host, assistive-technology and distribution checks. Prior green CI is not evidence for this candidate.

Development commands:

npm ci --ignore-scripts
npm run typecheck
npm test
npm run verify
npm run package:vsix
# Requires k6 and a local fixture; CI sets it up explicitly:
npm run test:integration:k6
# CI also runs real Go/Node/Python k6 and WebSocket fixtures:
npm run test:integration:runtimes
npm run test:integration:websocket
# Requires a VS Code download / GUI-capable environment:
npm run test:integration:vscode

The source repository is public. The package manifest does not use a private-repository flag. 0.3.0 publication to Marketplace, Open VSX or GitHub Releases is a separate, explicitly approved release decision, gated by the exact CI-verified source tree, immutable tag and verified reviewer-protected deployment environments. This PR does not publish an extension.

Project documents

Document	Purpose
Enterprise AAAA Master Plan	Architecture, delivery phases and measurable Definition of Done
0.3.0 release checklist	Current acceptance evidence, blockers and owner-only administrative actions
Status / Roadmap	Current implementation vs. planned features
Architecture	Components, boundaries and current technical limitations
Methodology	Load models, comparison, measurement caveats
Acceptance criteria	Measurable test and release gates
Security / Privacy	Threat boundaries, sensitive evidence and safeguards
Contributing / Changelog	Development standards and change history
Governance / Rulesets	Contribution decisions, protected branches/tags and activation status
Code of Conduct / Support	Public community standards and support channels

Community and contribution

Saturivo's source is now public and MIT-licensed. Contributions are welcome through issues and focused pull requests. Before contributing, review the contribution guide, Code of Conduct, security disclosure policy and governance rules.

Repository protection: Protect main and Protect release tags were active at the 0.2.2 audit baseline. The versioned 0.3.0 policy requires all seven CI checks and strict update checking; live application is not yet verified. Deployment-environment and security settings require separate owner configuration. See rulesets and governance.

---

Saturivo · Engineering evidence over guesswork
Developed by Alejandro Daniel Di Stefano — ArmoTuSitio
MIT License · Documentación en español