DEV Community: Avinash Gehi

I wrote a dependency scanner with zero dependencies. The parser was easy; the terminal was not.

Avinash Gehi — Mon, 31 Aug 2026 16:16:59 +0000

The premise was too neat to pass up: a tool that finds dependency problems should not have dependencies.

So depx reads a repository's source, extracts every import, resolves each one against the manifest and the install tree, and reports where the two disagree. Twelve languages. Fully offline. "dependencies": {} and no node_modules.

Built in 72 hours for Zero Dependency 2026, run by Hackathon Raptors, where the single rule is that your shipped manifest ships empty.

The interesting part was not "can you avoid npm." You can. The interesting part was discovering which of my reflexes were load-bearing and which were just habit.

Why this tool, specifically

A 2025 USENIX Security study fed 576,000 AI-generated code samples through a checker: 19.7% of the packages the models recommended did not exist.

The inventions repeat. Ask ten models for an HTTP retry helper and a good number reach for the same plausible name. So an attacker doesn't guess — they read what the models suggest, register those names first, and wait. You run npm install, the name resolves, and you're compromised having typed everything correctly. The industry calls it slopsquatting.

It's statically visible. Your code imports a name; your manifest doesn't have it; nothing on disk provides it. That's the whole detection.

What I reimplemented

Sixteen substitutions. Three worth talking about.

The JavaScript parser → a masking lexer

Every tool in this category — depcheck, dependency-cruiser, madge, every bundler — installs a full JavaScript parser to answer one question: which strings are import specifiers?

You don't need a syntax tree for that. You need to know which string literals sit in import position. So I mask the source: blank out comments, string bodies, template literals and regex literals while preserving byte offsets, then test what precedes each surviving string literal.

// after masking, every remaining string literal is real code
const before = masked.slice(0, start).trimEnd();
if (/\bfrom$/.test(before) || /\bimport$/.test(before)) { /* … */ }

About 150 lines against a 100 KB dependency. It can't be fooled by // import 'fake' or const s = "require('fake')", both of which are in the test suite.

Preserving offsets is the trick that makes it work. The masked text is the same length as the original, so an offset into one is an offset into the other, and you can report src/app.js:5:34 from a lexer that never built a node.

The terminal UI → `node:readline` and a dozen escape codes

This is the one that surprised me.

depx has a full-screen interface — alternate screen, arrow keys, live search, $EDITOR on Enter. The reflex here is ink: React, plus a reconciler, plus the Yoga layout engine compiled to WebAssembly. To draw a list you can arrow through in a terminal.

Every piece is already in Node:

Need	What you'd install	What's already there
Decode arrow keys	`keypress`, `ink`	`readline.emitKeypressEvents()`
Read keys unbuffered	`blessed`, `enquirer`	`stdin.setRawMode(true)`
Alternate screen, hide cursor	`blessed`, `cli-cursor`, `ora`	`\x1b[?1049h`, `\x1b[?25l`
Terminal size + resize	`term-size`	`stdout.columns`, the `resize` event
Two-pane layout, text wrap	`ink` + Yoga (WASM)	~30 lines of arithmetic
Highlight a row	`chalk`	`util.styleText('inverse')`

If you take one thing from this post, take the design decision underneath it: the state machine and the frame renderer are pure functions of (state, size).

reduce(state, key)              // → { state, action }
renderFrame(state, {cols, rows}) // → exactly `rows` strings of exactly `cols` width

Only runTui() touches stdin, stdout or the process. Which means 47 tests drive the entire interface without a terminal, asserting on frames as plain strings. Testing an ink app normally means installing ink-testing-library on top of ink.

That invariant — every frame is exactly rows lines of exactly cols display width — turned out to be the highest-leverage assertion in the project. One property, three bugs I would never have caught by eye:

a footer emitted without padding, invisible because the draw loop's \x1b[K was cleaning up after it
a chrome constant that assumed the detail panel always existed, leaving a stray row on every empty frame
three rows in the empty state emitted as '' instead of a full-width run — two columns wide instead of seventy-eight

None of them looked wrong on screen. All of them are obvious to displayWidth(line) === cols.

`chalk`, `minimist`, `string-width`, `cli-table3`, `globby`, `jest`, `esbuild`…

Mostly one-liners now:

import { styleText, parseArgs } from 'node:util';   // chalk, minimist
import { test } from 'node:test';                    // jest
import assert from 'node:assert/strict';

util.styleText even honours NO_COLOR and does TTY detection for you, which is most of why people install chalk in the first place.

What the standard library made painful

Three things, in ascending order of annoyance.

1. Nothing tells you how wide a string is.

'日本語'.length is 3. It occupies 6 terminal columns. That gap is the entire reason string-width exists, and if you're aligning columns you cannot ignore it. So: strip ANSI, iterate code points, skip control characters and combining marks, and count East Asian Wide and emoji ranges as two.

if (code < 0x20 || (code >= 0x7f && code < 0xa0)) continue; // control
if (code >= 0x0300 && code <= 0x036f) continue;             // combining mark
width += isWide(code) ? 2 : 1;

About 40 lines. Not hard, just genuinely absent.

2. Regex or division?

A lexer that masks regex literals has to decide what / means. a / b is division; a = /b/ is a literal. There is no stdlib help; you use the same preceding-token heuristic real lexers use — a set of characters and keywords after which a / can only start a regex.

const REGEX_PRECEDERS = new Set(['(', ',', '=', ':', '[', '!', '&', '|', '?', /* … */]);
const REGEX_KEYWORDS = /\b(return|typeof|instanceof|in|of|new|delete|void|yield|await)\s*$/;

Not infallible. Documented as such in the README, because a limitation you name is a limitation and one you hide is a bug.

3. Node ships no TOML support. At any version.

This was the only true gap — the one place the constraint forced original work rather than a smaller reimplementation. Cargo.toml and pyproject.toml are not optional if you claim Rust and Python support.

So: a subset reader for what a dependency manifest can actually contain — tables, dotted keys, strings, numbers, booleans, inline tables, inline arrays. Arrays-of-tables and datetimes are deliberately not implemented.

The part I'd flag to anyone hand-rolling one: your comment stripper and your key/value split both have to be quote-aware.

key = "a = b # c"

A naive split('=') and a naive split('#') each corrupt that line, and most quick TOML readers I've read do exactly one of the two.

