ENGINEERING NOTES / THE BEHAVIOR BEHIND THE PROJECT
Three projects.
Three real boundaries.
A scan should respect its scope. A saved index should preserve its evidence. An interface should tell the truth about what happened.
The changes below are published here as review patches against pinned repository revisions. Each patch includes the implementation and its regression tests. The repository links identify the base projects; the patches record the local changes reviewed for this page. Reproduction instructions · Source revisions and SHA-256 hashes.
01 / RANGECHECK
Configuration is part of the boundary.
RangeCheck is an asynchronous network exposure assessment tool with explicit target scope and explainable findings. Its scope parser determines which inputs the scanner may act on.
Repository ↗The concrete defect
Converting the YAML authorization field with bool(value) accepted nonempty strings, including "false". Numeric conversions also silently accepted booleans and numeric strings; a NaN timeout passed a simple positivity check.
The change
Authorization now requires the Boolean value true. Integer limits reject coercion, and the scope-file timeout must be a finite positive number. Invalid scope is rejected before scanning starts.
Validation and limit
38 tests passed locally. New cases exercise ambiguous authorization, invalid types, NaN, infinity, and defaults. This checks the parser; it does not establish permission to scan an arbitrary address or turn a finding into a confirmed vulnerability.
02 / POLICYSCOUT
A citation needs a stable identity.
PolicyScout combines TF-IDF and sparse BM25 retrieval with rank fusion and diversification. It retrieves passages from a supplied corpus and assembles extractive answers with citations.
Repository ↗The concrete defect
The loader checked that manifest.json existed, then ignored its contents. A wrong backend, unsupported format version, changed chunk count, or duplicate citation identifier could escape that boundary.
The change
New saves use a version-4 manifest containing a SHA-256 digest of the chunk bytes. Loading validates version, backend, count, digest, required fields, and unique document/chunk identifier pairs before rebuilding from those same verified bytes. Version-3 indexes remain readable with schema and count checks.
Validation and limit
The earlier local review recorded 40 passing tests. The publication review checked the patch against the pinned source; it did not rerun this suite because its test environment lacked scikit-learn. The added regressions include a same-length text alteration, a missing digest, invalid manifest fields, malformed chunks, and duplicate citations. A checksum detects inconsistency; an attacker who can rewrite both files can replace it. It is not a signature or a guarantee of source truth.
Read the earlier source review ↗03 / NOVAMIND
A successful response must mean something.
NovaMind is a Cloudflare Pages demonstration with a business-assistant chat and a contact flow. The important engineering work is at the request and response boundary.
Repository ↗The concrete defect
The contact endpoint returned success when no storage binding was present. The chat endpoint returned promotional fallback text when inference was unavailable. Both could make an incomplete setup appear functional.
The change
Both endpoints now read bounded JSON, validate field types, and return explicit client or service errors. Contacts report stored only after the KV write resolves. Chat distinguishes unavailable inference from a usable model answer. The interface preserves failed contact inputs and displays the returned error.
Validation and limit
14 tests passed locally. Tests hold a storage write open to verify ordering, simulate failed writes and missing bindings, reject malformed and oversized requests, and check empty model output. Storage acceptance does not prove an email was delivered. Authentication, abuse controls, and operational monitoring remain separate production work.
04 / WHY THIS WORK MATTERS
Reviewable engineering.
These changes make useful interview demonstrations: start with the failing input, trace the implementation, show the corrected contract, and run the regression. They support a discussion about reliable systems, auditability, and defensive software development without implying agency use or government endorsement.