The Command Center Engineering spec

Built to fail loud, not silent

The interesting engineering isn't the happy path. It's the four places the system refuses to lie when something goes wrong. Here is each guard, in the real code.

Want how it works instead? The build walkthrough →

Systems

Guard · content/scheduler.jsThe double-post can't happen

The auto-poster fires one approved draft per tick. The risk is a flaky network response causing the same draft to post twice. So the draft is marked posting before the network call returns. Success moves it to posted. Failure rolls it back to approved for an intentional retry. A duplicated or timed-out response can never re-fire it.

approved →
before call posting →
on ok posted ↵
on fail back to approved

// optimistic lock — mark in-flight BEFORE the call
updateDraft(draft.id, { status: 'posting', post_attempted_at: stamp });

const result = await postDraftToFacebook(draft);

if (result.ok) {
  updateDraft(draft.id, { status: 'posted', fb_post_id: result.postId });
} else {
  // roll back so a human can retry on purpose, and log LOUD
  updateDraft(draft.id, { status: 'approved', last_post_error: result.error });
}

Guard · pipeline/audit.jsWrong business, rejected

Google Places can return a different business than the one searched. Stapling a low-confidence match to the audit produces a Frankenstein result: one business's reviews describing another's website. Anything below a 0.7 confidence floor is thrown out before scoring or narrative can trust it.

const PLACES_MATCH_FLOOR = 0.7;
if (places.found && places.matchScore < PLACES_MATCH_FLOOR) {
  places = { found: false, weakMatch: true, /* ...zeroed... */ };
}

Guard · pipeline/audit.jsA partial audit beats a failed one

The site is read in headless Chromium so GTM-injected tags actually run. If rendering crashes, it falls back to a static fetch rather than failing outright. The fallback re-introduces the old false-negative, so it's flagged as renderFailed, but a partial audit still beats nothing.

let fetchResult = await fetchRenderedHtml(url);   // headless
if (!fetchResult.ok) {
  const staticResult = await fetchHtml(url);   // fallback
  if (staticResult.ok) fetchResult = { ...staticResult, renderFailed: true };
}

Guard · pipeline/audit.js"Blocked" and "empty" mean opposite things

A 403 or 429 means bot protection blocked the read. An empty page means the site really is bare. Scoring these the same way would email a prospect a confident zero about a site nobody could see. The blocked case is flagged so scoring treats it as couldn't scan, not as a bare site.

const blocked = !fetchResult.ok && (
  fetchResult.status === 403 || fetchResult.status === 401 ||
  fetchResult.status === 429 || [502,503,520,521,522,530].includes(fetchResult.status)
);
// downstream: inspectionRan === false  =>  emit "couldn't scan", not a zero

The through-line: every guard turns a silent wrong answer into a loud honest one. A dishonest zero, a mismatched business, a false negative, a confident score on a site nobody read, each one is caught and labeled instead of shipped. That's what "built to not break" actually means in the code.

← How it works Work with me →