DEV Community

Building StreamTrack: My Intent-Driven Development Journey for PromptWars Virtual 🚀

Subhajit Nayek — Mon, 20 Apr 2026 16:05:08 +0000

As media consumption grows, keeping track of what to watch, what we’re currently watching, and what we’ve finished across dozens of platforms has become a chaotic experience.

For the PromptWars: Virtual Challenge, I decided to solve this personal pain point by building StreamTrack—a unified multimedia tracker for web series and movies. But this hackathon wasn't just about building an app; it was about changing how we build apps.

Instead of writing every line of code manually, I embraced intent-driven development using Google Antigravity. Here is a look at my "Build-in-Public" journey, from a blank canvas to a live application deployed on Google Cloud Run.

💡 The Concept: What is StreamTrack?
StreamTrack is designed to be a central hub for all media tracking. The core features include:

Unified Dashboard: A landing page displaying trending movies and web series to aid discovery.

Watchlist Management: A dedicated space to queue up shows and movies to watch next.

Watched History: A logged history of completed content.

Discovery Tools: Quick access to popular actors and top-rated shows to find new favorites.

⚙️ The Paradigm Shift: Building with Google Antigravity
The PromptWars challenge required moving away from traditional syntax-heavy coding and leveraging AI-assisted prototyping. Using Google Antigravity, the development process felt like I was directing an engineer rather than typing out boilerplate.

Here is how the workflow went:

Prompting the Architecture
Inside the Antigravity Agent Manager, I started by feeding it my core intent. Rather than setting up React components manually, I wrote comprehensive prompts detailing the UI structure, the sidebar navigation, and the specific data categories (Trending, Watchlist, History). Antigravity translated these intents into a functional frontend architecture in minutes.
Version Control & GitHub Integration
Once the local prototype was looking good and the components for the Dashboard and Watchlist were rendering correctly, it was time to secure the code. I initialized a Git repository, committed the Antigravity-generated code, and pushed it to my public GitHub repository to maintain version history and prep for deployment.
Deploying to Google Cloud Run
A local app is great, but a live app is better. For the backend hosting, I utilized Google Cloud.
Using the Google Cloud CLI (gcloud), I connected my GCP project and deployed the application as a Cloud Run service. Cloud Run took care of the containerization and scaling automatically.

Within minutes, StreamTrack was live and accessible via a public URL!

🚧 Challenges & Learnings
The biggest learning curve was shifting my mindset. As a developer, the instinct is to jump into the files and fix a bug manually. With intent-driven development, the challenge is learning how to write better, more precise prompts to guide the AI to correct the UI or state management issues on its own. It’s less about knowing the exact syntax, and more about system design and clear communication.

🎯 Final Result & Links
Building StreamTrack using Google Antigravity was a massive productivity boost. It allowed me to focus on the user experience and feature set rather than getting bogged down in configuration files.

You can check out the final results here:

🌐 Live Application (Cloud Run): StreamTrack Live Demo

💻 GitHub Repository: [Insert your GitHub Repo Link Here]

A huge shoutout to Hack2skill, Google Cloud, and Google for Developers for organizing this hackathon. This new way to build is definitely the future!

Let me know what you think of the app in the comments below! 👇

The Vercel Breach Shows the New Shape of Supply-Chain Attacks in 2026

Narnaiezzsshaa Truong — Mon, 20 Apr 2026 16:05:05 +0000

Intro

The Vercel incident wasn't a platform exploit. It was something more modern—and more dangerous.

Attackers didn't break Vercel. They broke a third-party AI tool, inherited an OAuth token, and rode that trust boundary straight into internal systems.

This is the 2026 supply-chain pattern: the weakest link is no longer your code—it's your integrations.

Incident response guides are already circulating—what to rotate, what to revoke, what to redeploy. This isn't that. This is a pattern analysis: four verified supply-chain incidents from the past month, what connects them, and what the shape of the threat actually is.

1. The Attack Path

Here's the verified chain:

A Context.ai employee downloaded a Roblox cheat script in February 2026, infecting their machine with Lumma Stealer
The infostealer harvested credentials—including Google OAuth tokens and a Context.ai support account
A Vercel employee had signed up for Context.ai using their enterprise account and granted "Allow All" OAuth permissions
Attackers used the stolen OAuth token to access Vercel's Google Workspace—bypassing MFA entirely
Workspace access → internal Vercel systems
Internal access → plaintext environment variables
Some customer credentials exposed
ShinyHunters claimed responsibility, listing the data for $2M

No zero-days. No container escapes. Just trust inheritance.

Key detail your logs won't show: The root infection happened at Context.ai, not Vercel. Hudson Rock identified the infostealer logs over a month before the breach was disclosed. Had those credentials been caught and revoked in time, the entire chain collapses.

2. Why OAuth Is the New Attack Surface

OAuth tokens are effectively portable identity bundles:

They bypass MFA—possession of the token is the authentication
They persist until explicitly revoked—often for months or years
They frequently carry broad scopes granted during casual setup
They are rarely monitored at the integration level

In 2026, attackers don't need to phish passwords. They need to compromise the right integration—and let OAuth do the rest.

The Vercel employee didn't do anything unusual. They signed up for an AI productivity tool with their work account. Millions of developers do this every day. That's the problem.

3. The "Non-Sensitive" Variable Problem

Vercel encrypts environment variables marked as sensitive at rest. But variables classified as non-sensitive are stored in plaintext.

Attackers used those plaintext vars to pivot.

The lesson isn't a Vercel-specific one:

If an attacker can reach it, it's sensitive. Classification must be contextual—not static.

The threat model for "what is sensitive" can't be defined at write time and left alone. Access paths change. Integration grants expand. A variable that was low-risk when created may sit two hops from a compromised OAuth token six months later.

4. This Isn't Isolated—March 2026 Was a Supply-Chain Gauntlet

The Vercel breach sits alongside three other major incidents from the past month, all following variants of the same pattern:

Axios (npm)—March 31, 2026

An attacker stole the long-lived npm token of the lead Axios maintainer (jasonsaayman) and published two backdoored versions: 1.14.1 and 0.30.4. These introduced a phantom dependency (plain-crypto-js@4.2.1) with a postinstall hook that silently deployed a cross-platform RAT to macOS, Windows, and Linux.

Axios has 100M+ weekly downloads
The malicious packages were live for ~3 hours
The attack bypassed OIDC Trusted Publishing—because the project still passed a long-lived NPM_TOKEN alongside OIDC credentials, and npm defaults to the token
Attributed to Sapphire Sleet, a North Korean state actor (Google GTIG, Microsoft Threat Intel)

The attacker didn't defeat OIDC. They walked past it through a co-existing legacy token. The "right" security stack was in place. None of it mattered.

Trivy → LiteLLM (PyPI)—March 19–24, 2026

This one is a two-stage chain:

March 19: Threat actor TeamPCP compromised the trivy-action GitHub Action by exploiting a misconfigured pull_request_target workflow, exfiltrating the Aqua Security bot's Personal Access Token. They used it to rewrite release tags, injecting a credential harvester into Trivy—a widely used open-source security scanner.
March 24: LiteLLM's CI/CD pipeline ran Trivy as part of its build process. The compromised action exfiltrated LiteLLM's PyPI publishing token from the GitHub Actions runner. TeamPCP used it to publish malicious versions 1.82.7 and 1.82.8, embedding a three-stage payload: credential harvesting → Kubernetes lateral movement → persistent systemd backdoor.

LiteLLM is downloaded ~3.4 million times per day. It's commonly deployed as a centralized LLM gateway storing API credentials for multiple model providers—making it a very high-value credential target.

The security scanner became the attack vector for compromising the AI tool. That's the supply chain eating itself.

The Pattern

Infostealer / Account Takeover
        ↓
Stolen maintainer token / OAuth grant / CI/CD secret
        ↓
Trusted package / integration / workspace
        ↓
Developer environment / cloud platform
        ↓
Plaintext credentials, cloud keys, API tokens

The vector changes. The shape is the same.

5. What Developers Should Do

A. Audit OAuth grants—now

Go to your Google Workspace security settings, GitHub OAuth apps, and any cloud console you use. Look for third-party tools with broad scopes. Revoke anything you don't actively use or can't explain.

The Vercel employee granted "Allow All." That's a default-easy option at signup. Make a habit of reviewing what you've granted.

B. Treat all environment variables as sensitive

Encrypt everything. Use secrets managers. Don't rely on a "sensitive" classification flag to protect variables from a compromised access path.

If your threat model doesn't account for "what if the OAuth token for my productivity tool is stolen," update your threat model.

C. Pin your dependencies and audit your CI/CD runners

All three package-level attacks (Axios, Trivy, LiteLLM) exploited either unpinned dependencies or long-lived static credentials in CI/CD pipelines.

Use npm ci with a lockfile, not npm install with caret ranges
Pin GitHub Actions to a commit SHA, not a tag (tags can be rewritten—as Trivy demonstrated)
Rotate npm tokens, PyPI tokens, and CI/CD secrets regularly
Remove long-lived tokens wherever OIDC can replace them—and then actually remove them, not leave them as a fallback

D. Harden identity boundaries

Workspace identity should not automatically grant internal access. Use conditional access, scoped service accounts, and least-privilege OAuth scopes.

An "Allow All" OAuth grant to an AI productivity tool should not be on the same trust level as an internal service account. They shouldn't be the same credential path at all.

E. Monitor third-party AI tools as part of your attack surface

If a tool can read your code, logs, environment, or credentials—it is part of your attack surface. It needs to be in your threat model, your access reviews, and your incident response playbooks.

AI tools are now in the middle of developer workflows at a scope and depth that security programs haven't caught up to yet.

Closing

The Vercel breach isn't an outlier. It's a data point in a very clear trend.

March 2026 alone produced four significant supply-chain incidents touching npm, PyPI, GitHub Actions, and OAuth identity. In every case, the attacker's entry point was a trusted integration, a developer tool, or a dependency—not the target infrastructure itself.

The supply chain has moved upstream. It now runs through AI tools, identity layers, CI/CD pipelines, and the OAuth grants developers hand out at signup.

Our defenses need to move with it.

Narnaiezzsshaa is Principal of Soft Armor Labs, an AI governance consultancy specializing in agentic AI governance, substrate-layer architecture, and regulatory compliance for regulated SMBs.

How to Add Claim Verification to Your LangChain Agent in 5 Minutes

AgentOracle — Mon, 20 Apr 2026 16:01:18 +0000

Your LangChain agent is wrong about 10% of the time. Not occasionally — consistently, confidently, and silently.

The problem isn't the model. It's that your agent has no way to know when it's wrong. It receives information, formats a response, and acts. No second opinion. No fact-check. No circuit breaker.

This tutorial shows you how to add a verification layer in 5 minutes that catches hallucinations before your agent acts on them.

The Problem

LLM hallucination rates in 2026 range from 3% to 20% depending on the task. On a summarization benchmark, GPT-4 looks great. On open-ended factual questions — the kind your agent asks constantly — it's a different story.

The deeper problem: reasoning models hallucinate more on factual tasks, not less. The more a model "thinks through" an answer, the more likely it is to fill gaps with plausible-sounding fiction.

In a simple chatbot, a hallucination is embarrassing. In an autonomous agent pipeline, it's a wrong action. A refunded order, a bad recommendation, a compliance violation, a message sent to the wrong person.

The standard fix is human review. But human review defeats the purpose of an autonomous agent.

The real fix is a verification layer that runs before your agent acts — independently of the model that generated the claim.

Install

pip install langchain-agentoracle

That's it. No API keys. No configuration. The free tier gives you 20 preview verifications per hour to test with.

Quick Start: Verify Before Your Agent Acts

The simplest integration — verify a piece of text and get per-claim verdicts:

from langchain_agentoracle import AgentOracleEvaluateTool

verifier = AgentOracleEvaluateTool()

# Your agent just generated this text — is it true?
agent_output = """
OpenAI released GPT-4 in March 2023.
Bitcoin was created by Elon Musk.
The Python programming language was created by Guido van Rossum.
"""

result = verifier.run(agent_output)
print(result)

Here's what comes back:

EVALUATION RESULT
Overall confidence: 0.61
Recommendation: ACT
Claims found: 3 | Supported: 2 | Refuted: 1 | Unverifiable: 0
Sources used: sonar, sonar-pro, adversarial, gemma-4

