A public page is the end of a trust chain

Basaltborne explores a publishing platform for useful gear knowledge, built with AI coding assistants. Those tools can produce application surface area quickly. The engineering challenge is to prevent that speed from exposing private drafts or moving unreviewed behavior into the public experience.

The browser is treated as untrusted, privileged credentials stay server-side, and AI-generated changes require validation. Phase advancement depends on acceptance criteria and human review. The platform’s engineering work centers on those controls, from the private editorial experience to what a public visitor can read.

Set the phases and review the changes

Casey directs AI coding assistants through research, architecture, implementation, tests, documentation, and troubleshooting. He defines acceptance criteria, reviews the resulting changes, and coordinates validation. The assistants are contributors to the implementation; they are not independently authorized to advance a phase or publish.

The lifecycle separates foundational repository and database work, the public experience, and controlled publication. This gives each phase a reviewable purpose and keeps a polished interface from being mistaken for proof that the underlying data and approval boundaries work.

Enforce the boundary below the interface

The documented stack uses Next.js, React, and TypeScript for public and administrative surfaces, with PostgreSQL and Supabase for data. API/RPC boundaries, input validation, Row-Level Security, and versioned migrations separate private editorial work from the public release surface. Privileged credentials remain server-side.

Approvals are bound to an exact version, and releases are immutable. A change after approval cannot simply inherit that approval as though the reviewed artifact were unchanged. Withdrawal and rollback are part of the release model, while stale, rejected, and unapproved content remain outside the public surface.

An implemented admin-driven research flow lets the operator enter a request, download a batch launcher, and run it locally. That human-operated workflow keeps the research activity distinct from the platform’s approval and publication authority.

A publish button cannot be the security control

Exact-version approval makes the reviewed artifact the unit of authorization. An approval attached only to a mutable document name or UI flag could become detached from the content actually released. Version binding and immutable releases preserve that relationship while making withdrawal and rollback explicit operations.

The controls also separate research, drafting, validation, and publication. Tests deny stale or unapproved content and automation self-approval. Casey directs AI-assisted engineering and validates the result; generated content and generated code do not acquire permission to publish themselves.

The tests could pass locally and never run on review

A Phase 3 review found that GitHub Actions listened only to the main branch. Review branches therefore did not trigger the intended remote validation. The problem was the workflow’s trigger scope, not a failing application assertion: the relevant checks were absent from the pre-merge path.

Correcting the trigger scope enabled remote validation before merge. This is a useful secure-development lesson because the existence of test code is not enough. The event configuration has to cause those checks to run at the decision point where they are supposed to protect a change.

Know which layer each check actually exercised

At the documented Phase 3 checkpoint, remote validation passed Supabase migration replay, database policy assertions in pgTAP, database lint with no findings, and Vitest application tests after the trigger fix. These checks exercised reproducibility, data-layer behavior, and application logic in the remote CI environment.

Browser tests, accessibility scans, and a secret scan were run locally at that checkpoint. Keeping those results distinct from remote CI makes the evidence precise: the tests cover different risks and ran in different environments. The outcome is a platform foundation with verified release controls, with research and publishing authority kept separate.

Connect architecture to proof

The CI repair demonstrates a practical improvement in validation design: check that the gate runs, not only that the underlying tests exist. Distinguishing remote results from local checks makes the release evidence easier to assess and prevents a stronger assurance claim than the workflow actually provides.

Exact-version approvals, immutable releases, and tests against stale or self-approved content connect application architecture to authorization and provenance. Casey’s work directing and validating AI-assisted changes demonstrates skill in defining what is approved, where that rule is enforced, and which evidence supports the release decision.