Longtail Forge Update · August 22–September 4, 2026

The last Longtail Forge update was mostly about making deployment and recovery boring enough that I could trust them. This one is about what happens before a change ever gets that far.

There’s a point in a growing software project where “run the tests” stops being a useful instruction. Which tests? All of them? Every time? What happens when one fails because two database-heavy tests stepped on each other instead of because the code is actually broken? And how do you keep the fast feedback that makes small changes practical without quietly turning the full release check into an optional suggestion?

That’s the kind of problem I’ve been working through.

None of this gives Longtail Forge a new button somebody can click. It does something I care about just as much, though: it makes the process of changing the software better at catching the difference between “this change is wrong,” “this change needs a broader look,” and “this test had a bad day.”

The short version

• The test process can now route a small change toward the narrow checks that are most likely to matter, while shared or risky changes still escalate to the full verification gate.
• Fast TypeScript and unit-test failures happen before the slow regression suite, so obvious problems can fail quickly instead of wasting everybody’s time first.
• A very specific class of database test that fails under parallel load can be retried once with a fresh serial fixture. If it fails again, it is still a real failure.
• Database query and migration work has more dedicated checks for unsafe interpolation, schema drift, and missing migration housekeeping.
• Browser tests now render the real application at desktop and mobile sizes and include automated accessibility, keyboard, and focus checks.
• The private preview is still private. The public repository still treats invitations as gated on the final readiness record and candidate review.

The test suite got a traffic controller

Longtail Forge has enough automated testing now that the interesting problem is no longer “do we have tests?” It’s deciding which tests make sense while I’m in the middle of a change.

A one-module edit to Files doesn’t necessarily need the same immediate test path as a change to the shared framework, the database, or the release process. Eventually, before a slice is closed, the broad checks still matter. But while I’m working, making every tiny change wait for every possible regression test is a good way to teach myself not to run tests as often as I should.

That’s backwards.

The current development checks now have a more deliberate routing model. Focused module work can run focused module checks. Contract or schema work can run the contract tests and TypeScript. Shared framework changes get a wider look. Changes to database or release machinery escalate instead of pretending they are local.

There’s also a simpler improvement that makes a surprisingly large difference: the main verification gate runs the cheap, deterministic checks first. TypeScript typechecking and the fast unit tests get a chance to complain before the slower regression suite starts.

If I broke the type contract in three seconds, I don’t need the computer to spend several minutes proving that I also should not have done that.

The important part is what this doesn’t mean. The focused checks are for iteration. They don’t replace the full closeout gate. The point is to get useful feedback sooner while I’m working, not to invent a more sophisticated excuse for skipping the boring tests later.

---

Reliable automation

Automation is wonderful until it quietly stops working three Tuesdays ago. Raymond Tec builds integrations with logging, monitoring, and failure handling in mind so the boring work stays automated without becoming mysterious.

---

A failure can be real without being repeatable

Parallel testing creates another problem that sounds small until you have spent enough time chasing one of these failures.

Some regression tests use isolated database fixtures. Running safe buckets in parallel makes the full suite faster, but occasionally a database-heavy test can fail because of the test environment or timing rather than because the product behavior is wrong.

The lazy answer is to rerun anything that fails until it turns green.

I very specifically don’t want that.

The current runner only gives that second chance to one narrow case: an isolated-database regression that fails once under parallel load. That individual script gets one fresh serial fixture and one retry. If it passes, the result is reported as “flaky-recovered” instead of quietly pretending nothing happened. If it fails again, it stays failed.

Static checks and other regression buckets don’t get this treatment.

That distinction matters. A retry can be useful diagnostic information when the first failure may have been caused by parallel test contention. A blanket “eh, try it again” policy is how real intermittent bugs learn to live in your codebase rent-free.

I would rather have the test system admit, “I saw something weird, then it passed under controlled conditions,” than lie to me in either direction.

Database changes now have more ways to complain before users do

Longtail Forge still uses SQLite for its current small-office and self-hosted scale, and database changes are one of those places where a tiny-looking edit can have an annoyingly large blast radius.

There are now separate guardrails around two different problems.

The first is query construction. A parameter-binding audit checks database query changes for new, unreviewed SQL interpolation. In plain English: values that belong in a parameter should not get casually stitched into a SQL string just because doing that is convenient.

That’s partly a security issue, but it is also a correctness issue. Parameter binding gives the database a much clearer boundary between the query itself and the data being supplied to it.

The second problem is migrations and schema drift. Longtail Forge already runs migrations automatically, but there is now a more explicit workflow for creating a migration, refreshing a generated picture of the final schema, and checking that picture afterward.

