DEV Community: DnyaneshU

My browser and IDE won't work until I go outside, and a model on my laptop checks that I really did

DnyaneshU — Sun, 11 Oct 2026 10:02:48 +0000

AI was going to increase our productivity. It is also apparently going to replaces the human race before I turn 24, but let's stick to the productivity part, because that part came true.

We genuinely can do ten hours of work in four now. I've watched it happen. An agent chews through a refactor that would have eaten my afternoon, and it's done before my coffee goes cold.

So here's the question nobody seems to have asked: what happened to the other six hours?

They did not become a walk. They did not become sunlight, or a conversation with a person, or a nap. They became more work. The bar moved. Ten hours of output in four hours became the new baseline, and then we filled the remaining six with more of it. We took a productivity windfall and spent all of it on more productivity.

And the cruel detail: with an agent, you're sitting more still than before. You're not even typing. You're watching a model work, waiting for a diff, reviewing output. Thirty minutes can pass where the most athletic thing you did was scroll.

I built BreakTension because I was doing exactly this and my own break reminders were useless.

🔗 github.com/DnyaneshU/BreakTension

The problem with every break reminder I've installed

They're dismissible. A notification slides in, I click it away without reading it, and I keep sitting. I knew I should get up. The reminder was never the missing piece.

What I lacked was a reason I couldn't dismiss in a quarter of a second.

So BreakTension removes the dismiss button. After 35 minutes of active screen time, every browser tab goes dark. No "later," no X in the corner. There's a task — touch a leaf and show two fingers — and a QR code.

You scan it, you walk outside, you take the photo. Gemma, running locally on your own laptop, decides whether you actually went outside or just leaned toward the window. If it passes, your browser comes back.

And because the agent-driven sitting is the worst kind, there's a VS Code extension too, sharing the same timer. Switching from Chrome to your editor is not a break.

How it works

┌─ Chrome Extension (MV3) ──────────┐
│  lock overlay + QR                │
└──────────┬────────────────────────┘
           │
┌──────────▼────────────────────────┐     ┌─ VS Code Extension ─┐
│  Node verifier server             │◄────┤  modal reminder     │
│   owns ONE shared 35-min budget   │     └─────────────────────┘
└──────────┬────────────────────────┘
           │ localhost:11434
┌──────────▼────────────────────────┐
│  Ollama · gemma4:e4b (local)      │
└───────────────────────────────────┘
      ▲
      │ https://<your-lan-ip>:8787/capture?t=<token>
┌─────┴──────────┐
│  Phone browser │  live camera only, no file picker
└────────────────┘

One laptop, one phone, same Wi-Fi. No datacenter, no account, no API key, no internet connection at any point.

The trust boundary matters: the extension never unlocks because the phone asked it to. The phone can only submit a photo against a single-use token the server minted. Only the server — which called Gemma — can emit the unlock. A forged message from a web page can't skip the capture step.

Why open models aren't a cost optimization here

This isn't a project where an open model was the cheaper option. It's one where a closed model would have been the wrong thing to build.

The data is the most invasive imaginable. To verify a break, the system needs photographs of your hands, your street, your garden — taken at intervals that reveal precisely when you're away from your desk. Uploading that continuously, all day, to someone else's server is indefensible. Running Gemma locally isn't a privacy feature bolted on afterward. It's the only version of this idea I was willing to run on my own machine.

It works where "go outside" actually takes you. Basements. Trails. The dead patch behind my building. A cloud round-trip fails exactly where the product is supposed to succeed.

Zero marginal cost bought a better design. At ~15 breaks a day, a paid vision API would make this an expensive habit — and I'd have built a cheaper, weaker check to compensate. Because inference is free, I could afford to ask the model four separate questions per photo instead of one.

That turned out to be the difference between catching the central cheat and missing it entirely.

The finding that changed everything

I assumed the hard part would be recognising "outdoors." It wasn't. The hard part was a prompt engineering failure I only caught because I tested the attack instead of the happy path.

The attack: lean over, photograph the garden through the window, never leave the chair. If that works, BreakTension is just a slow dismissible reminder with extra steps.

My first prompt asked Gemma all six questions at once — is it outdoors, is it through glass, is it a screen, was the task done, how confident are you, and why. It read beautifully.

It detected the window photo 0 times out of 5.

Asking the same model the same question alone, in one short sentence:

Where is the camera standing: outdoors in the open air, or indoors
looking out through a window? Look for a window frame, glazing bars,
or reflections on glass.

