Launch Control Operations Manual

Oct 2, 2026 · Tristan Rogers

Purpose and scope

This manual is how TRMG builds, ships and runs Launch Control, and how a dealer's month moves through it. It is the reference for anyone working on the product or using it, and it replaces memory: if a step is not written here or in the repo, it is not yet a process.

Launch Control turns one offer brief into compliant creative for every channel a dealer runs: Meta, Google Display, TikTok, website banners, live HTML email, print and out of home. Every frame is checked against OEM, dealer, channel and agency rules before it can go out for approval. The example client throughout is Beck & Beck Buick GMC; all launch content in the system today is example data.

Who it serves

What this manual covers: the system and its environments, who does what, the change process from request to deploy, quality gates, releases and rollbacks, the database, the monthly launch cycle, brand kits, assets, access, integrations, security, accounts and costs, working with Claude, current status, troubleshooting and a glossary.

Where the source of truth lives: the GitHub repository trmg1/launch-control. This manual summarizes it; when they disagree, the repo wins and this manual gets corrected.

System overview

One Cloudflare Worker serves the app, the login page and the API from launchcontrol.trmg.cloud; GitHub holds everything it is built from, and only builds from main reach production data.

[Embedded content in the artifact: Launch Control architecture · from repository to live data. A drawn diagram in the source; it does not translate to markdown.]

A push goes to GitHub, where Actions runs the checks, and to Cloudflare, which builds main as production and every other branch as a preview. The lane switch inside the Worker decides which database and storage a build may use.

Environments and lanes

There are four places Launch Control runs, and only one of them is real. Production is the only environment that may touch real launches, people or approvals.

How a build knows its lane. Every build writes build.json with the branch and commit it came from. The Worker reads it: a build from main is production; anything else, including an unknown branch, is a preview. A preview swaps in the preview database and storage, and shows an orange banner naming its branch. /api/health on any environment reports its lane, branch and commit, so anyone can check which version they are looking at.

Rules that follow from this

• Never point a preview at the production database, even temporarily.
• Never share a preview link outside the team; it is public, though it holds only test data.
• The demo artifact never signs in and never shares data. Use it to show the product, not to run a launch.

Roles and responsibilities

Tristan owns the product and approves every change that reaches production; Claude builds, tests and documents. Inside the app, five roles decide what each signed-in person can do.

Building the product

Using the product (roles in the app)

The server enforces these on every request. Hiding a button is only a convenience; it is never the protection.

The change process

Every change, however small, travels the same path: branch, pull request, checks, preview, merge, deploy, verify. Nothing reaches launchcontrol.trmg.cloud any other way.

Step by step

1. Request. Tristan names the goal in a sentence or two: who it is for and what done looks like. Screenshots and client examples help. Or he says "next on the roadmap".
2. Plan. For anything larger than a small fix, Claude replies with what will be built and anything needed from Tristan (an account, a decision, a key).
3. Branch. Claude starts a branch from the latest main.
4. Build and test. Claude writes the change, its tests and its docs, then runs the full checks locally plus a real browser run for anything on screen.
5. Push and link. Claude pushes the branch and sends one prefilled pull request link.
6. Open the pull request. Tristan clicks the link, then Create pull request. The title and description are already written.
7. Checks. GitHub runs the checks (about two minutes). Red means Claude fixes it on the same branch; the pull request updates itself.
8. Preview. Cloudflare builds the branch and adds a preview link to the pull request. Tristan opens it and tries the change.
9. Merge. Tristan clicks Merge pull request, Confirm merge, then Delete branch.
10. Deploy and verify. Cloudflare deploys main in about two minutes. Tristan says "merged"; Claude confirms /api/health shows production at the new commit, deletes any leftover branch, and updates the roadmap.

Branch names

Lowercase, words joined by hyphens, one purpose per branch.

Every pull request answers four things (the template asks for them): what changes, why, how to check it in the preview, and whether it changes the database.

Definition of done

• Checks are green on the pull request
• Tristan has looked at it in the preview
• Any database change is a new numbered migration, applied to the preview database first
• Docs are updated in the same pull request (README, WORKFLOW, ROADMAP, or this manual)
• After merge, /api/health shows production at the new commit

Pace. One branch at a time while the team learns the routine. Later, two or three can run side by side, each with its own preview.

Quality gates

A change must pass three automatic checks on GitHub and a human look at the preview before it can merge. A red check means stop.

House rules every change follows

• No spaced dashes as separators anywhere: in creative, in the app, in docs, in commit messages. Use a colon, a semicolon, a middle dot, or let weight and size carry the break. The kit validator enforces this on kit files.
• Every fix to a misfiring rule starts with a new fixture that reproduces it, so it stays fixed.
• Tests ship in the same pull request as the code they cover.
• Secrets never enter the repository or a chat.