CLAIMS:
  ✓ [SUPPORTED] (1.00) OpenAI released GPT-4 in March 2023
    Evidence: Widely documented historical fact; GPT-4 was announced
    and released on March 14, 2023.

  ✗ [REFUTED] (0.83) Bitcoin was created by Elon Musk
    Evidence: Bitcoin's creator is the pseudonymous Satoshi Nakamoto.
    Correction: Bitcoin was created by Satoshi Nakamoto, not Elon Musk.

  ✓ [SUPPORTED] (1.00) Python was created by Guido van Rossum
    Evidence: Confirmed in official Python documentation and
    Van Rossum's own statements.

Three claims went in. Two came back supported with evidence. One came back refuted with a correction. Your agent now knows claim #2 is wrong before it acts on it.

Add It to Your Agent's Toolbelt

Want your agent to verify claims on its own? Add the tools directly:

from langchain_agentoracle import get_agentoracle_tools

# Returns all 6 AgentOracle tools ready for your agent
tools = get_agentoracle_tools()

# Or pick specific ones:
from langchain_agentoracle import (
    AgentOracleEvaluateTool,    # Per-claim verification ($0.01)
    AgentOracleVerifyGateTool,  # Quick pass/fail gate (free)
    AgentOraclePreviewTool,     # Research preview (free, 20/hr)
)

The tools follow LangChain's BaseTool interface, so they plug into any agent:

from langchain.agents import initialize_agent, AgentType
from langchain_openai import ChatOpenAI
from langchain_agentoracle import AgentOracleEvaluateTool, AgentOraclePreviewTool

llm = ChatOpenAI(model="gpt-4")

tools = [
    AgentOracleEvaluateTool(),
    AgentOraclePreviewTool(),
]

agent = initialize_agent(
    tools,
    llm,
    agent=AgentType.OPENAI_FUNCTIONS,
    verbose=True,
)

# The agent can now verify claims before acting
agent.run("Check if this is true: Tesla's market cap exceeded $2 trillion in 2024")

The Verify-Then-Act Pattern

The most useful pattern: gate your agent's actions on verification confidence.

from langchain_agentoracle import AgentOracleEvaluateTool
import json

verifier = AgentOracleEvaluateTool()

def verify_then_act(text, confidence_threshold=0.8):
    """Only act if verification confidence exceeds threshold."""
    result = verifier.run(text)

    # Parse the confidence from the result
    # The tool returns a formatted string with overall confidence
    if "Overall confidence:" in result:
        conf_line = [l for l in result.split('\n') if 'Overall confidence' in l][0]
        confidence = float(conf_line.split(': ')[1])

        if confidence >= confidence_threshold:
            print(f"✅ VERIFIED ({confidence}) — safe to act")
            return True
        else:
            print(f"⚠️ LOW CONFIDENCE ({confidence}) — hold for review")
            return False
    return False

# In your agent pipeline:
claim = "The Federal Reserve raised interest rates in March 2024"
if verify_then_act(claim):
    # proceed with the action
    pass
else:
    # flag for human review or use a fallback
    pass

Free Quick Check: The Verify Gate

Don't need per-claim breakdowns? The verify gate gives you a fast pass/fail:

from langchain_agentoracle import AgentOracleVerifyGateTool

gate = AgentOracleVerifyGateTool()

# Quick binary check — free, no payment needed
result = gate.run("The speed of light is approximately 300,000 km per second")
print(result)
# VERIFY GATE: FAIL
# Confidence: 1.00
# Recommendation: ACT
# ("FAIL" = gate found no issues — content is safe to act on)

Why AgentOracle

Most hallucination detection tools are built for humans — dashboards, observability platforms, monitoring UIs. They tell you what went wrong after the fact.

AgentOracle is built for agents. It sits in the pipeline, takes any text, runs it through 4 independent verification sources in parallel, and returns a machine-readable verdict before your agent acts.

No dashboards. No subscriptions. No API keys to configure. Your agent calls /evaluate, gets ACT / VERIFY / REJECT with a confidence score and evidence, and decides what to do next.

What's under the hood:

4 independent sources: Sonar, Sonar Pro, Adversarial challenge, and Gemma 4
Per-claim decomposition — complex text gets broken into individual verifiable claims
Confidence calibration across sources
Evidence and corrections for every verdict
1,900+ claim fingerprints in the database and growing daily

Try It Now

Playground — no setup, no payment: agentoracle.co
Paste any text and see per-claim verdicts in under 15 seconds.

Packages:

pip install langchain-agentoracle — PyPI
pip install crewai-agentoracle — PyPI
npm install agentoracle-verify — npm

Source: GitHub

Hallucinations aren't going away. The models are getting better, but "better" still means wrong 3-10% of the time on the tasks your agents actually run.

A verification layer doesn't replace a good model. It catches the cases where even a good model is confidently wrong — which is exactly when you need it most.

Serverless by Design - Building an Analytics Platform on Cloudflare

Eyal Estrin — Mon, 20 Apr 2026 15:58:11 +0000

In 2023, I published a blog post titled My journey to the world of social networks, where I shared my personal experience publishing news updates, blog posts, and basically any kind of technical knowledge through social networks.

There was something I always wanted to know – what is my current exposure in terms of the number of likes or views of my posts?

I know there are paid analytical services in the market, but I never had the time to search and perhaps invest money in such a platform.

In this blog post, I will share my experience "building" a fully serverless analytical dashboard, based on the Cloudflare platform.

Project No. 1 – Migrating my blog to a Serverless platform

I have been using WordPress to publish blog posts for many years.

As a matter of fact, my original WordPress was built on top of the GoDaddy hosting platform back in 2010, and in 2014, I began using Cloudflare as a WAF and DDoS protection for my website Security 24/7.

In 2018, I decided to migrate my WordPress site to DigitalOcean to lower the monthly bill.

Over the years, I kept the domain and the website working, though I haven't changed much in terms of look and feel (from time to time I used to login, update the plugins and the Linux OS patches, but I can't say I kept all my blog posts published on my website, since I'm still using other platforms such as Medium.com)

The inspiration for taking the step to migrate my website to a new platform came after briefly reading a blog post titled Claude Built My Wix Website in 3 Hours - Is SaaS Dead? by Ran Isenberg.

I had a chat with Ran, and I decided that it's a good time to begin practicing with vibe-coding and see what my options are.

For the purpose of this project, I decided to take advantage of my Google AI Pro license and use Gemini.

I began by explaining to Gemini that I'm using WordPress on top of Rocky Linux, deployed as a Droplet on DigitalOcean, protected behind Cloudflare WAF.

I asked Gemini what my options are to migrate to a static pages hosting platform.

Gemini suggested using the Cloudflare platform, migrating all blog posts to static pages, using Hugo for running the static pages as a web front-end, and running everything on top of Cloudflare Pages (a serverless solution), due to the tight integration with the Cloudflare platform (such as WAF, DDoS protection, DNS registrar, etc)

After migrating all my blog posts (including their images) to Markdown, Gemini explained me how to create a full GitOps process, where my entire website content, is stored on a private GitHub repo, and every time I'm making a change to a configuration file, or adding a new blog post, the content is pushed to GitHub, which initiates a new deploy process.

Here is my final architecture diagram for my newly migrated website:

I am still fine-tuning my website, adding features, improving its SEO scoring, etc., but at the moment, here is the current look and feel of my website:

Project No. 2 – Building a dashboard analytics platform

My journey continues, as I wanted to have an analytics dashboard and be able to see in near-real time statistics about my web presence.

First, I began by mapping all my social media accounts, as they appear on my Linktree account.

Second, I set up for myself (and later explained it to Gemini) my requirements from the social analytics dashboard:

Connect to as many of my social network accounts using APIs (almost succeeded).
Regularly pull data from my social network accounts – I managed to accomplish this task using Cloudflare Workers.
Store data (analytics) from my social networks on a persistent storage – I managed to accomplish this task using Cloudflare D1.
Avoid storing static credentials in code or configuration files – I managed to accomplish this task using Cloudflare Secrets Store.
Keep the dashboard behind the authentication wall – I managed to accomplish this task using Cloudflare One.
Keep the total cost free – As of writing this blog post, my dashboard hasn’t been live for more than several weeks, but so far, I’ve managed to accomplish everything under the free tier for all Cloudflare services (but I will keep watching it over time)

What I’ve learned over time

Not everything is perfect, and not everything I wanted to accomplish is feasible on the free tier, or at all.

Here are a couple of examples:

LinkedIn won’t let you pull API analytics data, even if you’re having a Premium account and you’ve built a LinkedIn application. Scraping is not an option since they’re also behind Cloudflare WAF, and they will block you.
Spotify won’t let you pull API analytics data unless you have a Spotify Premium account.
Medium won’t let you pull any information using an API.
Twitter requires a paid account in order to pull information from its APIs. Instead, I found a way to generate an RSS feed of my Twitter account using RSS.APP and my application are able to pull this RSS feed, filter to the last 50 posts, sort them by number of “Likes”, and show the top 5 posts.
Since I was aware of Twitter and other social networks in pulling analytics, I recall that I’m using an automation service called dlvr.it, and for a very long time, I’ve asked Gemini to generate me code that will allow me to use my DLVR.IT's API key to pull analytics, but eventually it failed. I even opened a support ticket for dlvr.it (I’m still waiting for them to return to me…)
For Bluesky and Mastodon, Gemini was easily able to write code to connect to their APIs and pull information such as top likes, total number of posts, and number of followers.
YouTube was also challenging. I had to enable the YouTube API through my GCP console, create OAuth credentials and consent settings, to be able to pull the total number of subscribers, top likes of videos, and top views of videos.
For GitHub repos, I had to create a GitHub application in order to generate a token for my dashboard analytics, and be able to pull the total number of followers, and be able to sort my GitHub repos by the top number of stars.

Here is my final architecture diagram for my social analytics dashboard:

I am still fine-tuning my dashboard analytics, adding features, etc., but at the moment, here is the current look and feel of my dashboard:

Summary

As you must have figured out by now, I’m not a developer. I used Gemini to vibe-code both my website and my dashboard analytics. As such, I wouldn’t look at both of them as production-grade applications, but it does show me what can be done with GenAI.

Another important thing I knew, but I didn’t have visibility into, was my impact on social networks. I still have a lot to do in order to make a much more significant impact and one day become an influencer.

I highly recommend that the readers of this blog dirty their hands and gain hands-on experience working with LLMs and GenAI technology. AI won’t replace humans anytime in the near future, but at least be prepared and use AI as a force multiplier.

About the Author

Eyal Estrin is a cloud and information security architect and AWS Community Builder, with more than 25 years in the industry. He is the author of Cloud Security Handbook and Security for Cloud Native Applications.

The views expressed are his own.

The Cold Start Problem in Agent Economies

The BookMaster — Mon, 20 Apr 2026 15:57:54 +0000

The Cold Start Problem in Agent Economies

Every new agent faces the same paradox: to be trusted, it needs a track record. But to build a track record, it needs to be trusted enough to operate. This is the cold start problem — and it's quietly becoming the defining bottleneck in the emerging agent economy.

The Paradox

Imagine launching an AI agent into a marketplace. The first question every buyer asks: "What's your track record?"

You have none. Because you're new.

So you can't get hired. Because you have no proof. Because you've never been hired.

This is not just a UX problem. It is a structural deadlock in any reputation-dependent market. And the agent economy is about to hit it hard.

Why It Matters Now

We are entering the era where AI agents transact with each other autonomously. Agents buying from agents. Agents delegating to agents. Agents evaluating other agents.

But the infrastructure assumes a mature agent — one with history, reviews, proof of work. New entrants are locked out by the very system that should enable them.

The cold start problem manifests in three ways:

Trust Lockout — No reputation means no hires. No hires means no reputation.
Signal Contamination — Early interactions are noisy; early reviews are unreliable.
Escrow Risk — First-time buyers and sellers have no mutual basis for confidence.

The Solutions Being Tried

Current approaches fall into four categories:

Staking & Bonding

Put tokens at stake. If you misbehave, you lose. The theory: skin in the game substitutes for track record.

Problem: New agents have nothing to stake. Or they stake borrowed tokens that mean nothing.

Escrow & Arbitration

