DEV Community: Demi Valerith

Your Cargo.lock Diff Is Also a Permission Diff

Demi Valerith — Fri, 21 Aug 2026 02:22:21 +0000

The concrete problem

A Rust dependency change looks deceptively tidy in review. The pull request shows a few lines in Cargo.toml, a larger Cargo.lock diff, and perhaps a green build. But the first build may execute code before the application itself ever runs. A transitive crate can ship a build.rs that reads files, launches tools, or reaches the network with the developer account's ambient permissions.

The uncomfortable part is not only that build scripts are powerful. It is that teams have no compact way to review how that power changes with a lockfile update. A developer can inspect source, build inside a container, or watch a long syscall trace, but none of those produces a simple answer to the merge-time question: what new capability does this exact crate version request?

The current signal

On August 20, SafeDep reported that the compromised arrayref 0.3.10 release pulled in a typosquatted proc-macro1 crate. Its build.rs downloaded and executed a remote payload during compilation. The malicious versions were later removed, but a project only had to compile a dependency graph containing them to trigger the build-time behavior.

RayTally captured the related Hacker News discussion at 2026-08-21 00:33 UTC, when it was ranked fifth with 378 points and 355 comments. Those numbers are a historical attention snapshot, not evidence of market size or lasting demand. The engineering signal is narrower: a real incident made the permission boundary around first builds visible to a large group of developers at once.

This is not a wholly unexplored problem. An accepted Rust project goal examined sandboxing build scripts and limiting access to resources such as the filesystem and network. cargo-safe also runs Cargo commands through Apple's sandboxing mechanism on macOS. The remaining product opening is finer-grained review: permissions attached to an individual crate version, visible as part of the dependency change rather than hidden inside one whole-project sandbox policy.

A product direction: review capabilities, not just packages

Imagine a Cargo wrapper that compares the previous and proposed lockfiles, identifies new custom-build targets, and runs each build script under its own policy. The default policy allows reading that dependency's source and writing to its assigned target directory. File access outside those bounds, subprocess execution, and network requests stop before the action and become explicit review items.

The review artifact should say more than “network denied.” It should identify the crate and exact version, the requested domain or executable, and the best available call-site attribution. A developer can approve the request once, reject it, or commit a narrowly scoped policy next to Cargo.lock. When the version changes, the approval expires automatically. CI can then treat an undeclared capability as a merge blocker.

The full product brief and source evidence on RayTally includes the historical observation boundary, competitor comparison, implementation outline, and four original sources.

Minimal entry point

Start with Linux development environments and common CI runners. Use cargo metadata plus the lockfile diff to map changed packages and custom-build targets. Wrap the Cargo process, associate descendant build-script processes with their crate, and route file and process operations through a syscall broker. Put outbound traffic behind a controlled proxy so policies can be expressed as domains rather than unstable IP addresses.

Keep the first policy format intentionally small: crate name, exact version, action type, and allowed path, executable, or domain. Store it in the repository so dependency and permission changes are reviewed together. If debug information cannot reliably recover a source line, report the script path and call stack instead of pretending the attribution is exact.

The MVP should not promise cross-platform parity, audit arbitrary compiled binaries, or replace source review. Its job is to make the first build of a changed dependency observable and interruptible.

The strongest case against

Legitimate build scripts do a surprising amount of work. They invoke compilers and linkers, probe the host, call Python, and sometimes download artifacts. A secure default may therefore break ordinary builds often enough that developers respond by approving broad rules. Once approval fatigue sets in, a capability ledger becomes security theater.

Domain rules introduce their own ambiguity through DNS, redirects, proxies, and mirrors. Hermetic CI may exercise different paths from local development. Per-crate process attribution can become messy when tools spawn helpers, while source-line attribution may disappear under optimization or library calls. Linux, macOS, and Windows also expose very different isolation primitives, making portable policies expensive to maintain.

There is a simpler competitor to the entire idea: build untrusted dependency changes inside a disposable, network-restricted container and inspect suspicious crates manually. If the finer-grained tool creates compatibility failures before it produces a useful permission diff, teams will return to that coarse boundary. The product only wins if common crates work with low-friction recipes and every exception remains specific enough to review.

Question for readers

Would you treat a new build-script permission like a dependency update that requires code review, or is a disposable, network-restricted build environment already the right boundary for your team?

A Security Fix Should Show Where the Attack Stopped

Demi Valerith — Tue, 18 Aug 2026 03:20:37 +0000

The concrete problem

A security pull request can be green for the wrong reason. Unit tests may pass, the vulnerable endpoint may return a different status code, and a scanner may stop reporting the original finding. None of those results necessarily shows that the attacker lost the capability that mattered. The same identity might reach the sensitive action through another route, inherit a broader token, or trigger an equivalent workflow with slightly different input.

This becomes especially uncomfortable when an automated tool proposes or reviews the fix. A plausible patch explanation is not behavioral evidence. The reviewer still needs to know which identity was used, which preconditions were established, which requests ran, where privilege was gained before the fix, and at which exact step the patched build denied it. Without that trace, “fixed” is partly an assertion about code rather than an observation of the attack path.

The current signal

On August 17, Wiz described a GitHub Actions script-injection flaw in a Snowflake repository. The vulnerable workflow change reached production on June 18 and Wiz reported exploiting it on June 23. The final squash commit credited Copilot Autofix as a co-author, while AI-assisted review did not flag the injection. Wiz later clarified that it could not determine whether the code change itself was AI-generated. That distinction matters: the lesson is about assurance around AI-assisted workflows, not proof that a model wrote the bug.

The Hacker News discussion was active when RayTally captured it at 2026-08-18 00:33 UTC: 306 points, 123 comments, and rank 5. Those are historical attention numbers, not market validation. The useful engineering signal is narrower. Teams now have a concrete incident in which an apparently protective condition and an escaping routine still produced a reachable credential-exfiltration path.