Releases, verification and rollback

Every merge to main is a release, live in about two minutes; if it goes wrong, roll back first and fix second.

How a release happens

1. A pull request merges into main.
2. Cloudflare's Git integration for the Worker launch-control runs the build command python3 prototype/build.py, then npx wrangler deploy using wrangler.jsonc.
3. The new version takes all traffic at launchcontrol.trmg.cloud. Cloudflare keeps every earlier version.

How to verify a release

Open https://launchcontrol.trmg.cloud/api/health. It must show "lane":"production", "branch":"main", and a commit matching the merge. Then open the app and check the thing that changed. Claude does both after every "merged".

How to roll back (one minute)

1. Open the Cloudflare dashboard, then Workers & Pages, then launch-control.
2. Open Deployments.
3. Find the last version that worked, open its menu, choose Rollback, and confirm.
4. Check /api/health: the commit now shows the older version.
5. Tell Claude what went wrong. The fix comes on a fix/ branch through the normal process; the next merge replaces the rollback.

What a rollback does not undo: database migrations, secrets and data written since the release. That is why migrations only ever add things (see Database operations).

Hotfixes. An urgent fix still uses a branch and a pull request, just a small one with only the fix. Skipping the process is how a fix breaks something else.

Release record. GitHub keeps the history: every merged pull request is a numbered release note (what, why, how it was checked). Pull request #1, the branch workflow, merged on Oct 2, 2026.

Database operations

The database is Cloudflare D1, two of them: launch-control for production and launch-control-preview for branch previews. Neither is connected yet; that is the next roadmap item.

What it holds

How the structure changes: migrations

The structure lives in numbered files in migrations/. 0001_initial.sql is the first. Each runs once per database, in order, and the database records which have run.

1. A change is a new file, for example 0002_add_frame_adjustments.sql. Never edit one that has been applied.
2. Add first, remove later. A new table or column ships with the code that uses it; anything old is removed in a later release, once nothing uses it. Rolling back code never undoes a migration, so this keeps rollbacks safe.
3. Order: Claude applies the migration to the preview database while the pull request is open (npx wrangler d1 migrations apply launch-control-preview --remote), then to production right before Tristan merges (npx wrangler d1 migrations apply launch-control --remote).
4. The pull request template's Database box says whether a migration is included.

How saves stay safe with several people

Every save of a brief carries the revision it started from. If a teammate saved first, the save is refused, the app loads their version and says so. Approval state only changes through dedicated actions (send, approve, request changes, next version), so editing a brief can never approve anything.

Backups and recovery. D1's Time Travel can restore a database to an earlier point in time. Confirm the retention window for the account's plan when the database is connected, and record it here.

Monthly launch operations

Each month runs on one loop: new OEM incentives arrive, each dealer's launches are briefed, checked, approved by three people, then delivered and reported. The Launches screen shows the month as a timeline of programs with every launch beneath them.

The cycle

1. Incentives land. When GM publishes a program (for example GMC Truck Month, Oct 1 to Oct 31), marketing updates brand-kits/gm-offers/programs.json through a pull request: name, OEM, start, end, and the chip wording. This is the one change made every month.
2. Launches are created. Marketing or dealer ops starts a launch per offer: program, vehicle, offer type (price stack, APR or brand USP), copy, end date, disclaimer and channels. Duplicating last month's launch is the fast path.
3. Compliance runs live. As the brief is typed, every frame is checked against the dealer kit, the GM offer rules, the channel specs and TRMG delivery rules. Blocking issues must be fixed before sending; warnings need a person's judgement.
4. Send for approval. Sending freezes the version (v1, v2, ...) with the exact brief, kit versions and check results. Three approvers are asked: the dealer general manager, the GM co-op reviewer and the TRMG creative lead.
5. Review and feedback. Each approver opens the frames, pins comments to exact spots, and either approves their slot or requests changes.
6. Iterate. Changes requested, or any edit after sending, starts the next version. Version compare shows the previous version beside the current one. Comments are resolved as they are addressed.
7. Approved. When all three slots approve, the launch is approved and the delivery actions unlock.
8. Deliver. Approved creative goes to its channels: PNG frames for Meta, Google and print, live HTML for email (a Mailchimp draft once connected), website banners for the dealer CMS. A delivery event tells connected systems.
9. Report. Links carry the launch slug as their UTM campaign, so reporting in AgencyAnalytics groups results by launch.
10. Close the month. Expired offers block automatically on their end date. Rights on vehicle photos that end before an offer are flagged in the Library.

