Example Proof Report — Banner hid the real error

Pattern: bug-fix proof · Stage: dev verification · Date: redacted · Identifiers: all client + product names anonymized; screenshots Gaussian-blurred to preserve layout but remove text.

EXAMPLE-001

Customer projects provisioned into the wrong cloud account; failure banner hid the real error

Reported by client (operations role), [date redacted]: "Account Activation Failed — cloud account service activation timed out after 24 hours. Please contact support. The banner appears about 5 minutes after we create a project — not 24 hours later. The accounts also do not appear to be created under our cloud organization."

Root cause: When an admin created a customer organization, the database column that records which cloud-environment partition the customer belongs to was never filled in. The project-creation code saw the blank value and silently fell through to the wrong code path, provisioning customer accounts into the platform's own internal sandbox instead of the customer's intended cloud organization. Separately, the failure banner was hardcoded with a "24 hours" message, regardless of the real error returned by the cloud provider.

Fix: (1) the customer admin form now always sets the cloud-partition value on submit, (2) the database refuses to store a blank or invalid partition (NOT NULL + CHECK constraint), (3) the project-creation code aborts with a clear error if the partition is ever missing, (4) the failure banner renders the actual cloud-provider error message recorded in the database — so the real cause (an IAM AccessDenied on AssumeRole) is visible immediately instead of being hidden behind a generic 24-hour timeout string.

Screenshot 1 — annotated (after fix): Project detail page with a pre-existing failed project row. The red circle highlights the activation-failed banner, which now displays the actual cloud-provider error message (an IAM permission failure) — not the hardcoded "24 hours" string the client originally saw.

Banner now shows the real cloud-provider error

Blurred · layout preserved

Visual Inspection

What's visible inside the red circle: the activation-failed banner now contains the actual cloud-provider error — an AccessDenied on the AssumeRole operation, including the calling principal and the target role ARN. Before the fix, this same banner showed only the hardcoded message "cloud account service activation timed out after 24 hours" regardless of the real cause. The pixels match the fix: the banner reflects the recorded bootstrap_error from the database, not the old hardcoded string.

Served-asset check: N/A for this fix — it's a data + template-rendering change, not a static-asset change. Verified by the annotated screenshot above. The template source change is committed and the running service rolled forward to the matching image digest.

Screenshot 2 — admin customer list (no regression): After applying the database constraint and the dispatch change, the admin customer list still renders normally. Existing customer rows continue to load.

Blurred · layout preserved

Screenshot 3 — customer creation form: The "New Customer" admin form renders correctly. The form submission now writes the cloud-partition value on every new organization. Full end-to-end form round-trip is deferred to the test-stage proof (this dev environment lacks one piece of background config).

Blurred · layout preserved

FIXED & VERIFIED (dev, light proof)

Infrastructure Verification

Why this matters (the pattern, not the project)

This kind of report is what we ship instead of "we fixed it" emails. The agent assembles the card from the bug ticket, the verbatim client quote, the diff, and a real after-state screenshot — but it refuses to ship the card unless the cross-checks resolve: the served code matches the diff, the database migration matches the schema claim, the rendered banner contains the asserted text. The pattern generalizes well beyond bug fixes — any AI-driven workflow that produces results a human must approve (medical record review, document classification, policy decisions) benefits from a "card that can't be assembled until the result is real."