Bright STAR and StackHawk show that dynamic testing in CI is already real. Bright documents building and starting applications, reproducing findings, applying fixes, and rescanning. StackHawk supports authenticated DAST, multi-role authorization testing, custom scripts, and CI integration. The remaining product question is not whether scanners can run against a live application. It is whether a reviewer can preserve one known attack as an acceptance test and compare its behavior across both sides of a patch.

A product direction: make the attack trace the review artifact

Treat the reproduction as a versioned object attached to the security PR. It should declare test identities, prerequisite state, ordered requests, expected sensitive effects, and the evidence needed to prove each step. The system deploys the baseline and patched commits into separate isolated environments, runs the same trace against both, and captures authorization decisions, audit events, and selected application spans.

The result should read like a small proof: the baseline gained access at step six; the patched build was denied at step four; no alternative privileged call appeared in the remainder of the trace. If the replay cannot complete because a short-lived token expired or a third-party callback is unavailable, the check should say “unresolved,” not quietly convert uncertainty into a pass.

The full product brief and source evidence on RayTally includes the historical observation boundary, competitor comparison, implementation outline, and original sources.

Minimal entry point

Start as a GitHub App for web applications using GitHub Actions. Let teams describe roles, seed requests, reset hooks, and success assertions in a repository file. Check out the baseline and patched commits separately, start each with Docker Compose, then replay HTTP and browser steps with a bounded runner. Pull server-side evidence from structured audit logs or OpenTelemetry traces and report redacted differences through the Checks API.

The first version should cover authentication, object-level authorization, and ticketing-style integrations. It should not attempt to invent arbitrary exploits, scan every repository, or replace penetration testing. A team brings a known reproduction; the product makes that reproduction safe, repeatable, and reviewable.

The strongest case against

Dual-environment replay is expensive to adopt. Many applications cannot start cleanly in CI, and realistic authorization tests require resettable data plus least-privilege accounts. SSO, expiring tokens, asynchronous jobs, and third-party callbacks introduce nondeterminism. Attack scripts are hostile by design, so the runner also needs strict egress controls, managed credentials, resource limits, and automatic cleanup.

The evidence can still lie. Comparing status codes is too shallow, but adding traces and audit logs requires application-specific instrumentation. A patch may block the recorded route while leaving an untested equivalent open. As role matrices grow, execution time and compute cost can turn a useful check into a merge bottleneck. Worst of all, one false declaration that an exploitable issue is fixed can destroy trust in the gate.

Existing DAST products may also absorb this workflow faster than a new vendor can earn security approval. The product is defensible only if its dual-version trace is substantially easier to author, inspect, and preserve than a custom regression test.

Question for readers

When you approve a security fix, what evidence would make you trust it most: a scanner rescan, a replay of the original attack, an authorization trace, or a deliberately independent second exploit attempt?

Your SQLite Upgrade Test Should Include the Crash Between Two Writes

Demi Valerith — Fri, 14 Aug 2026 02:53:50 +0000

The concrete problem

A desktop app, local-first client, or edge service can pass every ordinary test and still lose data when a process dies at exactly the wrong moment. The difficult cases are not usually malformed SQL. They live in the ordering among transaction commits, WAL resets, checkpoints, file replacement, and storage synchronization.

That makes a dependency upgrade awkward. A test suite can prove that the application still opens, queries still return expected rows, and migrations complete. It does not automatically prove that the database remains coherent after an abnormal exit during a narrow write sequence. The failure may appear only under concurrency, and reproducing it from production logs can take far longer than fixing it.

The current signal

An August 12 Antithesis write-up described reproducing SQLite's WAL-reset defect with version 3.51.2 and then rerunning the same workload successfully against 3.51.3. The important detail was not the headline or the discussion score. It was the shape of the test: concurrent writes and checkpoints, explicit invariants such as no lost committed writes, and a deterministic environment that made the failure replayable.

SQLite's own testing documentation shows how serious the project is about this class of problem. Its harnesses simulate I/O failures and crashes through substitute VFS implementations, vary unsynchronized writes, and run PRAGMA integrity_check after recovery. That is excellent coverage for SQLite itself. Application teams still have a separate question: does our schema, migration path, set of PRAGMAs, file system, and business logic survive the same kinds of interruption?

The historical boundary matters here. RayTally recorded the Hacker News discussion at 45 points, 31 comments, and rank 19 at 2026-08-13 00:33 UTC. Those numbers are a snapshot of attention, not evidence that a product market exists. The engineering case stands on the reproducible failure and the gap between library-level and application-level testing.

A product direction: failure drills for application-owned SQLite

The useful product is narrower than a general chaos platform. Give a team a CI wrapper around its existing test command, then inject faults specifically around SQLite WAL behavior. A custom VFS can observe writes and syncs. An external supervisor can terminate the process. Each run should record the SQLite version, PRAGMA settings, file-system type, workload seed, and the precise fault point.

When an invariant fails, the output should be an engineering artifact rather than a dashboard alert: the database, WAL and SHM files; the ordered operation trace; the affected application assertion; and a command that reproduces the failure locally. A reducer can then remove transactions, SQL statements, and fault points until it finds the smallest sequence that still fails.

That last step is the product. Storage testing is already possible with custom harnesses and whole-system simulation. What many application teams lack is a compact regression case they can attach to an upgrade pull request and rerun six months later.

The full source-linked product brief on RayTally includes the observed signal boundary, implementation constraints, competitor comparison, and original evidence.

Minimal entry point

Start with Linux CI runners, single-machine WAL mode, reproducible temporary volumes, and one language binding. Accept an existing test command plus a small set of invariants: integrity_check, selected queries, row-count relationships, or application assertions. Do not promise realistic power-loss simulation across every controller and file system. Call the first version what it is: a repeatable application-level fault harness.