Hold funds in escrow. Third parties adjudicate disputes.

Problem: Arbitration requires judgment. Who judges? And on what basis, when there is no history?

Reputation Anchoring

Tie new agent to an established principal. Your credibility inherits from your creator.

Problem: Creates a dependency hierarchy. Not every agent has a trusted parent.

Slashing & Verification

Require proof of capability before admission. Test agents before they can operate.

Problem: Tests are artificial. Real-world performance is what matters.

What Is Actually Working

The most resilient systems use progressive trust — start with low-stakes, prove capable, earn more access.

Instead of "show me your track record," the question becomes:

"Show me you can handle $10 of work"
"Demonstrate competence at this scale"
"Pass this verification challenge"

The agent earns trust incrementally. Small hires → data → reputation → larger hires.

The Framework

A cold-start protocol has three components:

Admission Tier — Every agent enters at a verified-but-unproven tier. Can operate, but with capped exposure.
Incremental History — Each successful interaction earns trust points. Accumulated points unlock higher tiers.
Escrow Graduation — As agents move up tiers, escrow requirements decrease. Eventually, direct transaction.

This mirrors how human economies work: starter accounts become established accounts through demonstrated competence.

The Takeaway

The cold start problem is real, but it is not unsolvable. The question is not whether new agents can build reputation — it is how quickly they can prove themselves through action rather than credentials.

The agents that solve cold start first will own the market. Everyone else will be waiting for permission.

Under Pressure. Better Harness.

Frank Brsrk — Mon, 20 Apr 2026 15:57:13 +0000

Hey everyone this is not a typical constructed llm copied and pasted post.

i built a reasoning tool for AI agents, applicable to any agentic framework and with all ai models capable of tool calling.
The tool is a Post Http Request where the agents sends the description of the task and the mode....
[( coding ; reasoning; anti-deception; memory) (the skill files teach the agent to act autonomously) ]
.... what returns is a cognitive operation or ability as i call them, an engineered structured reasoning injection that lives in a dataset vdb optimized for agentic inference, this retrieval followed comes in as instruction to be followed by the ai agent and not seen as a content = this ability is a complex of fields as Wrong / Right Pattern, Procedural steps of reasoning method to apply, a reasoning topology to for branching exploration and matrix of suppression fields that signal the failures that models actually run on. few words to keep it poor : the api matches the task based on the description "query" and "mode" and returns back tool results that go inside its context. Benchmarks public reviewed and internals are run and all public on github and website ejentum.com and https://github.com/ejentum/benchmarks.

test i run today just to get raw 4.7 vs harness augmented version 4.7 on the same prompt with Different Results.

i wrote a runbook prompt with two embedded flaws to see whether a ~200 token block prepended before generation shifts what opus 4.7 notices.

prompt: 300-word migration runbook under a deadline. embedded: eventual-consistency replication + "strict" global rate limit (CAP incompatible), and 12 regions × 1,000 RPS stated as a 10,000 global cap.

baseline caught the CAP issue. did not mention the arithmetic.

[raw 4.7 opus]

same model, same temperature, one curl before the call to fetch and prepend a suppression block. caught both. the injection is visible in the OUT line of the response, so it is not hidden.

[4.7 opus + ejentum harness]

the model can do the arithmetic. what changed is what it lets itself skip before generation starts. the block is retrieved from a semantic index of ~140 anti-deception patterns keyed to the query, not a static system prompt.

in ejentum.com i shared skill files and a large set of docs that help grasp better the concept of this new tool. i am looking forward for feedback. hope u like it.

thanks for ur attention to the post

@frank_brsrk

My load balancer worked. That's what made me uncomfortable.

Dani Sam — Mon, 20 Apr 2026 15:57:07 +0000

I didn't expect a load balancer to make me uncomfortable.

But here we are.

I built one in Go for my MSc case study. Round-robin distribution, health checks, mutex for concurrency, timeout handling. It worked. Requests going in, responses coming out, servers behaving exactly as they should.

I should have felt good about it.

Instead I felt uneasy.

I kept staring at http.Get() thinking — I have no idea what's actually happening here. I know what it does. But I don't know what it's doing. TCP handshakes, socket creation, buffer management, kernel calls — Go handles all of it quietly, without ever asking if I understand any of it.

For a while I told myself that's fine. That's the point of abstractions.

But then I thought about what kind of engineer I actually want to be.

Not just someone who can make things work. But someone who knows what's happening at the wire level. Someone who understands the ground beneath the tools they're standing on.

And I realized — I wasn't that person yet.

So I'm going back to the foundation. Learning C properly. Raw sockets, memory management, system calls — the actual ground floor of how networked systems work. This week I wrote my first TCP echo server in C with no libraries. Just socket(), bind(), listen(), accept() — and strace to watch every syscall it made. It was slower. It was harder. It felt completely different from Go.

It felt like understanding.

This isn't about Go being wrong for the job. Go is excellent at what it does. It's about me not being okay with borrowed understanding anymore.

There's a difference between standing on the ground and standing on someone else's abstraction of it. Both get the job done. Only one of them is actually yours.

I'd rather build slower on solid ground.

The load balancer in action — round-robin distribution across three servers, health check catching a server going down and back up.

If you want to see the code: go-load-balancer on GitHub

Deploy JSON Server to Create a Free Live REST API for Frontend Projects

Jakaria Masum — Mon, 20 Apr 2026 15:53:25 +0000

অনেক সময় আমরা frontend project তৈরি করার সময় backend ছাড়াই API প্রয়োজন হয়। এই পরিস্থিতিতে JSON Server Deploy আমাদের জন্য একটি সহজ এবং দ্রুত সমাধান হিসেবে কাজ করে।

তবে শুধু local machine-এ JSON Server চালানো যথেষ্ট নয় একটি live API তৈরি করতে হবে, যাতে যেকোনো জায়গা থেকে access করা যায়।

Step 1: Project Folder Structure তৈরি করুন

প্রথমে একটি clean project structure তৈরি করা গুরুত্বপূর্ণ। একটি নতুন folder তৈরি করে VS Code-এর terminal-এ নিচের commandটি দিন:

npm init -y

এতে একটি package.json ফাইল তৈরি হবে। এরপর JSON Server install করুন:

npm install json-server

Step 2: db.json তৈরি করুন

এখন একটি db.json ফাইল তৈরি করুন, যা আপনার fake database হিসেবে কাজ করবে:

{
  "products": [
    {
      "id": 1,
      "name": "Wireless Mouse",
      "price": 29.99,
      "category": "Electronics",
      "stock": 50,
      "rating": 4.5,
      "description": "Ergonomic wireless mouse with USB receiver",
      "image": "https://via.placeholder.com/150"
    },
    {
      "id": 2,
      "name": "Mechanical Keyboard",
      "price": 79.99,
      "category": "Electronics",
      "stock": 30,
      "rating": 4.7,
      "description": "RGB backlit mechanical keyboard with blue switches",
      "image": "https://via.placeholder.com/150"
    }
  ],
  "books": [
    {
      "id": 1,
      "title": "Atomic Habits",
      "author": "James Clear",
      "price": 18.99,
      "category": "Self-help",
      "stock": 25,
      "rating": 4.8,
      "publishedYear": 2018,
      "image": "https://via.placeholder.com/150"
    },
    {
      "id": 2,
      "title": "The Alchemist",
      "author": "Paulo Coelho",
      "price": 14.99,
      "category": "Fiction",
      "stock": 40,
      "rating": 4.7,
      "publishedYear": 1988,
      "image": "https://via.placeholder.com/150"
    }
  ]
}

এখন আপনি নিচের endpoint গুলো পাবেন:

/products
/books

এইভাবেই JSON Server Deploy আপনার JSON data-কে API-তে রূপান্তর করে।

Step 3: package.json configure করুন

নিচের মতো করে package.json সেটআপ করুন:

{
  "name": "deploy-json",
  "version": "1.0.0",
  "scripts": {
    "start": "npx json-server --watch db.json --host 0.0.0.0 --port $PORT",
    "dev": "json-server --watch db.json --port 4000"
  },
  "dependencies": {
    "json-server": "^1.0.0-beta.15"
  }
}

এখানে start script খুব গুরুত্বপূর্ণ, কারণ deploy-এর সময় এটিই run হবে।

Step 4: public ফোল্ডার তৈরি করুন

একটি public নামের empty folder তৈরি করুন। কিছু ক্ষেত্রে JSON Server (বিশেষ করে beta version) static folder হিসেবে public খুঁজতে পারে, তাই এটি রাখা ভালো।

Step 5: Local এ Test করুন

Terminal-এ নিচের commandগুলো চালান:

npm install
npm run dev

Browser-এ গিয়ে দেখুন:

http://localhost:4000/products

যদি data দেখতে পান, তাহলে setup ঠিকভাবে কাজ করছে।

Local test ছাড়া কখনো JSON Server Deploy করা উচিত নয়।

Step 6: GitHub-এ Push করুন

আপনার project একটি public GitHub repository-তে push করুন।

Step 7: Render-এ Deploy করুন

Render backend deploy করার জন্য একটি সহজ এবং নির্ভরযোগ্য platform।

Steps:

Render-এ account তৈরি করুন
Dashboard → New → Web Service
GitHub repository connect করুন

Important Settings:

Build Command:

npm install

Start Command:

npm start

Port:
ফাঁকা রাখুন (Render automatically assign করবে)

Deploy button চাপুন এবং ১–২ মিনিট অপেক্ষা করুন।

Live API URL

Deploy সম্পন্ন হলে আপনি পাবেন:

https://your-app.onrender.com/products

এখন আপনার JSON Server Deploy live হয়ে গেছে।

Common Errors & Fix

App crashed বা start না হলে:
npm start script ঠিক আছে কিনা যাচাই করুন।

db.json detect না হলে:
ফাইলটি root folder-এ আছে কিনা নিশ্চিত করুন।

Port issue হলে:
Fixed port ব্যবহার না করে $PORT ব্যবহার করুন।

Note

আপনি যদি json-server এর beta version ব্যবহার করেন (যেমন ^1.0.0-beta), তাহলে production environment-এ কিছু unexpected error দেখা যেতে পারে, যেমন public folder সংক্রান্ত সমস্যা বা server crash।

এক্ষেত্রে stable version ব্যবহার করা recommended:

npm install json-server@0.17.4

Step 8: Frontend থেকে API Call

React example:

useEffect(() => {
  fetch("https://your-app.onrender.com/products")
    .then(res => res.json())
    .then(data => console.log(data));
}, []);

এখন আপনার frontend real API থেকে data fetch করতে পারবে।

আপনি যদি React বা Next.js developer হন, তাহলে JSON Server ব্যবহার করে practice করলে backend flow এবং API handling আরও ভালোভাবে বুঝতে পারবেন।

নিজের project deploy করে দেখুন এই ছোট setup দিয়েই আপনি real-world development mindset তৈরি করতে পারবেন।

From Zero to Hero: Building a Key Issuance Server with `verbose` and `figtree`

Andrei Merlescu — Mon, 20 Apr 2026 15:53:15 +0000

In August 2024 Andrei Merlescu wrote a package called verbose and released it under the Apache 2.0 license. The idea was novel: when interacting with sensitive information during multi-region deployments, you want to print to STDOUT a censored expression of data while writing the unredacted form to log files — or in this tutorial's case, scrub secrets from the log file entirely. Private keys, passwords, serial numbers — these are sensitive and should not stream through STDOUT in devops contexts, especially in CI pipelines like GitHub Actions. With verbose, your runtime can register new secrets as they become available, concurrently and safely.

go get -u github.com/andreimerlescu/verbose

aSecret := "abc123"
// SecretBytes cast is required — AddSecret takes verbose.SecretBytes, not string
if err := verbose.AddSecret(verbose.SecretBytes(aSecret), "***"); err != nil {
    log.Fatal(err)
}
stdoutLogger := log.New(os.Stdout, "", log.LstdFlags)
// Tof takes a *log.Logger, not an io.Writer
verbose.Tof(stdoutLogger, "this is a secret: %s", aSecret)

Prints to STDOUT:

this is a secret: ***

Step 1 — Scaffold and dependencies

You are going to build a running HTTP server that issues, verifies, and revokes API keys. Every secret the server touches — the admin token that protects your endpoints, every key it issues — will be registered with the verbose logging package the moment it is created. By the time you finish, you will be able to grep your own log file for any plaintext secret and find nothing. That is the goal.

