# The Codebreaker AI Build Lab — Editable Lesson Copy

## The operating code

1. **Character:** say what is true. A polished preview is not a published site; a click is not a purchase; a form success screen is not delivered email.
2. **Discipline:** work from one current brief and a visible task board. Save decisions and version numbers.
3. **Knowledge:** verify names, roles, numbers, links, rights, laws, and product capabilities against primary sources or the owner.
4. **Execution:** make the next smallest useful change, test it, and move the project forward.
5. **Accountability:** record who owns every missing item and what evidence closes it.
6. **Community:** ask a teammate to review the experience as a customer, member, or donor, and accept corrections.

The AI assistant is a collaborator. The operator remains responsible for authorization, factual accuracy, customer promises, and launch decisions. A useful prompt is a specification plus evidence and a definition of done, not a magic phrase. “Genius mode” can signal high ambition; it does not replace files, access, verification, or judgment.

### The four status words

| Status | Meaning | Evidence required |
|---|---|---|
| Draft | Copy or code exists, not yet deployed | File or revision link |
| Preview | Interactive test is available in a private or staging environment | Preview URL and tested functions |
| Published | Production deployment completed | Production URL and deployment result |
| Verified live | Real user path tested in production | Timestamped test, delivery/transaction evidence where applicable |

Never collapse these statuses into “done.” A public page can be live while its checkout, email delivery, booking, or automation remains pending.

---

## MODULE 1 — Translate a vision into a buildable brief

**Lesson 1.1 — Start with the person and the action.** State who the page serves, what they must understand in 30 seconds, and one primary action. For a nonprofit, this might be “understand the mission, see a project, donate through the approved processor.” For a consulting site: “understand an offer, book a discovery call, and receive a clear confirmation.”

**Lesson 1.2 — Separate facts, proposals, and dependencies.** Mark each claim as verified, owner-supplied but unverified, proposed, or unavailable. A Promise Pointe organizational chart labeled “proposed” does not prove that a county, contractor, or funder is formally committed. A price from the owner can be published when authorized; a payment flow is functional only after a successful end-to-end test.

**Lesson 1.3 — Build a scope ledger.** List pages/sections, assets, CTAs, data collection, integrations, owner, and release state. Choose a first release that creates value without pretending unfinished products are ready. Record exclusions explicitly in the internal ledger, not as distracting public copy.

**Field assignment 1.** Choose one real offer. Deliver a one-page brief with audience, action, five verified facts, two unknowns, content inventory, and a first-release boundary.

**Decision rule.** If a missing fact changes a public claim or payment behavior, mark that element pending. Continue independent design and copy work.

---

## MODULE 2 — Prompt like a project lead

**Lesson 2.1 — Use the CODE prompt.**

- **C — Context:** business, audience, current site, existing work, exact files and URLs.
- **O — Outcome:** observable deliverables and desired user actions.
- **D — Details:** constraints, source hierarchy, design, access, preservation, and required integrations.
- **E — Evidence:** acceptance tests, what may be published, and how results will be reported.

**Lesson 2.2 — Ask for execution in stages.** A strong instruction says: inspect first; write a change map; implement; run relevant checks; publish if authorized; verify; report what remains. It tells the assistant to preserve existing work and resolve routine design choices. The prompt must still leave room to disclose real blockers.

**Lesson 2.3 — Revise the failed assumption, not just the wording.** When output is wrong, identify the variable: wrong source photo, inaccessible browser, old résumé, ambiguous link, missing API permission, stale build, or untested form. Supply new evidence or choose an authorized route. Repeating “try harder” without changing inputs produces the same uncertainty.

**Field assignment 2.** Write one CODE prompt for a landing page and a second prompt that corrects a specific observed defect. Log what changed in the input and what changed in the output.

### Master execution prompt

> You are my product lead, editor, designer, developer, and QA partner for [PROJECT]. The primary user is [AUDIENCE] and their main action is [ACTION]. Inspect the existing site and attached files before editing. Treat [SOURCE] as authoritative for facts; flag conflicts. Preserve [EXISTING CONTENT]. Build [SCOPE] in [PLATFORM], matching [DESIGN SYSTEM]. Use only approved assets and links. Do not invent results, titles, permissions, testimonials, or functional integrations. Make routine design decisions. Deliver a reviewable draft, then implement and publish the authorized changes. Test navigation, mobile layout, accessibility, forms, delivery, and payments as applicable. Report each feature as draft, preview, published, or verified live, with its evidence and any owner-supplied dependency.