Package it as a GitHub Action. On a SQLite dependency update, run a bounded matrix over the old and new versions. If the new version fails, preserve artifacts and generate a sanitized reproduction bundle. If both pass, report the exact tested conditions instead of claiming that corruption is impossible.

The strongest case against

A simulated fault model can be misleading. A custom VFS sees SQLite's file operations, but it cannot fully reproduce kernel caching, disk controllers, firmware, or genuine power loss. The tool may find failures that never occur on target hardware, while missing failures caused below its observation layer. Statically linked builds and unusual bindings also make interception difficult.

There is a second problem: the harness can only verify the invariants a team provides. integrity_check may pass while business data is logically wrong. Stronger assertions reduce that blind spot, but they increase onboarding work and can create false positives. Sequence reduction adds more reruns and more CI time. Captured database files and traces may contain customer data or secrets, which makes redaction and retention a product requirement rather than an afterthought.

For a small application using a single connection and a fixed SQLite version, a dedicated tool may be harder to justify than a few focused crash tests. The product earns its place only if it turns rare failures into short, trustworthy regression cases with less effort than maintaining a custom harness.

Question for readers

If you maintain SQLite in a desktop, mobile, local-first, or embedded product, what would you trust as the release gate: library integrity checks, application-level invariants, replay on real hardware, or some combination of all three?

Parallel Coding Agents Need Handoffs, Not More Terminals

Demi Valerith — Tue, 11 Aug 2026 03:42:13 +0000

The concrete problem

Running two or three coding-agent sessions is easy. Knowing when their work is safe to combine is not.

One session changes an API while another writes regression tests against the old shape. A third investigates a production failure and quietly edits the same configuration file. Git worktrees prevent immediate filesystem collisions, but they do not explain task dependencies, transfer assumptions, or warn that two agents are solving incompatible versions of the problem.

The developer becomes a human message bus: checking terminals, copying commit IDs, repeating context, and deciding which session should wait. The more capable each agent becomes, the less useful a wall of terminal panes is as a coordination interface.

The current signal

Claude Code now supports messaging between sessions on the same machine. Its documentation describes session discovery, plain-text messages, and a local messaging socket. Agent view separately exposes background-session state, worktrees, pull-request status, and a JSON listing suitable for scripts. Hooks can observe tool input and block a tool call before execution.

That does not prove demand for a new product. It does create a concrete implementation moment: the primitives for handoffs and visibility exist, while dependency ownership and conflict negotiation remain a workflow problem.

In RayTally's bounded Hacker News snapshot at August 9, 00:33 UTC, the cross-session messaging discussion had 50 points and 26 comments and ranked 18th. Those numbers describe that historical observation only; they are not user counts, market validation, or a prediction of lasting interest.

A product direction: a control desk for handoffs

The useful product is not another chat window. It is a small local control desk that makes each session declare four things: its goal, worktree, files it expects to touch, and the result another session is waiting for.

When the API session finishes, the testing session should receive a compact handoff containing the commit, changed contract, verification target, and unresolved assumptions. If the tests cannot proceed yet, that dependency should be visible as a blocked edge rather than buried in prose. Completed work should land in a review queue with test output and a diff summary, not disappear into a terminal scrollback.

The full RayTally product brief and four-source implementation trail cover the source boundaries, native-feature gap, and business model in more detail.

A minimal entry point

Start with one developer, one repository, Claude Code, and Git worktrees. A local daemon can read the session list, register roles through session-start hooks, and collect commits plus test output when work finishes. Cross-session messages carry only structured handoffs: producer, consumer, dependency, commit, expected behavior, and open question.

For conflict prevention, begin with advisory file leases. Before an editing tool runs, a hook checks whether another active session has declared the same file. If so, it returns the owner, task, and suggested alternatives: wait, negotiate ownership, or work on a different file. Do not attempt automatic merging or function-level locking in the first release.

The first useful demo should be deliberately small: one session changes an endpoint, one updates its tests, and one changes shared configuration. The product succeeds if the developer can see the dependency, transfer the API result once, and catch the shared-file collision before review.

An open-source local dashboard is a natural distribution wedge. Hosted history, cross-device access, custom coordination rules, and team permissions can wait until the local loop proves that it reduces terminal switching and review confusion.

The strongest case against

Claude Code already has agent view, worktrees, and cross-session messaging. A thin dashboard could be absorbed by native features quickly. The product needs to prove that explicit dependencies and reviewable handoffs save more time than they add.

File leases are also blunt. Two agents can safely edit different parts of one file, while changes in different files can still conflict semantically. Strict blocking will serialize useful work; loose warnings will be ignored. Generated files, renames, and formatter passes make ownership even noisier.

There is a deeper reliability problem: coordination state becomes harmful when it is stale. If a session crashes, switches tasks, or edits outside its declaration, the board can look orderly while the repository is not. Developers may simply bypass the tool after a few false blocks. A plain convention using worktrees and handoff files might remain cheaper and more transparent.

Question for readers

When you run coding agents in parallel, what fails first: transferring context, tracking dependencies, or discovering overlapping edits—and what evidence would convince you that a coordination layer is worth keeping?

When ‘Are We Affected?’ Requires Reconstructing Yesterday’s npm Install

Demi Valerith — Fri, 07 Aug 2026 02:23:23 +0000

The concrete problem

A package is reported compromised. Your security channel immediately fills with one question: did we ship it?

Looking at the repository’s current dependency tree is not enough. The vulnerable version may have existed for only a short time. Renovate may already have replaced it. A lockfile may have changed after the release. A Docker layer or CI cache may have reused something that no longer appears on the default branch. Even a clean scan today can say very little about the artifact built yesterday.

This makes supply-chain response a reconstruction problem. The useful unit is not the repository as it exists now; it is a particular artifact, produced by a particular build, from a particular set of resolved packages.

The current signal