3 out of 3 detections. 0 false positives on genuine outdoor photos.

The model could always see the window frame. My long prompt was drowning the signal.

	long combined prompt	four short prompts
Window photo detected	0 / 5	3 / 3
False positives on real outdoor photos	—	0 / 3
Time per judgement	45s+ (timed out)	3–24s

The verifier now asks four short questions in sequence — outdoors? through glass? a screen? task done? — short-circuiting on the first failure. Each prompt is kept under 420 characters, because the thing that broke it was length.

A second measurement in the same vein: gemma4:e4b has a thinking mode, and leaving it on cost ~24 seconds per judgement versus ~3 seconds off, with no accuracy gain. When someone is standing in a car park waiting to be let back into their browser, that's not a tuning detail.

Then I tested it on real photographs

Everything above was measured on synthetic fixtures — gradients generated by a Python script. Those prove the model discriminates. They don't prove it copes with the noise and lighting of a real camera.

So I ran real photos through it, including the two that matter:

Photo	Expected	Result	Rejected at	Time
Hikers on rocks, backlit	pass	✅ all gates	task only	12.2s
Field and trees	pass	✅ all gates	task only	13.2s
Reading under a tree	pass	✅ all gates	task only	13.0s
Interior window, trees beyond	reject	✅ caught	`glass`	28.8s
Desk, chair, lamp	reject	✅ caught	`outdoor`	3.4s

Zero false rejections. Zero false acceptances.

The window result is worth reading closely. Gemma said the scene was outdoors — and then caught that the camera wasn't:

"The image clearly shows a window frame and glass panes. Go all the way outside."

Separating "the view is outside" from "the photographer is outside" is the entire product.

And the short-circuit pays for itself: the indoor photo rejects in 3.4 seconds on one model call, the window photo in two, while only a genuinely outdoor photo costs all four. The most common cheat is the cheapest to catch.

The bugs I only found by actually running it

The code was finished and verified before I loaded the extension in Chrome for the first time. Four things broke immediately:

The extension reported "verifier not running" while the server sat there answering requests. An MV3 service worker can't click through a self-signed certificate warning the way a tab can — its fetch just fails, silently.
It could sit "locked" with no overlay on screen and a dead button.
F5 in VS Code did nothing — I'd never written a launch.json.
The extension host timed out waiting for a debugger that never attached.

Every one is an integration or packaging failure. Verifying the code was correct told me nothing about whether the thing was runnable. Those are different questions, and I'd only been asking the first one.

The cert fix is the interesting one. The certificate exists so the phone can open its camera — getUserMedia refuses a non-secure origin over the LAN. But that cert is self-signed, and local clients choked on it. The server now also listens on plain HTTP bound to 127.0.0.1, because localhost is a secure context by specification. Phone gets TLS, extensions get loopback, nothing is exposed to the network.

The escape hatches, and why they're limited

A tool that locks your browser at the wrong moment gets uninstalled, and an uninstalled tool prevents exactly zero minutes of sitting. So there has to be a way out. But every way out is also a way to cheat:

Hatch	Limit	Why
Snooze	5 min, once per break	Long enough to finish a thought, too short to be an escape
Emergency skip	2 per day	A bad afternoon shouldn't become a bad week
In a meeting	1 hour, self-expiring	See below
Quiet hours	configurable	3am must never demand you go outside

Skipping asks twice. The second prompt names what it costs: "This spends one of your 2 skips today, and your streak resets." A one-click skip would quietly undo the only claim this product makes.

The spec originally called for detecting video calls from "active mic/camera state, not hostname sniffing." That turned out to be impossible — no Manifest V3 API exposes a page holding a microphone stream. So it's a manual toggle, which is honest and has no false positives. Its obvious weakness is that you flip it, forget, and the product goes quiet forever. That's answered with a one-hour expiry rather than left standing.

What it deliberately doesn't do

It never touches your work. The VS Code extension shows a modal and nothing else — no blocked saves, no intercepted edits, no closed editors. An editor holds unsaved thought, and a reminder that risks losing it is worse than no reminder.

The browser overlay lives in a shadow root and never touches the page's DOM, so form inputs, scroll position and unsaved text all survive a lock.

Honest limitations

