BiasLens
A political-news bias analysis prototype and an experiment in AI-assisted release management.
Purpose and status
BiasLens is a political-news bias analyzer intended to help users compare coverage from multiple outlets. As of the September 6, 2026 inventory the container is running again, and its most recent recorded exit was clean rather than a forced termination.
The security review below concluded that this prototype should stay stopped until authorization denies by default. Restarting the container did not address any of those findings. The honest record is that a service with known open authorization issues is currently running on the host, reachable from the local network but not published through the reverse proxy. The earlier exit-code-137 event is retained further down because the resource question it raised was never answered either.
Architecture
The project combines a React and Vite interface with an Express server. It uses Gemini through a server-side integration, Firebase services, RSS parsing, Mozilla Readability, Cheerio, charts, Markdown rendering, image processing, and motion components.
Analysis workflow and responsibility
Media-bias analysis is an inference problem, so the interface should distinguish source facts, measured language signals, model-generated interpretation, and uncertainty. Comparisons need transparent source selection, dates, links, and an explanation of what the score can and cannot prove.
A model can assist comparison, but it should not silently become the authority on political truth. Results need provenance, repeatability, and visible uncertainty.
Release automation
The project records semantic versioning and an automated release command. The v0.1.1 report shows lint and build preflight checks, a synchronized version bump, changelog update, packaged release artifact, artifact-size check, and recommended tag.
Security and quality considerations
- Keep Gemini and Firebase administrative credentials server-side.
- Allowlist feed protocols and protect server-side fetching against internal-network access.
- Sanitize extracted and rendered article content.
- Respect publisher terms, attribution, retention, and copyright boundaries.
- Test model failure, rate limits, duplicate stories, missing sources, and misleading confidence.
Google sign-in is present, but current Firestore rules allow every read and write, the admin interface accepts any authenticated Google user, and the feed-processing operation lacks a confirmed server-side administrator check. Keep the prototype stopped until authorization denies by default and direct API/Firestore tests prove it. Read the complete review.
Hurdles and next steps
Exit code 137 often accompanies forced termination or resource pressure, but logs and host measurements are required before assigning a cause. The next recovery cycle should capture container logs, memory and CPU limits, process exit evidence, and a minimal reproduction before restarting production.
- Add a health endpoint and structured logs.
- Document source-selection and scoring methodology.
- Add unit tests for text heuristics and integration tests for feed failures.
- Remove or protect obsolete release archives and verify no secrets are packaged.