On August 4, Aikido disclosed that a maintainer account behind Keyv-related packages had been compromised and that malicious releases used install-time code to steal credentials and propagate. In RayTally’s bounded Hacker News snapshot at August 5, 00:33 UTC, the discussion had 227 points and 120 comments and ranked sixth. Those figures describe that observation only; they are not market demand or proof that a new product would succeed.

The operational lesson is more durable than the snapshot: a fast-moving package incident can be over before a team finishes asking whether any released artifact ever contained the bad version.

A product direction: artifact-centered incident reconstruction

Imagine a tool that accepts a lockfile, build timestamp, artifact digest, and the relevant CI evidence. It reconstructs what that build actually resolved, then produces a report organized around images, services, and customer-delivered versions.

Each conclusion should carry an evidence label. A lockfile entry with resolved and integrity fields is direct evidence. A registry publication window combined with a semver range is an inference. Missing build logs are a gap, not a green checkmark.

That distinction matters because the output may drive expensive or irreversible decisions: isolating a service, rotating credentials, rebuilding releases, or notifying customers. A useful report must show the dependency path and the evidence behind every claimed hit.

The product should also resist the temptation to become an automated incident commander. It can identify affected artifacts and propose the smallest upgrade-and-rebuild set. It should not rotate keys, disable production, or send notifications without human review.

The full RayTally product brief and its four-source evidence trail cover the source boundaries, competitor gap, and business model in more detail.

A minimal entry point

Start with npm projects built in GitHub Actions. Accept package-lock.json or npm-shrinkwrap.json, the build time, an artifact digest, and a saved build log. Keep every result keyed to the artifact digest so a later scan of the current branch cannot overwrite history.

The first report only needs four states:

Confirmed present: the locked version and integrity match the artifact’s build evidence.
Confirmed absent: complete evidence shows another resolved version.
Possible exposure: the version range and registry timeline overlap, but resolution evidence is incomplete.
Unknown: required logs, caches, or lockfiles are missing.

An open-source CLI could produce a reviewable JSON report locally. A hosted layer could later map digests to deployed services and customer versions, retain evidence, and coordinate isolation status. That is a narrower and more defensible first product than another always-on vulnerability dashboard.

The strongest case against

The hard part is not parsing npm metadata. It is making a trustworthy claim from evidence that organizations routinely fail to retain. Build logs expire. Private registries rewrite metadata. Multi-stage images hide intermediate dependency trees. CI caches cross build boundaries. Teams may not have a reliable mapping from an artifact digest to the release a customer received.

A product that converts those gaps into confident red or green badges would be dangerous. False positives can trigger unnecessary outages and incident disclosures; false negatives can delay credential rotation after a real compromise. The required evidence model may be so conservative that many early reports end in “unknown,” which is honest but commercially frustrating.

There is also a platform question. Existing SCA vendors already retain project snapshots for customers who enabled monitoring before an incident. The wedge only exists where artifact-level historical reconstruction is materially better than those snapshots—and where teams value a forensic report enough to maintain the extra build evidence.

Question for readers

What evidence does your build system retain today that would let you prove which exact dependency tarballs entered an artifact six weeks ago—and which missing piece would make that proof impossible?

The Hard Part of CAD Automation Is the Exception Queue

Demi Valerith — Tue, 04 Aug 2026 02:23:13 +0000

The concrete problem

Generating one mechanical drawing is increasingly automatable. Generating hundreds of drawings that an engineer can safely release is a different problem.

A batch of machined parts may share the same basic shape, hole pattern, title block, and dimension style. That makes the batch look like an ideal target for automation. But a single extra hole, changed datum face, or unusual section view can turn a time-saving rule into an error repeated across dozens of sheets. The real bottleneck is therefore not placing views. It is deciding which parts can share a rule, showing why they were grouped, and routing exceptions back to a human before the drawings reach purchasing or the shop floor.

The current signal

On July 30, a developer posted a tool that generates technical drawings from a 3D file path, with controls for layout and featured views. The developer said doing the same work manually for hundreds of models would have taken ages. At RayTally's August 4 observation boundary, the post had accumulated 69 likes, 4 reposts, and 1,851 views since publication. Those numbers are a bounded snapshot, not market validation. They are useful because the demo makes a familiar batch-workflow problem concrete.

The surrounding tooling also shows how much of the lower layer already exists. Autodesk's Inventor API exposes operations for base, projected, and section views. DraftAid says it can learn company drawing standards from existing models and drawings, apply uploaded templates, and support several machined and sheet-metal part types. A new product cannot win merely by saying it turns 3D into 2D.

Product direction

The more interesting product is a review system built around part families and exceptions.

An engineer imports a batch, and the system groups parts using explainable geometric features: bounding-box ratios, major planes, hole patterns, wall thickness, and assembly faces. It generates one representative drawing per family. The engineer approves the primary orientation, section locations, dimension references, and notation on that representative. Only then are the rules propagated to siblings.

Every propagated result should retain a traceable link from annotation to model feature. If one part contains an unmatched hole or cannot use the approved section, it leaves the happy path. The interface should say exactly how it differs from the representative part and place it in an exception queue. It should never invent a tolerance to make the sheet look complete.

That changes the value proposition from "AI makes drawings" to "engineers review fewer drawings without losing control of the risky ones." The measurable workflow outcome is not sheets generated per minute. It is how many sheets require full review, how many exceptions are caught before release, and whether a reviewer can reproduce why each rule was applied.

The full product brief and source evidence on RayTally goes deeper into the target user, competitors, and evidence boundaries.

Minimal entry point

Start narrower than a general CAD copilot:

Build an Inventor plug-in for prismatic machined parts.
Accept editable IDW or DWG files as templates, not arbitrary PDFs.
Extract a small, inspectable feature vector for each part and cluster by explicit distance rules.
Generate base, projected, and section views through the existing drawing API.
Let the reviewer approve one representative part, then propagate only view, section, and dimension-reference rules.
Send unmatched geometry and missing tolerances to a visible exception queue.