This is friction, not attestation. You can stand on a balcony. The goal was never unbeatable verification — it was making cheating cost more than complying. One click became: pick up your phone, scan, walk to a door, perform a random gesture, pass four checks.
Gemma is a 6.6 GB open-weight model, not an oracle. It will sometimes reject a legitimate photo. That's why failures always explain themselves and retakes are unlimited.
Test photos were stock images, not ones I took. Said plainly because the distinction matters.
The points system is trivially cheatable. It's local, there's no server, you could edit it in devtools. It exists so skipping costs something visible — not as a deterrent.
Peer review is cut. The original design had strangers approving each other's photos. It needs a backend, identity, photo storage, and other users who exist. It also contradicts the only argument that makes this worth building. A private streak does the same job.

Try it

Prerequisites: Ollama, Node 20+, a phone on the same Wi-Fi.

1. Server (required — this is the brain)

git clone https://github.com/DnyaneshU/BreakTension.git
cd BreakTension

ollama pull gemma4:e4b      # 6.6 GB, CPU is fine
npm run server              # zero dependencies to install

You'll see:

  BreakTension server
  ├─ extension : http://localhost:8788  (loopback only)
  ├─ laptop    : https://localhost:8787
  └─ phone     : https://192.168.1.9:8787

Leave it running. Both clients talk to it.

2. Chrome extension (optional)

Open chrome://extensions
Toggle Developer mode on (top right)
Click Load unpacked
Select the extension/ folder

Pin the icon from the puzzle-piece menu. The popup shows your desk time and should say Verifier: running.

