DEV Community: Sharon Basovich

The server locked the scores. The judge’s screen still said “Update.”

Sharon Basovich — Sat, 03 Oct 2026 23:17:07 +0000

Glassbox had a misleading screen at exactly the moment a judging platform needs to be clearest.

An organizer published the results. The server correctly refused further score changes. But the judge’s page still looked editable.

A judge could spend time revising a comment, press Update, and discover that the action had already become impossible.

This turned up during the build’s browser walkthrough. The fix is small enough to read in one commit. The underlying lesson reaches beyond hackathons: a state transition has to change both what the system permits and what it tells people they can do.

Building around the moment results become final

Glassbox is an open-source, self-hosted submission and judging portal built for DOGFOOD 2026. It uses Node 24, TypeScript, built-in SQLite, and server-rendered HTML, with no runtime npm dependencies.

Its most consequential button is Publish.

Before publication, judges can revise their assigned scores and organizers can inspect raw and calibrated rankings. After publication, people need a stable answer to “What were the results?”

The implementation makes that transition explicit. Publication computes the ranking, serializes an aggregate results snapshot, hashes it with SHA-256, stores it, marks the event published, and appends an audit entry in a transaction. Public results are served from the stored snapshot rather than recalculated on every request. See the publication service.

That gives the public page a specific artifact to display. It also keeps individual judges’ score rows out of the public payload.

The browser had missed that transition.

A regression test for the promise on the screen

The fix derives the score form’s locked state from the event phase. Once published, the page displays a locked notice, disables the score fields, and removes the save and recusal actions.

The backend remains responsible for rejecting forbidden writes. The disabled form makes the restriction understandable before someone wastes effort.

The regression test follows the transition:

Open an assigned score page as a judge and confirm that saving is available.
Publish the event through the organizer API.
Fetch the judge page again.
Check for the locked notice and disabled fieldset.
Check that save and recusal controls are gone.

That test checks rendered HTML. The build’s separate browser retest also records checking that the fields could no longer be changed and that the saved score stayed unchanged.

Both checks matter. An API test can prove that an invalid write fails while missing a screen that encourages the write.

A ranking also needs an explanation

Publication freezes a number, but the number still needs a defensible path from the ballots.

Glassbox converts each review into a weighted total and offers shrunk z-score calibration. A judge’s mean and spread are blended with the event-wide pool, using three pseudo-reviews by default. Sparse judging histories therefore receive more pooling than large ones.

The important product choice is that the adjusted ranking does not erase the raw ranking. Organizers can compare them, inspect judge offsets and spreads, and export review-level values. The dashboard, exports, and publication use the same normalization implementation.

This is a model with assumptions. If a judge sees unusually strong projects, high scores can resemble leniency. Showing the adjustment makes that assumption inspectable; it does not establish that every ranking change is correct.

What the evidence establishes

The committed acceptance report records seven passing checks and verifies the claimed T1 and T2 tiers. Those checks cover public gallery behavior, deadline rejection, score access isolation, and CSV export. This is the build’s historical report; no new test run is claimed here.

They do not establish production readiness or real-world fairness.

Glassbox remains a single-node SQLite application. It has no community voting, email delivery, or built-in login rate limiting. The hash chain detects inconsistent edits, but an administrator controlling the database could rewrite the chain; there is no external trust anchor.

The reusable lesson

For an irreversible-looking moment such as publication, test three things together: the forbidden write, the newly rendered screen, and the artifact people will rely on afterward.

That small “Update” button exposed a gap between a correct backend and an understandable product. Closing that gap made the judging lifecycle much easier to defend.

Built for DOGFOOD 2026, organized by Hackathon Raptors.

#HackathonRaptors

Claim Ledger gives a project review a paper trail

Sharon Basovich — Fri, 02 Oct 2026 22:10:16 +0000

What I Built

In a fictional project, a README says the app works offline. Its limitations file says route planning still needs a connection. What should the handoff actually promise?

Claim Ledger puts the claim beside the source passages worth checking, then keeps the reviewer's decision with those receipts. In the fictional TrailMend example, the offline claim and its narrower limitation appear together. The model finds candidate evidence; the reviewer decides what the claim can support.

I built this for a teammate who takes an independent second pass through my projects. Their handoff can span a README, setup notes, test records and known limitations. The goal is to make each review decision traceable to the words it was based on.

Try the fictional packet below. Open a source passage, record a verdict, and export the review with its filenames, line ranges and content fingerprints. If the evidence changes, the earlier approval needs another look.

Excerpts from the running app's fictional TrailMend packet. Hybrid ranking surfaced both passages; this illustration preserves their meaning but is not an app screenshot. Similarity does not determine the verdict.

Demo

