A complete forensic record of recurring failure patterns, root causes, and the structural fixes deployed to prevent recurrence.
Compiled April 13, 2026 | Bright Side Plumbing / Nexus AI.ct-section, .oxy-inner-content, main, .entry-content, #content) but should target the specific Oxygen Builder shortcode element #shortcode-15-90.Robert must manually edit Snippet #55 line ~259 in wp-admin to fix the selector targeting. Alternatively, Kalen rebuilds the CRO page natively in Oxygen Builder (discussed in team meeting). Detailed fix instructions are in Section 5 below.
API returns HTTP 200 (success status code). I report the task as "done" without reading back the data to verify it actually changed. The status code is treated as proof of success. It is not.
ALWAYS verify OUTPUT not status code. After any write operation: read back what was written. Compare to what was intended. If they don't match, the operation failed regardless of what the status code says. Three checks: (1) what did it produce? (2) is the output correct? (3) did it change real data?
Credentials exist in memory files (reference-api-keys.md, reference-bricks-staging-creds.md) but I either ask Robert for them or fail to locate them, wasting time and destroying trust.
Mandatory lookup order: (1) reference-api-keys.md (2) reference-bricks-staging-creds.md (3) history.jsonl search (4) Zeus RAG search. Only after all four return nothing should the question reach Robert. NEVER ask Robert for credentials.
A rebuild or update script destroys an existing document design that Robert approved. The new version may have correct data but loses the layout, styling, or structure Robert signed off on.
ALWAYS read the existing file first. Preserve the design/structure. Only modify content within the existing layout. If unsure, show Robert a diff before writing. The pre-write gate (pre_write_gate.py) enforces gated_write() for protected files.
Create, delete, or modify production resources that Robert never asked for. The intent is usually to "help" or "fix faster" but the result is unauthorized changes to live systems.
If Robert didn't explicitly ask for it, don't do it. For anything touching production: state what you intend to do, which site, and wait for approval. The Pre-Action Gate (Section 4) codifies this as a mandatory checkpoint.
Report systems as "working," numbers as "real," or tasks as "complete" without actually checking the output. Process running does not equal output correct.
Three-part verification before ANY claim: (1) What did it produce? Show the actual output. (2) Is the output correct? Compare to ground truth. (3) Did it change real data? Not test data, not placeholders. If all three can't be shown, say "running but unverified."
After 5-7 tasks in a single session, quality degrades. Details are forgotten. Names get mixed up. Verification steps are skipped. Work becomes sloppy. Robert catches errors that shouldn't exist.
Every 5-7 tasks: (1) Re-read the master checklist. (2) Audit the last 5 things built. (3) Verify they still work. (4) Then continue. This periodic self-audit catches decay before Robert does. Quality must be best in class at task 20 just as it was at task 1.
Instructions meant for one WordPress site are applied to a different site. With multiple environments (production callbrightside.com, Bricks staging, etc.), one wrong target means production outage.
add_filter code to the main site's wp-config.php instead of the Bricks staging wp-config.php. callbrightside.com returned HTTP 500. The production site went down.ALWAYS specify and verify: exact site URL, exact file path, exact DB_NAME. Before any wp-config or database change, confirm with Robert: "I am about to edit [file] on [site]. Is this correct?" Never assume which site Robert is working in.
After 2 failed attempts at the same fix: STOP. Tell Robert exactly what was tried, exactly what failed, and what the remaining options are. Let Robert decide the next move. Do NOT keep trying random approaches. Do NOT create new things to work around the original problem.
Before ANY production change, answer four questions: What am I changing? Which site is this for? Did Robert ask for this? What is my rollback plan? If any answer is unclear, stop and ask Robert.
After ANY change, verify the OUTPUT not the status code. Read back what was written. Compare to what was intended. Three checks: produced? correct? changed real data? All three required.
Log every action and learning so the next session has full context. nexus_session_logger.py --log after tasks, --learn after discoveries, --briefing at session start.
Planner (Claude + Robert) decides. Executor (scripts) acts. Verifier (nexus_output_verifier.py) confirms. No single agent plans AND executes AND verifies. Separation of concerns.
Check memory files before asking Robert anything. Order: reference-api-keys.md, system-state.md, open-issues.md, Zeus RAG search, then session history. The data is almost always already there.
| Gate | #1 API | #2 Creds | #3 Overwrite | #4 Scope | #5 Claims | #6 Decay | #7 Site |
|---|---|---|---|---|---|---|---|
| Pre-Action Gate | - | - | - | YES | - | - | YES |
| Post-Action Verify | YES | - | - | - | YES | - | - |
| Session Logger | - | YES | - | - | - | YES | - |
| Triad (Verifier) | YES | - | YES | - | YES | - | - |
| Memory-First | - | YES | - | - | - | - | - |
Every failure in every session traces to rushing. Building before reading. Fixing before understanding. Reporting before verifying. Before every action -- edit, query, build, deploy, report -- pause and ask:
If the answer to any is no, STOP and do that first.
Go to callbrightside.com/wp-admin → Code Snippets (left sidebar) → Find and open Snippet #55 (CRO Contact Form v4.0).
Use Ctrl+G (Go to Line) or Ctrl+F to search for ct-section. You should find the JS selector line.
Find the section where the form is appended to the container. Replace it to clear old content first:
Click Save Changes and Activate (or just Save if already active). The Code Snippets plugin will save directly to the database.
Open an incognito/private window and navigate to callbrightside.com/contact-us/. Verify the form renders inside the booking section, not after the footer. Test form submission on both desktop and mobile.
As discussed in the team meeting, Kalen can rebuild the contact/booking page natively in Oxygen Builder. This would eliminate the dependency on Code Snippets JS repositioning entirely. The form fields, validation, and routing logic would need to be recreated in Oxygen's native form builder or embedded as an Oxygen Code Block. This is the cleaner long-term solution but requires more time.