DEV Community: z

Commonfeed 1.4.1: keep the fictional sample clear through completion

Thu, 22 Oct 2026 22:08:22 +0000

Commonfeed is a local RSS and Atom reader built around finite reading sessions. I released 1.4.1 with a small completion-screen fix.

The sample already labeled its items as fictional while you read them. At completion, it switched to “Private session receipt.” The explanation that no receipt was saved appeared only after feedback.

Now the completion screen keeps “Fictional sample session” visible, calls the totals a “Sample session summary,” and says before feedback:

No receipt is saved, even if you give feedback.

This changes the explanation, not the storage behavior. Sample sessions still leave no receipt, and real-session behavior is unchanged.

I verified a fresh npm installation in the browser: the explanation appeared before feedback, and the isolated data file stayed empty afterward. All 94 tests passed before release.

Those checks cover the tested sample flow. Long-term reliability and improved reading outcomes remain unproven.

Try it with Node.js 22+:

npx commonfeed@1.4.1

Read the 1.4.1 release notes.

Building inspectable systems: my portfolio, Sentra–Hermes, and five public projects

Thu, 22 Oct 2026 20:41:06 +0000

I build systems where authority, execution, and evidence stay connected.

A task can finish and still leave an operating problem. Was it authorized against the right state? Does the evidence support advancing? What happens if the next run inherits something it should not?

Those are the problems behind my portfolio. Sentra–Hermes is the flagship case study. Five public repositories give you tools to inspect and try.

Sentra–Hermes: authority before advancement

Sentra–Hermes explores a bounded lifecycle for governed agent execution:

Readiness → Authorization → Execution → Verification → Advancement → Completion

The Hermes name refers to Nous Research’s Hermes Agent. My contribution is the surrounding operating infrastructure: Sentra’s decision layer, authorization boundaries, readiness checks, verification, and preserved evidence for workflows involving Hermes agents.

The case study examines this operating infrastructure and its bounded validation. The checkpoint evidence does not establish that Hermes Agent executed those tasks.

Two failures make the operating problem concrete. One involved candidate selection treating a consumed authorization as live authority, blocking successor intake. Another involved successor state still referencing the predecessor’s execution. The corrections separated historical evidence from live authority and isolated successor activation within a rollback boundary.

At the documented July 24, 2026 checkpoint:

13 of 13 repository-integrity checks passed.
Three of three governed tasks completed.
Four single-transition authorizations were consumed.
Predecessor and successor evidence was preserved.

A later read-only replay of that historical snapshot found zero recovery issues. That result is separate from the original checkpoint results.

This is evidence for a bounded prototype checkpoint. It does not establish general agent safety, production readiness, or current runtime health.

The public evidence guide includes extracts and provenance. You can inspect the cited records, but the extracts are not the full implementation and are not sufficient to reproduce the entire system.

Five public projects

1. Pick Up Here

Pick Up Here helps you resume work in a Git repository using saved evidence, change comparisons, and optional local AI guidance.

Prototype release candidate. Facts and comparisons work without AI. They help establish what changed; they do not establish runtime correctness.

2. Commonfeed

Commonfeed is a local RSS and Atom reader with finite reading sessions, explained selections, and private feedback.

Published local reader; focused product probe. The README includes a fictional sample session. Long-term reliability and improved reading outcomes remain unproven.

3. Backsolve

Backsolve records decisions, evidence, tests, and outcomes behind AI-assisted work in Whyfiles and portable archives.

Local v0.1 CLI prototype. Records are assembled deterministically from explicit captures. The confidence score is a heuristic, not independent verification.

4. LineForge

LineForge turns chess games into annotations, mistake cards, review sessions, and portable study artifacts.

Local v0.1 application prototype. Coach lenses are deterministic; optional Stockfish analysis is separate. Learning gains and broader usability have not been established.

5. Hermes Observability

Hermes Observability provides observability standards, structured trace contracts, and local readiness reports for governed workflows.

v0.1 standards and validation tooling. A fixture PASS supports the behavior that fixture exercises. It does not establish live ingestion, another repository’s compliance, or production readiness.

Each README has first-run steps, an example output or development screenshot, and the current limits.

What I want feedback on

The common thread is making the next action easier to judge: what can run, what changed, what evidence survives, and where a person needs to make the call.

The public tools also need to earn their place in someone’s workflow. Passing checks cannot answer that on their own.

If you try one, I’d like to know:

Could you follow the first-run instructions?
Did the example make the intended behavior clear?
Were the evidence and limits specific enough to judge the claims?

Start with the portfolio, read the Sentra–Hermes case study, or pick a repository from my GitHub profile.

What I learned about matching rows between CSV files

Wed, 21 Oct 2026 22:09:28 +0000

Why I started

I started building a CSV comparison tool for my own use and to explore a business idea. I wanted to see where I could improve on standard comparison tools.

One thing I found frustrating was ambiguous matches. Before comparing values, you need to know which rows belong together.

What makes a match ambiguous?

Here's a made-up example to illustrate the problem.

Suppose these are two exports, and I'm using customer_id to match rows.

First export

`customer_id`	item	amount
101	Hosting	20
101	Support	50

Second export

`customer_id`	item	amount
101	Support	55
101	Hosting	20

Both files have two rows with customer_id 101. That ID identifies the customer, but it doesn't identify an individual row.

Matching by row order would compare Hosting with Support and report misleading changes. Looking at the item names makes the likely matches clearer, but customer_id alone doesn't provide enough information.

How I approached it

I settled on matching rows by unique keys, then showing additions, removals, and changes.

For the example above, a subscription ID could identify each record:

`subscription_id`	`customer_id`	item	amount
sub-001	101	Hosting	20
sub-002	101	Support	50

If those subscription IDs stay the same in the next export, the rows can be matched even when their order changes. The comparison can then show that Support changed from 50 to 55.

The key needs to be unique within each file and identify the same record across both files. A row number might be unique, but it won't reliably identify the same record after rows are reordered.

My approach is to reject duplicate keys rather than guess. The tradeoff is that the person comparing the files needs to find a suitable key or prepare the data first.

What I'm still trying to understand

Tracking rows by unique keys to show additions, removals, and changes is the part I find most useful so far.

What kinds of datasets do you compare repeatedly?
How often do you compare them?
What do you use to identify the same record across exports?
What do you do with the differences afterward?

I'd be interested in concrete examples, especially where matching gets messy or your current tools fall short.

Written from my own notes, with AI assistance for organization, wording, and the illustrative example.