(Bun 1.4 ships Bun.TOML. I was targeting Node on a machine with Bun 1.3.14, so it wasn't an option — but a Bun submission could legitimately delete this whole file.)

The afternoon that vanished

The interface worked. Arrow keys moved, search filtered, q restored my prompt.

And then the process just… sat there. Prompt back, terminal clean, shell unresponsive. ctrl-c to get out, every time.

The quit path looked correct:

stdin.off('keypress', onKey);
stdin.setRawMode(false);
stdin.pause();
stdout.write(ALT_OFF);

The listener is gone. Raw mode is off. The stream is paused. The alternate screen is closed. What is holding the event loop open?

pause() is not the same as releasing the handle. readline.emitKeypressEvents() leaves a reader attached to the TTY, and a referenced TTY handle keeps libuv's loop alive whether or not you're reading from it. The fix is one line:

stdin.unref?.();

What cost me the afternoon wasn't the fix — it was that every symptom pointed away from the cause. The terminal was restored, so the teardown "worked." The prompt was back, so the program "exited." I went looking for a stray setInterval and an unresolved promise before I thought to question pause().

The lesson I'd generalise: when a Node process won't exit, stop reading your cleanup code and start asking which handles are still referenced. Those are different questions, and only the second one matters.

It's now a regression test that injects fake streams and asserts unref was called — no terminal required, because of the pure-function split above.

Two things about terminal UIs that have nothing to do with dependencies

Your success state is a UI state.

Running depx on a healthy repository opened onto a header, a footer, and twenty blank rows. It was behaving correctly — there are no findings, so there is nothing to browse — but a mostly-empty screen reads as a program that failed to load. It was happening on exactly the repositories the tool should be reassuring about.

The fix wasn't code, it was noticing. Now the no-findings case gets a composed panel: a mark, a headline, what was actually scanned, and the nested projects that were skipped along with why. And the three ways of having nothing to show stay distinct, because a repository whose findings are all suppressed by config is configured, not clean, and one with no source files at all was never really analysed.

If your empty state is a blank screen, you didn't design an empty state.

I nearly shipped a lie, and it would have demoed better.

The analysis is fast: four files in 40ms, six thousand in 0.70s. So when I added a scanning screen — real file counts, streamed from the walker through an onProgress callback — it flickered past faster than you can perceive it.

The obvious fix was a minimum display time. Five hundred milliseconds and the demo looks great. Everyone does this.

I didn't, and I think the reason generalises. A floor on your loading indicator means shipping a slower tool so that it looks busier — trading a real strength (it's fast) for a manufactured one (it looks like it's working hard). The screen is now up for exactly as long as the walk takes: a flicker on a small project, about 0.4 seconds on four thousand files, and genuinely useful on a monorepo.

If your progress indicator needs a minimum duration to be visible, you don't need a progress indicator. You need to print the number.

The bug report that was really a design review

Someone watching me demo it asked the question that reframed the whole thing:

"Why do I have to quit the UI, run another command, and open it again? Why the hell am I bouncing between the two?"

They were right, and I'd been blind to it because I built the pieces in the order the code wanted rather than the order a person uses them. The interface was a view onto one subcommand — check. The zero-dependency rule check and the vendoring scan were separate commands, so answering three questions about the same repository meant three round trips through a shell.

That's not a missing feature. That's having modelled the tool as a set of commands with a UI bolted onto one of them, instead of as a thing you point at a repository.

Three keys now — f findings, z rule, v copied source — switch view from anywhere. Both analyses run behind the single scan screen, so switching is instant. It turned out to be two passes and not three, because verifyZeroDep() already returned the vendoring scan; the data had been sitting there the whole time, reachable only by exiting and typing a different word.

The change also caught a bug it had just introduced. The fuller footer overflowed 76 columns, and my all-or-nothing fallback silently swapped in a shorter hint line — one that didn't mention the new views at all. So the feature existed and was undiscoverable at exactly the widths most people use. The footer is tiered now, and drops the movement hints before the view list:

A key you cannot discover is a feature that does not exist.

The rule I wish I'd started with

depx opened the interface when you ran it bare, and printed a report when you gave it a path. Two behaviours, and the boundary was "did you pass an argument" — which is a fact about your typing, not about your intent.

It's one rule now:

No subcommand, in a terminal → the interface. Everything else → the report.

Naming a subcommand is the signal that you want that command's output. So depx check . is text and always was. So is a pipe, a redirect, a CI job, --json, --quiet. And depx and depx ./some/project both mean "show me this project", where how it's shown depends on whether a person is looking.

The property that makes a rule this broad safe: every scripted invocation either names a subcommand or isn't attached to a terminal. So no script's behaviour can change, which is the actual thing you're protecting. Two tests pin it — a bare path through a pipe is still the report and still exits 1, and a named subcommand is never the interface.

I'd been treating "adapt to the terminal" as the risky thing. It isn't. The risky thing is adapting on a signal a script can accidentally produce.

The insight I actually care about

Replacing packages was the fun part. The hard part was deciding what the tool is allowed to claim.

depx is offline. It can prove an import resolves to nothing in the project in front of it. It cannot prove a package doesn't exist anywhere — that needs a copy of the registry index, which is precisely the kind of dependency this tool exists without.

So there are two findings where a lazier tool would have one:

ghost — imported, and nothing here provides it. High confidence, because the full resolution universe was visible: either the language's manifest is authoritative (Go won't compile an import absent from go.mod) or an install tree was on disk to check against.
undeclared — imported, not declared, and no evidence available to judge further. Deliberately weak.