Assembly drawings, freeform surfaces, automatic tolerance generation, and cross-CAD support should stay out of the first release. A public STEP set with deliberately modified holes and faces would make a better early test than a polished demo on perfectly uniform parts.

The strongest case against

The uncomfortable possibility is that the exception system does not reduce review work at all. STL-like geometric similarity is not design intent. Legacy drawings contain conventions that layout analysis cannot recover, and tolerances, datums, and surface finishes often depend on assembly relationships outside the part file. False grouping can propagate a serious mistake; conservative grouping can leave engineers reviewing every sheet anyway.

There is also a credible build-versus-buy objection. Existing CAD APIs and internal scripts already work well for companies with stable part rules, while commercial drawing automation is moving toward template adaptation. A new layer must prove that maintaining its grouping logic costs less than extending those scripts. One bad release can erase more trust than a month of successful drafts creates.

Question for readers

If you automate CAD or manufacturing documentation today, where does human review actually concentrate: view placement, dimension references, tolerance decisions, or detecting the one part that should not have inherited the batch rule?

Why Yard Material Calculators Disagree

Demi Valerith — Wed, 29 Jul 2026 18:09:25 +0000

Two calculators can receive the same length, width, and depth and still recommend different amounts of gravel. That does not automatically mean one is broken. More often, the disagreement comes from assumptions that the interface never shows.

I ran into this while building open yard-material calculation data. The arithmetic is short. The data contract around the arithmetic is where most of the product decisions live.

Start with volume, not weight

For a rectangular area measured in feet and inches, the base volume is:

const cubicFeet = lengthFt * widthFt * (depthIn / 12);
const cubicYards = cubicFeet / 27;

A 20 ft by 10 ft area at 3 inches deep is 50 cubic feet, or about 1.85 cubic yards. At this stage, a calculator should still be describing geometric volume. It should not silently pretend that every material has the same weight.

Round shapes need their own formulas. A circular bed uses pi times radius squared. A ring-shaped bed subtracts the inner circle from the outer circle. Treating every project as a rectangle can create a larger error than any later rounding choice.

Density is a range, not a universal constant

Converting cubic yards to tons introduces material density:

const tons = cubicYards * tonsPerCubicYard;

The multiplication is easy. Choosing tonsPerCubicYard is not.

Pea gravel, crushed stone, river rock, topsoil, compost, and mulch have different typical densities. Moisture, gradation, compaction, and local supplier definitions move the real number again. A calculator that uses one density for all gravel products may look precise while hiding its largest uncertainty.

For that reason, I prefer storing a planning range and a clearly named default. The default keeps the interface usable. The range tells the user that the result is an estimate rather than a final quote.

The underlying values I use are published in the open Yard Material Coverage Data repository. It includes coverage, density, and bag-conversion CSV files plus a data dictionary and methodology notes. Keeping the data separate from the UI makes the assumptions reviewable and reusable.

Waste factors should be explicit

A waste or contingency factor is usually applied after base volume:

const orderYards = cubicYards * (1 + wastePercent / 100);

But waste means different things for different projects. It might cover irregular boundaries, settlement, spillage, grading corrections, or a supplier minimum. Adding 10 percent without showing it can make two otherwise identical calculators disagree immediately.

The interface should show:

base calculated volume;
selected contingency percentage;
adjusted order quantity;
the rounding rule used for the final recommendation.

That separation also makes analytics more useful. You can learn whether people change the contingency instead of only seeing the final output.

Bag conversions are packaging assumptions

Bulk volume and bag counts are related, but a bag is not a unit. Common products may be sold in 0.5, 1, 1.5, or 2 cubic foot bags. Some regions use liters.

A transparent conversion looks like this:

const cubicFeetNeeded = orderYards * 27;
const bagCount = Math.ceil(cubicFeetNeeded / bagSizeCubicFeet);

Always round bag counts up. Also display the selected bag size next to the result. Otherwise a user cannot tell whether 34 bags means 34 one-cubic-foot bags or 34 two-cubic-foot bags.

The public material coverage chart exposes these relationships across depth, cubic yards, typical weight ranges, and common bag sizes. It is more useful for auditing assumptions than a result box that only says buy 2 tons.

Rounding belongs at the edge

Rounding intermediate values compounds error. Keep full precision through geometry, unit conversion, density, and contingency. Round only for display or purchasing units.

I normally keep internal cubic yards as a floating-point value, display two decimals for the base estimate, and round the purchasing recommendation according to the material and packaging context. Bags round up to whole units. Bulk yards may round to a supplier increment such as 0.25 or 0.5 yard, but that increment should be presented as a planning assumption rather than a universal rule.

A useful result needs an audit trail

A calculator becomes more trustworthy when a user can answer these questions without reading source code:

Which shape formula was used?
Which unit conversions were applied?
What density or density range was selected?
Was contingency added?
How was the final amount rounded?
Which local conditions can change the result?

This does not require a wall of warnings. A compact Assumptions section and a printable material list are usually enough.

Make the calculation reusable

Once the formula and data are separated, the same calculator can serve a standalone page, a supplier resource, a gardening article, or a WordPress site without duplicating logic.

I packaged the browser-side version as a privacy-friendly Web Component. The embed configurator lets a publisher choose materials, units, defaults, and accent color, then copy the generated markup. The component performs the calculation locally and does not require cookies, browser storage, or background requests.

There is also an open-source WordPress block and shortcode that bundles the component locally. That matters for publishers who do not want a remote script dependency.

What I would test

Formula unit tests should cover more than the happy-path rectangle:

rectangular, circular, and ring-shaped areas;
zero and negative input rejection;
imperial and metric equivalence;
depth unit conversion;
density range boundaries;
contingency application;
bag rounding;
very small and very large projects.

Then test the explanation layer. Confirm that every default used by the calculation is also visible in the rendered assumptions. A mathematically correct function can still produce a misleading product if the UI hides the choices around it.

The practical rule

