DEV Community: opensource

I gave Claude a memory of everything I browse — here's the architecture

Kiell Tampubolon — Mon, 15 Jun 2026 08:05:42 +0000

Claude can read my files, my terminal, even my screen. But it had no idea what I read in my browser yesterday.

That gap bugged me enough to build BraveMCP: a local-first "second brain" that gives Claude Desktop access to my browsing history, bookmarks, highlights, and notes through the Model Context Protocol (MCP). Everything stays on my machine. No cloud, no tracking.

This is the technical write-up: the architecture, the one constraint that shaped the whole design, and the bugs that cost me the most time.

The constraint that shaped everything

MCP servers talk to Claude Desktop over stdio, a JSON-RPC stream on stdin/stdout. A browser extension lives in a sandbox and cannot speak stdio. It can only make outbound HTTP requests.

So the two halves of the system physically cannot talk to each other directly. That single fact drove the entire design.

The fix is a small HTTP bridge: an Express server running on port 3747, inside the same process as the MCP server. The extension POSTs browsing events to it; the MCP server reads from the shared database when Claude calls a tool.

The storage layer: hybrid search

Keyword search and semantic search each miss things the other catches. So BraveMCP runs both and merges them.

SQLite with FTS5 for fast BM25 keyword ranking over titles, summaries, notes, and highlights.
ChromaDB for cosine vector similarity, so "MCP security" still finds a page titled "Claude agent hardening."

// Merge keyword + vector hits; boost items that appear in both
const merged = new Map();
for (const m of chromaMatches) merged.set(m.id, { ...m, source: "semantic" });
for (const m of ftsMatches) {
  const existing = merged.get(m.id);
  if (existing) existing.relevance *= 1.1; // appears in both -> boost
  else merged.set(m.id, { ...m, source: "keyword" });
}

If ChromaDB is not running, the server degrades to FTS5-only instead of failing. Local-first means it has to work with whatever services you actually have up.

The AI pipeline, and why the fallback matters

When a page is captured, BraveMCP generates a summary and an embedding. It tries Ollama first (fully local: llama3.2 for summaries, nomic-embed-text for embeddings), then falls back to the Anthropic API.

But here is the trap I walked into. The first version, when no LLM was available, returned canned strings:

// before: this ignores the actual data entirely
return `Synthesis on "${topic}": Relies on the gathered browser research database.`;

That is useless. It says the same thing no matter what you searched. So I rewrote every fallback to be extractive: to build a real summary from the actual data, grouping matching pages by domain with real snippets pulled from SQLite. With no LLM at all, asking for a topic synthesis now returns the genuine sources. Different input produces different output. The "AI" tools stay useful even when there is no AI running.

Recovering forgotten pages

The tool I use most is find_forgotten_content. You give it a vague description and it does hybrid search, then re-ranks with time decay and a visit-count boost:

const timeDecay  = Math.max(0.5, Math.exp(-0.01 * daysElapsed));
const visitBoost = 1 + 0.2 * Math.log(visitCount);
const adjusted   = Math.min(0.99, relevance * timeDecay * visitBoost);

A page you opened three times last week beats one you glanced at once today. That matches how memory actually feels.

Two bugs that cost me hours

1. dotenv v17 broke the entire protocol. MCP communicates over stdout. dotenv v17 prints a status line to stdout by default. That one line corrupted the JSON-RPC channel and Claude Desktop refused to connect with a cryptic Unexpected token error. The fix was pinning dotenv@16. Two hours on a single log line.

2. The dual-process state problem. Claude Desktop and my dev client each spawn their own copy of the MCP server. Only the instance that grabs port 3747 receives extension data. The other had empty in-memory state, so tab tools returned nothing. The fix: stop treating in-memory state as the source of truth and fall back to SQLite, which both processes share.

What's in the box

A Manifest V3 extension (tab sync, bookmarks, context-menu highlights)
An MCP server exposing 13 tools (search_memory, find_forgotten_content, summarize_research_topic, generate_weekly_digest, suggest_tab_cleanup, and more)
SQLite + ChromaDB hybrid search
A test suite on Node's built-in runner, wired into CI

It is open source, MIT licensed: https://github.com/glatinone/BraveMCP

If you are building on MCP, the stdio-vs-HTTP bridge pattern is the part worth stealing. What would you want your AI to remember?

I'm building a read-only context engine for Kubernetes and AI agents

Luca Sepe — Mon, 15 Jun 2026 08:03:09 +0000

Kubernetes gives us an incredibly powerful API.

It also gives us a familiar debugging ritual:

kubectl get pods
kubectl describe pod ...
kubectl get svc ...
kubectl get endpointslices ...
kubectl get deployment ...
kubectl get events ...
kubectl get application.argoproj.io ...

Then we mentally stitch the result together.

Which workload owns this Pod? Which Service routes to it? Are there ready endpoints? Is the namespace unhealthy because of one bad Deployment, a missing backend, warning Events, or something else?

Which facts should I paste into an incident, attach to a CI failure, or give to an AI assistant before asking it to reason?

I started building kctx because I wanted a small tool for that missing middle layer: not raw YAML, not a dashboard, not an auto-remediation system.

Just structured Kubernetes context.

The short version

kctx is a read-only Kubernetes context engine for humans, scripts, and AI agents.

It turns live Kubernetes API state into a compact model of:

entities: Pods, Services, workloads, Nodes, PVCs, ConfigMaps, Secrets, and supported CRDs
relations: ownership, selection, scheduling, service routing, and dependencies
signals: factual observations such as unhealthy Pods, missing endpoints, warning Events, failed readiness, or degraded workloads
graphs: dependency and ownership views around supported resources
dumps: deterministic namespace snapshots for automation, incident review, and agent grounding

The design goal is intentionally conservative:

read cluster state, normalize facts, avoid speculative root-cause claims.

That boundary matters.

I do not want kctx to be a tool that confidently invents explanations. I want it to provide the evidence layer that humans, automation, and AI agents can use before reasoning.

Why another Kubernetes tool?

Most Kubernetes tools are optimized for one of a few jobs:

kubectl exposes the raw API very well
dashboards make current state visible
monitoring systems track metrics and alerts over time
logging systems answer "what happened in the process?"
GitOps tools understand desired state and sync status

Those are all useful. I use them too.

But during debugging, there is still a recurring gap between "I can query every object" and "I have a compact operational picture of what is connected to what."

For example, when looking at a Service, I often care less about the complete YAML and more about questions like:

Which EndpointSlices back this Service?
Which endpoints are ready?
Which Pods do those endpoints point to?
Who owns those Pods?
Which Nodes are involved?
Are there obvious factual signals, such as missing endpoints or no ready Pods?

That is the kind of context kctx tries to assemble.

kctx trace service payments-api --namespace payments

For a namespace-level view:

kctx health namespace payments

For a focused resource view:

kctx explain pod api-xyz --namespace payments

And when you need a deterministic JSON snapshot for automation or incident review:

kctx dump namespace payments > payments-dump.json

The important constraint: read-only

kctx does not mutate Kubernetes resources.

It does not:

restart workloads
apply manifests
patch resources
delete anything
perform remediation
claim to know the root cause

That is not because remediation is uninteresting. It is because I think the context layer should be boring, auditable, and safe before anything else is built on top of it.

This becomes even more important when AI agents enter the picture.

If an agent needs Kubernetes context, I would rather give it a narrow read-only tool that returns structured facts than hand it broad cluster access and hope the prompt is enough of a safety boundary.

Kubernetes context for AI agents

One of the areas I am experimenting with is exposing kctx through the Model Context Protocol.

Current serve modes include:

kctx serve --mode mcp
kctx serve --mode mcp-sse

The MCP tools currently cover the same core context operations:

get_namespace_health
explain_resource
trace_service
get_pod_graph
dump_namespace

The idea is simple: let an AI assistant ask for Kubernetes context without giving it mutation capabilities.

No remediation.
No raw YAML firehose.
No root-cause guessing dressed up as certainty.

Just compact operational facts that can be used as evidence.

There is also an MCP/SSE release test guide for anyone who wants to try this with a local kind cluster, the released Helm chart, Online Boutique, ngrok, Codex, Claude Code, or ChatGPT Developer Mode:

https://github.com/lucasepe/kctx/tree/main/docs/kctx-mcp-sse-release-test-guide.pdf

Important note: the MCP/SSE endpoint is read-only, but built-in AuthN/AuthZ is not production-ready yet. Treat it as local-lab or trusted-network tooling for now, or put it behind an external access-control layer.

CRDs need semantics, not wishful thinking

Another design choice: kctx does not pretend that every custom resource can be understood generically.

Kubernetes discovery can tell you that a CRD exists. It cannot tell you what that CRD means operationally.

So kctx uses explicit adapters for ecosystem-specific resources. An adapter can translate a CRD into the same core model used by the rest of the project: resource identity, compact status, related entities, relations, signals, and graph nodes or edges.

The current adapter set includes:

Argo CD Application
Argo CD AppProject
cert-manager Certificate

That approach is slower than saying "we support every CRD", but I think it is more honest. If a tool is going to describe operational context, it should know what it is describing.

JSON first, because scripts and agents need contracts

The CLI and HTTP API emit versioned JSON by default.

Responses include a schema version and kind, for example:

{
  "schemaVersion": "kctx.io/v1alpha1",
  "kind": "NamespaceHealth"
}

The repository includes machine-readable JSON schemas under:

schemas/kctx.io/v1alpha1

That part may sound less exciting than graphs or agents, but it is one of the pieces I care about most.

If humans are the only users, text output can be enough. If scripts, CI systems, incident tooling, and AI agents are also users, the output needs a contract.

Data safety