That distinction exists because a false ghost is the most damaging error this tool can make. It sends someone hunting a supply-chain compromise that isn't there. So the design leans away from it everywhere: modules the repo defines, a package importing itself, subpath imports, bundler aliases, #internal/x, $lib/w, Python's __future__, Ruby's English — all excluded before judgement.

An empty .venv directory does not promote anything to a ghost either. A directory is not evidence. It has to contain something.

I validated against eighteen real repositories — every public submission I could find, plus working Go, Rust, Python and TypeScript projects with trees installed. That produced twenty-one defects, mostly false positives, each now a regression test named for the case that caused it:

Rust: a bin target importing its own crate is not a ghost
Go: an // indirect requirement is not reported as dead
Python: a URL requirement line is not a package named "git"
Java: a Maven coordinate is never reported as dead

That last one is a whole tier of the design. In Java, import org.apache.commons.lang3.StringUtils is satisfied by the artifact org.apache.commons:commons-lang3. The namespace and the coordinate are unrelated strings, connected only by a mapping that lives on Maven Central. Resolving that offline means shipping the registry index.

So Java, C#, PHP and C/C++ are tier 3: ghost detection off by design. They report file inventory and declared dependencies and stay silent on ghosts and dead code.

Shipping a feature that says "I can't answer this" is less satisfying than shipping one that guesses. It's also the only honest option, and I think it's the thing in this project I'd defend hardest.

Numbers

237 tests, 55 suites, node:test, no config file
16 stdlib substitutions, each documented with reasoning
12 languages across 9 adapters
6,000 files scanned in 0.70s
Scan screen driven by real file counts, with no minimum display time
Single-file build that's byte-identical across runs — and the verify step diffs the bundle's behaviour against the source tree, so a build that changed behaviour fails even if it hashed the same
dependencies: {}, no node_modules, and the tool verifies that claim about itself

Would I do it again

For a scanner? Yes, and I'd keep it. The dependency count of a tool that audits dependencies is not a gimmick, it's the argument.

For a product with a deadline? No. I'd install ink.

But I know what's inside ink now, and that's worth something. The uncomfortable finding of the weekend is how few of my reflexes survived contact with the standard library. chalk became one import. minimist became one import. jest became one import. The genuinely irreplaceable thing turned out to be TOML — a text format from 2013.

We didn't outsource the hard parts. We outsourced the parts we stopped looking at.

Built for Zero Dependency 2026 by Hackathon Raptors. Source: github.com/Avi36005/ZeroDependency_Team_Kryptonite — MIT.

I ported croniter to Rust and got 228/228. That number proved nothing

Avinash Gehi — Fri, 07 Aug 2026 13:08:34 +0000

A port that compiles and passes its tests isn't evidence the port is correct. It's evidence that whoever wrote the port also controlled the tests. Generating a port is nearly free now. Proving it holds up is the part almost nobody does.

So here's what I actually did to try to falsify my own croniter → Rust port, and where it fell short.

1. Run the original tests, hash-pinned

Not a translated suite. The actual upstream files, SHA-256 fingerprinted before a line of Rust existed, wired to Rust through a PyO3 bridge. git log -- tests/original/ shows one commit: the vendoring.

Then the step I'd argue is mandatory: build the bridge against a deliberately wrong stub first and confirm the tests fail.

222 failed, 6 passed

That's success — it proves the suite is importing and judging Rust before any correct logic exists to muddy the signal. And note the 6: my stub returned False from is_valid, which satisfies every test asserting an expression is invalid. Even my broken baseline had false positives.

2. Sabotage your own green suite