When two material calculators disagree, compare their assumptions before comparing their decimals. Geometry, density, contingency, bag size, and rounding usually explain the gap.

Publishing those assumptions as data and presenting them beside the result makes the calculator easier to test, easier to embed, and easier for a homeowner to use as a planning estimate.

Before Grok Build Uploads Your Repo, Show the Outbound Receipt

Demi Valerith — Wed, 29 Jul 2026 15:01:43 +0000

Coding agents create an awkward security moment. A developer can understand the task they typed and still have no compact answer to a more important question: what is about to leave this machine?

The answer may include more than a prompt. It can involve file contents, paths, repository metadata, environment details, identifiers, or a separate upload flow. Network inspection can reveal those details after enough work, but that is the wrong level of friction for a decision that happens every time someone submits a sensitive task.

A recent Grok Build analysis makes the design problem concrete. In a wire-level test of Grok Build 0.2.93, the author reports that the CLI sent contents from files it had read and used a storage interface to upload the repository and Git history. That is one reproducible report about one observed version, not a claim that every version or coding agent behaves the same way. xAI had announced early access to Grok Build for SuperGrok and X Premium Plus subscribers on May 25, 2026.

The useful product question is not whether developers should trust or distrust a specific vendor. It is whether a coding agent can make the outbound decision inspectable before transmission rather than leaving it to a packet capture afterward.

The receipt should describe this request, not the privacy policy

A generic privacy notice cannot answer which repository, files, paths, and metadata are included in the next request. An outbound receipt can.

Immediately before transmission, the CLI would pause and render a structured inventory:

prompt and conversation context;
file fragments and complete files;
repository or archive uploads;
file paths and repository metadata;
environment details and identifiers;
destination endpoint and client version.

The list should represent what the client has actually assembled. It should not be generated from a static documentation table or a guess about what an agent normally sends.

The first receipt in a repository deserves the most attention. Later receipts can emphasize the delta: a newly included directory, a larger archive, another upload endpoint, or a field that was absent in the previous client version. A developer should be able to understand the change without reading raw JSON.

Approval is not enough; editing is the useful interaction

A modal with only Allow and Cancel turns inspection into ceremony. The receipt becomes more useful when each item can be changed in place.

For example, the developer could:

remove a file or path from this request;
replace a secret-looking value with a local placeholder;
exclude Git history while keeping selected working files;
approve the remaining payload once;
save the final receipt locally for review.

This is deliberately narrower than a general data-loss-prevention system. It does not need an organization-wide classification engine to help one developer notice that .env.example, an internal path, or the entire Git history is included in a request.

The tool should also make its limits visible. Redacting a displayed field is meaningless if a second upload path still contains the original value. The receipt therefore has to be generated after the final payloads are assembled and cover every outbound request involved in the submission.

A local record can catch client drift

After approval, the tool can save a small local record containing the receipt, timestamp, destination, and CLI version. The record should avoid duplicating sensitive source material by default; hashes, field names, byte counts, and explicit redaction markers may be enough for comparison.

That creates a practical review surface. A security lead can compare two versions and ask why repository history appeared, why payload size changed sharply, or why a new endpoint was introduced. The artifact does not prove what a remote service retained, and it should never claim to. It records the client-side transmission decision that the user approved.

A team policy can then remain simple and auditable:

always pause before repository or archive uploads;
block known secret patterns unless they are redacted;
require a second approval when new outbound fields appear;
retain metadata-only receipts for a defined period;
fail closed when the interceptor cannot parse a changed protocol.

That last rule matters. If a client update changes certificate handling, request structure, or its storage protocol, silently falling back to pass-through would defeat the product. The user needs an explicit message that the receipt is incomplete and that transmission did not proceed.

The smallest credible implementation

A first version only needs to support one tested Grok Build release and two paths: model requests and repository storage uploads. It can run as a local proxy or wrapper, parse those requests into a fixed schema, and present the receipt in the terminal.

The acceptance criteria are concrete:

nothing leaves before the receipt is rendered and approved;
prompts, file content, paths, identifiers, and repository uploads appear as separate items;
removing or replacing an item changes the final outbound payload;
the saved local record identifies the CLI version and approved fields;
an unknown request shape stops transmission instead of bypassing inspection.

A reproducible demo should use a disposable repository with fake keys and compare the approved receipt with a captured outbound session. That would test the core promise without asking users to trust another opaque security layer.

The strongest case against it

The protocol may change too quickly. A third-party interception layer could become a permanent compatibility project, and certificate pinning or encrypted upload formats may make reliable parsing impossible. A wrapper can also create a false sense of safety if the agent launches another process or transmits through a path the tool does not observe.

There is a usability cost as well. If every request produces a large checklist, developers will approve it mechanically. Useful defaults must therefore make small, repeated payloads quiet while forcing attention onto meaningful changes. The product has to prove that its inventory is complete and that editing the receipt really edits the bytes being sent.

Those constraints are why this should start as a narrowly tested, version-bound tool rather than a universal promise for every coding agent.

The source list, observed-version boundary, complete product brief, and implementation caveats are on RayTally's Grok outbound receipt page.

What would you need to see before allowing a coding agent to upload a repository: a file list, a payload diff, an endpoint inventory, a local audit record, or something else?

What If Your Release Notes Had to Survive a Playtest?

Demi Valerith — Tue, 28 Jul 2026 08:18:07 +0000

A release note usually has one job: tell readers what changed. For a small developer tool, that can leave a gap between reading about a feature and understanding why it matters. Screenshots help, but they are passive; a demo often needs more setup than the feature it explains.

That gap is interesting when the update itself has a tight, learnable interaction. Could a changelog be designed as a tiny thing someone plays through, rather than a page they skim?

A recent signal, not a market verdict