Try Claim Ledger. No account or API key is needed. Start with Load fictional example packet, then enable on-device AI ranking or use the labelled keyword mode. The included TrailMend, PantryPal and Inkwell documents are synthetic examples.

Try “Can I use the trail planner on a plane with no signal?” TrailMend's README discusses downloaded routes, while its limitations document excludes offline route planning and GPX import. Open the source context before deciding what the broad phrase “works offline” should mean.

A separate automated check exercised a deliberately small evidence-change scenario: a claim said an import limit was 200 items; its source was replaced with a version saying 210. The repaired app invalidated the earlier confirmation through replacement, reranking and reload. The old note remained, labelled as having been recorded against earlier evidence. Explicitly choosing Confirmed again records a new review.

The review can be exported as Markdown or JSON. These are review records, not certificates of truth.

A supplementary AI review exercised nine frozen, AI-authored public-document cases on the deployed app. All 11 supplied excerpts and their exported receipts retained exact text and manually entered provenance. The stale 48-second demo description still ranked first in the version-check case; reviewer judgment and a Follow-up note were needed. With only one to four chunks per case and expected guidance visible to the AI reviewer, this is workflow evidence, not accuracy or human validation.

Use unique filenames for different versions or projects: same-named sources replace one another. An initial harness run made this mistake; both its invalid outcomes and the corrected filename run were retained.

Code

View the application source on GitHub. The application is Apache-2.0 licensed. Source, tests, benchmark cases, raw results and correction history are included. Model and runtime binaries are distributed separately from the small source archive.

How I Built It

Build and evaluation disclosure

Fully Autonomous: AI agents researched, implemented, tested and drafted this project under my direction. The independent QA described here was automated. My teammate has not tried the tool yet, so I have no recipient feedback or measured time savings to report.

A README assertion, a supplied test record and an actual reviewer observation have different meanings. The interface labels those distinctions. A similar passage gives someone a place to investigate; it doesn't establish that a feature works.

The retrieval core combines BM25 keyword search with the open mixedbread-ai/mxbai-embed-xsmall-v1 embedding model. The pinned revision is e6ac24e5d6efb8782b59de1647b3ececb4ece94e, using q8 ONNX weights through Transformers.js 4.3.0 and CPU/WASM in a Web Worker. The model is Apache-2.0 licensed.

The model ranks candidate excerpts. It doesn't write answers or set verdicts. Hybrid mode combines lexical and semantic rankings with reciprocal-rank fusion. Keyword mode remains available without enabling the model.

Independent automated QA caught problems that mattered to the workflow: older receipts could pick up replacement text, confirmation could survive changed evidence, and multiline Markdown excerpts could escape their intended formatting. Those cases are now covered by targeted regression checks. A separate reviewer rebuilt the repaired source archive and matched its compiled JavaScript byte-for-byte to the deployed application. Typecheck, build, 48 unit tests and 16 end-to-end tests passed in that review. The browser regression runs used the byte-identical local build.

The benchmark has a less tidy story, and the source archive keeps it. It uses 48 AI-created questions over fictional documents: 40 answerable and eight no-answer cases. On the preserved exploratory run, BM25 retrieved the labelled passage first for 20/40 answerable questions; semantic and hybrid retrieval each did so for 23/40. All three methods correctly abstained on 0/8 no-answer questions. Keyword search outperformed semantic search on the negation category.

These are exploratory results. Chunking and the threshold were changed after inspecting results, on the same set. The original first raw output was overwritten and lost. A later rerun and an older differently chunked result remain separately labelled, alongside the correction manifest. The repaired release preserves those benchmark files unchanged. This is not a held-out evaluation or evidence of improved review quality.

Why Does Open Innovation Matter?

An openly licensed model makes this narrow use of AI inspectable and replaceable. Developers can compare semantic search against the keyword baseline, inspect every failed query, and decide whether the model helps their documents.

Inference processes the documents in the browser. The host still serves the site, model and runtime assets and receives ordinary network metadata. In the tested canary scenario, the reviewer observed same-origin GET requests and no transmission of the canary text. That observation is scoped to the tested flow, not a universal privacy guarantee.

Limits and Next Steps

Only Chromium has been tested; Firefox, Safari and real phones remain untested. The model-loading progress display can sit at zero while WASM initializes. An immediate reload can lose the most recent approval, which fails safely by losing the approval rather than inventing one. Deleting and re-adding byte-identical evidence can restore the earlier confirmation while also showing a stale indicator. One split receipt covers only part of its cited line, and JSON exports omit a claim's original source-line field.

The first trial with the intended teammate is still ahead. For now, the result is a working, inspectable claim-to-evidence review workflow with automated checks and visible limitations.