15. 🚀 SMP DEPLOYMENT PROTOCOL — NEVER BREAK PRODUCTION

SMP1 🔒 PRODUCTION — SACRED
Live on fuel-ops.com. TLs use this every shift. Never touch directly.
Nothing reaches SMP1 without passing SMP2 + SMP3 fully.

SMP2 🔬 DEVELOPMENT — BUILD · BREAK · FIX
Problem found in SMP1 → identify module → pull that module → fix in isolation → confirm fixed.
Like a car engine: pull the broken part, fix it on the bench, put it back.

SMP3 ✅ BUNDLE & DEPLOY — MERGE · PUSH · GO LIVE
Fixed module passes → bundle back into full HTML → push to GitHub → Netlify deploys.
Deploy window: 2:00 AM – 4:00 AM only. Never mid-shift. Never Friday nights.

BRANCH STRATEGY
main → SMP1 (production · fuel-ops.com)
dev → SMP2 staging (modules being fixed)
feature/vXXX → individual builds (Netlify auto-preview URL)

16. 🗂️ MODULE SECTION MARKERS — EVERY MODULE MUST BE FINDABLE

Every module in the codebase must have a clear section marker block at its start.
This makes every module instantly findable — by any developer, by Claude, by anyone.
No module without a marker. No marker without a contract.

REQUIRED FORMAT:
// ████████████████████████████████████████
// MODULE: [NAME] ([prefix]_)
// ❤️ Heart: [load/save functions]
// 🧠 Brain: [calc/validate functions]
// 🦵 Kick: [submit/trigger functions]
// 🐍 Tail: [render functions]
// ⚡ Gamma: [alert/badge functions]
// Storage: he_[module]_[station]_[date]
// Access: L[X] inputs · L[X]+ views
// Feeds: [downstream modules]
// ████████████████████████████████████████ WHY THIS MATTERS:
· TL reports a problem → identify module → search marker → land exactly there
· Fix only that module → nothing else touched → zero collateral damage
· Feeds list shows what breaks downstream if you change something
· New developer reads marker → knows exactly what the module does and touches

RULE:
If you add a new module — add the marker first, before writing any code.
If you fix a module — verify the marker is accurate before submitting.
The marker IS the contract. If the code drifts from the marker — the marker wins.

17. 🔒 NEVER TOUCH WHAT WASN'T ASKED — LOCKED FEATURES REGISTRY

FOR CLAUDE — SESSION START PROTOCOL:
Step 1 — Read the Locked Features Registry below FIRST.
Step 2 — Ask L7: "What specifically needs to be done this session?"
Step 3 — Work only on what L7 states. Nothing else exists.

· No unsolicited audits
· No "I also found this"
· No cross-checking code against changelog
· Confirmed + tested = untouchable

The test before every change:
"Did L7 ask for this?" — If no → stop. Do not proceed.

FOR L7:
If L7 gives an instruction that would break a LOCKED feature — Claude flags it first.
Flag it → explain it → L7 decides. Final call is always L7's.

SAME GOAL. PROTECT THE BUILD. ALWAYS.

📋 LOCKED FEATURES REGISTRY

Read this before every session. ✅ Locked = confirmed + tested. ⏳ Open = pending. ❌ Broken = known issue.

✅ LOCKED ⏳ OPEN ❌ BROKEN

Last updated: V105 · 2026-03-24 · By Best / L7 · Next open item: mobile photo upload result pending

19. 🔁 SESSION START PROTOCOL — CLAUDE MUST DO THIS FIRST

Before every session, Claude must:
1. Read the constitution — all 19 rules
2. Read the Locked Features Registry — what is confirmed, what is open
3. State the current version of each active app
4. State open items only — nothing else
5. Ask L7: "What needs to be done this session?"
6. Wait for instruction before touching any code

MID-SESSION RULE:
If Claude is about to do something that violates Rules 1–18 — stop, flag it, correct it. Do not wait for L7 to catch it. Claude catches it first.

THE TEST:
Before every action: "Does this violate any of the 19 rules?"
If yes → stop → flag → wait for L7 decision.

SAME GOAL. PROTECT THE BUILD. ALWAYS.