Auto-ship pipeline, verified before it ran live

What this is

Most consulting engagements either ship without verification or claim verification without producing artifacts. This document is the artifact. It walks the actual verification regime applied to vibekoded.com across the autoship pipeline and the v2.6 build, with real numbers from real measurement.

The gate stack

Every commit that lands on the deployment branch passes through a layered verification regime. Each layer is a gate; failing any gate stops the commit before it ships.

Layer 1: TypeScript type checks. pnpm typecheck must exit zero. No any types in new code. No untyped exports.

Layer 2: Linter. pnpm lint must exit zero. The lint config catches conventional bugs plus the project-specific voice rules.

Layer 3: Test suite. pnpm test runs the Vitest suite. As of the most recent v2.6 work, this is 33 tests across 7 files. All must pass.

Layer 4: Build. pnpm build must succeed. This catches integration errors the type checker misses (route conflicts, broken imports, page-level prerender failures). The current build produces 173 static pages and three dynamic route templates.

Layer 5: Pre-commit voice gate. Custom hook runs against staged content files: em-dash check, vendor-name check, identity-leak check, personal-name check, contact-email single-source check. Each rule is grep-based and either passes clean or blocks the commit.

Layer 6: Identity verification. Author and committer must match the deployment-platform-approved identity. The build platform rejects pushes from unauthorized identities.

These six layers run on every commit. Six gates. Six chances to catch a problem before it reaches a visitor.

What this catches in practice

A representative recent sample: during the v2.6 security remediation, a hashing function change required updates across three files plus environment configuration. Without the gate stack, this could have shipped with broken tests or undefined-environment-variable runtime failures.

The gate stack caught and surfaced:

• The hashing function's IP_HASH_SECRET env-var requirement (the function throws when the secret is missing, which the test suite verified)
• The need to update the test setup file with a stub secret value (caught by failing tests)
• An invariant comment that needed precision updating (caught by post-commit grep verification)

Each of these would have been a production bug if the gate stack had not run. Each was caught before any code reached the deployment branch.

The autoship pipeline as its own verification surface

The autoship pipeline runs unattended. It fires on a daily schedule, reads research signals, drafts content, applies the same voice gates the human commits apply, and ships to production. It is a multi-stage agent system gated against its own failure modes.

The pipeline's own gates include:

• A daily I-CAP that limits how many posts can ship per calendar day (default three) to prevent runaway output
• An I-AUTOSHIP-TARGET-MAIN invariant added on 2026-06-08 that ensures the pipeline auto-switches to the deployment branch before any commit, after a 2026-06-07 incident where a pipeline run committed to a feature branch
• An anti-repetition gate that compares today's candidate post against the last three shipped posts and rejects collisions
• A pre-commit voice gate that runs the same checks as human commits
• A push-identity gate that uses the platform-approved author identity

The pipeline ran without operator intervention on 2026-06-08 and 2026-06-09. Both runs produced live posts on the deployment branch within the expected time window. Both posts passed every gate cleanly. The methodology is alive.

Live measurement

The deployed site reports its own verification surface. Analytics across the last thirty days show:

• 179 visitors
• 758 page views
• Bounce rate 55 percent
• Top page distribution matches the funnel architecture (homepage primary, /log secondary, /work-with-us tertiary)
• Facebook is the dominant referrer (about 45 percent of visitors), reflecting the operator's distribution practice
• Cluster 3 (project rescue) blog posts lead organic discovery, confirming the pain-language hypothesis

These numbers are real because the deploying platform reports them. They are interesting because they correlate cleanly with shipping events: traffic inflected upward on 2026-05-24, which is when the autoship pipeline started firing daily. Product shapes traffic. The relationship is observable.

What the audit found

A separate read-only security audit on 2026-06-08 reported:

Severity	Count
Critical	0
High	1
Medium	3
Low	5
Informational	4

Zero critical findings on a Next.js site is not the default outcome. The discipline of running parameterized SQL, declining to expose admin routes, putting honeypot fields off-screen rather than display:none, and refusing to commit secrets all contributed. Each of those is a choice. Each choice is auditable in the codebase.

The High finding (IP spoofing in the rate-limit function) and one of the Mediums (unsalted IP hashing) were closed in commit 5d51010 before this receipt shipped. The full remediation receipt is at /receipts/security-audit-2026-06-08 for the audit trail.

The methodology lesson

Verification is not a stage at the end. Verification is what the layers do continuously.

A site that ships without verification produces unverifiable claims. A site that verifies at every layer produces an audit trail. The audit trail is the receipt. The receipt is the proof.

This document is not a claim that the methodology works. This document is a description of the measurement regime that produces evidence the methodology works. The reader can run the gates themselves, read the analytics, walk the commits, and decide.

That is the only honest form of "we ship reliable software" worth offering.

Verifiable artifacts

• The test suite: pnpm test in the repo, currently 33/33 passing
• The build output: pnpm build, 173 static pages
• Live analytics: visible on the deploying platform's dashboard, daily delta tracking
• The autoship pipeline's daily run logs: in the repo's pipeline state directory
• The security audit report: SECURITY-AUDIT-2026-06-08.md at the repo root
• The remediation commit: 5d51010 on the deployment branch