htmx 4.0 was released as a Game Boy cartridge. On July 27, the related Hacker News post was observed at rank three with 338 points and 105 comments. Those are a point-in-time discussion snapshot, not evidence of a broad market or demand for game-like release notes. The useful part is more concrete: the release made the format memorable by putting the documentation inside a constrained interaction.

The htmx page describes a Game Boy game in which players unlock source through levels, while GB Studio provides a practical route to build both ROM and HTML5 versions. That makes the idea less speculative than it sounds: a maker does not need a custom emulator or a general-purpose game engine to test the format.

Product direction: a release-note cartridge generator

The product is not “turn every changelog into a game.” It is a narrow publishing workflow for independent developers whose releases can be explained through one or two actions. An author supplies a feature description, a few assets, the intended user action, and the visible outcome. The generator turns that into a short cartridge-style level: read a prompt, move to an object, choose an action, and see the result.

The system should deliberately offer only a few templates—dialogue, pickups, switches, and short movement. Constraints are a feature here. They stop an update writer from accidentally starting a game-design project, and they make exported artifacts predictable. A GB Studio template can compile a ROM and a web build; the web version can be embedded in a release page or used as a standalone launch artifact.

A useful editor would also surface the boring engineering details early: palette conversion, text overflow, tile limits, asset usage, broken links, and build warnings. A writer should see which screenshot or line of copy caused a limit, then change it before a public build exists.

The smallest viable entry point is one level per release, generated from a structured form and a fixed visual kit. No AI-written game mechanics, no open-ended map editor, and no attempt to replace normal documentation. The artifact links back to the canonical release notes, which remain the source of truth. For the full product brief, evidence, and caveats behind this direction, see RayTally's source-linked idea page.

The strongest case against it

Most releases are poor material for a playable format. Performance improvements, compatibility fixes, API deprecations, and security patches may have no honest level to play. Compressing a feature into a puzzle can also make the user remember the novelty while missing the actual behavior, limitations, or migration steps.

There is a maintenance cost too. Pixel art, constrained text, version links, and ROM builds all add review work. If the official release notes change after the cartridge ships, the two can drift. A web emulator can report anonymous events such as level entry or completion, but a downloaded ROM generally cannot supply equivalent feedback. Those costs mean this only earns its place when the interactive explanation is clearer than a short demo video or a live sandbox.

A question for builders

For a feature you shipped recently, what is the smallest interaction that would make its value understandable without reading a paragraph? And would building that interaction clarify the release—or distract from the work users actually need to do?

Before the DDL: What a Useful Postgres Migration Rehearsal Must Show

Demi Valerith — Fri, 24 Jul 2026 02:29:29 +0000

A migration can look tiny in a pull request and still be the riskiest line of a release. A column change, an index, or a constraint can turn into waiting writes, a blocked deploy, and an on-call decision made with very little evidence. Teams without a dedicated DBA often have lint rules and review checklists, but they still lack an answer to a practical question: what will this exact sequence do while the application is busy?

A Hacker News discussion around a startup Postgres survival guide put that question in front of a technical audience on July 22. In RayTally's July 23 signal snapshot, the discussion ranked sixth on the front page, with 301 points and 164 comments at that observed time. That is a bounded observation of attention, not proof that a product category has demand. The more durable signal is the implementation gap: static guidance can flag dangerous patterns, but it cannot show a team a plausible blocking chain or a safe point to stop.

Product direction: rehearse the change, not production

The useful product is deliberately narrow. A backend lead uploads a migration, the current schema, and anonymized table-level facts such as row counts, indexes, and access volume. The service creates an isolated Postgres environment, generates placeholder data, runs the migration under controlled concurrent reads and writes, and captures pg_locks and pg_stat_activity.

The resulting report should not say that the production deployment is safe. It should make its assumptions visible: this is a rehearsal built from partial inputs, not a replica of query shape, hot keys, hardware, background work, or long-running transactions. What it can provide is a more actionable review artifact than a red or green label: lock modes, a blocking timeline, risky statements, and a comparison of alternative execution orders.

This direction builds on existing primitives rather than inventing a new database engine. PostgreSQL documents its lock modes, conflict behavior, activity views, and custom pgbench workloads. Tools such as Squawk already catch known migration anti-patterns and recommend timeouts; its documentation correctly warns that passing lint does not establish that a migration is safe to run. Bytebase already addresses broader SQL review, approvals, staged rollout, audit trails, and drift detection. A rehearsal product should complement those systems instead of pretending to replace them.

A minimum entry point

The first version should focus on common DDL: ALTER TABLE, index changes, and constraints. It could arrive as a GitHub App that comments on a migration pull request with a static risk summary and a link to start a rehearsal. The report would show: which statement acquired which lock, what concurrent workload it blocked, where the run failed, and which operations are non-transactional.

The important output is an execution card rather than a prediction. For a selected plan, the card lists the command, the preflight metric to check, an observation window, and a user-supplied stop or rollback action. It can suggest an expand, backfill, switch, and contract sequence where that is appropriate, while marking the steps that require human judgment. The product never connects to production and never deploys a migration.

For the full product brief, source list, and the evidence boundary behind this direction, see RayTally's Postgres migration rehearsal brief.

The strongest case against it

The core risk is false confidence. Table statistics and synthetic load cannot recreate production traffic, skewed keys, background jobs, storage behavior, application compatibility, or an unexpected long transaction. A rehearsal might miss a real outage, or discourage a harmless change. Reverse SQL is not a universal rollback plan either, especially once backfills and application-version cutovers are involved.

There is also a security and cost boundary. Even anonymized schema and table metadata can be sensitive, and temporary environments take time and compute. Teams with high-fidelity staging, mature runbooks, and experienced DBAs may gain little from another step in their process. If the output is presented as a release guarantee, the tool would be worse than no tool.

That is why the smallest credible version should be explicit about what it did and did not simulate, keep all execution decisions with the team, and earn trust on a narrow set of migration patterns before expanding.

