About

Solo founder building Ringly, an iPhone alarm clock and sleep app for harder mornings. I care about calm, trustworthy consumer software: mission-based wake flows, sleep planning, privacy, and the small details that make a daily-use app feel reliable.

Badges

Gemologist
Gemologist
Tastemaker
Tastemaker
Gone streaking
Gone streaking
Gone streaking 5
Gone streaking 5

Maker History

Forums

ShipGuard v4 roadmap: what should AI agents prove before you trust them?

I m building ShipGuard as an open-source, local-first assurance layer for using Codex on real iOS work.

The current public release is now green on main with release-candidate readiness proof: install, upgrade, uninstall, release-proof consumption, schema docs, plugin refresh proof, package proof, and blocked stable-release claims. In plain English: ShipGuard is getting closer to being a product, not just a bundle of useful scripts.

The v4 direction is narrower than it might look:

inspect -> prepare -> verify

What should Codex prove before it edits production iOS code?

I am building ShipGuard around one rule: agent speed is great, but risky iOS work needs a proof lane.

For me the line changes by surface:

- build/run for compile and obvious integration

- logs/debugger for runtime behavior

ShipGuard - Make Codex prove the diff before risky edits

ShipGuard is an open-source, local-first workflow kit for AI-assisted iOS maintenance. It makes Codex start with a scoped task contract and finish with diff, evidence, and claim verification. The goal is simple: let agents move fast around build, simulator, StoreKit, widgets, notifications, performance, and release work without losing reviewability.
View more