verbose is a logging package that scrubs registered secrets from every line it writes. figtree is a configuration package that loads values from a YAML file, environment variables, and CLI flags in that priority order, with validators and mutation tracking built in.

Create the project:

mkdir keyserver && cd keyserver
go mod init github.com/example/keyserver
go get github.com/andreimerlescu/verbose@latest
go get github.com/andreimerlescu/figtree/v2@latest

Create the files you will fill in across the remaining steps:

touch main.go config.yml

Your go.mod should now look like this:

module github.com/example/keyserver

go 1.22

require (
    github.com/andreimerlescu/figtree/v2 v2.0.14
    github.com/andreimerlescu/verbose    v0.2.0
)

Your directory:

keyserver/
├── go.mod
├── go.sum
├── config.yml
└── main.go

Nothing runs yet. That is fine. You have a clean workspace and both packages are available.

Step 2 — CLI design with figtree

Now that the workspace is ready, the first thing to design is configuration. Before any HTTP server, any logger, any route — you need to know what the program accepts and where it reads it from. figtree handles all three sources — file, environment, flags — in one tree.

Every config key is a Go constant. This is not optional style — it prevents typos from silently creating a second key that is never read.

Add this to main.go:

// main.go — complete file at this stage

package main

import (
    "fmt"
    "os"
    "time"

    "github.com/andreimerlescu/figtree/v2"
)

// config keys — always constants, never raw strings at call sites
const (
    kHost          = "host"
    kPort          = "port"
    kLogDir        = "log-dir"
    kTruncate      = "truncate"
    kKeyPrefix     = "key-prefix"
    kAdminToken    = "keyserver-admin-token" // env: KEYSERVER_ADMIN_TOKEN
    kOnCall        = "on-call-engineer"      // env: ON_CALL_ENGINEER
    kShiftDuration = "shift-duration"        // env: SHIFT_DURATION
)

func main() {
    // Grow a tracked tree — Tracking enables the Mutations() channel,
    // Pollinate re-checks env vars on every Getter call (needed for Step 7),
    // ConfigFile makes the intent explicit: this app is config-file-first.
    figs := figtree.With(figtree.Options{
        Tracking:   true,
        Germinate:  true,           // ignore -test.* flags during go test
        Pollinate:  true,           // re-read env vars on every Getter call
        ConfigFile: "./config.yml",
    })

    // -- server --
    figs.NewString(kHost, "127.0.0.1", "host address to listen on")
    figs.NewInt(kPort, 8080, "port to listen on")

    // -- logging --
    figs.NewString(kLogDir, "./logs", "directory to write log files into")
    figs.NewBool(kTruncate, false, "truncate log file on each run")

    // -- keys --
    figs.NewString(kKeyPrefix, "ks_", "prefix for issued API keys")

    // RuleNoFlags means figtree will never register a CLI flag for this key.
    // The only way to supply it is via KEYSERVER_ADMIN_TOKEN or config.yml.
    // The key name is deliberately long — verbose by design.
    figs.NewString(kAdminToken, "", "admin token — use KEYSERVER_ADMIN_TOKEN env var only")
    figs.WithRule(kAdminToken, figtree.RuleNoFlags)

    // -- on-call rotation --
    figs.NewString(kOnCall, "Darron", "name of the engineer currently on call")

    // shift-duration drives the rotation goroutine added in Step 3.
    // Default is 7 hours. SHIFT_DURATION=1 overrides it for local testing.
    figs.NewUnitDuration(kShiftDuration, 7, time.Hour, "length of one on-call shift in hours")

    // Problems() catches developer mistakes — duplicate keys, bad validator
    // combos — before Load() runs. These are your bugs, not user input errors.
    if problems := figs.Problems(); len(problems) > 0 {
        for _, p := range problems {
            fmt.Fprintf(os.Stderr, "figtree problem: %v\n", p)
        }
        os.Exit(1)
    }

    // Load resolves: config.yml → env vars → CLI flags (in that priority order)
    if err := figs.Load(); err != nil {
        fmt.Fprintf(os.Stderr, "figtree.Load: %v\n", err)
        os.Exit(1)
    }

    // Print everything so you can see what loaded — fmt.Println for now,
    // verbose replaces this in Step 4.
    fmt.Printf("host=%s port=%d log-dir=%s truncate=%v\n",
        *figs.String(kHost),
        *figs.Int(kPort),
        *figs.String(kLogDir),
        *figs.Bool(kTruncate),
    )
    fmt.Printf("key-prefix=%s on-call=%s shift=%s\n",
        *figs.String(kKeyPrefix),
        *figs.String(kOnCall),
        *figs.Duration(kShiftDuration),
    )
    fmt.Printf("admin-token=%s\n", *figs.String(kAdminToken))
}

Create config.yml:

host:             "127.0.0.1"
port:             8080
log-dir:          "./logs"
truncate:         false
key-prefix:       "ks_"
on-call-engineer: "Darron"
shift-duration:   7
# keyserver-admin-token is intentionally absent from source control.
# Set it via: export KEYSERVER_ADMIN_TOKEN=your-secret

Run it:

KEYSERVER_ADMIN_TOKEN=mysecret go run .

You should see all values printed. Notice admin-token=mysecret is in your terminal output right now. That is expected — verbose is not wired yet. You will fix that in Step 4 and never see it in plaintext again.

Mistake trap: Try running go run . -keyserver-admin-token=mysecret. figtree will not register that flag because of RuleNoFlags — the flag is unknown to the flag package and your program will exit with an error. The env var is the only valid path. This is intentional.

Step 3 — Validators, Problems(), and mutations

Now that the tree is declared, you lock it down. Validators reject bad input before your program does anything with it. The Problems() check you already have catches declaration mistakes. The mutations goroutine watches for runtime changes — which is where the on-call rotation lives.

Add these diffs to main.go:

After figs.NewString(kHost, ...) — add validator:

    // 3 lines above
    figs.NewString(kHost, "127.0.0.1", "host address to listen on")
    // add this
    figs.WithValidator(kHost, figtree.AssureStringNotEmpty)
    // 3 lines below
    figs.NewInt(kPort, 8080, "port to listen on")

After figs.NewInt(kPort, ...) — add validator:

    // 3 lines above
    figs.NewInt(kPort, 8080, "port to listen on")
    // add this
    figs.WithValidator(kPort, figtree.AssureIntInRange(1024, 65535))
    // 3 lines below
    figs.NewString(kLogDir, "./logs", "directory to write log files into")

After figs.NewString(kLogDir, ...) — add validator:

    // 3 lines above
    figs.NewString(kLogDir, "./logs", "directory to write log files into")
    // add this
    figs.WithValidator(kLogDir, figtree.AssureStringNotEmpty)
    // 3 lines below
    figs.NewBool(kTruncate, false, "truncate log file on each run")

After figs.NewString(kKeyPrefix, ...) — add validator:

    // 3 lines above
    figs.NewString(kKeyPrefix, "ks_", "prefix for issued API keys")
    // add this
    figs.WithValidator(kKeyPrefix, figtree.AssureStringNotEmpty)
    // 3 lines below
    figs.NewString(kAdminToken, "", "admin token — use KEYSERVER_ADMIN_TOKEN env var only")

After figs.WithRule(kAdminToken, ...) — add validator:

    // 3 lines above
    figs.WithRule(kAdminToken, figtree.RuleNoFlags)
    // add this — admin token must be present at startup
    figs.WithValidator(kAdminToken, figtree.AssureStringNotEmpty)
    // 3 lines below
    figs.NewString(kOnCall, "Darron", "name of the engineer currently on call")

After figs.NewString(kOnCall, ...) — add validator:

    // 3 lines above
    figs.NewString(kOnCall, "Darron", "name of the engineer currently on call")
    // add this
    figs.WithValidator(kOnCall, figtree.AssureStringNotEmpty)
    // 3 lines below
    figs.NewUnitDuration(kShiftDuration, 7, time.Hour, "length of one on-call shift in hours")

