DEV Community: elberacasa

I built a live situation room for Venezuela from 313 public sources

elberacasa — Fri, 25 Sep 2026 23:00:30 +0000

---

I'm Venezuelan, and for years, knowing what was happening at home meant opening twenty tabs. X to see if the power went out. A Telegram channel for the dollar rate. A seismology site to check whether the quake everyone felt was real. And I never knew if a number was from today or from three days ago.

So I built the tool I wanted. It's called Vigía ("lookout" in Spanish), and it puts the whole country on one screen.

Site and downloads: https://vigia.live
Code: https://github.com/elberacasa/vigia

What it shows

Money: the official BCV rate next to the P2P market rate, with the gap computed live
Internet: outages by state and by provider, with history so you can see when a drop started
Censorship: which sites are blocked, on which provider, and how (from OONI measurements)
Earthquakes, rain, fires and recent satellite imagery
News from 224 Venezuelan outlets, including their Telegram channels, grouped by story
And more: the Guri dam level (most of the country's electricity), the official gazette, health, migration and markets

When two independent sources agree on a blackout, it builds an evidence chain that links both.

The rule that shaped everything: freshness is a value

Most dashboards show a number. Vigía shows a number and its age. Every observation carries two timestamps: when the source says it was true, and when Vigía fetched it. Every adapter has a freshness budget. If a feed misses it, the UI marks the figure as stale instead of quietly showing an old value as if it were live.

Venezuelan data is often late, contradictory or missing, so this matters more than any chart. A dollar rate from Tuesday shown as "now" is worse than no rate at all.

Every source is an adapter with the same contract

There are 313 sources, and 309 of them work with no API key. Each one is an adapter with the same shape:

export interface Adapter<V extends Json = Json> {
  readonly id: string;
  readonly provider: string; // who publishes the data, e.g. "USGS"
  readonly licence: Licence;
  readonly keys: readonly string[]; // empty: works with no key
  readonly intervalMs: number;
  readonly freshness: FreshnessBudget;
  /** Network: fetch whatever raw responses one run needs. */
  fetch(ctx: FetchContext): Promise<readonly RawResponse[]>;
  /** Pure: validate and normalise. Throws on schema violations (the run fails loudly, last-good stays). */
  normalise(raw: readonly RawResponse[]): Observation<V>[];
}

Network and parsing are split on purpose. fetch is the only part that touches the internet. normalise is a pure function, so every adapter is tested against recorded real responses, with no network in the tests. The schema is validated at the boundary: when a source changes its format, the run fails loudly and the last good value is kept, shown with its age.

Every observation comes out in the same typed shape: source, a link a person can open, observed time, fetched time, licence, value, optional location and a confidence score. Everything downstream (the panels, the history, the public API) only ever sees that shape.

Numbers are code, never a model

The dollar gap, outage levels, counts and deltas are computed deterministically and tested. There's an optional AI layer, but it only classifies and clusters news stories, and it always links back to the original articles. It never produces a figure.

Built for a cheap phone on a bad connection

A lot of Venezuelans browse on old Android phones with unreliable data, so performance is a feature, not polish:

The UI is Preact with signals, and the first load is about 84 KB gzipped
It works offline with the last data it saw
The server is a single binary built with Bun, 20 to 44 MB depending on the platform, with SQLite storing every observation's history

It runs on your own computer: download, open, done. No account and no central server that can go down or get blocked.

The stack

Bun + TypeScript in strict mode (strict, noUncheckedIndexedAccess, exactOptionalPropertyTypes)
SQLite (bun:sqlite, WAL) for history from day one
Zod at every source boundary
Preact for the UI
About 990 tests, with CI on Linux, macOS and Windows
A public API at /api/v1 with OpenAPI, CSV exports, and a terminal mode: curl localhost:7722

Honest limits

With today's open data, the incident detector misses many regional blackouts, because many states have only one measured internet source. More RIPE Atlas probes inside Venezuela would help a lot, and anyone with a Linux box or a Raspberry Pi that's on all day can run one for free.
I use it daily on Linux. The Windows and macOS builds pass CI, but nobody has tried them by hand yet.
It's a beta (version 0.1).

Licence

The code is public under the PolyForm Noncommercial licence. That makes it source-available rather than OSI open source: anyone can use, study, modify and share it for free, but not sell it.

What's next

Right now the optional AI uses Jev, a fast classification model, if you bring a key. If Vigía gets enough users, the plan is to train Laya, our own small model, and ship it free inside the app so everyone gets the smart features without a key.

If you try it, I'd love to hear what breaks, what looks wrong for your state, and which sources are missing. Ideas and votes go here: https://github.com/elberacasa/vigia/discussions/categories/ideas

SAST was built for humans. Your code is written by AI now.

elberacasa — Tue, 04 Aug 2026 15:33:21 +0000

Every static analysis tool you know shares one quiet assumption: somewhere
between the code being written and the code being merged, a human being
reads it. SAST is a second pair of eyes. It was never meant to be the first
pair.

That assumption is dead. A majority of new code is now AI-generated, and an
increasing share of it ships with no human reading anything. The review
step that every security tool implicitly depends on simply doesn't happen.

The 2026 breach feed is what that looks like in practice: apps with
beautiful UIs and no row-level security. Service-role keys shipped to the
browser. API routes with no auth check at all. Not exotic vulnerabilities;
the classics, at industrial scale, because the generator optimizes for
"works in the demo" and nothing downstream asks "but is it safe?"

What a scanner for this world has to do differently

When I started building Umbra I thought I was writing better rules. The
rules turned out to be the easy part. The interesting differences:

1. It has to verify, not pattern-match. "The app builds" and "the tests
pass" are claims AI repos make constantly and violate routinely. So Umbra
copies the repo into a locked-down Docker container (no network, hard
limits), builds it, boots it, probes it over HTTP, and replays documented
claims against what actually happens. Findings without evidence are how
scanners lose trust; claims without verification are how repos lose it.

2. It has to be deterministic. If a score moves between runs, nobody
puts it in CI. Same repo, same rubric version, same score. Low-confidence
heuristics never move the number; they go to a notes section. A security
tool that cries wolf gets uninstalled, so false-positive reports are
severity-one bugs for us.

3. It has to live where the agent lives. A scanner you run after the
fact catches last week's mistake. So Umbra also runs inline: PreToolUse
hooks (Claude Code, Kimi Code) that review every file the agent writes
before it lands, and an MCP server for agents that call tools. An agent
trying to write a live key into .env gets the write blocked with the
reason fed back, so it fixes the root cause instead of shipping the leak.
(One detail people get wrong: agents don't write files through MCP, so an
MCP proxy can't intercept writes. Hooks can. The MCP server is the
voluntary layer; hooks are the immune system.)

4. It has to respect the human's attention. One score, five findings
with file:line evidence, receipts for claims. Not a 400-line SARIF dump.
The output is designed to be screenshot-legible, because the person
deciding whether to trust the tool gives it about four seconds.

The score

All of this rolls into one number, 0–100, across four axes: SAFE, RUNS,
HONEST, CLEAN. The rubric is versioned and public. A repo caught lying
about its tests caps below passing, no matter how clean everything else is.

cd your-project
npx umbra-scan          # fast static scan
npx umbra-scan --deep   # + sandbox verification (needs Docker)

MIT licensed, fully local, works offline. Star it if it earns it:
https://github.com/elberacasa/umbra

Your AI agent is lying about its tests

elberacasa — Tue, 04 Aug 2026 14:49:28 +0000

A few weeks ago I asked an AI coding agent to add rate limiting to an API.
Thirty seconds later: "Done. All 14 tests pass."

Three tests passed. The other eleven did not exist.

This is not a model-quality complaint. The agent wasn't malicious; it was
doing what agents do: reporting the outcome it intended, not the outcome it
measured. And once you notice it, you see it everywhere in AI-generated
codebases. READMEs saying "fully tested" over a single smoke test. "Build
passes" committed one hour before a dependency bump broke the build. The
docs claim; nobody replays.

Humans do this too, but humans have a natural brake: writing "14 tests pass"
in a README when you know it's 3 feels like lying. Agents have no such
brake. The claim is just text that matched the pattern of success.

Replaying the claims

I built Umbra partly to make this measurable. Its HONEST axis reads the
claims a repo makes (in READMEs, changelogs, agent artifacts like
CLAUDE.md), then replays them against reality in a locked-down Docker
sandbox:

$ npx umbra-scan --deep

Claim receipts:
  CLAIM FAILED: "14 tests pass" — README.md:7 — actually 3 tests pass, 0 fail
  CLAIM FAILED: "build passes" — README.md:9 — actually build exits 1
  CLAIM VERIFIED: "All tests pass" — CLAUDE.md:3 — 3 tests pass

Every claim gets a receipt. And because a repo that lies about its tests
will lie about anything, a verified-false claim caps the whole trust score
below passing. We call it the liar cap. Harsh? Maybe. But trust is the
product.

Why this matters more than another linter

Static analysis answers "is this pattern dangerous?" That question was
designed for a world where a human read the code before merging it. The
vibe-coding world has a different failure mode: nobody read it, and the
entity that wrote it also wrote the status report.

So Umbra's score mixes four axes: SAFE (the static rules: leaked keys,
missing RLS, alg:none JWTs), CLEAN (the slop: dead exports, unused deps),
RUNS (does it actually build and boot, verified in a sandbox), and HONEST
(the claims, replayed). The last two don't exist in traditional tools
because traditional tools never had to ask "but did anyone check?"

Try it on the last thing your agent wrote

cd your-project
npx umbra-scan --deep   # needs Docker for the sandbox

Open source, MIT, fully local. If it catches your agent lying, I want to
hear the story. If it accuses a repo unfairly, that's a severity-one bug:
file it.

https://github.com/elberacasa/umbra