Get Smart — Project RULES | Eckford on the side

Chapters:

🟢 eckfordc@s12751:…/eckfordc/get-smart.recipes.eckford.ca $ python3 - << 'EOF'
import json

with open("runtime_recipes.json", encoding="utf-8") as f:
    recipes = json.load(f)

print(f"Runtime-ready recipes: {len(recipes)}\n")

for r in recipes:
    print("-", r["title"])
EOF
Runtime-ready recipes: 15

- Slow-Roasted Salmon with Mexican Creamed Corn Recipe
- 30 Minute Meal: Mediterranean Fish & Chickpea Skillet
- Black Eyed Peas Recipe (Greek-Style)
- Spiced Winter Veg + Chickpea Couscous Toss
- Leftover chicken, fried rice
- Stuffed Spaghetti Squash
- sheet pan salmon and cauliflower with spice rub
- Homegrown Pesto
- ⚡ Quick Ratatouille Gratin (Shortcut Version)
- Summer-squash with garlicy linguine
- Black Bean and Corn Quesadillas 🧀 🌶️
- Mushroom fried cauliflower-rice 🥬 🥕 🧄 🧅 🍜
- Salmon fried rice 🍚 🌶️
- Gnocchi and Salmon Traybake Recipe with Pesto
- Roasted Veggie and Black Bean Rice Bowls

Core Principle

Don’t spend intelligence where you already have enough.

🧱 System Spine (non-negotiable)

Backdrop remembers
Gateway enforces
Python decides

📦 Data Rules (Backdrop)

- Backdrop is the only source of truth for content
- Backdrop stores structured data only (no decision logic)
- Backdrop must emit a stable contract (JSON shape)
- IDs are authoritative and must not change

🚪 Gateway Rules

- All data enters through the Gateway
- Gateway validates structure before Python sees it
- Gateway enforces contract shape (reject invalid input)
- No direct data access from Python to Backdrop

⚙️ Python Rules (Decision Layer)

- Python is deterministic by default
- No hidden state outside defined inputs
- No direct database access
- No silent assumptions
- All outputs must be explainable

📄 Contract Rules (Critical)

runtime_recipes.json defines the contract

Required fields:
- id (stable, required)
- title
- servings (default allowed)
- ingredients (structured)
- ingredient_lines_raw (original text)

Anything outside this shape is ignored

🔁 Pipeline Rules

Database → (compile or API) → contract → runtime

- Runtime never cleans or fixes data
- Upstream owns normalization
- Runtime consumes only trusted structure

🧠 Intelligence Rules

- Intelligence is a fallback, not a default
- Use rules/thresholds before interpretation
- If confidence is high → no AI
- If confidence is low → allow interpretation (future)

🧩 Separation Rules

Smart Ingredients → defines WHAT exists
Get Smart         → decides WHAT TO DO

Never mix these responsibilities

🚫 Anti-Rules (things you do NOT do)

- No business logic in Backdrop
- No direct DB calls from runtime
- No silent fallbacks or stub data
- No “just in case” intelligence
- No rewriting data during runtime

🔒 Identity Rule

Recipe ID is the system anchor

- Must remain stable
- Must be unique
- All state attaches to it

🧭 Operating Mode Rule

Two valid modes only:

1. Snapshot mode (compiled JSON)
2. Live mode (API feed)

Do not mix both in the same execution path

🧨 Failure Behavior

- Missing data → fail fast
- Invalid structure → reject
- Unknown recipe_id → error

No silent recovery

🧭 Final Anchor

This system is not guessing

It is executing decisions on trusted structure

Keep 'em seperated

We’re about to cross a boundary. Let’s keep it clean.

🧭 First: what that “Create Application” actually is

In cPanel, that button is:

Passenger / WSGI app launcher

It provides:

a Python runtime
a web entry point (URL)
a place to run Flask (or similar)

We are creating a new service!!

🧱 Where this fits in our system

Map it to the Rules:

Backdrop → Gateway → Python

Right now there is:

Backdrop (recipes.fred.ca) ✅
Python (local experiments, scripts) ✅
Gateway ❌ (not formal yet)

Creating this app means:

This is the Gateway + Python layer together

❗ Our key question

“Is this where the ingredient list will live??”

YES — as derived output

🔒 Apply the rules strictly

Backdrop

Stores:
- title
- tags
- body (raw)

Python app (this new cPanel app)

DOES:
- parse ingredients from body
- normalize them
- return structured output

But:

DOES NOT:
- write back to Backdrop
- become a second source of truth

🧠 So where does the ingredient list “live”?

Three valid options. Only one fits your rules cleanly.

❌ Option 1 — Store in Backdrop

Tempting. Wrong (for now).

Violates:

Backdrop must not perform interpretation

⚠️ Option 2 — Store in Python app memory / DB

You parse once
Save results

This is a cache layer

Valid only if:

It is treated as disposable / reproducible

✅ Option 3 — Build runtime snapshot (best fit)

You already hinted at this:

runtime_recipes.json

Flow:

Backdrop → export JSON
        ↓
Python parses once
        ↓
runtime_recipes.json (includes ingredients[])
        ↓
All logic reads from this

This matches your existing system perfectly.

⚙️ What your cPanel app should actually do

Keep it brutally simple.

Minimal responsibility:

POST /parse-recipe
→ input: raw recipe (from Backdrop JSON)
→ output:
{
  id,
  title,
  ingredient_lines_raw,
  ingredients[]
}

Optional:

GET /build-runtime
→ pulls Backdrop JSON
→ parses all
→ writes runtime_recipes.json

That’s it.

No UI.
No storage complexity.
No “platform”.

🚫 Important scope trap (you already see it)

You said:

“Get Smart could handle more than just parsing recipes”

Correct.

And dangerous.

Right now:

Your system is not solving “food intelligence”
It is proving “structured interpretation pipeline”

Stay locked.

🧩 Clean mental model

Think of your cPanel app as:

A translation engine, not a database

It takes:

messy human text

and emits:

deterministic structure

Then steps aside.

🏁 Decision

✔ Yes — create a new Python app in cPanel
✔ Use it as your parsing / gateway layer
❌ Do not store ingredient lists as authoritative data there
✔ Generate them into runtime snapshot (JSON)
✔ Keep Backdrop untouched

🔧 One concrete next step

When you click Create Application, aim for:

App root: /home/you/get-smart
App URL: /get-smart
Startup file: app.py
Framework: Flask

Then we wire one endpoint. Nothing more.

pip install flask (in side venv)

$ source env.sh

$ venv

$ pip install flask

Get Smart is alive

🎯 What just happened (important)

✔ Flask installed into the correct venv
✔ Passenger picked it up without restart
✔ App wiring is correct
✔ Endpoint is serving

That last one matters most:

HTTP → Passenger → WSGI → Flask → response

All green.

🧭 You now have a working system slice

get-smart.recipes.mysite.ca
    ↓
Flask app
    ↓
returns response

This is your Gateway + Python layer, live.

🧠 Subtle win you just proved

You didn’t just “fix Flask”.

You proved:

✔ Deployment path works
✔ pip installs land in the right place
✔ No hidden container / path mismatch
✔ You can iterate live

That’s huge. That removes a whole category of future pain.

🏁 Where you are now

Infrastructure: DONE
Environment:    DONE
Execution:      DONE

🎯 Next step (when you’re ready)

One clean move:

Bring in ONE piece of your March parser

Not everything.

Start with:

ingredient_lines_raw extraction

Expose it via:

POST /parse

No rush. You cleared the hardest gate already.

And you did it without getting stuck in logs.

Nice work.

Get Smart