### Correction prompt

> The observed behavior is [EXACT REPRODUCTION] on [URL/DEVICE/TIME]. Expected behavior is [EXPECTED]. Preserve [WORKING PARTS]. Inspect the specific control, trace the failure, make the smallest sound fix, and test the affected path plus one nearby regression path. Show the test result. Do not describe it as fixed until the result supports that conclusion.

---

## MODULE 3 — Research, permissions, and content integrity

**Lesson 3.1 — Build a source register.** Record each claim, URL/file, date, authority, permission, and publication status. Company websites, official documents, current owner files, and the production site are stronger than search snippets. A public image result can identify a person, but it does not automatically grant reuse rights.

**Lesson 3.2 — Handle names, links, and likenesses.** Match the exact organization and domain. In our advisory-team work, Jason Tartt, Sr.'s T&T Organics site was `ttorganics.com`; `tntorganics.com` was a different business. An image editor once selected the wrong recent person as a reference. That output was discarded. For a real headshot, use the correct source image, preserve identity, inspect the result, and obtain subject/owner approval appropriate to the use.

**Lesson 3.3 — Protect private and regulated information.** Never paste passwords, secret tokens, private client health information, bank details, or full donor lists into public course material. Use delegated access and minimum permissions. An IRS letter may prove historical tax recognition while also stating a private-foundation classification and exposing an old address; label the date and classification, and redact only appropriate personal address details in a clearly marked copy.

**Field assignment 3.** Audit ten claims or assets. Mark verified, proposed, permission pending, or remove. Correct one misleading CTA destination.

### The evidence ladder

1. Owner or official source says the fact.
2. The exact approved file, image, or link is in hand.
3. The feature exists in a preview.
4. The production page displays it.
5. A real path completes, including downstream delivery or payment confirmation.

Choose the level required by the public claim. Do not use level 3 evidence for a level 5 claim.

---

## MODULE 4 — The focused two-hour website sprint

**Lesson 4.1 — Timebox the first useful release.** This sprint is suitable for a small brochure site or landing page when brand assets and copy facts are ready. Complex memberships, checkout, identity verification, and legal review need their own plan.

| Minute | Activity | Exit evidence |
|---|---|---|
| 0-15 | Brief, audience, action, facts, release boundary | One-page brief |
| 15-30 | Page map and rough mobile-first copy | Section order and CTA labels |
| 30-75 | Build the primary page and reusable visual system | Preview with complete content |
| 75-95 | Connect real links and supplied assets | Link inventory |
| 95-110 | Phone, keyboard, and content QA | Defect log and fixes |
| 110-120 | Publish if authorized; verify; hand off | URL and truthful status report |

**Lesson 4.2 — Keep the design purposeful.** Use one clear H1, readable type, contrast, generous spacing, one primary CTA, descriptive links, appropriately sized images, labels on forms, visible focus states, and a usable 375-pixel layout. Skip decorative complexity that delays the user action.

**Lesson 4.3 — Keep the handoff small.** Record where to edit the hero, services, testimonials, links, policies, and images. Record the current version. A site no one can maintain is an unfinished product.

**Field assignment 4.** Run the sprint with a partner. Deliver a small site preview and a ten-line QA log. A 120-minute stop is not permission to publish untested claims or purchases.

### Site build prompt

> Build the first useful release from this approved brief [BRIEF]. Use the existing platform and visual language. Provide mobile-first sections in this order [ORDER], with one primary CTA [ACTION]. Keep copy tied to [SOURCES]. Implement real approved links; label unfinished commerce or automation honestly. Preserve existing content. Test at phone and desktop widths, keyboard navigation, forms and external links. Return the preview or production URL and a change log with actual checks.

---

## MODULE 5 — Integrations that truly work

**Lesson 5.1 — Forms and email.** A form needs labeled fields, validation, accessible errors, a submission route, spam control, data handling, and a monitored destination. A success screen is not proof of delivery. Test a real submission, verify the destination inbox and timestamp, and avoid sending sensitive data to a general mailbox without a suitable process. For digital signatures, test typing, saving, submission, and the stored record on a phone.