That generated schema is useful because a stack of migration files tells you how the database got here. The final-schema snapshot tells you what “here” is supposed to look like.

Those are different questions.

I don’t expect somebody self-hosting Longtail Forge to care what command I used to create migration 47. I do expect them to care that an update doesn’t leave the application and its database disagreeing about what columns, indexes, or constraints are supposed to exist.

This is still risk reduction, not magic. A schema check can’t prove every future migration is perfect. It makes a particular class of mistake easier to detect before that mistake reaches somebody else’s database.

---

Technical discovery & auditing

The public page doesn’t tell you much about the machinery behind it. Raymond Tec audits inherited and long-running projects to uncover the plugins, integrations, data, dependencies, and old decisions that determine what the next change will really involve.

---

The browser finally gets a vote

A unit test can prove that a function returns the right answer. It can’t prove that the button is visible on a phone, that the page can be used with a keyboard, or that focus jumps somewhere absurd after a modal closes.

For that, the application actually has to render.

Longtail Forge now has a separate Playwright end-to-end smoke test that opens the real application in a managed browser environment at named desktop and mobile viewport sizes. It’s intentionally separate from the normal fast development gate because browser tests are heavier, and pretending they cost nothing would just make the whole test process slower.

The browser pass also includes automated axe accessibility scans and explicit keyboard and focus checks.

I want to be careful with that sentence, because accessibility tooling is one of those places where green checkmarks can become marketing copy faster than they become reality.

A clean axe scan doesn’t mean “Longtail Forge is WCAG compliant.” The project documentation says that directly. Automated tooling can catch a useful set of accessibility failures. It can’t tell me whether every workflow makes sense to a screen-reader user, whether the language is clear, or whether I have technically satisfied a rule while still building an irritating interface.

So this is a better net, not a certificate.

It’s still an important net. Longtail Forge is explicitly supposed to help people resume work and reduce the amount of context they have to hold in their heads. It would be a pretty spectacular own goal to build that around an interface that becomes harder to use because somebody relies on a keyboard, a smaller screen, or assistive technology.

---

Custom application development

Off-the-shelf software is great when your business works the way the software expects. When it doesn’t, Raymond Tec builds focused internal tools, dashboards, portals, plugins, and custom applications around the work that actually needs to happen.

---

The boring closeout list is becoming an actual system

There’s one more piece tying this together: the project now has a single closeout command that collects several of the housekeeping checks I otherwise have to remember independently.

It checks version consistency, the generated regression manifest, the database schema snapshot, parameter binding, documentation ownership, and licensing readiness, then reports which failures are hard blockers and which items are warnings.

It doesn’t run the full regression and lint gate. Again, this is deliberately not one magic command that makes every other responsibility disappear.

What it does is turn several “did I remember to…” questions into something the project can ask consistently.

The documentation check is a good example. Changed areas can suggest which documentation probably owns the subject. If the docs really need to change, I update them. If they don’t, the closeout record can say why instead of making me edit an unrelated document purely to make a checker stop complaining.

That sounds like process because it is process. I’ve become increasingly convinced that mature software is mostly a collection of boring processes designed to keep future-you from discovering that past-you was feeling optimistic.

So, what will anybody actually notice?

Probably still less than the amount of work would suggest.

That’s fine.

A user shouldn’t need to know whether a regression was routed through a metadata-driven test bucket or whether a schema snapshot matched after a migration. The useful consequences are simpler:

• Smaller changes can get useful feedback faster, which makes it easier to keep changes small.
• Riskier shared changes are less likely to hide behind a narrow test that was never meant to cover them.
• Database mistakes have more chances to get caught before an update touches a real installation.
• Browser and accessibility problems can be found in an actual rendered application instead of being inferred from source code.
• The release process depends a little less on me remembering six separate pieces of housekeeping at the end of a long development session.

None of that makes Longtail Forge bug-free.

It makes certain mistakes louder.

I will take louder.

Where things stand now

The friends-and-family preview remains technically deployed, and invitations are still intentionally gated.

The current public project documentation still requires the signed readiness record, the participant-account review, scanner and recovery review, and an explicit invite-or-do-not-invite decision for the actual candidate before that person gets access.

So there is no dramatic “the doors are open” announcement in this update.

There is, however, a better verification system behind the door than there was before. Right now, I consider that the more important change.

---

Want the detailed version history instead of my explanation of why this stuff matters? The Longtail Forge Changelog keeps the release-level record, the Roadmap shows what I’m aiming at next, and you can subscribe for Longtail Forge updates if you would rather have the next development summary come to you.