kctx` is designed to provide operational context, not sensitive data.

It avoids returning raw manifests, Secret data, ConfigMap data, raw environment variables, logs, and workload metrics.

Supported outputs also pass metadata and Kubernetes messages through a small redaction policy for common secret-bearing keys and text patterns.

This is not a magic privacy shield, but it is an intentional boundary in the design.

A tiny example workflow

Install:

bash curl -fsSL https://raw.githubusercontent.com/lucasepe/kctx/main/install.sh | bash

Run against your current Kubernetes context:

bash kctx health namespace default kctx explain pod <pod-name> --namespace default kctx trace service <service-name> --namespace default kctx graph pod <pod-name> --namespace default --render mermaid kctx dump namespace default

Or run the read-only HTTP server:

bash kctx serve curl http://localhost:8080/health/namespace/default

Or install the in-cluster server with Helm:

bash VERSION=0.3.0 helm upgrade --install kctx \ "https://github.com/lucasepe/kctx/releases/download/v${VERSION}/kctx-${VERSION}.tgz" \ --namespace kctx-system \ --create-namespace

Then:

bash kubectl -n kctx-system port-forward svc/kctx 8080:8080 curl http://localhost:8080/health/namespace/default

What I am looking for

The project is still under active development. It is useful today, but I am still hardening packaging, production deployment guidance, auth boundaries for server mode, and client compatibility around MCP/SSE.

I would love feedback from SREs, platform engineers, Kubernetes operators, and people experimenting with AI-assisted operations.

In particular:

Does the output feel like useful operational context?
Are the signals too noisy, too sparse, or missing obvious facts?
Which CRDs would be most valuable to support next?
Does the JSON contract work for your scripts or internal tools?
Does the MCP interface fit how you want AI agents to inspect infrastructure?
Where does the install, Helm chart, or local test flow feel confusing?
What would make you trust a tool like this in a production debugging workflow?

If you try the MCP/SSE path, I am especially interested in:

OS and Kubernetes/kind version
AI client and version
transport used: localhost, port-forward, ngrok, or internal URL
whether the standalone smoke test passed
whether the AI client discovered and called the tools
any rough edges in the responses

The repo

GitHub:

https://github.com/lucasepe/kctx

If this idea resonates with you, a star would help the project reach more Kubernetes and platform people.

But even more useful: open an issue, tell me where the model feels wrong, or share a debugging scenario where structured context would have saved time.

That is the kind of feedback that can make kctx sharper.

We Submitted 59 PRs and Got 0 Merged — Here Is What We Learned

Кирилл — Mon, 15 Jun 2026 08:00:17 +0000

I've been working on integrating AI-powered features into my e-commerce platform for the past year. Honestly, it's been a wild ride. My team and I decided to contribute to an open-source project that aligns with our goals, hoping to give back to the community and gain some experience. We spent 3 months submitting 59 pull requests, but none of them were merged. I remember last Tuesday, I was going through our 3-server setup, trying to figure out why our changes weren't being accepted.

The project we contributed to is a popular AI-powered chatbot built using Node.js and TensorFlow.js. We chose this project because it aligns with our system's requirements, and we believed that our contributions could make a significant impact. Our goal was to improve the chatbot's natural language processing capabilities by integrating a custom intent recognition model. The thing is, we didn't just want to contribute to the project - we wanted to learn from it too.

We started by forking the repository and creating a new branch for our contributions. Our first PR was a simple bug fix, which we thought would be easy to get merged. However, the maintainers asked us to add more test cases and improve the code documentation. We obliged, and here's an example of how we added test cases using Jest:

// tests/intentRecognition.test.js
const intentRecognition = require('../intentRecognition');

describe('intentRecognition', () => {
  it('should recognize intent correctly', () => {
    const input = 'I want to buy a product';
    const expectedOutput = 'buy_product';
    expect(intentRecognition(input)).toBe(expectedOutput);
  });
});

We also improved the code documentation by adding JSDoc comments:

// intentRecognition.js
/**
 * Recognizes the intent behind a given input string.
 * @param {string} input - The input string to recognize intent from.
 * @returns {string} The recognized intent.
 */
function intentRecognition(input) {
  // implementation
}

One of our PRs aimed to improve the chatbot's performance by reducing the latency of the intent recognition model. Turns out, we were able to achieve this by optimizing the model's architecture and using a more efficient algorithm. We measured the performance improvement using the performance-now library:

// performanceTest.js
const performance = require('performance-now');
const intentRecognition = require('../intentRecognition');

const input = 'I want to buy a product';
const startTime = performance();
const output = intentRecognition(input);
const endTime = performance();
const latency = endTime - startTime;
console.log(`Latency: ${latency}ms`);

Our optimization reduced the latency from 500ms to 200ms, resulting in a 60% improvement. This was a significant win for us, and we were excited to see the impact it could have on our system.

Although none of our PRs were merged, we still benefited from the experience. We learned how to optimize our system's performance, which resulted in a 30% reduction in cloud costs. We also improved our testing and documentation processes, which saved us 10 hours of development time per week. This was a huge win for us, and we were able to apply these lessons to our production system.

We spent a total of 240 hours working on the PRs, which is equivalent to 6 weeks of full-time development. Although it was a significant investment, we gained valuable experience and insights that we can apply to our system. We also developed a custom AI agent that we can use in production, which will save us 20 hours of development time per month.

In the end, I realized that the time and effort we invested were not wasted. We saved around 40 hours of development time and $1,500 in cloud costs per month. And when I did the math, I was amazed to see that we saved our company $27,000 over the next 6 months. It just goes to show that even unmerged PRs can have a significant impact on your business.

Our OS AI skills framework is actually getting some heat - new contributors welcome <3

Ross Peili — Mon, 15 Jun 2026 07:51:55 +0000

Today, we released Skillware v0.3.6, Skillware is basiclaly an open-source framework for packaging Python capabilities (wallet screening, PDF tools, compliance checks, etc.) as skills agents call via normal tool APIs, instead of generating one-off code each time.

This release is mostly contributor-facing: CLI works out of the box (pip install skillware, python -m skillware fallback), clearer help, CI runs bundle tests under skills/, and a small wallet_screening fix, and this made me pause for a moment and be grateful of all the contributors and what we've built.

Today, we have over 40 stars and 12 contributors from all over the world. I know it might sound like nothing to some, but we started from zero, and slowly built this upwards together. I won't explain here why Skillware is better than agent skills, you can check the docs or read articles about it, but I wanna share why I am so excited about these numbers, even tho again, to some they might sound non worthy of hype.

Initially, we built skillware having machines in mind. Most people are building AI, apps, services, tools, products, targeting humans. But in 2026, AI is your core audience, the one that makes up more than half of the internet traffic. I mean, even when humans dyor they essentially employ an AI to do the search, even when you google things, AI is replying. So, the idea was to make Skillware easily accessible, discoverable, parsable, testable, and usable by LLMs and AI Agents with 0 friction.

We built the website in a way that makes it easy for agents to find, browse skills, find skills they need, and use them out of the box with one code block, no matter which model or framework they are coming from.

On top of that, our repo is not only AI friendly, but AI focused. YES! we expect that everyone is using AI tools, code assitsants and AI enabled IDEs. There is no excuse to not do it in 2026. Our repo is build in such a way, that literally any agent or model can understand it instantly and start solving issues with single shots, without back and forths, without breaking files, or ignoring important ripple effects or complementary files etc.

I take this moment to celebrate Skillware. Even if I am celebrating alone ❤️ and I would like to welcome anyone who wants to contribute to open source AI, or sharpen their python skills to join us and give it a spin, not just a project/tool, but also as modern clean cut repo tailored for agents at work. Lots of good first issues, as well as complex and sophisticated skill bundles that are not just silly md prompts.

You can check the repo at arpahls/skillware, install with pip install skillware, or visit skillware.site

I resurrected an archived C++/Qt6 desktop mascot and injected a fully autonomous local AI agent core into it (Powered by Ollama/Qwen)

Lumina403 — Mon, 15 Jun 2026 07:47:09 +0000

Hey everyone,

I’ve been working on a small passion project for the past few weeks and wanted to share it here: Lumina AI.

It started as me reviving an old archived project called Shijima-Qt—a simple Qt desktop mascot. I always liked the idea, so I tried to push it further and turn it into something more useful: a lightweight, offline AI desktop agent.

I’m a 17-year-old self-taught developer from Indonesia, and this project has basically been my way of learning more about C++, desktop applications, and local AI systems by building something far beyond what I originally thought I could handle.

Some of the things I ended up implementing include:

Local AI integration through Ollama
A native tool-calling system written in C++
Desktop and active-window awareness
Basic file and system automation
Lightweight web scraping using Qt networking
Persistent JSON-based memory between sessions

The project is built with C++17, Qt6, Make, and Ollama, with a strong focus on staying lightweight and running entirely offline.

One thing I tried to be careful about was preserving the original project's history. The repository still contains the full commit history from Shijima-Qt, since I see this more as continuing an abandoned idea rather than replacing it.

The project is open source under GPLv3.

I'm still learning, so I'd be especially interested in hearing how more experienced C++ and AI developers would approach some of these problems differently. If you spot architectural mistakes, questionable design decisions, or areas that could be improved, I'd genuinely love to learn from the feedback.

Repository:
https://github.com/Lumina403/Lumina-AI

Wavelength Calculator: Easily Calculate Wave Length, Frequency, and Wave Speed

CloudAiRambo — Mon, 15 Jun 2026 07:43:46 +0000

Understanding wavelength is essential in physics, engineering, telecommunications, optics, and even everyday technologies like Wi-Fi, radio, and mobile networks. Whether you're a student learning wave mechanics or a professional working with electromagnetic signals, calculating wavelength accurately is important.

To make calculations fast and error-free, try the free online Wavelength Calculator:

https://www.cloudaipdf.com/calculators/wavelength/

What Is Wavelength?

Wavelength is the distance between two identical points in a repeating wave, such as two consecutive crests or troughs.

It is commonly represented by the Greek letter λ (lambda).

Wavelength is usually measured in:

Meters (m)
Centimeters (cm)
Millimeters (mm)
Nanometers (nm)

The wavelength of a wave depends on both its frequency and speed.

The Wavelength Formula

The standard formula for wavelength is:

λ = v ÷ f

Where:

λ = Wavelength
v = Wave speed
f = Frequency

This equation shows that wavelength and frequency are inversely proportional.

When frequency increases, wavelength decreases.

When frequency decreases, wavelength increases.

Real-World Examples of Wavelength

Wavelength calculations are used in many fields:

Radio Broadcasting

Radio stations transmit signals at specific frequencies. Engineers use wavelength calculations when designing antennas and communication systems.

Wi-Fi Networks

Wireless routers operate at frequencies such as 2.4 GHz and 5 GHz. These frequencies correspond to different wavelengths that affect signal propagation.

Fiber Optic Communication

Light signals travel through optical fibers using specific wavelengths to transmit data across long distances.

Medical Equipment

Various imaging and diagnostic systems rely on wave behavior and wavelength calculations.

Astronomy

Scientists analyze wavelengths emitted by stars and galaxies to understand their composition and movement.

Example Wavelength Calculation

Suppose a wave travels at:

Speed = 300,000,000 m/s
Frequency = 100 MHz

Using the formula:

λ = 300,000,000 ÷ 100,000,000

Result:

Wavelength = 3 meters

This means each complete wave cycle occupies a distance of three meters.

Instead of performing manual calculations, you can instantly calculate results using:

https://www.cloudaipdf.com/calculators/wavelength/

Why Use an Online Wavelength Calculator?

Manual calculations are straightforward for simple values, but they become more complicated when dealing with:

Scientific notation
High frequencies
Unit conversions
Engineering calculations
Laboratory measurements

A dedicated calculator helps eliminate mistakes and saves time.

Benefits include:

Instant calculations
Accurate results
Easy-to-use interface
Helpful for students and professionals
No software installation required
Common Mistakes When Calculating Wavelength
Using Incorrect Units

Frequency should be entered in the correct units, such as Hertz (Hz), kilohertz (kHz), megahertz (MHz), or gigahertz (GHz).

Mixing Speed and Frequency Units

Always ensure that speed and frequency values are compatible.

Confusing Frequency and Wavelength

Many beginners assume that higher frequency means longer wavelength. In reality, the opposite is true.

Forgetting Scientific Notation

Electromagnetic waves often involve very large or very small numbers, making scientific notation important.

Who Can Benefit From a Wavelength Calculator?

This tool is useful for:

Physics students
Science teachers
Electrical engineers
Telecommunications professionals
Radio operators
Researchers
Network engineers
Electronics hobbyists

Anyone working with waves, signals, or electromagnetic radiation can benefit from quick wavelength calculations.

Applications of Wavelength in Modern Technology

Modern technology depends heavily on wavelength calculations.

Examples include:

Mobile communications
Satellite systems
Radar technology
GPS navigation
Optical networking
Medical imaging
Wireless internet
Scientific research

Understanding wavelength helps professionals optimize performance, improve signal quality, and design more efficient systems.

Final Thoughts

Wavelength is one of the fundamental concepts in physics and wave science. From radio transmissions and internet connectivity to optical communications and astronomy, wavelength calculations play a critical role in modern technology.

If you need a fast and reliable way to calculate wavelength, frequency, or wave speed, try the free online Wavelength Calculator:

👉 https://www.cloudaipdf.com/calculators/wavelength/

Whether you're studying physics, designing communication systems, or solving engineering problems, this tool can help you obtain accurate results in seconds.

Working Capital Calculator: The Financial Metric Every Business Owner Should Track

CloudAiRambo — Mon, 15 Jun 2026 07:41:13 +0000

Running a business is not just about making sales. A company can be profitable on paper and still struggle to pay suppliers, employees, or day-to-day expenses. This is where working capital becomes one of the most important financial metrics for business owners, startups, freelancers, and finance professionals.

If you want to quickly calculate your company's working capital, you can use this free online tool:

https://www.cloudaipdf.com/calculators/working-capital/

What Is Working Capital?

Working capital measures a company's short-term financial health. It shows whether a business has enough resources to cover its immediate obligations and continue operating smoothly.

The standard formula is:

Working Capital = Current Assets − Current Liabilities

Current assets typically include:

Cash and cash equivalents
Accounts receivable
Inventory
Short-term investments

Current liabilities may include:

Accounts payable
Short-term loans
Taxes payable
Payroll obligations

A positive result generally indicates that a business can comfortably meet its short-term financial commitments, while a negative result may signal liquidity challenges. Financial experts widely use this formula to evaluate operational efficiency and short-term financial stability.

Why Working Capital Matters

Many business owners focus only on revenue and profit. However, cash flow issues often arise even when sales are growing.

Healthy working capital helps businesses:

Pay suppliers on time
Cover employee salaries
Purchase inventory
Handle unexpected expenses
Invest in growth opportunities
Improve creditworthiness with lenders

Without sufficient working capital, businesses may face operational disruptions or be forced to rely on expensive short-term financing.

Example Calculation

Imagine a company has:

Current Assets: $75,000
Current Liabilities: $45,000

Working Capital:

$75,000 − $45,000 = $30,000

This means the business has $30,000 available after covering its short-term obligations.

Instead of calculating manually every time, you can use the free Working Capital Calculator:

https://www.cloudaipdf.com/calculators/working-capital/

Signs of Strong Working Capital Management

Businesses with effective working capital management often:

Collect customer payments quickly
Maintain optimal inventory levels
Control operating expenses
Negotiate favorable supplier terms
Monitor cash flow regularly

Good working capital management supports both stability and growth. Financial analysts often consider it one of the key indicators of operational efficiency.

Common Mistakes Businesses Make

Ignoring Accounts Receivable

Outstanding invoices can create cash shortages even when sales are strong.

Overstocking Inventory

Excess inventory ties up cash that could be used elsewhere.

Paying Suppliers Too Early

While maintaining good supplier relationships is important, paying invoices significantly before due dates can reduce available cash.

Not Monitoring Working Capital Regularly

Many businesses review finances only monthly or quarterly, which can delay identifying cash flow issues.

How a Working Capital Calculator Helps

A reliable calculator eliminates manual calculations and reduces the chance of errors.

The free calculator available at:

https://www.cloudaipdf.com/calculators/working-capital/

allows users to:

Calculate working capital instantly
Evaluate short-term financial health
Support budgeting decisions
Improve financial planning
Save time compared to spreadsheet calculations

Whether you're a startup founder, accountant, finance student, or small business owner, having quick access to this metric can improve financial decision-making.

Who Should Use a Working Capital Calculator?

This tool is useful for:

Small business owners
Startups
Accountants
Financial analysts
Entrepreneurs
Finance students
Business consultants

Anyone responsible for managing cash flow can benefit from understanding and tracking working capital.

Final Thoughts

Working capital is more than a simple accounting formula. It is a key indicator of a company's ability to operate, grow, and survive unexpected financial challenges.

Regularly monitoring your working capital helps ensure your business maintains enough liquidity to meet short-term obligations while positioning itself for future growth.

If you want a fast and free way to calculate working capital, try the online calculator here:

👉 https://www.cloudaipdf.com/calculators/working-capital/

Understanding your numbers today can help prevent financial problems tomorrow.

5 heuristic bugs that made my design-token tool call a bright cream page "dark and moody"

Yuvraj Angad Singh — Mon, 15 Jun 2026 07:36:19 +0000

i maintain a small cli called brandmd. it points a headless browser at any url, reads the computed css, and writes a DESIGN.md that AI coding agents (Claude Code, Cursor, Gemini CLI) can read so they build on-brand UI instead of guessing.

last week i ran it on cognition.ai's FrontierCode blog post and the output was embarrassing. the page is cream and bright, basically a magazine layout. here is what brandmd said about it:

mood: "Dark and moody"
#F7F6F5 got named "Light Muted Orange" (it is off-white)
#2200FF got named "Dark Blue" (it is the most electric blue you have ever seen)
border radii: 4px, 3.35544e+07px (yes, scientific notation in a design doc)
type scale: 11px, 11.05px, 11.5px, 12px, 12.5px, 12.75px, 13px (seven sizes that are really three)

every single one was a different heuristic bug. here is the anatomy of each, because they are the kind of mistakes that look fine in a unit test and fall apart on a real site.

1. mood from averaging luminance

the mood line came from averaging the luminance of the whole palette, then bucketing: high average is "light and airy", low is "dark and moody".

the problem is averaging treats a tiny dark footer the same as a full-viewport cream background. cognition has a dark footer and a few dark chips. they dragged the average down far enough to flip the whole verdict, even though 90% of the screen is cream.

the fix was to stop averaging and anchor to the dominant background instead. find the background color that covers the most viewport area, judge the mood from that. one color, weighted by how much of the page it actually owns.

Bright, high contrast; off-white background dominates with black text and vivid blue accents

that line is evidence-based now. it names the dominant color and what it does, instead of a vibe word.

2. color names from nearest-RGB

color naming used nearest-neighbor in RGB space against a list of named colors. cream (#F7F6F5) has a slight warm cast, so the closest named color by raw RGB distance landed on a muted orange. technically the nearest point. completely wrong to a human.

RGB distance is a bad model for how we name colors. switched to HSL rules instead:

lightness above ~90% is a near-white. if the hue is warm it reads as cream, if cool it reads as off-white. it never gets a chromatic name.
high saturation in the mid lightness band gets "vivid".
everything else maps hue ranges to names.

now #F7F6F5 is "off-white" and #2200FF is "vivid blue".

3. blue is "dark" by luminance

this one is the most counterintuitive. #2200FF is a bright electric blue, but brandmd called it "dark blue". why? because the tone word was derived from luminance, and blue barely contributes to luminance.

the standard luminance formula weights the channels roughly:

luminance = 0.2126*R + 0.7152*G + 0.0722*B

blue is only 7% of the weight. so a fully saturated blue scores darker than a muted brown. by luminance, #2200FF genuinely is "dark", even though your eye reads it as loud and bright.

the fix is to take tone words from HSL lightness, not luminance. lightness treats the channels evenly, so a mid-lightness blue reads as a mid-tone, and the saturation check adds "vivid".

4. scientific notation in a design doc

3.35544e+07px. that is what getComputedStyle returns for border-radius: 9999px on a pill-shaped button (the browser resolves the "make it fully round" intent into a giant pixel value).

brandmd was printing the raw computed value straight into the markdown. worse, it was feeding that giant number into the shape-language inference, so a sharp-edged site with one pill button got described as "rounded and friendly".

two fixes:

normalize any radius above ~999px to 9999px (pill) for display, keep it CSS-valid.
exclude pill values from the "is this site rounded or sharp" judgment. judge shape from the largest non-pill radius.

5. sub-pixel font sizes are noise

the type scale had seven sizes between 11 and 13px because sub-pixel rendering and zoom produce values like 11.05px and 12.75px. those are not distinct steps in a design system, they are rendering artifacts.

the fix is a clustering pass: round every size to the nearest 0.5px before ranking, then dedupe. seven noisy values collapse to the three real ones.

the lesson that actually mattered

the bug that taught me the most was not in this list directly. while fixing the palette i found that element count is a terrible proxy for visual dominance.

brandmd was ranking colors by how many elements used them. a 6% alpha black overlay sat on dozens of tiny chips, so by element count it outranked the actual page background that lived on one big element. the "primary" color was an overlay nobody consciously sees.

weighting by viewport area share instead of element count fixed the palette ordering in one line. how much of the screen a color owns is a far better signal than how many nodes reference it.

try it

all of this shipped in brandmd v0.12. you can reproduce the before and after yourself:

npx brandmd@0.11.1 https://cognition.ai/blog/frontier-code   # the bad output
npx brandmd@0.12.0 https://cognition.ai/blog/frontier-code   # the fixed output

the full changelog has the side by side. repo is here if you want to point your coding agent at a real design system instead of letting it guess.

Stop pasting JWTs into random websites — I built a zero-dep CLI to decode them in your terminal

benjamin — Mon, 15 Jun 2026 07:31:16 +0000

You're debugging an auth issue. There's a JWT in a log line, or in an Authorization header you copied out of the network tab. You need to know two things: what's in it, and has it expired?

So you do what everyone does — paste it into jwt.io.

Stop for a second. That token is often a live credential. You just pasted it into a third-party web page: it's in your browser history, maybe in someone's logs, maybe cached. For a token that's still valid, that's a real problem.

The other option is the pipeline nobody can remember:

echo "$TOKEN" | cut -d. -f2 | base64 -d 2>/dev/null | python -m json.tool

...which doesn't decode the header, doesn't tell you whether it's expired, breaks on base64url padding, and needs base64 -d on Linux but -D on macOS.

So I built jwtpeek: one command, fully offline, zero dependencies.

npx jwtpeek <token>

Header
  {
    "alg": "HS256",
    "typ": "JWT"
  }

Payload
  {
    "sub": "1234567890",
    "name": "John Doe",
    "exp": 1609459200
  }

Claims
  issued   2020-12-31 23:00:00 UTC  5y 166d ago
  expires  2021-01-01 00:00:00 UTC  EXPIRED 5y 166d ago

It turns every time claim (exp, iat, nbf, auth_time, …) into a real date plus "expires in 3h 21m" / "EXPIRED 2d ago" — which is usually the actual answer you were after.

It fits how you already paste tokens

pbpaste | jwtpeek                  # pipe it in
echo "$AUTH_HEADER" | jwtpeek      # a leading "Bearer " / "Authorization:" is stripped
jwtpeek "$t" --json | jq .payload  # machine-readable; stdout stays pure

Decoded output goes to stdout; the "signature not verified" note goes to stderr, so piping into jq stays clean.

Script-friendly exit codes

0   decoded OK and not expired (or no exp claim)
1   decoded OK but expired
2   not a valid JWT

jwtpeek "$TOKEN" >/dev/null 2>&1 && echo "still valid" || echo "expired or invalid"

Decode, not verify — on purpose

The one thing I want to be loud about: jwtpeek does not check the signature. It shows you what a token says, not whether it's authentic. Verifying a signature needs the issuer's secret/public key, which is out of scope for a "what's in this thing" tool. Never make an authorization decision from decoded-but-unverified contents — jwtpeek prints a reminder on stderr every time.

A couple of design notes

Zero dependencies, both ecosystems. Node uses Buffer, Python uses base64/json/datetime. Nothing else — npx/pipx and it runs.
NumericDate is seconds per RFC 7519, but some issuers wrongly emit milliseconds. jwtpeek detects implausibly large values (a real seconds value won't reach 1e12 until the year 5138) and handles both.
The Node and Python ports are behavior-identical: same flags, same exit codes, byte-identical --json.

Install

npx jwtpeek <token>        # Node >= 18
pip install jwtpeek        # Python >= 3.8

npm: https://www.npmjs.com/package/jwtpeek
PyPI: https://pypi.org/project/jwtpeek
GitHub: https://github.com/jjdoor/jwtpeek

How do you inspect tokens today — jwt.io, a base64 one-liner, an editor plugin? And would you actually want signature verification (bring-your-own-key) in a tool like this, or does that cross the line from "decoder" into "just do it properly in your app"? Curious what people think.

I Built Calcify — All Calculators in One Place

Parsun kumar Patel — Mon, 15 Jun 2026 07:29:07 +0000

As developers, students, and professionals, we constantly search for calculators:

✅ EMI Calculator
✅ SIP Calculator
✅ BMI Calculator
✅ Percentage Calculator
✅ Age Calculator
✅ Unit Converters
✅ And dozens more...

I got tired of opening different websites every time I needed a simple calculation.

So I built Calcify — a growing collection of calculators and tools available in one place.

🔗 Try it here:
https://new-calcify-calcify.vercel.app

Why I Built It
Fast and mobile-friendly
No unnecessary clutter
Multiple calculators in one platform
Free to use
Regular updates and new tools being added
Current Focus

I'm continuously improving:

UI/UX
Performance
More finance calculators
More developer tools
Better search and navigation
Looking for Feedback

I'd love to hear:

What calculator/tool should I add next?
What can be improved?
Any bugs or issues you find?

Building in public and learning every day. 🚀

The Best React Data Grid Is the One You Will Not Hate After Feature Request Number Seven

Vitalii Shevchuk — Mon, 15 Jun 2026 07:21:09 +0000

I have never seen a product manager open a ticket called:

Turn this table into a small operating system.

It happens one perfectly reasonable request at a time.

"Can we sort it?"

"Can status be editable?"

"Can I paste this column from Excel?"

"Can the total stay visible?"

"Can it remember my filters?"

"Can it load the next ten thousand rows from the server?"

By feature request number seven, the table has focus rules, validation, permissions, persistence, and performance problems.

Congratulations. You built a product inside a rectangle.

That is why most "best React data grid" articles miss the useful question. Every grid looks good with twenty rows and a sort icon.

The real question is:

Which grid will you still like after the roadmap arrives?

Here is my actual shortlist

If I wanted the safest established answer, I would start with AG Grid.

If I wanted complete control over markup and styling, I would start with TanStack Table.

If the app already lived inside Material UI, MUI X Data Grid would be hard to ignore.

If users wanted an actual spreadsheet experience, I would test Handsontable.

If a focused open-source grid was enough, I would test Comcast React Data Grid.

If I were building an application workflow that could grow in several directions, I would put Ace Grid in the final two.

That last sentence is the interesting one.

Why Ace Grid is on this list

Ace Grid is not trying to win the longest-feature-list contest.

Its useful position is narrower:

It is for the awkward middle where a table is no longer enough, a workbook is the wrong data model, and a full enterprise-grid commitment feels premature.

Ace Grid Core is MIT licensed. It covers the grid foundation: editing, selection, sorting, filtering, virtualization, CSV workflows, theming, and custom cells.

When the product becomes more spreadsheet-like, Pro adds formulas, validation, Excel import and export, grouping, tree data, spanning, sparklines, and advanced filtering.

When browser-owned data is no longer enough, Enterprise adds server row model, pivoting, charts, and master-detail.

That progression matters.

You can start with the workflow you have instead of buying the workflow somebody might request next year.

The Ace Grid features that matter after the demo

The tier path is only half the story.

Ace Grid also has compatibility packages for AG Grid and MUI migrations. They translate known configuration and produce diagnostics about what maps, what needs manual work, and what may require another tier.

That is more honest than promising a magic migration button.

Ace Grid also has schema packages for describing grid state and validating structured output, including AI-generated results, before the application renders or applies them.

This matters when an assistant returns a table that users can edit, approve, or use to trigger actions.

The model should not be allowed to invent arbitrary component props and hope for the best.

These are not the features that make a five-second demo exciting.

They are the features that matter when a grid becomes infrastructure.

The honest reason not to choose Ace Grid

Ace Grid is younger.

There are fewer production years behind it, fewer community answers, and fewer engineers who already know it.

That is a real cost.

I would not choose it because of this article. I would build the ugliest screen in the product:

the custom editor everyone fears
invalid Excel paste
keyboard movement through errors
pinned rows and columns
a very wide virtualized view
a slow server response
a rejected save
restored filters and column state

If Ace Grid passes that screen, the staged architecture becomes a meaningful advantage.

If it does not, choose the library that passes.

That is how a challenger earns trust.

1. AG Grid: the safe heavyweight

AG Grid is the maturity and breadth choice.

It has deep documentation, a large ecosystem, multiple framework integrations, and an enormous feature surface.

For many teams, that ends the discussion.

The question is not whether AG Grid can do enough. It almost certainly can.

The question is how much platform you want, which edition your real workflow needs, and how much application code will become AG Grid-shaped.

Choose it when: proven breadth matters more than keeping the grid footprint small.

2. MUI X Data Grid: the ecosystem choice

MUI X becomes very attractive when the rest of the application already uses Material UI.

Shared themes, components, conventions, and team experience save real time.

Choose it when: Material alignment removes work you would otherwise need to build.

Do not choose it only because the demo looks familiar.

3. TanStack Table: the ownership choice

TanStack Table is headless.

It gives you state and data-processing tools without pretending to be a finished visual grid.

That is freedom.

It is also work.

Your application owns more rendering, editing, menus, keyboard behavior, virtualization integration, and accessibility.

Choose it when: owning every pixel and interaction is intentional.

"Lightweight" is not always less work. Sometimes the weight moved into your repository.

4. Handsontable: the spreadsheet choice

Handsontable makes sense when users think in cells, ranges, formulas, paste operations, autofill, and undo.

That is different from an application grid, even when both products look like rows and columns.

Choose it when: spreadsheet behavior is the product, not a supporting interaction.

5. Comcast React Data Grid: the focused choice

React Data Grid provides TypeScript, editing, selection, virtualization, frozen columns, custom renderers, and keyboard accessibility in a focused open-source package.

Choose it when: that capable, narrower scope is the destination.

6. Ace Grid: the staged product-grid choice

Ace Grid is for teams that want to begin with a real application grid without deciding on every future layer today.

Start with MIT Core.

Add spreadsheet behavior when users need it.

Move operations to the server when the dataset and permissions require it.

Use compatibility diagnostics when an existing grid needs to move.

Use structured schemas when AI-generated table output needs validation and control.

Choose it when: your table is becoming a product, but you still want to decide when complexity enters the architecture.

A brutally short decision guide

Need the broadest proven platform? Test AG Grid.
Need Material UI consistency? Test MUI X.
Need headless primitives? Test TanStack Table.
Need a spreadsheet experience? Test Handsontable.
Need a focused open-source component? Test React Data Grid.
Need a grid that can start free and grow into spreadsheet, server, migration, and AI-shaped workflows? Test Ace Grid.

Build one unpleasant prototype

Do not compare the finalists using their homepages.

Give both of them the same bad afternoon:

stable row IDs
a custom status cell
editable money
invalid clipboard data
keyboard navigation
selection and filters
pinned totals
horizontal and vertical scrolling
a delayed request
a rejected save
restored state

Write down how much code your team had to own.

Check the license tier you actually used.

Run the keyboard path.

The winner is the grid that makes ordinary product chaos boring.

My conclusion

Ace Grid should not be positioned as the grid that beats every other grid. Nobody trustworthy can make that claim.

Its position is more useful:

Ace Grid is the product-grid challenger for teams that have outgrown a table but still want control over when spreadsheet and enterprise complexity enter the architecture.

AG Grid has more history.

Ace Grid offers a cleaner staged bet.

For the right React product, that difference matters.

Read the complete comparison and official source list:

https://ace-grid.com/guides/best-react-data-grid-libraries

From Signals to Ownership: Why I Built a Dataflow Kernel

Luciano0322 — Mon, 15 Jun 2026 07:17:57 +0000

When I first started building signal-kernel, I thought I was simply writing a signal library—a fine-grained reactive system not tied to any specific UI framework. On the surface, it had all the basic building blocks you would expect from a signal library:

Core primitives: Signal, Computed, and Effect
Mechanisms: dependency tracking and scheduling
Extensions: async resources and framework adapters

It could build a reactive graph, track dependencies, update derived state precisely when data changed, and bridge the result into React or Vue. But the deeper I dug into the implementation, the more I realized the real problem wasn't about building another signal library. The core question was actually this:

In a complex application, who should truly own the dataflow?

Fragmented Dataflow and the Derived State Problem

In modern frontend applications, dataflow often feels natural at first. API data comes back, gets written into state, and components render the result. If we need derived data, we use useMemo. If we need side effects, we use useEffect. If we need async requests, we use a query library, and if we need shared state, we introduce a store.

Individually, none of these solutions are wrong. React is not wrong. Vue is not wrong. TanStack Query is not wrong. Zustand and Jotai are not wrong either. The real problem appears when the system grows larger. At that point, the exact same logical dataflow starts getting split across multiple ownership models.

Some state belongs to components, while other state belongs to a store. Some derived state is trapped inside the render phase, and async state lives inside a query cache. The system still works, but the boundaries of the dataflow start to depend heavily on conventions, team discipline, and developer memory. It becomes incredibly hard to answer one seemingly simple question: Who actually owns this derived state? Is it the component, the store, the framework runtime, or just a temporary value calculated inside a hook?

Render Should Not Naturally Own the Entire Dataflow

Frontend developers often treat render as the center of the system. This is completely understandable—what we look at and debug every day is the UI. So when data changes, our first instinct is usually: "Which component needs to re-render?"

But if we reverse the question, the architecture looks very different. When data changes, perhaps the first question should be: "Which pieces of derived data are actually affected?" Render is simply one kind of side effect caused by data changes. It is extremely important, but it should not naturally own the entire dataflow.

This became one of the core architectural lessons I learned:

The reactive graph should first describe the relationships between data, while render should only be one consumer of that graph.

From Signal Library to Dataflow Kernel

If I only saw signal-kernel as a signal library, then most design questions would stay at the API surface: Should it feel more like Solid? Should computed values be lazy or eager? Should it support batching? These are important, but they hide the deeper issue: When a piece of state changes, who is responsible for deciding which derived states are affected?

In a traditional component-driven model, this usually happens during render:

Data changes → component re-executes → derived data is recalculated.

This model works beautifully for small applications, but it forces the lifecycle of derived state to follow the lifecycle of render. Once derived state becomes expensive, needs to be shared across frameworks, or needs to be deeply connected with async streams, this model becomes fragile.

That is why the real goal of signal-kernel was never simply to “reduce re-renders.” The goal was to detach derived dataflow from render ownership. What I actually wanted to build was a dataflow kernel.

A system that focuses on lower-level architectural concerns:

How state becomes a pure source of truth.
How derived state is tracked stably inside a reactive graph.
How effects can be separated cleanly from the render lifecycle.
How async work and continuously written streams can become part of the reactive graph while keeping clear state boundaries.
How render can return to its proper role: a consumer, not the owner.

Keeping the Boundary: Thin Framework Adapters

This way of thinking also directly shaped how I designed the React and Vue adapters. At the beginning, I naturally wanted to provide many convenient hooks and APIs that felt familiar to framework users. But over time, I became much more conservative.

If an adapter becomes too thick, it quietly pulls ownership back into the UI framework. And once that happens, the data independence that signal-kernel is trying to preserve starts to fade away.

A cleaner and more stable boundary should look like this:

Core owns the reactive graph.
Async-runtime owns the consistency of async state.
Framework adapters only subscribe to and read snapshots.
Render only draws the current result to the screen.

An adapter should not redefine the dataflow. It should only be a transparent pipe into the framework.

Rethinking Framework Responsibility

I want to make one thing clear: this series is not meant to criticize React or any other UI tool. React is still excellent at handling UI consistency, and TanStack Query solves a very real, difficult server-state problem.

What I want to explore is a deeper architectural question:

When we habitually put all data logic into the model of a UI framework, are we accidentally making render responsible for too much?

If reactive dataflow itself can be an independent system, then what role should a UI framework actually play?

What I Was Really Studying Was Ownership

While implementing the core and async-runtime of signal-kernel, I kept running into a series of uncomfortable architectural questions:

After a Promise resolves, is it really just a simple setState?
If a stream keeps emitting chunks, who should own its stable value, status, and error?
After a mutation succeeds, is invalidation the responsibility of the query cache, or the reactive graph?

All of these questions eventually point to the same word: Ownership.

I originally thought I was building a signal library. But the more I built, the more I realized that what I was really studying was how the boundaries of dataflow should be redefined in increasingly complex frontend applications. APIs can change. Implementations can be replaced. But the core question remains the same:

When data changes, who is responsible for understanding that change?

If the answer is always render, then we are forced to keep layering workarounds around the UI framework. But if the answer is the reactive graph, then render can return to its most reasonable position. It is one outlet of the dataflow. It is one side effect. It is a consumer of the system, not the owner.

That is the most important lesson I learned while building signal-kernel. If this idea resonates with you, I’m exploring it through signal-kernel, a framework-agnostic reactive dataflow kernel.

The project is still evolving, but its direction is clear: render should be a consumer of the dataflow, not the owner.

In the next article, I want to continue exploring this question:

What actually changes in frontend architecture when render no longer owns the entire dataflow?