This is a submission for the Presage SmartSpectra SDK Challenge.

What I Built

Most "smart" developer tools add things: another panel, another badge, another notification. I wanted the opposite. ZenDev is a developer workspace that removes friction when I am calm and adds exactly one thing when I am not: a breath.

It measures pulse, heart-rate variability, breathing and, when the SDK reports them, facial expressions and skin conductance through the Presage SmartSpectra SDK. It learns what calm looks like for me, then expresses everything else as a single relative number: a 0–100% load index. The interface cools and opens up when that number is low. When it climbs, lines loosen, the palette warms, and the bio-timeline records it.

ZenDev in flow

The part I care about most is the guardrail. A destructive command typed into the sandbox shell — rm -rf, git reset --hard, DROP TABLE — does not run while load is in strain. Instead a breathing ring appears, and the proceed button stays disabled until I have taken one full breath. The same rule is available inside VS Code through a companion extension.

Why relative, not absolute

The SDK gives absolute values — beats per minute, RMSSD in milliseconds, breaths per minute — and it is very easy to build a dashboard that tells people they are stressed. I do not think that is honest. Resting heart rate differs by tens of beats between healthy people, and HRV varies with age, fitness and the time of day.

So ZenDev spends its first ten seconds building a baseline from confident readings only. Every value after that is a difference from that baseline: each metric's delta is normalised and clamped to 0–1, then weighted into the load index. A pulse of 85 is not "high". A pulse of 85 when your calm median is 61 is a signal.

That choice changes the whole app. There is no red state by default, no score to optimise, and no population comparison. There is only "you, right now, compared to you ten minutes ago".

Demo

Watch the demo

The demo shows the app receiving live camera input, the signal rail displaying pulse, breathing rate and HRV with confidence, the load index rising above the guardrail threshold, the breathing gate, and the VS Code status bar. It also labels the one boundary clearly: the shell inside ZenDev is a simulated sandbox, while the VS Code command runs in a real terminal.

Code

Repository: github.com/Emanuelmsjv/zendev

Requirements: Node 22.12+ and a Presage API key.

git clone https://github.com/Emanuelmsjv/zendev cd zendev npm install cp .env.example .env # add SMARTSPECTRA_API_KEY npm start

There is no ZenDev account or login. Camera input needs a Presage API key; after accepting consent, the clearly labelled simulator is available without one for exploring the interface. npm run app runs the Vite dev server with hot reload. The VS Code extension lives in vscode-extension/ and installs as a .vsix; the README has the one-line commands. Camera and phone input require the Electron build.

How It Responds to Human Signals

ZenDev uses live SmartSpectra signals end to end:

  • cardio.pulseRate for pulse
  • cardio.hrv.rmssd for HRV
  • breathing.rate for breathing rate
  • face.expression for facial tension
  • eda.trace for skin-conductance slope

The last two are used when the extended face/EDA models are available. If they are not, the app retries with pulse, HRV and breathing and says which signals it is using. It never invents a missing value.

The pipeline is:

phone or laptop camera → Presage SmartSpectra SDK (breathing + cardio + face + EDA) → per-field cache with 8 s freshness, EMA smoothing with rate limits → ten-second personal baseline and weighted load index → theme, meter, signal rail, bio-timeline, terminal guardrail, VS Code status bar

Two implementation details mattered more than I expected.

Partial payloads. The SDK emits different metrics on different frames. Dropping the last packet when hrv is missing made the meter jump. Each metric now carries its own timestamp and confidence, and a value is reused for up to eight seconds before it is shown as missing. A stale number is labelled, never invented.

Two time constants. Load rises faster than it falls: a 1.2 s attack and a 5 s release. A single bad frame no longer repaints the app, and the guardrail does not flap.

The response is visible in real time. The palette, line height and letter spacing interpolate with load. The signal rail exposes the live SDK output instead of hiding it behind a single score. The bio-timeline marks commits, runs, phase changes and guardrail events. In VS Code, the extension reads the current load from a guard-state file and shows one status-bar item; if the file is older than fifteen seconds, the item disappears so a dead app never leaves a stale number behind.

The guardrail is deliberately easy to bypass. It is a speed bump for the version of me that types git reset --hard at 96% load, not a security control.

Guardrail

Prize Categories

I am entering both:

  • Most Creative or Delightful Use. The workspace does not display a stress dashboard and ask me to interpret it. It changes how the editor feels, then turns a destructive command into a breathing pause. The unexpected part is that the reward for a high reading is not more data — it is a moment of stillness.
  • Best Thoughtful Real-World Use. Developers already lose work to rushed destructive commands. ZenDev addresses that moment with a personal baseline, visible live signals, explicit consent, local-only processing, and a deletion path that removes stored data. It is designed for one person at one desk, not for surveillance or medical decision-making.

Consent and Data Handling

Camera access is opt-in. On first run, ZenDev shows a consent screen that explains what it reads, what leaves the machine, and what it keeps. The camera and phone options remain disabled until the consent checkbox is ticked and an API key is present; the simulator is available after consent without a key. The app shows a visible LIVE, PHONE or SIMULATED indicator while a session is running.

What leaves the machine. ZenDev does not upload camera frames or measured metrics. The SDK contacts Presage only to authenticate the API key, validate the subscription, and fetch on-device models when needed. Metric computation runs on-device. SDK telemetry is explicitly disabled with enableTelemetry: false, so no session summaries or device-readiness reports are sent. There is no optional AI service.

What is stored. Consent state, settings (including the API key), and a rolling session trace of the latest 3,600 samples plus commit markers live in the app's local storage profile. The desktop app also writes a small guard-state file to ~/.zendev/guard.json and to its Electron userData directory so the VS Code extension can read the live load. That file contains only load, phase, confidence, threshold and timestamps. Exports are written only when the user chooses a path.

Retention and deletion. There is no server-side retention. Local data stays until it is deleted. Delete data stops the session, clears ZenDev's local storage, and removes both guard-state files. Deleting data does not revoke the API key with Presage; that is done in the Presage account.

This is a relative-arousal experience, not a diagnosis or treatment tool. A high number means "different from your baseline", not unwell. No reading is used for medical decision-making, and nothing is monitored without the user starting the session.

Built for the Presage SmartSpectra SDK Challenge. If you try it, tell me whether the breathing gate feels like a pause or like a punishment — that is the part I am least sure about.