228/228 has two explanations and you can't tell them apart from the green: the port is right, or the suite can't fail. So I broke it on purpose — two single-token changes in two unrelated files:

consts.rs   hour range (0,23) -> (0,22)  ->  32 failed, 196 passed
expand.rs   wrap length +1 -> +2          ->   2 failed, 226 passed
reverted                                  -> 228 passed

Ten minutes, and it's the difference between a measurement and a decoration. I did the same to the benchmark checksum.

3. Make the library contradict itself

The technique I'd steal from this project. croniter exposes three APIs answering overlapping questions — get_next, get_prev, match — and they must agree. If get_next(start) returns N, nothing strictly between may match, and N must match. A violation means the library contradicts itself and one answer is wrong under any reading of cron semantics.

That's an oracle with no external reference. No second implementation, no spec, no human. The library grades itself.

My first one was worthless. It checked one property, on naive datetimes only, never called get_prev. 19,440 cases, zero findings — and I briefly read zero as correctness. It was evidence the question was too easy. An invariant that can't fail isn't an oracle.

The rewrite checked five properties, called get_prev, and biased half its start times to within four hours of a real DST transition — including Australia/Lord_Howe, the only zone on Earth with a 30-minute shift. It found two real bugs in croniter, both now filed upstream (#258, #259):

tz    = zoneinfo.ZoneInfo("Australia/Lord_Howe")
start = datetime(2019, 10, 6, 1, 43, tzinfo=tz)

croniter("0 * * * *", start).get_next(datetime)   # 03:00+11:00
croniter("0 * * * *", nxt).get_prev(datetime)     # 02:30+11:00  <- AFTER start
croniter.match("0 * * * *", <02:30+11:00>)        # True

match returns True for a minute-0 schedule at minute 30. In a normal 1-hour zone the same code path lands on 03:00, which is valid — so the bug is invisible everywhere except the 30-minute shift. Which is exactly why the generator was pointed there.

The second: croniter_range's stop test is v < stop, and CPython ignores tzinfo when both operands share it. Across a DST transition it compares wall-clock instead of elapsed time — returning 1 result where 6 exist, or results outside the interval you asked for. Silent, no exception.

My port reproduces both deliberately. A port's job is to behave like the thing it ports, including where that's wrong.

4. The bug 228 passing tests could not find

Differential fuzzing: same probe under two interpreters, comparing values and exception types. Adding timezone-aware inputs surfaced 221 divergences in 164,500 — all one cause, and it was a type, not a value. croniter raises a bare ValueError; my port raised CroniterError.

CroniterError subclasses ValueError. Every except ValueError caught it. The suite was green at 228/228 before and after. It could not have found this, no matter how long I ran it.

That's the whole argument for differential fuzzing in one paragraph. Zero value divergences, though — the date math was right, only a label was wrong. Final run: 160,500 inputs, 0 divergences.

5. What I'd take back

The first oracle cost a day and taught nothing. I should have asked "what input would falsify this?" before running it for an hour.
Triage cost more than the hunt. One harness gave 927 raw findings; 750 were documented behaviour. An earlier one gave 1,408 findings that were entirely my own bug in the checker.
The fuzzer tests the bridge, not the shipped binary. Both sides run under Python, so core is validated as called through PyO3. The artifact judges receive is one layer removed from the evidence.
228/228 hid a hole in the deliverable. Every timezone test supplies a tzinfo, so they all went through the bridge — while the standalone binary couldn't do DST at all. A suite measures the path the tests take. Mine bypassed a third of the product and reported full marks.
I wrote an unverified claim into my own README (a Docker build that had never run). Caught it late, marked it unverified rather than deleting it.
The number nobody prints: the suite runs in 1.54s against Python and ~1.8s against my 25x-faster Rust. Every call crosses FFI. Both facts are true at once.

Numbers

228/228 on unmodified tests · 160,500 fuzz inputs, 0 divergences · 2 upstream bugs filed · 0 unsafe (compiler-enforced) · 25.3x mean, 26.1x p99, 3.2x smaller RSS · 0 test files modified.

Every figure was observed on one machine and written down after the run. The one claim I couldn't verify is marked as unverified in the repo rather than dropped.

Repo: github.com/Avi36005/Portmortem-Team-Kryptonite

Why stateless LLMs can't make consistent decisions, and how Hindsight fixed that

Avinash Gehi — Mon, 15 Jun 2026 12:17:45 +0000

I spend most of my time in the frontend. I build dashboards, wire up routes, push the thing to a CDN, and obsess over the half-second between a click and something useful appearing on screen. So when we set out to build ExceptionOS — a platform that helps companies make consistent, explainable decisions about business exceptions like refunds, discount approvals, and SLA compensation — the part I owned was the surface: the React app, the deploy pipeline, and a chat-plus-voice assistant that anyone could talk to.

The interesting problem turned out not to be the UI at all. It was what sat behind it: a memory layer that remembers every decision an organization has ever made, and an assistant that answers questions by recalling from it. This is the story of building that assistant, the dumb mistake I made that made it feel slow and weird, and how a memory system called Hindsight ended up shaping the whole product.

What the system actually does

ExceptionOS captures a business exception — say, a customer asking for a refund outside policy — and runs it through a debate. Ten specialized agents look at the case from different angles: one finds the applicable policy, one estimates the financial hit, one assesses churn risk, one digs up similar past cases, and one plays critic and pokes holes in the emerging recommendation. The output is a structured recommendation with reasoning a human can read and override.

That debate is only as good as its memory. An agent that finds "similar past cases" needs somewhere those cases live. We use Hindsight Cloud for that — agent memory as a managed service, with three operations we lean on constantly: retain (store a decision), recall (find relevant ones), and reflect (surface patterns over time). Every organization gets its own memory bank, created on first use:

bank = await self.hindsight.create_bank(
    name=f"exceptionos-{org_name}-{organization_id}",
    description=f"Memory bank for organisation '{org_name}' on ExceptionOS",
)

One bank per org means recall is naturally scoped — Acme's assistant never sees Globex's decisions. That property mattered a lot once I started building the front-facing assistant.

The assistant: a chat orb that knows your history

The feature I'm proudest of is a floating orb that lives in the corner of every screen. You can type at it or talk to it. Ask "what's our approval rate for contractor exceptions?" and it answers from your organization's actual decision history, then reads the answer aloud.

The frontend side is deliberately thin. The browser doesn't talk to the memory layer or the LLM directly — it posts a message, an optional bank ID, and the current page context to one backend endpoint, and gets back an answer plus the sources it used:

export async function askAssistant(
  message: string,
  opts: { bankId?: string; context?: string } = {},
): Promise<AssistantReply> {
  const res = await fetch(`${API}/api/v1/assistant/chat`, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json', ...authHeader() },
    body: JSON.stringify({ message, bank_id: opts.bankId, context: opts.context }),
  })
  const json = await res.json()
  const data = json.data || json
  return { answer: data.answer, sources: data.sources || [], provider: data.provider }
}