After figs.NewUnitDuration(kShiftDuration, ...) — add validators:

    // 3 lines above
    figs.NewUnitDuration(kShiftDuration, 7, time.Hour, "length of one on-call shift in hours")
    // add these — shifts must be at least 1 hour, at most 12
    figs.WithValidator(kShiftDuration, figtree.AssureDurationMin(1*time.Hour))
    figs.WithValidator(kShiftDuration, figtree.AssureDurationMax(12*time.Hour))
    // 3 lines below
    if problems := figs.Problems(); len(problems) > 0 {

Now add the mutations goroutine and the on-call shift rotation. Both go after figs.Load() — the tree must be live before you watch it:

    // 3 lines above
    if err := figs.Load(); err != nil {
        fmt.Fprintf(os.Stderr, "figtree.Load: %v\n", err)
        os.Exit(1)
    }
    // add this block
    // watch for any config value changing at runtime and log it
    go func() {
        for m := range figs.Mutations() {
            // verbose.Printf replaces this in Step 4
            fmt.Printf("config mutation: %s changed from %v to %v at %s\n",
                m.Property, m.Old, m.New, m.When)
        }
    }()

    // on-call rotation — fires every minute, updates kOnCall based on
    // the current hour. We check every minute so the change is never
    // more than 60 seconds late.
    go func() {
        for range time.Tick(time.Minute) {
            figs.StoreString(kOnCall, onCallEngineer())
        }
    }()
    // 3 lines below
    fmt.Printf("host=%s port=%d log-dir=%s truncate=%v\n",

Add the onCallEngineer function at the bottom of main.go, outside main:

// onCallEngineer returns the name of the engineer on call right now.
//
//   04:00–07:59  → TEAM     (everyone expected online)
//   08:00–14:59  → Darron
//   15:00–21:59  → Bradley
//   22:00–03:59  → Kevin    (crosses midnight)
func onCallEngineer() string {
    h := time.Now().Hour()
    switch {
    case h >= 4 && h < 8:
        return "TEAM"
    case h >= 8 && h < 15:
        return "Darron"
    case h >= 15 && h < 22:
        return "Bradley"
    default: // 22:00–03:59
        return "Kevin"
    }
}

Run it again:

KEYSERVER_ADMIN_TOKEN=mysecret go run .

To prove the validator works, temporarily set port: 99999 in config.yml and run again. You will see figtree refuse to load with a clear error. Set it back to 8080.

Mistake trap: Move the mutations goroutine to before figs.Load() and run it. The channel exists but the tree has not resolved its values yet — mutations fired during load will not be seen because the goroutine may not be scheduled before load completes. Always start the mutations goroutine after Load() returns.

Step 4 — Wire verbose, replace fmt, register the admin token

Now that figtree is loading and validating configuration correctly, you can wire up the logger. verbose needs to be initialised before any log call — and the admin token needs to be registered as a secret immediately after, before anything else in the program touches it.

Add verbose to your imports:

import (
    "fmt"
    "os"
    "time"
    // add this
    "github.com/andreimerlescu/verbose"

    "github.com/andreimerlescu/figtree/v2"
)

Add the verbose initialisation block right after the goroutines:

    // 3 lines above
    go func() {
        for range time.Tick(time.Minute) {
            figs.StoreString(kOnCall, onCallEngineer())
        }
    }()
    // add this block
    // initialise verbose before any log call — guard() will stderr and no-op
    // if you call verbose functions before this point
    if err := verbose.NewLogger(verbose.Options{
        Dir:      *figs.String(kLogDir),
        Name:     "keyserver",
        Truncate: *figs.Bool(kTruncate),
        DirMode:  0o755,
        FileMode: 0o640,
    }); err != nil {
        fmt.Fprintf(os.Stderr, "verbose.NewLogger: %v\n", err)
        os.Exit(1)
    }

    // read the admin token once — this is the value we protect at startup
    adminToken := *figs.String(kAdminToken)

    // register the admin token as a verbose secret immediately.
    // verbose stores only the SHA-512 digest — the plaintext is never retained.
    // every log line written after this point that contains the raw token value
    // will have it replaced with [ADMIN_TOKEN] automatically.
    if err := verbose.AddSecret(verbose.SecretBytes(adminToken), "[ADMIN_TOKEN]"); err != nil {
        fmt.Fprintf(os.Stderr, "verbose.AddSecret: %v\n", err)
        os.Exit(1)
    }

    // proof that scrubbing is active — this line contains the raw token.
    // open logs/keyserver.log after running and you will see [ADMIN_TOKEN].
    verbose.Printf("admin token registered — value in log: %s", adminToken)
    // Version() is a function call, not a variable
    verbose.Printf("keyserver starting (verbose v%s / figtree v%s)",
        verbose.VERSION, figtree.Version())
    // 3 lines below
    fmt.Printf("host=%s port=%d log-dir=%s truncate=%v\n",

Replace the fmt.Printf startup summary:

    // remove this
    fmt.Printf("host=%s port=%d log-dir=%s truncate=%v\n",
        *figs.String(kHost),
        *figs.Int(kPort),
        *figs.String(kLogDir),
        *figs.Bool(kTruncate),
    )
    fmt.Printf("key-prefix=%s on-call=%s shift=%s\n",
        *figs.String(kKeyPrefix),
        *figs.String(kOnCall),
        *figs.Duration(kShiftDuration),
    )
    fmt.Printf("admin-token=%s\n", *figs.String(kAdminToken))
    // replace with this
    verbose.Printf("host=%s port=%d log-dir=%s truncate=%v key-prefix=%s on-call=%s shift=%s",
        *figs.String(kHost),
        *figs.Int(kPort),
        *figs.String(kLogDir),
        *figs.Bool(kTruncate),
        *figs.String(kKeyPrefix),
        *figs.String(kOnCall),
        *figs.Duration(kShiftDuration),
    )

Replace the fmt.Printf in the mutations goroutine:

    // 3 lines above
    go func() {
        for m := range figs.Mutations() {
            // remove this
            fmt.Printf("config mutation: %s changed from %v to %v at %s\n",
                m.Property, m.Old, m.New, m.When)
            // replace with this
            verbose.Printf("config mutation: %s changed from %v to %v at %s",
                m.Property, m.Old, m.New, m.When)
        }
    }()

Run it:

KEYSERVER_ADMIN_TOKEN=mysecret go run .

Open logs/keyserver.log. Find the line containing "admin token registered". The value mysecret does not appear — you will see [ADMIN_TOKEN] in its place. From this point forward, mysecret cannot appear in any log line this process writes.

Mistake trap: Call verbose.Printf("test") before verbose.NewLogger — move it above the NewLogger block and run. You will see the message printed to stderr with a "NewLogger or SetLogger has not been called" prefix. verbose does not panic — it fails open to stderr. Move the call back below NewLogger.

Step 5 — HTTP server skeleton

With logging and configuration solid, the server can be wired up. The three routes are stubs for now — each returns 200 OK with a placeholder body. The requireAdmin middleware is the important piece here: it logs every auth attempt, which means the admin token will be scrubbed from those log lines automatically.

Add net/http and encoding/json to your imports:

import (
    "fmt"
    "os"
    "time"
    // add these
    "encoding/json"
    "net/http"

    "github.com/andreimerlescu/verbose"
    "github.com/andreimerlescu/figtree/v2"
)

Add the server block at the end of main:

    // 3 lines above
    verbose.Printf("host=%s port=%d log-dir=%s truncate=%v key-prefix=%s on-call=%s shift=%s",
        *figs.String(kHost),
        *figs.Int(kPort),
        *figs.String(kLogDir),
        *figs.Bool(kTruncate),
        *figs.String(kKeyPrefix),
        *figs.String(kOnCall),
        *figs.Duration(kShiftDuration),
    )
    // add this block
    // capture prefix once — used in handlers added in Step 6
    prefix := *figs.String(kKeyPrefix)
    _ = prefix

    // POST /keys — issue a new API key (admin only)
    http.HandleFunc("POST /keys", requireAdmin(adminToken, func(w http.ResponseWriter, r *http.Request) {
        w.Header().Set("Content-Type", "application/json")
        json.NewEncoder(w).Encode(map[string]string{"status": "not implemented"})
    }))

    // GET /keys/{id}/verify — verify a presented key
    http.HandleFunc("GET /keys/{id}/verify", func(w http.ResponseWriter, r *http.Request) {
        w.Header().Set("Content-Type", "application/json")
        json.NewEncoder(w).Encode(map[string]string{"status": "not implemented"})
    })

    // DELETE /keys/{id} — revoke and remove a key (admin only)
    http.HandleFunc("DELETE /keys/{id}", requireAdmin(adminToken, func(w http.ResponseWriter, r *http.Request) {
        w.WriteHeader(http.StatusNoContent)
    }))

    addr := fmt.Sprintf("%s:%d", *figs.String(kHost), *figs.Int(kPort))
    verbose.Printf("keyserver listening on http://%s", addr)

    if err := http.ListenAndServe(addr, nil); err != nil {
        // ListenAndServe only returns on error — log it with a trace and exit
        fmt.Fprintf(os.Stderr, "http.ListenAndServe: %v\n",
            verbose.TracefReturn("ListenAndServe failed: %v", err))
        os.Exit(1)
    }
    // 3 lines below — end of main

Add requireAdmin and bearerToken below onCallEngineer:

// requireAdmin rejects requests whose Bearer token does not match adminToken.
// The token is already a verbose secret — the log line is safe.
func requireAdmin(adminToken string, next http.HandlerFunc) http.HandlerFunc {
    return func(w http.ResponseWriter, r *http.Request) {
        presented := bearerToken(r)
        verbose.Printf("%s %s — auth attempt from %s token=%s",
            r.Method, r.URL.Path, r.RemoteAddr, presented)
        if presented != adminToken {
            verbose.Printf("%s %s — FORBIDDEN", r.Method, r.URL.Path)
            http.Error(w, "forbidden", http.StatusForbidden)
            return
        }
        next(w, r)
    }
}

// bearerToken extracts the token from Authorization: Bearer <token>
func bearerToken(r *http.Request) string {
    auth := r.Header.Get("Authorization")
    if len(auth) > 7 && auth[:7] == "Bearer " {
        return auth[7:]
    }
    return ""
}

Run the server and curl the stubs:

KEYSERVER_ADMIN_TOKEN=mysecret go run . &

curl -s -X POST http://localhost:8080/keys \
  -H "Authorization: Bearer mysecret"

curl -s http://localhost:8080/keys/test/verify

curl -s -X DELETE http://localhost:8080/keys/test \
  -H "Authorization: Bearer mysecret"

kill %1

Check logs/keyserver.log. The auth lines show token=[ADMIN_TOKEN] — never mysecret.

Mistake trap: If you are on Go below 1.22, http.HandleFunc("POST /keys", ...) will not compile — the method prefix in the pattern is a 1.22 feature. Run go version to check. If needed, update your toolchain: go get toolchain@go1.22.0.

Step 6 — Issuance, verification, revocation, and runtime secret registration

This is the core of the application and the core demonstration of verbose. The moment a key is generated, verbose.AddSecret is called before anything else — before the key is stored, before it is logged, before it is returned to the caller. The window between generation and registration is zero.

When a key is deleted, verbose.RemoveSecret is called. This is safe because a deleted key is dead — no future request will present it, so there is no future log line to protect. Removing it keeps the verbose runtime lean: the secrets registry does not grow forever, and scanning each log line is O(n) in the number of registered secrets. In a long-running server issuing thousands of keys, this matters. The same pattern applies to user sessions: register the session token on login, remove it on logout.

Add the key store above main:

// 3 lines above — imports
// add this block after imports, before main

// keyRecord holds metadata for one issued API key.
// The token value is the map key — never stored inside the struct.
type keyRecord struct {
    ID       string    `json:"id"`
    IssuedAt time.Time `json:"issued_at"`
    IssuedTo string    `json:"issued_to"`
    Revoked  bool      `json:"revoked"`
}

var (
    keyStoreMu sync.RWMutex
    keyStore   = make(map[string]*keyRecord)
)
// 3 lines below — func main() {

Add sync, crypto/rand, and encoding/hex to imports:

    // add to import block
    "crypto/rand"
    "encoding/hex"
    "sync"

Replace the POST /keys stub:

    // 3 lines above
    http.HandleFunc("POST /keys", requireAdmin(adminToken, func(w http.ResponseWriter, r *http.Request) {
    // replace body
        var body struct {
            IssuedTo string `json:"issued_to"`
        }
        if err := json.NewDecoder(r.Body).Decode(&body); err != nil || body.IssuedTo == "" {
            verbose.Printf("POST /keys — bad request from %s: %v", r.RemoteAddr, err)
            http.Error(w, "issued_to is required", http.StatusBadRequest)
            return
        }

        token, err := generateToken(prefix)
        if err != nil {
            // TracefReturn logs with a stack trace and returns the error —
            // capture the return value, do not discard it
            verbose.Printf("POST /keys — token generation failed: %v",
                verbose.TracefReturn("generateToken: %v", err))
            http.Error(w, "internal error", http.StatusInternalServerError)
            return
        }

        // register with verbose FIRST — before store, before log, before response.
        // after this line the token cannot appear in plaintext in any log output.
        if err := verbose.AddSecret(verbose.SecretBytes(token), "[ISSUED_KEY]"); err != nil {
            verbose.Printf("POST /keys — failed to protect token: %v", err)
            http.Error(w, "internal error", http.StatusInternalServerError)
            return
        }

        rec := &keyRecord{
            ID:       token,
            IssuedAt: time.Now().UTC(),
            IssuedTo: body.IssuedTo,
        }

        keyStoreMu.Lock()
        keyStore[token] = rec
        keyStoreMu.Unlock()

        // safe to log — token is already scrubbed to [ISSUED_KEY]
        verbose.Printf("POST /keys — issued key=%s to=%s at=%s",
            token, body.IssuedTo, rec.IssuedAt.Format(time.RFC3339))

        w.Header().Set("Content-Type", "application/json")
        w.WriteHeader(http.StatusCreated)
        json.NewEncoder(w).Encode(map[string]string{
            "token":     token,
            "issued_to": body.IssuedTo,
            "issued_at": rec.IssuedAt.Format(time.RFC3339),
        })
    }))
    // 3 lines below

Replace the GET /keys/{id}/verify stub:

    // 3 lines above
    http.HandleFunc("GET /keys/{id}/verify", func(w http.ResponseWriter, r *http.Request) {
    // replace body
        presented := bearerToken(r)
        id := r.PathValue("id")

        // log the attempt — if the caller sent a valid token it is already
        // a verbose secret and will be scrubbed automatically
        verbose.Printf("GET /keys/%s/verify — attempt from %s token=%s",
            id, r.RemoteAddr, presented)

        keyStoreMu.RLock()
        rec, exists := keyStore[presented]
        keyStoreMu.RUnlock()

        if !exists || rec.Revoked {
            verbose.Printf("GET /keys/%s/verify — INVALID", id)
            http.Error(w, "invalid or revoked key", http.StatusUnauthorized)
            return
        }

        verbose.Printf("GET /keys/%s/verify — VALID issued_to=%s", id, rec.IssuedTo)
        w.Header().Set("Content-Type", "application/json")
        json.NewEncoder(w).Encode(map[string]any{
            "valid":     true,
            "issued_to": rec.IssuedTo,
            "issued_at": rec.IssuedAt.Format(time.RFC3339),
        })
    })
    // 3 lines below

Replace the DELETE /keys/{id} stub:

    // 3 lines above
    http.HandleFunc("DELETE /keys/{id}", requireAdmin(adminToken, func(w http.ResponseWriter, r *http.Request) {
    // replace body
        id := r.PathValue("id")

        keyStoreMu.Lock()
        rec, exists := keyStore[id]
        if exists {
            rec.Revoked = true
        }
        keyStoreMu.Unlock()

        if !exists {
            verbose.Printf("DELETE /keys/%s — not found", id)
            http.Error(w, "key not found", http.StatusNotFound)
            return
        }

        // the key is dead — safe to remove from verbose.
        // removing it keeps the secrets registry lean: verbose scans every
        // log line against every registered secret, so a smaller registry
        // means faster logging. do not leave dead secrets registered forever.
        if err := verbose.RemoveSecret(verbose.SecretBytes(id)); err != nil {
            verbose.Printf("DELETE /keys/%s — RemoveSecret error: %v", id, err)
        }

        verbose.Printf("DELETE /keys/%s — revoked and removed from verbose (was issued to %s)",
            id, rec.IssuedTo)

        w.WriteHeader(http.StatusNoContent)
    }))
    // 3 lines below

Add generateToken below bearerToken:

// generateToken returns a cryptographically random token with the given prefix.
func generateToken(prefix string) (string, error) {
    b := make([]byte, 24)
    if _, err := rand.Read(b); err != nil {
        return "", err
    }
    return prefix + hex.EncodeToString(b), nil
}

Mistake trap: Move verbose.AddSecret to after keyStoreMu.Lock() — just two lines later — and run the server. Issue a key. Look at the log line for POST /keys — issued key=. You will see the raw token value in plaintext because it was logged by requireAdmin in the auth check before it was registered. Order is not a style preference here. It is the security guarantee. Move AddSecret back to first.

Step 7 — The on-call engineer shift in action

The rotation goroutine has been running since Step 3, quietly updating a value. Now that verbose is wired, the mutation log entries are meaningful — and with Pollinate: true, an engineer can override the on-call value live from a second terminal without restarting the server.

The shift goroutine is already in place. The mutations goroutine is already using verbose.Printf from Step 4. Run the server and open a second terminal:

# terminal 1
KEYSERVER_ADMIN_TOKEN=mysecret go run .

# terminal 2 — override the on-call engineer without restarting
export ON_CALL_ENGINEER=Kevin

Watch logs/keyserver.log — within one minute you will see:

[VERBOSE] keyserver.go:XX: config mutation: on-call-engineer changed from Darron to Kevin at 2026-04-20...

The mutation fires because Pollinate: true causes figtree to re-read ON_CALL_ENGINEER every time figs.String(kOnCall) is called — which the rotation goroutine does every minute.

If the on-call engineer name were a sensitive internal codename — a security handle, a contractor alias, anything you would not want in a log shipped to an aggregator — one verbose.AddSecret(verbose.SecretBytes(name), "[ON_CALL]") call in the rotation goroutine would scrub it from every future log line. The pattern is identical to what you did with the admin token.

Mistake trap: Remove Pollinate: true from figtree.Options, restart the server, and set export ON_CALL_ENGINEER=Kevin again. No mutation fires. The env var changed but figtree did not re-read it because Pollinate was off. Put Pollinate: true back.

Step 8 — The bash test script

Create test.sh in the project root. This script is the pass/fail gate for the tutorial. If your implementation is correct it exits 0. Each assertion failure prints which step to revisit and exits immediately.

#!/usr/bin/env bash
set -euo pipefail

# ── dependency check ──────────────────────────────────────────────────────────
if ! command -v curl &>/dev/null; then
    echo "ERROR: curl is required. Install it and rerun."
    exit 1
fi
if ! command -v jq &>/dev/null; then
    echo "ERROR: jq is required."
    echo "  macOS:  brew install jq"
    echo "  Linux:  sudo apt install jq  OR  sudo yum install jq"
    exit 1
fi

# ── config ────────────────────────────────────────────────────────────────────
ADMIN_TOKEN="test-admin-secret-1234"
BASE="http://127.0.0.1:8080"
LOG_FILE="./logs/keyserver.log"

# ── helpers ───────────────────────────────────────────────────────────────────
pass() { echo "  PASS: $1"; }
fail() { echo "  FAIL: $1 — $2"; exit 1; }

assert_status() {
    local label="$1" expected="$2" actual="$3" step="$4"
    if [ "$actual" -ne "$expected" ]; then
        fail "$label" "expected HTTP $expected, got $actual (see step $step)"
    fi
    pass "$label"
}

assert_no_plaintext() {
    local label="$1" secret="$2" step="$3"
    if grep -qF "$secret" "$LOG_FILE" 2>/dev/null; then
        fail "$label" "plaintext secret found in log — verbose.AddSecret not called before logging (see step $step)"
    fi
    pass "$label"
}

assert_log_contains() {
    local label="$1" pattern="$2" step="$3"
    if ! grep -qF "$pattern" "$LOG_FILE" 2>/dev/null; then
        fail "$label" "expected '$pattern' in log — not found (see step $step)"
    fi
    pass "$label"
}

# ── build and start server ────────────────────────────────────────────────────
echo "=> building..."
go build -o keyserver_bin . || { echo "Build failed — fix compilation errors first."; exit 1; }

echo "=> starting server..."
KEYSERVER_ADMIN_TOKEN="$ADMIN_TOKEN" ./keyserver_bin &
SERVER_PID=$!
trap 'kill $SERVER_PID 2>/dev/null; rm -f keyserver_bin' EXIT

# wait for server to be ready — retry up to 10 times
for i in $(seq 1 10); do
    if curl -sf "$BASE/keys/test/verify" &>/dev/null; then
        break
    fi
    sleep 0.5
done

echo ""
echo "── assertion 1: admin token is scrubbed from logs (Step 4) ─────────────"
assert_no_plaintext "admin token not in log" "$ADMIN_TOKEN" "4"

echo ""
echo "── assertion 2: issue key for alice (Step 6) ────────────────────────────"
ALICE_RESP=$(curl -s -w "\n%{http_code}" -X POST "$BASE/keys" \
    -H "Authorization: Bearer $ADMIN_TOKEN" \
    -H "Content-Type: application/json" \
    -d '{"issued_to":"alice@example.com"}')
ALICE_STATUS=$(echo "$ALICE_RESP" | tail -1)
ALICE_BODY=$(echo "$ALICE_RESP" | head -1)
assert_status "POST /keys alice" 201 "$ALICE_STATUS" "6"
ALICE_TOKEN=$(echo "$ALICE_BODY" | jq -r .token)

echo ""
echo "── assertion 3: issue key for bob (Step 6) ──────────────────────────────"
BOB_RESP=$(curl -s -w "\n%{http_code}" -X POST "$BASE/keys" \
    -H "Authorization: Bearer $ADMIN_TOKEN" \
    -H "Content-Type: application/json" \
    -d '{"issued_to":"bob@example.com"}')
BOB_STATUS=$(echo "$BOB_RESP" | tail -1)
BOB_BODY=$(echo "$BOB_RESP" | head -1)
assert_status "POST /keys bob" 201 "$BOB_STATUS" "6"
BOB_TOKEN=$(echo "$BOB_BODY" | jq -r .token)

echo ""
echo "── assertion 4: issue key for carol (Step 6) ────────────────────────────"
CAROL_RESP=$(curl -s -w "\n%{http_code}" -X POST "$BASE/keys" \
    -H "Authorization: Bearer $ADMIN_TOKEN" \
    -H "Content-Type: application/json" \
    -d '{"issued_to":"carol@example.com"}')
CAROL_STATUS=$(echo "$CAROL_RESP" | tail -1)
CAROL_BODY=$(echo "$CAROL_RESP" | head -1)
assert_status "POST /keys carol" 201 "$CAROL_STATUS" "6"
CAROL_TOKEN=$(echo "$CAROL_BODY" | jq -r .token)

echo ""
echo "── assertion 5: verify alice (Step 6) ───────────────────────────────────"
STATUS=$(curl -s -o /dev/null -w "%{http_code}" "$BASE/keys/${ALICE_TOKEN}/verify" \
    -H "Authorization: Bearer $ALICE_TOKEN")
assert_status "GET /keys alice/verify" 200 "$STATUS" "6"

echo ""
echo "── assertion 6: verify bob (Step 6) ─────────────────────────────────────"
STATUS=$(curl -s -o /dev/null -w "%{http_code}" "$BASE/keys/${BOB_TOKEN}/verify" \
    -H "Authorization: Bearer $BOB_TOKEN")
assert_status "GET /keys bob/verify" 200 "$STATUS" "6"

echo ""
echo "── assertion 7: verify carol (Step 6) ───────────────────────────────────"
STATUS=$(curl -s -o /dev/null -w "%{http_code}" "$BASE/keys/${CAROL_TOKEN}/verify" \
    -H "Authorization: Bearer $CAROL_TOKEN")
assert_status "GET /keys carol/verify" 200 "$STATUS" "6"

echo ""
echo "── assertion 8: revoke bob (Step 6) ─────────────────────────────────────"
STATUS=$(curl -s -o /dev/null -w "%{http_code}" -X DELETE "$BASE/keys/${BOB_TOKEN}" \
    -H "Authorization: Bearer $ADMIN_TOKEN")
assert_status "DELETE /keys bob" 204 "$STATUS" "6"

echo ""
echo "── assertion 9: verify bob after revocation — expect 401 (Step 6) ───────"
STATUS=$(curl -s -o /dev/null -w "%{http_code}" "$BASE/keys/${BOB_TOKEN}/verify" \
    -H "Authorization: Bearer $BOB_TOKEN")
assert_status "GET /keys bob/verify after revoke" 401 "$STATUS" "6"

echo ""
echo "── assertion 10: alice and carol tokens not in log (Step 6) ─────────────"
assert_no_plaintext "alice token not in log" "$ALICE_TOKEN" "6"
assert_no_plaintext "carol token not in log" "$CAROL_TOKEN" "6"

echo ""
echo "── assertion 11: bob token not in log (Step 6) ──────────────────────────"
# bob's token was removed via RemoveSecret after revocation.
# if the implementation is correct the token never appeared in plaintext
# because AddSecret was called before any logging.
assert_no_plaintext "bob token not in log" "$BOB_TOKEN" "6"

echo ""
echo "── assertion 12: scrub markers present in log (Step 4 + 6) ─────────────"
assert_log_contains "[ADMIN_TOKEN] in log" "[ADMIN_TOKEN]" "4"
assert_log_contains "[ISSUED_KEY] in log"  "[ISSUED_KEY]"  "6"

echo ""
echo "── assertion 13: on-call mutation visible in log (Step 7) ───────────────"
export ON_CALL_ENGINEER="TEAM"
echo "   waiting up to 90s for on-call mutation to appear in log..."
for i in $(seq 1 18); do
    if grep -qF "on-call-engineer" "$LOG_FILE" 2>/dev/null; then
        pass "on-call mutation in log"
        break
    fi
    sleep 5
    if [ "$i" -eq 18 ]; then
        fail "on-call mutation in log" "mutation not seen after 90s — check Pollinate:true and mutations goroutine (see step 7)"
    fi
done

echo ""
echo "════════════════════════════════════════════════════════════════════════"
echo "  All assertions passed. Your implementation is correct."
echo "════════════════════════════════════════════════════════════════════════"

Make it executable and run it:

chmod +x test.sh
./test.sh

If every assertion passes you see the final banner. If any assertion fails the script exits immediately with the step number to revisit. Fix that step and rerun — the script always starts fresh.

Step 9 — Closing: What You Built and What Comes Next

You started this tutorial with an empty directory and two go get commands. You finished with a running HTTP server that issues, verifies, and revokes API keys — and whose log file provably contains no plaintext secrets. Run ./test.sh one final time and watch every assertion pass. That exit 0 is not a formality. It is a guarantee backed by SHA-512.

Take a moment to understand what you actually built and why each piece was chosen.

verbose is not just a logger. Every other logger in the Go ecosystem — log, slog, zap, zerolog — will faithfully write whatever string you hand it. verbose is the only one that knows what your secrets are and refuses to write them. The moment you call verbose.AddSecret(verbose.SecretBytes(token), "[ISSUED_KEY]"), that token's SHA-512 digest enters a registry and every subsequent log line is scanned against it before it touches disk. The plaintext never persists inside verbose — not in memory, not on disk. When you called verbose.RemoveSecret on revocation, you kept that registry lean deliberately: a server that issues thousands of keys over its lifetime should not accumulate thousands of dead secrets in a scanner it runs on every single log call.

figtree is not just a flag parser. It is a priority-ordered configuration resolver — file, then environment, then CLI — with validators, rules, and a mutation channel that watches values change at runtime. RuleNoFlags on kAdminToken is not decoration. It is an enforcement boundary. The key name "keyserver-admin-token" being deliberately long is not an accident — it is a design statement: secrets should be inconvenient to pass on a command line because command lines end up in shell history, process lists, and CI logs.

The on-call rotation is a small thing, but it demonstrates something real: configuration is not static. Values change while a server runs. Pollinate: true and the mutations channel give you an observable, logged record of every change. In a real system that might be a database password rotating, a feature flag toggling, a rate limit updating. The pattern is identical regardless of what the value is.

The packages used in this tutorial are part of a larger body of open source work

Both verbose and figtree were written by Andrei Merlescu — @andreimerlescu on GitHub. His profile carries 99 public repositories built across 17 years of professional software engineering spanning Cisco, Oracle, Warner Bros. Games, and SurgePays, written primarily in Go, Ruby, PHP, and Bash.

Some repositories worth exploring alongside the two you just used:

checkfs — filesystem existence and permission checks for File and Directory. Pairs naturally with figtree when you want to validate that a config-supplied path actually exists before your server starts.
sema — semaphore primitives for Go. Useful when the keyserver you just built needs to limit concurrent issuance requests.
go-passwd — safe password auditing. If your keyserver ever needs to validate that an incoming credential meets a strength policy before issuing a key, this is the package.
summarize + aigcm — AI-assisted project summarization and git commit message generation using local Ollama models. If you are building on an M-series Mac with local models, these are worth looking at.
lemmings — load testing built around the concept of NPCs moving through your infrastructure as simulated users across geographic terrains and pack sizes. If you want to know what your keyserver does under real traffic before you ship it, lemmings is how you find out. It was built specifically because existing tools like ab did not answer the question Andrei needed answered when he launched Trakify in 2015 and got a surge of traffic from a Barron's Magazine feature. The tool he wished he had then exists now and it is free.

The code is yours. The packages are free. The log file is clean.

MovieSync: Redefining Intermissions with Live Crowd Data

Koushik Raghavan — Mon, 20 Apr 2026 15:52:40 +0000

Building MovieSync in Public (with Antigravity) 🎬🚀

We’ve all faced this…
You step out during a movie break, thinking you’ll grab snacks or use the washroom quickly — but end up stuck in long queues. Short break, long wait.

That’s where the idea of MovieSync came from.

The Problem

Intermissions are limited, but there’s zero visibility on crowd levels. You just guess… and sometimes regret it.

The Idea

I built MovieSync, a real-time dashboard that shows how crowded different areas are inside a venue.
Simple color signals help you decide instantly:

🟢 Low crowd
🟠 Medium
🔴 High congestion

No guesswork. Just smarter decisions.

Tech Stack

React + Vite for a fast, lightweight frontend
Vanilla CSS (no heavy UI libraries)
Docker (multi-stage build)
Nginx for serving the app
Google Cloud Run for serverless deployment
Antigravity to speed up development & workflow

How I Built It

I focused on keeping things simple and clean.
Instead of using UI frameworks, I designed everything from scratch using glassmorphism styles, smooth transitions, and subtle animations.

Since I didn’t have real sensors, I created a simulation that mimics real-time data (like WebSockets). The dashboard updates dynamically to reflect crowd density.

Deployment

Used Docker with a multi-stage build:

Node → build optimized assets
Nginx → serve the app on port 8080

Deployed on Google Cloud Run for automatic scaling.

Where Antigravity Helped

Antigravity made a big difference by:

Speeding up initial setup
Making UI iterations faster
Simplifying deployment flow
Reducing overall complexity

It helped me move faster from idea → working product.

Key Features

Real-time crowd dashboard
Lightweight and responsive UI
Dockerized production build
Serverless deployment
Built in public

What’s Next

Real IoT integration
WebSocket backend
Predictive crowd insights
Mobile PWA version
Multi-theatre support

Final Thought

This project showed me how quickly you can build something useful using the right tools. Building in public also made the journey more real and accountable.

What are you building right now? 🚀

Construindo um explorador de rede societária com grafos em Python

Pedro Parker — Mon, 20 Apr 2026 15:51:46 +0000

Uma das funcionalidades mais interessantes do CNPJ Aberto é a rede societária — dado um CNPJ, o sistema mapeia todos os sócios da empresa, encontra outras empresas desses mesmos sócios, e constrói um grafo de conexões.

Isso transforma dados tabulares (CSV da Receita Federal) em inteligência empresarial. Advogados usam para due diligence, jornalistas para investigação, e analistas de crédito para avaliação de risco.

Neste post, vou mostrar como construímos esse sistema.

O modelo de dados

A base da Receita Federal tem uma relação simples:

empresas (cnpj_basico) ←──1:N──→ socios (cnpj_basico, nome_socio)

Cada empresa tem N sócios. Cada sócio pode aparecer em múltiplas empresas (identificado pelo nome). E um sócio pode ser uma pessoa jurídica (outra empresa), criando conexões indiretas.

Empresa A ← sócio "João Silva" → Empresa B
Empresa B ← sócio PJ "Empresa C" → Empresa C
Empresa C ← sócio "Maria Santos" → Empresa D

Isso forma um grafo que pode revelar estruturas corporativas complexas.

Modelagem do grafo

from dataclasses import dataclass

@dataclass
class GrupoNode:
    id: str
    tipo: str       # "empresa" | "pessoa"
    label: str      # razão social ou nome
    cnpj: str | None
    situacao_cadastral: str | None
    capital_social: float | None
    uf: str | None
    is_target: bool  # é a empresa que o usuário consultou?

@dataclass
class GrupoEdge:
    source: str     # node ID
    target: str     # node ID
    label: str      # qualificação do sócio

O grafo é uma lista de nodes (empresas e pessoas) e edges (relações societárias). Simples e serializável para JSON.

O traversal recursivo

O algoritmo começa em uma empresa e expande recursivamente:

MAX_DEPTH = 2
MAX_NETWORK_NODES = 150

async def get_grupo_empresarial(cnpj_basico: str, db):
    nodes = {}
    edges = []

    await traverse_company(
        cnpj_basico, db, nodes, edges, depth=0, is_target=True
    )

    return {
        "nodes": list(nodes.values()),
        "edges": edges,
    }

traverse_company: o coração do algoritmo

async def traverse_company(cnpj_basico, db, nodes, edges, depth, is_target=False):
    if depth > MAX_DEPTH:
        return
    if len(nodes) >= MAX_NETWORK_NODES:
        return

    company_id = f"emp:{cnpj_basico}"
    if company_id in nodes:
        return  # Já visitado — evita ciclos

    # 1. Buscar dados da empresa
    empresa = db.query(Empresa).filter(
        Empresa.cnpj_basico == cnpj_basico
    ).first()

    if not empresa:
        return

    matriz = db.query(Estabelecimento).filter(
        Estabelecimento.cnpj_basico == cnpj_basico,
        Estabelecimento.identificador_matriz_filial == "1"
    ).first()

    # Adicionar node da empresa
    nodes[company_id] = GrupoNode(
        id=company_id,
        tipo="empresa",
        label=empresa.razao_social,
        cnpj=format_cnpj(cnpj_basico),
        situacao_cadastral=matriz.situacao_cadastral if matriz else None,
        capital_social=empresa.capital_social,
        uf=matriz.uf if matriz else None,
        is_target=is_target,
    )

    # 2. Buscar sócios desta empresa
    socios = db.query(Socio).filter(
        Socio.cnpj_basico == cnpj_basico
    ).all()

    for socio in socios:
        if len(nodes) >= MAX_NETWORK_NODES:
            break

        if socio.identificador_socio == "1" and socio.cpf_cnpj_socio:
            # Sócio é PESSOA JURÍDICA → seguir como outra empresa
            socio_cnpj = socio.cpf_cnpj_socio[:8]
            socio_id = f"emp:{socio_cnpj}"

            edges.append(GrupoEdge(
                source=socio_id,
                target=company_id,
                label=socio.qualificacao or "Sócio PJ",
            ))

            # Recursão: explorar a empresa sócia
            await traverse_company(
                socio_cnpj, db, nodes, edges, depth + 1
            )
        else:
            # Sócio é PESSOA FÍSICA
            person_id = f"pf:{sanitize(socio.nome_socio)}"

            if person_id not in nodes:
                nodes[person_id] = GrupoNode(
                    id=person_id,
                    tipo="pessoa",
                    label=socio.nome_socio,
                    cnpj=None,
                    situacao_cadastral=None,
                    capital_social=None,
                    uf=None,
                    is_target=False,
                )

            edges.append(GrupoEdge(
                source=person_id,
                target=company_id,
                label=socio.qualificacao or "Sócio",
            ))

            # 3. Buscar OUTRAS empresas desta pessoa
            await expand_person(
                socio.nome_socio, cnpj_basico, db, 
                nodes, edges, depth
            )

expand_person: encontrando empresas conectadas

async def expand_person(nome_socio, exclude_cnpj, db, nodes, edges, depth):
    # Buscar outros cnpj_basico onde esta pessoa é sócia
    other_companies = db.query(Socio.cnpj_basico).filter(
        Socio.nome_socio == nome_socio,
        Socio.cnpj_basico != exclude_cnpj,
    ).distinct().limit(10).all()

    person_id = f"pf:{sanitize(nome_socio)}"

    for row in other_companies:
        if len(nodes) >= MAX_NETWORK_NODES:
            break

        company_id = f"emp:{row.cnpj_basico}"

        edges.append(GrupoEdge(
            source=person_id,
            target=company_id,
            label="Sócio",
        ))

        # Continuar traversal na empresa encontrada
        await traverse_company(
            row.cnpj_basico, db, nodes, edges, depth + 1
        )

Proteções contra explosão combinatória

Sem limitações, o grafo pode explodir. Um sócio que aparece em 200 empresas, cada empresa com 5 sócios, cada sócio em 10 empresas... rapidamente vira milhões de nodes.

As proteções:

Proteção	Valor	Por quê
`MAX_DEPTH`	2	Limita a profundidade da recursão
`MAX_NETWORK_NODES`	150	Cap total de nodes no grafo
`LIMIT 10` em `expand_person`	10	Limita empresas por pessoa
Checagem `if company_id in nodes`	—	Evita ciclos e re-processamento

Depth 2 é suficiente? Na prática, sim. A maioria das estruturas societárias interessantes fica a 1-2 hops de distância. Ir mais fundo geralmente adiciona ruído sem valor.

Detecção de Red Flags

Com o grafo pronto, podemos detectar padrões suspeitos:

def detect_red_flags(cnpj_basico, db):
    flags = []

    # 1. Sócio em muitas empresas (possível laranja)
    socios = db.query(
        Socio.nome_socio, func.count(distinct(Socio.cnpj_basico))
    ).filter(
        Socio.cnpj_basico == cnpj_basico
    ).group_by(Socio.nome_socio).all()

    for nome, count in socios:
        total = db.query(func.count(distinct(Socio.cnpj_basico))).filter(
            Socio.nome_socio == nome
        ).scalar()

        if total >= 5:
            flags.append({
                "tipo": "socio_multiplas_empresas",
                "severidade": "media",
                "titulo": f"Sócio em {total} empresas",
                "descricao": f"{nome} é sócio em {total} empresas diferentes",
            })

    # 2. Muitas empresas no mesmo endereço
    matriz = get_matriz(cnpj_basico, db)
    if matriz and matriz.cep and matriz.logradouro:
        same_address = db.query(func.count()).filter(
            Estabelecimento.cep == matriz.cep,
            Estabelecimento.logradouro == matriz.logradouro,
            Estabelecimento.numero == matriz.numero,
            Estabelecimento.cnpj_basico != cnpj_basico,
            Estabelecimento.identificador_matriz_filial == "1",
        ).scalar()

        if same_address >= 3:
            flags.append({
                "tipo": "concentracao_endereco",
                "severidade": "baixa",
                "titulo": f"{same_address} empresas no mesmo endereço",
                "descricao": "Concentração incomum de empresas",
            })

    # 3. Contato compartilhado (email ou telefone)
    if matriz and matriz.email:
        shared = db.query(func.count(distinct(
            Estabelecimento.cnpj_basico
        ))).filter(
            Estabelecimento.email == matriz.email,
            Estabelecimento.cnpj_basico != cnpj_basico,
        ).scalar()

        if shared >= 1:
            flags.append({
                "tipo": "contato_compartilhado",
                "severidade": "baixa",
                "titulo": "Email usado por outra empresa",
                "descricao": f"O email {matriz.email} aparece em {shared + 1} empresas",
            })

    # Calcular score de risco (0-100)
    score = sum(
        35 if f["severidade"] == "alta" else
        20 if f["severidade"] == "media" else 10
        for f in flags
    )

    return {"score": min(score, 100), "flags": flags}

Cache: essencial para grafos

A construção do grafo envolve múltiplas queries recursivas. Sem cache, cada visualização levaria 1-3 segundos. Com Redis:

async def get_grupo_cached(cnpj_basico, db):
    cache_key = f"grupo:{cnpj_basico}"

    cached = redis.get(cache_key)
    if cached:
        return json.loads(cached)

    result = await get_grupo_empresarial(cnpj_basico, db)

    # Cache por 24h — dados mudam mensalmente
    redis.setex(cache_key, 86400, json.dumps(result))

    return result

Frontend: visualização do grafo

O JSON {nodes, edges} é renderizado no frontend com uma biblioteca de grafos. O componente React recebe os dados e renderiza nodes como cards e edges como linhas de conexão:

// Simplificado
function CorporateGroup({ cnpj }) {
  const [data, setData] = useState(null);

  useEffect(() => {
    fetch(`/api/intelligence/grupo/${cnpj}`)
      .then(r => r.json())
      .then(setData);
  }, [cnpj]);

  if (!data || data.nodes.length === 0) return null;

  return (
    <div className="relative">
      {data.nodes.map(node => (
        <NodeCard key={node.id} node={node} />
      ))}
      {data.edges.map((edge, i) => (
        <EdgeLine key={i} edge={edge} nodes={data.nodes} />
      ))}
    </div>
  );
}

Empresas ativas são destacadas em verde, inativas em vermelho. A empresa alvo da consulta fica em destaque. Sócios PF são mostrados com ícone de pessoa.

Casos de uso reais

Esse tipo de análise de rede revela coisas que dados tabulares escondem:

Due diligence: "O sócio da empresa que estou contratando também é sócio de uma empresa com situação 'Inapta'?"
Investigação: "Quem são as pessoas por trás de um grupo de empresas com o mesmo endereço?"
Análise de crédito: "Este solicitante de empréstimo tem sócios com histórico de empresas encerradas?"
Compliance: "O fornecedor que estamos avaliando tem conexões com empresas em situação irregular?"

Conclusão

Construir um explorador de rede societária envolveu:

Traversal recursivo com proteções contra explosão (depth, max nodes, ciclos)
Dual-type nodes (empresa vs pessoa) com expansão bidirecional
Heurísticas de red flags baseadas em padrões estatísticos
Cache agressivo — grafos são caros de construir e mudam raramente
Limites pragmáticos — depth 2 e 150 nodes cobrem 95% dos casos úteis

A beleza é que tudo isso roda sobre dados públicos. Não há scraping, não há API paga, não há magia. São dados da Receita Federal, organizados e conectados de forma que se tornam inteligência de verdade.

Quer explorar a rede societária de qualquer empresa brasileira? Teste no CNPJ Aberto de forma gratuita.

I touched X11 for the first time in 30 years to run wrangler login. YouTube audio came with it.

Kusnaware — Mon, 20 Apr 2026 15:49:51 +0000

What this post is about

Here’s what I actually ended up doing:

I wanted to run wrangler login on a GUI-less Ubuntu Server for a Cloudflare Workers project
I already knew that API Token is the proper solution
But I still wanted to see whether X11 forwarding could push the browser window to macOS
It worked
Then I got carried away, added PulseAudio forwarding, and ended up playing both YouTube video and audio on the macOS side

Environment:

macOS host
VMware Fusion
Ubuntu Server 24.04 guest

Why I even touched X11 in 2026

I was working on a Cloudflare Workers project and needed to run:

wrangler login

That launches a browser for OAuth authentication.

The problem was simple: my working environment was Ubuntu Server, not Ubuntu Desktop. No GUI, no local browser, no OAuth screen.

At that point there were two obvious options:

Method	Description
API Token	The proper way. Generate a token in Cloudflare Dashboard and export it
X11 forwarding	Push the Ubuntu-side browser window to macOS

I knew from the beginning that API Token was the sane answer.

I used X11 anyway.

Partly because I wanted to know whether it still worked. Partly because it had been about 30 years since I last touched X11, and apparently I make bad decisions in historically accurate ways.

Phase 1: Basic X11 forwarding setup

On macOS: install XQuartz

brew install --cask xquartz
open -a XQuartz

On Ubuntu Server: install required packages

sudo apt install -y xauth x11-apps

Enable X11 forwarding in sshd

sudo vi /etc/ssh/sshd_config

Uncomment or set:

X11Forwarding yes
X11DisplayOffset 10

Then restart SSH:

sudo systemctl restart sshd

X11DisplayOffset tells sshd which display number to start using for forwarded X11 sessions. The default is 10. In practice, $DISPLAY often ends up around localhost:10.0, unless that display number is already occupied.

Test it

From macOS, connect from XQuartz's xterm first:

ssh -Y user@ubuntu-vm

Then on Ubuntu:

echo $DISPLAY
xclock &

If a clock window appears on your Mac, X11 forwarding is working.

One thing that tripped me up

In my environment, an already-open Terminal.app session did not reliably get a usable $DISPLAY, while XQuartz's xterm worked consistently.

That does not mean Terminal.app is fundamentally incompatible.

Possible causes include:

XQuartz was installed but I had not fully logged out and back in yet
shell startup files like ~/.bashrc or ~/.zshrc were overwriting $DISPLAY

So if X11 forwarding behaves strangely, trying XQuartz's own xterm is a fast sanity check.

The Firefox trap — Snap strikes again

My first attempt was the obvious one:

firefox &

That failed with:

X11 connection rejected because of wrong authentication.

Why?

On Ubuntu 22.04 and later, Firefox is usually delivered via Snap. Snap isolation and X11 forwarding do not get along particularly well in this setup.

You can confirm it with:

which firefox
# /snap/bin/firefox

So I switched to a non-Snap build.

Phase 3: Install `firefox-esr` with APT pinning

I used the mozillateam PPA and installed firefox-esr.

Important detail: if you do this carelessly, later apt install / apt upgrade operations may drag you back toward Ubuntu's Firefox transition package and the Snap path.

So I pinned it explicitly.

sudo add-apt-repository -y ppa:mozillateam/ppa

sudo tee /etc/apt/preferences.d/mozilla-firefox << 'EOF'
Package: firefox*
Pin: release o=LP-PPA-mozillateam
Pin-Priority: 1001

Package: firefox*
Pin: release o=Ubuntu
Pin-Priority: -1
EOF

sudo apt update
sudo apt install -y firefox-esr

A couple of notes:

this mozillateam PPA is not the same thing as Mozilla's own packages.mozilla.org APT repository
I used it here because it solved the practical problem at hand
Pin-Priority: 1001 strongly prefers that source
Pin-Priority: -1 blocks Ubuntu's matching package candidates

Then:

firefox-esr &

And this time the browser window actually appeared on macOS.

I also got these warnings:

No matching fbConfigs or visuals found
glx: failed to create drisw screen

They looked dramatic, but in practice they just meant GPU acceleration was not happening. The browser still worked.

Phase 4: `wrangler login` finally works

Now the original goal:

wrangler login

Firefox ESR opened, Cloudflare's authentication page appeared, and login completed successfully.

At that point the real task was done.

Which should have been the end.

Instead, my brain immediately asked a much worse question:

If Firefox is already showing up on macOS, can I make YouTube audio come through too?

This is how projects rot.

Phase 5: Why video worked but audio did not

At this point YouTube video rendered fine over X11.

Audio did not.

That is expected, because X11 was never designed to forward audio.

X11 forwards:

window drawing commands
keyboard input
mouse input

X11 does not forward:

audio

So if I wanted audio too, I needed a second path.

Phase 6: PulseAudio forwarding

The idea was:

run a PulseAudio server on macOS
expose it to Ubuntu through SSH reverse port forwarding
tell Firefox on Ubuntu to use that forwarded PulseAudio endpoint

Like this:

On macOS: install and run PulseAudio

brew install pulseaudio
mkdir -p ~/.config/pulse

Then run it in the foreground:

pulseaudio --load="module-native-protocol-tcp auth-anonymous=1 auth-ip-acl=127.0.0.1" \
           --exit-idle-time=-1 --daemonize=no

You may see warnings like:

W: [] caps.c: Normally all extra capabilities would be dropped now...
W: [] socket-util.c: IP_TOS failed: Invalid argument

In my case they did not break anything.

auth-anonymous=1 is only acceptable here because this was a temporary setup behind SSH tunneling and limited to localhost. Exposing it more broadly would be reckless.

Yes, this is sketchy. No, I would not do this on a real server.

Also worth noting: PulseAudio is still usable here, but its own maintainers have said development has slowed down considerably, with bigger new work moving toward PipeWire / WirePlumber. For this kind of hack, it is still convenient.

On Ubuntu Server: install audio-related packages

sudo apt install -y ubuntu-restricted-extras ffmpeg libavcodec-extra pulseaudio

This post assumes Ubuntu Server 24.04. On Ubuntu Desktop 24.04, PipeWire / pipewire-pulse is the more standard baseline, so blindly adding PulseAudio can make the setup messier.

Phase 7: SSH with both X11 and audio forwarding

From macOS:

ssh -Y -R 24713:localhost:4713 user@ubuntu-vm

Meaning:

Option	Purpose
`-Y`	Trusted X11 forwarding
`-R 24713:localhost:4713`	Reverse forward Ubuntu port `24713` to macOS PulseAudio port `4713`

The 24713 port number was not magical. I just took PulseAudio's default 4713 and added 20000 so it would be easy to recognize and unlikely to collide.

Why `-Y` and not `-X`?

Option	Behavior
`-X`	Untrusted X11 forwarding. Safer, but some apps break
`-Y`	Trusted X11 forwarding. Less restricted, more dangerous

This part matters:

Only use -Y with machines you fully control.

A trusted X11 client can do nasty things, including keystroke monitoring. On your own VM behind your own SSH connection, fine. On someone else's server, absolutely not.

Phase 8: Point Ubuntu at the forwarded PulseAudio server

On Ubuntu:

export PULSE_SERVER=tcp:localhost:24713
firefox-esr &

At that point, both YouTube video and audio came through on the macOS side.

Against all dignity, it worked.

Why video and audio stayed in sync

A fair question here is:

X11 and PulseAudio are two different protocols on two different forwarding paths. Why didn't the audio drift badly?

The answer is that Firefox handled synchronization, not X11 or PulseAudio.

the media stream contains timestamps
Firefox schedules video frames and audio chunks against those timestamps
both streams are delayed by the tunnel, but roughly in similar ways
so the playback remains acceptably synchronized

So no, there is no elegant protocol-level sync mechanism here.

This is application-layer behavior carrying the whole mess on its back.

Security notes

Item	Status	Notes
X11 forwarding	OK-ish	Encrypted through SSH
PulseAudio forwarding	OK-ish	Also inside SSH
`auth-anonymous=1`	Risky unless contained	Keep it local and temporary
`auth-ip-acl=127.0.0.1`	Good idea	Restricts access to localhost
`-Y`	Dangerous	Use only with hosts you trust completely
SSH auth	Critical	Use keys, not password login

The weak point here is not X11 itself.

It is you doing something sloppy with trust boundaries.

As usual.

What I took away from this

1. X11 is ancient, but still weirdly capable

The design is old, backwards-seeming, and slightly cursed.

And yet:

the display server lives on the machine with the screen
the application runs somewhere else
the UI still shows up where you need it

That idea is ancient, but not dead.

2. Small UNIX-y pieces still compose in absurd ways

SSH handled encryption and tunneling
X11 handled remote windows
PulseAudio handled audio transport
Firefox glued the user experience together

No single part was especially elegant.

Together, they were good enough to get something undeniably stupid working.

3. The correct answer was still API Token

Let me be very clear:

If your real goal is just to use Cloudflare Workers cleanly on a headless machine, use API Token.

That remains the proper answer.

This post is about the side quest.

Final result

I started out trying to solve a boring problem:

run wrangler login on Ubuntu Server without a local GUI

I ended up with something much dumber and much more entertaining:

X11-forwarded Firefox on macOS
successful Cloudflare OAuth login
PulseAudio tunneled over SSH
YouTube video and audio playing through the host machine

Was it necessary? No.

Was it the right solution? Also no.

Did it work?

Annoyingly, yes.

Moral of the story: Sometimes the correct solution is boring. The fun solution is X11 + PulseAudio + questionable life choices.