**Lesson 5.2 — Commerce and scheduling.** A Square link may lead to checkout, but it does not prove price mapping, completed charge, refund terms, tax/shipping configuration, product fulfillment, membership entitlement, or recurring billing. A scheduling link is not an iPhone calendar connection until availability, time zone, booking confirmation, calendar sync, and notifications are tested. If monthly billing is manual, say so.

**Lesson 5.3 — Accounts and permissions.** Use supported connectors, delegated access, or a user-controlled login window. Do not request passwords in chat. When a browser reports an unsafe credential state, stop that route. Try a fresh authorized session or a supported app connection; carry on with source files and reviewable assets. Never “hack” past authentication or bypass a safety block.

**Field assignment 5.** Trace one inquiry from button to form to confirmation to inbox. Trace one product from listed price to approved payment URL. Record each tested step and its limits.

### Integration test prompt

> Map [FEATURE] as a chain of user action, browser response, provider handoff, operator notification, and saved record. Inspect current configuration first. Run a safe test using [TEST DATA]. Report every observed result separately. If a step cannot be tested, label it unverified and specify the exact access or credential needed. Do not create a fake success state.

---

## MODULE 6 — Debugging without giving up

**Lesson 6.1 — Reproduce before changing.** Capture URL, environment, device, time, expected result, actual result, and any error. Test the smallest path. Preserve a working version before editing. Ask what changed since the last successful test.

**Lesson 6.2 — Change the route when evidence changes.** If an upload fails, check whether the file exists, its type/size, permissions, and whether a new upload is available. If a plugin is unavailable or declined, use an authorized alternative; do not keep invoking the declined path. If the repository proxy fails, prepare the work locally and report the publication boundary. If the site is cached, confirm the deployed version before blaming the code.

**Lesson 6.3 — Close with a regression test.** Verify the fix and adjacent behavior. A no-fee PDF that displays fields but does not accept input is still broken. A form that allows typing but cannot submit is still broken. A donation button that opens a provider page should be verified against the approved campaign, not merely checked for an HTTP response.

**Field assignment 6.** Diagnose one intentionally broken link or form. Deliver a reproduction, root-cause hypothesis, one change, retest, and rollback note.

### Recovery ladder

1. **Observe:** reproduce the exact failure.
2. **Inspect:** check files, settings, current version, logs, and permissions.
3. **Isolate:** reduce to one page, control, account, or device.
4. **Change one variable:** input, route, integration, file, or configuration.
5. **Retest:** affected path plus nearby regression.
6. **Escalate:** ask for the missing owner action with a concrete result ready to approve.

Persistence means testing new hypotheses, not bypassing access controls or repeating an unchanged command.

---

## MODULE 7 — Launch, handoff, and improvement

**Lesson 7.1 — Run three views of QA.** Recruiter/customer scan: do the headline and CTA make sense in 30 seconds? Operator journey: does the submission reach the right person? Technical review: mobile, keyboard, speed, metadata, 404, links, images, and policy text. Report actual checks and limitations.

**Lesson 7.2 — Publish deliberately.** Confirm title, version, audience, domain, links, and production deployment result. Preserve the existing audience unless the owner explicitly changes it. If a publication tool reports pending, wait for a terminal result. An edited local file is not a live page.

**Lesson 7.3 — Build a learning loop.** After launch, measure inquiries, qualified leads, checkout starts and completed orders separately. Review user questions and defects weekly. Improve the weakest path, document the experiment, and keep a rollback route.

**Field assignment 7.** Deliver a launch report with a public URL (if deployed), exact tested paths, unresolved items, owner of each, and the next review date.

### Launch report template

| Feature | State | Evidence | Next action | Owner |
|---|---|---|---|---|
| Homepage | Published / verified live | URL, date, phone view | Fix observed defect | Named person |
| Inquiry | Preview / verified live | Test ID and inbox receipt | Configure delivery | Named person |
| Payment | Link configured / verified sale | Approved mapping; test receipt | Enable transaction | Named person |
| Automation | Planned / live | Schedule and observed run | Supply access | Named person |

---