Passing context — the case or page the user is currently looking at — is what makes the assistant feel like it's there with you. Ask "is this one risky?" while staring at a specific case and it knows what "this" means. Passing bankId is what makes it org-aware. Two small fields, most of the perceived intelligence.

On the backend, the endpoint recalls grounding memories from Hindsight and feeds them to the LLM as context. The recall itself is one HTTP call:

async def recall_all(self, bank_id: str, query: str, top_k: int = 5):
    return await self.hindsight.recall(bank_id, query, top_k=top_k)

Then a system prompt tells the model to use those memories only when the question actually calls for them, answer in one to three sentences, and keep a natural spoken tone — because that same text gets sent to ElevenLabs for voice synthesis and read back to the user.

The mistake: recalling on "hi"

Here's where I got it wrong. My first version was clean and uniform: every message went through the same path. User says something, we recall from memory, we hand the memories to the model, we answer. Symmetry felt right.

It was terrible.

You'd open the orb, type "hi", and wait. Behind that one word the system was doing a full vector recall against the org's entire decision history, pulling five "relevant" memories about refunds and NDAs, and stuffing them into the prompt. The model, dutifully handed a pile of past cases, would respond to "hi" by listing refund precedents. It was slow — a network round-trip to the memory layer before any greeting — and it was unsettling, like saying hello to someone who immediately recites your file.