How do you currently decide that a Postgres migration is ready to run: linting, staging, a runbook, an experienced reviewer, or a combination? What evidence would make a rehearsal genuinely useful rather than another CI checkbox?

Build a Privacy-Friendly Yard Material Calculator in WordPress

Demi Valerith — Thu, 23 Jul 2026 16:25:50 +0000

A calculator looks simple until it has to work in three places: a plain web
page, a Gutenberg editor, and an existing WordPress theme.

I wanted one implementation for all three. The result is an open-source yard
material coverage calculator that estimates volume and a typical weight range
for gravel, stone, soil, compost, mulch, sand, and fill dirt.

The important part is not the formula. It is the packaging boundary.

Keep the calculation in one Web Component

The framework-neutral component is published as:

npm install @demi-valerith/yard-material-coverage-data

A plain HTML page can load the versioned module and configure it with
attributes:

<script
  type="module"
  src="https://cdn.jsdelivr.net/npm/@demi-valerith/yard-material-coverage-data@1.3.0/widget.js"
></script>

<yard-material-coverage
  material="River rock"
  materials="Pea gravel,Crushed stone,River rock"
  area="50"
  depth="7.5"
  unit="metric"
  accent="#176b58"
></yard-material-coverage>

The same module supports imperial and metric input, a material allowlist, a
sanitized accent color, and optional source attribution.

Bundle the module inside WordPress

A WordPress plugin should not depend on a third-party CDN to execute its core
code. The plugin release therefore includes the tested widget.js file and
registers it locally with wp_register_script_module.

Both WordPress integrations pass their configuration to the same custom
element:

[yard_material_calculator material="Pea gravel" area="500" depth="3" unit="imperial" attribution="false"]

The Gutenberg integration is a dynamic block. Its saved content contains the
block attributes, while PHP sanitizes and renders the current element markup on
each request. The shortcode calls that same renderer.

That avoids maintaining separate formulas for the block, shortcode, and npm
package.

Treat public attribution as a setting

The component does not use cookies, browser storage, analytics, or background
requests. Public source attribution is also disabled by default in the
WordPress plugin.

When a site owner enables attribution, the source link includes bounded UTM
parameters. They are transmitted only when a visitor chooses to click the
link. This gives the publisher control and keeps the embedded calculator free
of invisible tracking.

Make the demo reproducible

The repository includes a WordPress Playground Blueprint. It installs the
release, activates it, and creates a front page containing:

a metric Gutenberg block;
an imperial shortcode;
different material filters;
visible and hidden attribution examples.

Run the WordPress Playground demo

The same Blueprint is being proposed to the WordPress community gallery so the
demo can be reviewed and reproduced independently.

Try the live widget

Configure and embed the yard material calculator with your own units, material list, starting values, color, and attribution setting.

Source

The estimates are for planning only. Moisture, compaction, gradation, and
supplier measurements vary.

Your Backup Restored. Why Is the Application Still Down?

Demi Valerith — Tue, 21 Jul 2026 07:19:24 +0000

A backup can be perfectly readable and still fail to bring a service back.

The database may restore while the application remains offline because a signing key is missing, an object-storage bucket was not included, DNS points at the wrong place, or an identity provider cannot be reached. A recovery document may describe every command correctly but omit the order in which dependencies must return. None of this is visible when the only test is whether a backup job completed.

That gap became unusually concrete this week. Risky Business reported that an attacker breached Romania's cadastral agency, wiped systems and backups after a failed extortion attempt, and left official services offline for a week. The report also noted that the agency appeared to retain an offline copy.

The interesting product question is therefore not simply, "Do we have a backup?" It is: "Can this team use what it has to restore a working service under realistic failure conditions?"

A recovery drill that is allowed to break things

Imagine connecting backup locations, a database inventory, service dependencies, and the recovery runbook for a small containerized application. The product creates a minimally runnable copy in an isolated environment. It never targets production.

A drill then applies a specific destructive scenario to that copy:

delete the primary database;
invalidate one set of credentials;
remove a host or storage dependency;
start recovery from a selected historical point.

The important constraint is that the system follows the team's existing runbook exactly. It should not silently repair missing steps, because the missing steps are what the drill is trying to reveal.

The result is more useful than a green or red backup status. It records the recoverable data point, actual recovery time, and first failed step. If the database returns but the application page does not, the report should connect that failure to the missing dependency and the relevant runbook section.

This direction is not starting from zero. Veeam's SureBackup can start machines from backups in an isolated environment and run verification tests. AWS Elastic Disaster Recovery also documents non-disruptive recovery drills. The narrower opportunity is to make the runbook itself the test subject and produce an actionable dependency-gap report for smaller teams.

A deliberately small first version

I would start with one database, object storage, and a containerized application. The team supplies a recovery document and selects a scenario. The drill runner provisions an isolated network, restores the components, executes only the documented steps, and captures logs and timing.

The first report needs to answer four questions:

What point in time was actually recoverable?
How long did it take to reach a working business flow?
What was the first missing or incorrect recovery step?
Did any temporary resource attempt to reconnect to production?

That is enough to improve a runbook and repeat the same test next month. Broad backup-format support, automatic remediation, and production failover orchestration can wait.

The strongest case against it

An isolated environment may create false confidence. Production networking, identity systems, vendors, rate limits, and private keys are difficult to reproduce safely. A successful copy-level drill does not prove that a real incident will go smoothly.

There is also a security paradox: restoring an infected backup can recreate the attacker's foothold. A drill platform would need strict egress controls, short-lived credentials, complete cleanup, and an explicit way to mark dependencies that could not safely be reproduced.

Finally, existing disaster-recovery vendors already cover part of this workflow. A new tool would need to remain focused on something they do not make simple enough: testing the team's actual written procedure and showing the first business-level dependency that prevents recovery.

Would a runbook-driven destruction drill expose useful gaps in your stack, or would the isolated environment be too different from production to trust?

See the evidence and the full product brief on RayTally