Approval rules

Suggested rhythm, to confirm with dealers: incentives entered within a day of release, first versions sent within two days, approvals turned around within one business day.

Brand kit management

Brand kits are the rules Launch Control checks against, kept as files in GitHub next to the guidelines they came from. Six kits hold 27 rules today.

How a rule is written. A rule names a check from the check library (prototype/src/checks.js), gives it parameters and its own pass and fail wording, and has a severity: block, warn or off. Locked rules are guaranteed by the templates and can't be switched off. Brand managers change wording, limits and severity; a new kind of check is an engineering change.

How a kit changes

1. Edit kit.json and bump its version, or change a severity on the Brand kits screen, which shows the change as a pull request preview.
2. Open a pull request. The validator fails it if anything is malformed or any example launch changes outcome.
3. Review the preview to see exactly what the new rules block.
4. Merge. Every version sent for approval afterwards records the new kit version.

Cadence

Asset management

Every image, logo and font the templates use is registered in assets/manifest.json, with its rights and where it is used; git keeps the record, and the files themselves are meant to live on the CDN. Eight assets are registered today.

What each record carries: a stable id, a human name, kind (vehicle, backdrop, logo, font), the kit it belongs to, tags, and rights (source and end date). The build adds the file's size, dimensions, SHA-256 content hash, CDN key and URL.

Content-hashed names. A file's CDN key includes the first 10 characters of its content hash, for example kits/beck-beck/vehicles/veh-sierra-1500-at4.688e661541.png. The same bytes always get the same key, so duplicates are caught and files can be cached forever. A changed image gets a new URL, so nothing already published changes underneath anyone.

Rights are a compliance check. Rule GM-06 compares a vehicle photo's license end date with the offer's end date and flags the launch when the license ends first. The example Yukon XL photo is set to end Oct 15, 2026, so the Yukon launch shows that warning.

Adding or replacing an asset

1. Upload it on the Library screen (today it is hashed and measured in the browser; once storage is connected it uploads to R2), or send it to Claude.
2. Record its rights: where it came from and when the license ends. An asset with no rights record is flagged.
3. Claude adds it to the manifest in a pull request; the build computes its key.
4. After merge, node scripts/sync-assets.mjs uploads it to the bucket. Re-running is safe.

Open item: the Futura font. It came with the client's files under a desktop license. Confirm the license covers web and email embedding, or switch to a licensed web font, before it is served from a public CDN.

Planned CDN: an R2 bucket with cdn.trmg.cloud as its custom domain (roadmap item 5). Until then, email exports carry {{CDN}} placeholders and the app embeds images directly.

Access management

Once the database is connected, every page except /login needs a signed-in person (switched on Oct 2, 2026), and admins manage who that is on the Team screen.

Organizations. Everyone belongs to one organization. TRMG sees every client. Each client, in automotive or any other industry, sees only its own launches and people; anything else answers as if it didn't exist. TRMG admins add clients on the Team screen. A Client admin at each dealer group adds, changes and disables their own people, and can't touch anyone else. This ships with feature/client-workspaces.

Dealers and groups. Below a client sit dealer groups and dealers (sub-clients outside automotive). Hi Tech Motorcars, for example, has the Hi Tech Luxury Imports group (Aston Martin Austin, Bentley Austin, Lotus of Austin, Rolls-Royce Motor Cars Austin, Hi Tech Luxury Collection) and Georgetown INFINITI on its own. Platinum Land has Highland Branch, The Estates at Highland Branch and Platinum Land. A launch is for the whole client, a group, or one dealer. Each person's Access on the Team screen is every dealer, or chosen groups and dealers, and a group covers every dealer in it, including ones added later. Someone with Georgetown INFINITI sees only that store's launches; someone with the Luxury Imports group sees its five stores and its group campaigns; someone with every dealer sees everything at that client. Changes apply on the person's next click.

Client sign-in, planned. Dealer staff will use Sign in with Microsoft with their Outlook work login, and TRMG will use Sign in with Google. Either way a session lasts 30 days and every visit restarts it. Some dealer groups' IT must approve a new app once before their staff can use it.

Ways to sign in

Sessions last 30 days on a device. Signing out ends that session; disabling a person ends all of theirs at once.

What each role can do

Onboarding a person

1. Team screen, then Add a person: email, name, role, and for approvers their slot (general manager, co-op reviewer or creative lead).
2. Click Add and get link, then Copy link.
3. Send it to them directly. They open it and click Sign in to Launch Control.

Offboarding: on the Team screen, click Disable next to the person. Their sessions end immediately and their links stop working. Their comments and history stay.