The fix was to admit that not every message is a query. Small talk shouldn't touch memory at all:

normalized = message.lower().strip(" .!?")
is_smalltalk = normalized in GREETINGS or len(normalized) <= 3

memories: list[dict] = []
if not is_smalltalk:
    memories = await RecallService(get_hindsight_client()).recall_all(bank_id, message, top_k=5)

Before: "hi" → recall five memories → 2-second pause → an awkward dump of past refund cases.
After: "hi" → no recall → instant, warm one-liner inviting you to ask about a case.

The system prompt reinforces it: greetings get a warm sentence and never enumerate cases; memories get referenced only when the user asks about a case, refund, discount, policy, or decision. The lesson generalizes well beyond greetings. Recall is not free — it costs a round-trip and it costs prompt space — and a memory system is most impressive when it stays quiet until it has something worth saying.

The gotcha that cost me an afternoon: metadata is strings only

A quieter lesson lived at the boundary between our data model and Hindsight's. Hindsight's memory metadata accepts string values only, so anything structured — case IDs, financial figures, nested objects — has to be coerced or JSON-encoded before a retain call, or it silently fails to stick. The fix was a small normalizer that every retain passes through. The takeaway: when you adopt a managed memory layer, learn its type contract early — the constraints are usually there for good reasons, and guessing from the client side just wastes an afternoon.

What I'd tell someone starting this

Shipping the frontend taught me that a memory layer doesn't live in the backend — it leaks into every product decision you make. Whether to recall, when to recall, how much to show, what to read aloud: those are UX calls as much as infrastructure calls. Two small request fields (bank_id, context) carried most of the assistant's apparent intelligence. One conditional (is_smalltalk) carried most of its perceived speed and warmth.

If you're building something similar, start with the operations — retain, recall, reflect — and resist the urge to apply them uniformly. The product feels smart not when it remembers everything, but when it knows the difference between a question and a hello.

You can see the project at github.com/Avi36005/ExceptionOS, read more about the memory layer in the Hindsight docs and its GitHub repo, or dig into the concept of agent memory itself.

DEV Community: Avinash Gehi

I wrote a dependency scanner with zero dependencies. The parser was easy; the terminal was not.

Why this tool, specifically

What I reimplemented

The JavaScript parser → a masking lexer

The terminal UI → node:readline and a dozen escape codes

chalk, minimist, string-width, cli-table3, globby, jest, esbuild…

What the standard library made painful

The afternoon that vanished

Two things about terminal UIs that have nothing to do with dependencies

The bug report that was really a design review

The rule I wish I'd started with

The insight I actually care about

Numbers

Would I do it again

I ported croniter to Rust and got 228/228. That number proved nothing

1. Run the original tests, hash-pinned

2. Sabotage your own green suite

3. Make the library contradict itself

4. The bug 228 passing tests could not find

5. What I'd take back

Numbers

Why stateless LLMs can't make consistent decisions, and how Hindsight fixed that

What the system actually does

The assistant: a chat orb that knows your history

The mistake: recalling on "hi"

The gotcha that cost me an afternoon: metadata is strings only

What I'd tell someone starting this

The terminal UI → `node:readline` and a dozen escape codes

`chalk`, `minimist`, `string-width`, `cli-table3`, `globby`, `jest`, `esbuild`…