AI Field Guide - Deeper module

Codex is a local operator, not a magic button.

Codex is powerful because it can work in a folder. That is exactly why beginners need a folder boundary, rules sheet, approval gate, and proof checklist before trusting any change.

Lesson 1

What a local operator is.

A chat tool helps with words. A local operator can help with a project folder. That makes it useful for code, websites, docs, and cleanup work, but it also raises the stakes.

Good beginner use

Explain the folder, identify important files, propose a small change, and show exactly how to check it.

Bad beginner use

Point it at private records, live business systems, money-related code, or a folder you do not understand.

First rule: do not let a tool work wider than your understanding.

Lesson 2

Pick one folder.

The folder is the boundary. Start with one practice project, one website section, one draft folder, or one small tool. Do not mix beginner practice with private operations or live money work.

Good

A copied practice folder, static page, docs folder, or low-risk toy project.

Careful

A real project with customer-facing pages, business records, or unknown scripts.

No

Passwords, private customer files, payment flows, public routing, or production systems.

Check

Know what folder is open before asking for changes.

Lesson 3

Write the rules sheet.

A rules sheet tells the operator how to behave in the folder. Keep it short, boring, and clear. The point is not fancy instructions. The point is staying inside the lane.

# Project Rules

You are working in one folder only.

Before changing files:
- explain what this folder appears to contain
- identify the files that matter for the request
- name anything risky or unclear
- propose the smallest useful change
- wait for approval before editing

When editing:
- touch only the files needed for the request
- keep the style already used in the project
- do not add new services, accounts, packages, or public routes
- do not include secrets, private data, or customer records

After editing:
- summarize what changed
- list the files touched
- explain how to check the result
- mark anything not verified yet

Lesson 4

Make a safe first ask.

Start read-only. Ask Codex to look, explain, and plan before it changes anything. That gives you a map before you hand it a tool.

Look through this project folder and explain it in plain English.

Tell me:
1. what this folder appears to be
2. which files seem most important
3. what looks risky or unclear
4. what you would change for this request:

[describe the request]

Do not edit files yet. Give me the plan first.
Make the smallest safe edit for this request:

[describe the request]

Rules:
- touch only the files needed for this change
- keep the existing style
- do not add accounts, services, packages, public routes, or secrets
- explain what changed
- tell me exactly how to check it
- mark anything not verified yet

Lesson 5

Approvals are not annoying. They are brakes.

Approval gates slow the work down just enough for you to stay responsible. When the tool wants to read wider, edit more files, run a command, or touch something sensitive, that is a moment to think.

Level 1

Read and explain. Lowest risk.

Level 2

Plan a small change. Still no edits.

Level 3

Edit one narrow area. Verify right away.

Level 4

Anything wider needs explicit approval and a rollback plan.

Do not treat approvals as friction. Treat them as the dashboard lights.

Lesson 6

Proof before trust.

A confident summary is not proof. Proof means the operator can show what changed, where it changed, how it was checked, and what still needs human review.

Ask for proof

  • What files did you touch?
  • What changed in each file?
  • What check did you run?
  • What did you not verify yet?
  • What should a human review?

Do not trust yet if...

  • The tool cannot name the files touched.
  • The check was skipped or vague.
  • The change is bigger than the request.
  • The answer hides risk behind confident wording.

Lesson 7

The red zone.

Some work should not be beginner practice. If the task touches private data, public routing, payments, account access, legal claims, customer records, or live business systems, slow down and get the right approval.

Red-zone checklist

  • Private customer or employee records.
  • Payment, checkout, bank, or tax flows.
  • Public hosting, DNS, domains, or live routing.
  • Secrets, tokens, passwords, or account access.
  • Anything you cannot verify after the change.

Next safe move

Keep Codex in one folder, ask for a plan first, approve the smallest useful change, and require proof before trust.

Deeper Field Guide preview. Purchase path is not connected yet.