Continuous Integration (CI) - the Unseen Guardian

I wrote a post earlier about how application changes go live in SuiteResources.com, but I want to go deeper.

Over the past week or so, Claude and I have been locking down Application Manager's Continuous Integration routines to ensure every application it creates or updates—including itself—is "whole": properly provisioned and release-managed. Like every application it builds, Application Manager has evolved through many versions. It started as two Kanban boards to track applications (we called them Ideas) and their features. Then we added amendments—minor tweaks to a feature when I hadn't been clear enough the first time. "Yeah, Claude, you got it 90% right based on what I told you, but can you adjust X?"

That's essentially vibe coding, assisted by Kanban and a few APIs pushing changes to GitHub, which then triggered our deployment service, Forge, to deploy to the web server. Simple.

Shortly after, we added versioning and began using GitHub more fully. That's where Continuous Integration started—but we didn't yet have the rules in place to manage versions properly. We could create versions, push code to them, and perform every action the process required. But there's a big difference between could and should.

Here's what our CI workflow actually checks:

• Code targets the active version. Only one version per application can be active at a time.
• The active version is the correct one. All prior versions must be released before the current one—you can't go backward. All versions after the active one must have a status of planning.
• All features and amendments slated for the active version are built, tested, and complete. This also includes in-code comments and notes per feature or amendment, used to create accurate release notes for every release.
• Every step across every system must succeed before any code reaches production. The deployment pipeline spans Anthropic, GitHub, and Forge—failures anywhere get surfaced. Even after deploying to production, we compare the dev version against prod to confirm they match exactly.

There's more detail inside each of these, but the core idea is simple: CI needs to catch every possible failure and report on the workflow's health. Without a robust CI process, you're flying blind—exposed to risk, confusion, and inefficiency.