Guard rails: there must always be at least one active admin; the system refuses to demote or disable the last one. Review the Team list monthly and disable anyone who has left.

Integrations and webhooks

Launch Control tells other systems what happened through signed webhooks, and pushes approved creative to the platforms each channel runs on. Webhooks go live with the database; platform connectors arrive one roadmap item at a time.

Events sent

How delivery works. Each event is a JSON POST with an LC-Signature header: an HMAC SHA-256 of the timestamp and body, keyed with that endpoint's secret. Receivers verify it and reject anything older than five minutes; the Integrations screen has copy-ready code. The first attempt runs immediately; failures retry on the minute cron after 1, 2, 4, 8, 16, 32 and 64 minutes, then are marked failed. A receiver answering 410 Gone pauses its endpoint.

Managing endpoints (admins): Integrations screen, then Add an endpoint: a name, an https:// URL, and the events it should receive. Copy the signing secret when it is shown; it is never shown again. Pause, test or remove endpoints from the same screen, and read every event's delivery status in the event log.

Inbound webhooks. Other systems post to /api/v1/inbound/<source>, signed the same way or with a token in the URL. They become inbound.<source> events that endpoints can subscribe to. Planned uses: Stripo saving an edited email, an OEM incentive feed, monday.com status changes.

Connections

Security and data handling

The rule of thumb: secrets live only in Cloudflare, permissions are checked on the server, and test data never mixes with real data.

Built into the system

People rules

• Keys, tokens and passwords are never pasted into chat, email or the repository. They go straight into the Worker's Variables and Secrets in Cloudflare.
• The GitHub repository stays private. It holds client brand files and a licensed font.
• Preview links stay inside the team.
• Disable people the day they leave.
• Real customer data (names, emails) is not in the system and should not be added until it is needed and reviewed.

Known gaps, tracked on the roadmap

• Compliance results on submit come from the browser; the server will re-run the checks itself (roadmap item 3).
• Sign-in routes have per-address limits but no wider rate limiting yet.
• main can't be protected by GitHub rules on the free plan; for now it is a habit that only Tristan merges.

Accounts, domains, credentials and costs

Everything runs on accounts TRMG owns, on free tiers today.

Accounts

Domains

Credentials and where they live

Costs to expect

• Today: none beyond existing subscriptions.
• Optional: GitHub Pro (a few dollars a month) to make GitHub enforce pull requests and green checks on main.
• Later: Cloudflare's paid Workers plan only if traffic or storage outgrows the free tier; Resend's paid tier only above its free sending limit.

Working with Claude

Claude is the builder on this project: it writes, tests and documents every change, and Tristan decides and approves. Conversations end and get compressed, so the project's memory lives in files, not in any one chat.

Asking for work

• Say the goal, who it is for, and what done looks like. "Dealers need to duplicate last month's launches in one click" beats "add a button".
• Send screenshots of anything confusing or broken, and client examples of what good looks like.
• "Next on the roadmap" is always a valid request.
• Expect a short plan back for anything bigger than a small fix, naming anything Claude needs from you.

What Claude always does

• Works on a branch, never on main; Tristan merges.
• Runs every check, and a real browser test for anything on screen, before sending a link.
• Says plainly what was verified and what wasn't.
• Updates the docs in the same pull request.
• Asks before anything hard to undo or outward facing: deleting, sending, sharing, spending.

What Claude never does

• Asks for passwords or keys in chat.
• Merges its own pull requests or changes production data directly.
• Guesses at facts it can't check; it marks them as open questions instead.

Where context lives

Sessions. A fresh session per roadmap item keeps conversations focused. Automatic compression can be turned off in Claude Code with /config; if it is off and a conversation fills, start a new session and point Claude at this manual and the roadmap.

Approvals that happen on this Mac. Cloudflare authorization opens a browser page on the Mac where Claude's commands run, with a 2-minute window. Before Claude starts one, it says so; be at this Mac to click Allow.

Current status and roadmap

The product, sign-in, roles, shared data and webhooks are built and tested; they switch on when the databases are connected, which is waiting on one Cloudflare authorization click at this Mac.

Shipped

Next, in order

Later: incentive programs from an OEM feed through the inbound webhook; a GMC brand kit when guidelines arrive; Stripo editing; Meta, Google Ads and Duda delivery.

Open questions for Tristan

• Whose Mailchimp account receives drafts: TRMG's, or each dealer's?
• Does the Futura license cover web and email embedding?
• Who are the first five people to invite, and in which roles?
• Is GitHub Pro worth adding now so GitHub enforces the merge rules?

Troubleshooting

Most problems have a known cause and a one-step fix; when in doubt, check /api/health first, then send Claude a screenshot.

Glossary