To test it immediately: open any normal website (not chrome:// — extensions can't inject there), then click the icon → Take a break now.

3. VS Code extension (optional)

code --extensionDevelopmentPath=/full/path/to/BreakTension/vscode

A second window opens with BreakTension loaded. Confirm with Ctrl+Shift+P → BreakTension — three commands should appear:

Command	What it does
`Show status`	Desk time left + which clients are live
`Take a break now`	Trigger a break immediately
`Pause or resume`	Stop counting editor time

F5 from inside vscode/ also works, but the extension host starts paused waiting for the debug adapter and can time out before activating. The command above skips that handshake.

Both at once

Run BreakTension: Show status in VS Code while the Chrome extension is running. It reports both clients sharing one budget — switching apps doesn't dodge the break.

Useful commands

node scripts/verify-image.js photo.jpg      # judge any photo from the CLI
node scripts/verify-image.js --list-tasks   # see the task pool
BT_MODEL=llava:13b npm run server           # swap the model
BT_PORT=9000 npm run server                 # change the port

The CLI is the quickest way to see the model reason:

$ node scripts/verify-image.js window.jpg
FAIL 28.8s (failed at: glass)
  outdoor=y glass=n screen=n task=n
  The image clearly shows a window frame and glass panes.
  Go all the way outside.

What I'd tell you if you build on this

Test the attack, not the happy path. My prompt looked excellent and failed 5 times out of 5 at the one job that mattered. I only found out because I built the cheat and pointed it at my own system.

And the thing nobody tells you about AI productivity: the hours it gives back don't come with instructions. If you don't decide what they're for, someone else will — and it'll be more work.

I'm going outside.

My mother couldn't read her own blood reports. So I built an AI that never invents a number.

DnyaneshU — Sun, 04 Oct 2026 15:48:23 +0000

TrueTrend: Making Medical Reports Understandable, Traceable, and Private with Open AI

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend.

🔗 Explore the product: TrueTrend

💻 Source code: GitHub Repository

The Problem: Medical Reports Contain Data. Patients Need Understanding.

Every medical test generates information. Yet for millions of patients, understanding that information remains unnecessarily difficult.

Laboratory reports are often distributed as PDFs containing clinical terminology, abbreviations, numerical measurements, and reference ranges. Understanding an individual result can be challenging. Understanding how that result has changed over months or years is even harder.

Consider a patient managing a chronic condition such as Type 2 diabetes.

Their HbA1c results may be distributed across multiple reports, generated by different laboratories, using different layouts and sometimes different units. The patient must manually locate previous results, compare values, interpret changes, and determine what questions to raise during their next consultation.

The information exists. What is missing is a reliable, accessible way to connect it.

TrueTrend addresses this gap by transforming disconnected laboratory reports into a longitudinal, understandable, and verifiable health record.

Introducing TrueTrend

TrueTrend is a privacy-first, AI-powered medical report intelligence platform designed to help individuals understand their laboratory results and track changes over time.

Built around the principle of आरोग्य वही — a personal health notebook — TrueTrend brings medical reports together into a single interface where patients can explore trends, understand measurements, and access explanations in their preferred language.

Rather than functioning as another generic AI health chatbot, TrueTrend focuses on three fundamental requirements:

Continuity: Connect laboratory results across reports and time.
Trust: Ensure that displayed values can be traced to their original source.
Accessibility: Make health information understandable through multilingual explanations and local voice assistance.

What TrueTrend Enables

1. A Unified Health Record

Import laboratory reports from different dates and providers into one personal health notebook.

TrueTrend organizes supported test results chronologically, allowing users to review their medical history without manually navigating multiple PDF attachments.

2. Longitudinal Health Tracking

View individual biomarkers across multiple tests through interactive charts.

For example, a patient's HbA1c history can be displayed as a continuous trend, even when the measurements originate from different laboratories.

Where conversion is supported, units are standardized to enable meaningful comparison.

Clinically Informed Change Detection

A numerical difference does not necessarily indicate a meaningful health change.

TrueTrend evaluates supported measurements against documented analytical variation thresholds and distinguishes between:

Real Increase: A change exceeding the applicable variation threshold.
Normal Variation: A difference within the expected variation range.
Not Compared: A reliable comparison cannot be established.

When laboratory methods, units, or available evidence do not support a dependable comparison, the platform avoids presenting an unsupported conclusion.

Multilingual Voice Assistance

TrueTrend provides concise explanations in English and Marathi, including locally generated Marathi speech.

Users can ask questions such as:

माझी साखर वाढली आहे का?

Has my blood sugar increased?

The application responds using the patient's recorded results and identifies the relevant measurements and dates.

This makes the platform more accessible to users who are less comfortable interpreting medical terminology or reading lengthy reports.

Our Core Differentiator: Every Number Must Be Verifiable

In healthcare applications, a confident but incorrect answer is not merely a technical defect. It can undermine user trust and lead to misunderstanding.

TrueTrend is built around a strict design principle:

The AI must never present a numerical medical result that cannot be verified against its original source.

Language models are useful for interpreting documents and understanding questions, but they can occasionally misread values, confuse table columns, or generate information that was never present in the source.

TrueTrend separates AI interpretation from numerical verification.

How the verification architecture works

The AI identifies candidate test names, values, dates, and units from the report.
The application independently extracts the underlying PDF text and document structure.
Each proposed result is checked against the source, including its associated test name and unit.
Unverified values are flagged for human review.
Only verified values are eligible for charts, spoken responses, and trend analysis.

Users can select a plotted result and navigate directly to the corresponding page of the original report, where the source value is highlighted.

This creates a transparent relationship between the original medical document and the information presented by the application.

Initial Verification Results

In our current sample evaluation:

34 of 34 extracted values were confirmed against their source documents.
Eight deliberately introduced incorrect values were detected.
The application includes 603 automated tests, with no network access required by the test suite.

These are initial engineering validation results, not clinical validation or a guarantee of accuracy across all laboratory formats.

Beyond Comparison: Distinguishing Meaningful Change from Measurement Noise

One of the central challenges in longitudinal health tracking is determining whether a difference between two measurements is meaningful.

Biological variation, laboratory measurement uncertainty, and testing conditions can cause values to fluctuate even when a patient's underlying condition has not materially changed.

A system that treats every numerical movement as a meaningful trend risks producing unnecessary concern and gradually eroding user confidence.

TrueTrend incorporates documented variation thresholds for supported tests and adopts a conservative comparison strategy.

Every supported threshold is linked to its research source within the codebase. When adequate evidence is unavailable, the application declines to classify the change.

The objective is not to generate more alerts. It is to provide fewer, more defensible interpretations.

Privacy by Architecture, Not Just Policy

Medical records are among the most sensitive categories of personal information.

Traditional cloud-based AI workflows can require users to transmit documents to external servers for processing. TrueTrend takes a different approach.

The application is designed to run locally on the user's computer.

Its open-weight AI model, Google Gemma 4, runs through Ollama. Report processing, storage, and analysis take place on the local machine.

This architecture provides:

No mandatory cloud account.
No external medical-report upload.
Local processing and storage.
Offline operation after the required model and voice assets have been installed.

Privacy is therefore not dependent solely on a promise in a policy document. It is supported by the system's architecture.

The application does not require users to surrender control of their medical documents to access its core functionality.

Product Demonstration

🔗 Product website: https://dnyaneshu.github.io/TrueTrend/

The product page provides screenshots, an overview of the workflow, and the underlying implementation.

Run TrueTrend Locally

The repository includes four synthetic sample reports representing multiple laboratories and document layouts. These allow users and reviewers to explore the application without uploading real patient information.

git clone https://github.com/DnyaneshU/TrueTrend
cd TrueTrend

pip install -e ".[voice]"

ollama pull gemma4:e4b
truetrend-voice install

truetrend-serve

Open:

http://127.0.0.1:8000

Create a local account and import the sample PDFs from the samples/ directory.

Processing time is approximately 30 seconds per page on the tested setup, subject to hardware and document complexity.

Why We Do Not Offer a Hosted Medical-Report Demo

A conventional hosted demonstration would require users to upload medical documents to an externally managed server.

That would conflict with one of TrueTrend's central product commitments.

Instead, we provide a product walkthrough and a reproducible local installation. This allows users to evaluate the application while keeping their medical information under their own control.

Technology and Architecture

TrueTrend combines open-weight AI with deterministic document-processing and verification components.

Technology	Role
Google Gemma 4 via Ollama	Document interpretation and question understanding
Piper	Local Marathi text-to-speech
PyMuPDF	PDF text extraction, source verification, and value highlighting
FastAPI	Application backend and API
HTML, CSS, JavaScript	Lightweight frontend

The implementation deliberately avoids a frontend build pipeline, keeping the application straightforward to install and inspect.

An Engineering Challenge: Understanding Laboratory Tables

The most difficult part of the implementation was not simply extracting text from a PDF. It was preserving the relationship between values and their corresponding test names.

PDF documents often represent tables as positioned text rather than structured rows and columns.

For example, a test named Vitamin D, 25 Hydroxy may contain the number 25 as part of the test name itself.

A naïve line-by-line extraction process can confuse that number with the actual result.

TrueTrend therefore reconstructs document content into table-like structures before attempting verification.

This structural processing is essential to maintaining the reliability of the numerical verification layer.

Why We Constrained AI-Generated Explanations

During development, unrestricted AI rewriting of Marathi explanations introduced risks such as changing numerical associations, adding unsupported qualifiers, or reversing the intended direction of a statement.

The generative rewriting feature was removed.

TrueTrend instead uses controlled, data-grounded sentence generation for its core health summaries.

The design prioritizes factual consistency over conversational fluency.

Why Open Innovation Matters

Open innovation is particularly important when developing AI products for sensitive domains.

For TrueTrend, open-weight models and inspectable software provide four essential advantages.

1. Data Sovereignty

Users can process sensitive health documents locally without requiring an external AI service to receive their reports.

2. Inspectability

Developers can examine the complete pipeline between document extraction, AI interpretation, verification, and user-facing output.

3. Auditable Reasoning

Clinical variation thresholds are linked to their research sources, allowing reviewers to inspect the basis for supported comparisons.

4. Accessibility Without Continuous Connectivity

Once the required components are installed, the core application can operate without an internet connection.

Open AI is not merely a cost-saving decision for TrueTrend. It enables a product architecture built around privacy, transparency, and user control.

Responsible Use and Current Limitations

TrueTrend is designed as a medical information organization and interpretation aid, not a diagnostic system or replacement for professional medical advice.

Its current scope includes:

Support for 15 common laboratory tests.
Comparison against the laboratory's own printed reference range.
Supported longitudinal trend analysis.
Conservative change classification.
English and Marathi explanations.

Unsupported tests are excluded rather than interpreted through assumptions.

Photographs and scanned reports require additional human verification because the source-text verification process cannot establish the same level of certainty as supported text-based PDFs.

Users should consult qualified healthcare professionals for diagnosis, treatment decisions, and interpretation of clinically significant results.

The Vision

Medical information should not become less accessible simply because it is distributed across different laboratories, technical formats, languages, or digital platforms.

TrueTrend is an effort to make personal health records more understandable without compromising the accuracy, privacy, and traceability that sensitive information demands.

Our long-term direction is to make trustworthy, local-first health intelligence accessible to individuals who need it most, particularly those managing long-term conditions and navigating medical information across language barriers.

TrueTrend: Your health history, connected. Your information, in your control.

Project and Open-Source Links

Product: https://dnyaneshu.github.io/TrueTrend/
GitHub: https://github.com/DnyaneshU/TrueTrend
Challenge: Hacktoberfest Weekend Challenge — Build for a Friend

We welcome feedback, technical review, and contributions from developers, healthcare professionals, and accessibility advocates interested in building more trustworthy open-source health technology.