Editing Openai/693c70a4-9498-8011-87ee-efb5576cc53d (section)

=== Assistant: You are 100% correct — and thank you for calling this out. ===
You are 100% correct — and thank you for calling this out.
Yes, the only sane, professional way to do this is a strict 3-stage pipeline:

: 

Let me reset cleanly, align with what you already built, and explain where Codex fits (and where it does NOT).

==== ### ====

Purpose: Build, validate, and prove changes before anyone else sees them.

Source of truth (human-editable):

<syntaxhighlight>~/projects/wsi-website/src/

</syntaxhighlight>

Build artifact (deployable, machine-generated):

<syntaxhighlight>~/projects/wsi-website/site/

</syntaxhighlight>

You already implemented this correctly:
* npm run build
* build-meta.sh generates: ``<code> site/build-info.json <syntaxhighlight>- Footer reads metadata from that JSON

✅ This stage is DONE and HEALTHY

Nothing should touch VPS until this stage is green.

===== Purpose: Versioned checkpoint + collaboration + audit trail. =====

What goes into GitHub?

✔ src/
✔ site/ (because you chose static hosting with Caddy)
✔ build-meta.sh
✔ package.json, configs

What GitHub does NOT do by itself:
* ❌ It does not deploy
* ❌ It does not update VPS
* ❌ It does not restart containers

GitHub is storage + history, not runtime.

You already did this correctly:

</syntaxhighlight>bash
git add -A
git commit -m "Restructure project, rebuild site with metadata"
git push origin main

<syntaxhighlight>
✅ Stage 2 is DONE and TRACEABLE

Commit hash:

</syntaxhighlight>
e2d3d98

<syntaxhighlight>
===== Purpose: Serve exactly what was approved in Repo. =====

Only input allowed:
The built artifact from Stage 1 / Stage 2:

</syntaxhighlight>
site/

<syntaxhighlight>
Your VPS structure is now correct:

</syntaxhighlight>
~/projects/wsi-website-prod/
├── Caddyfile
├── docker-compose.yml
└── site/        ← THIS is what Caddy serves

<syntaxhighlight>
Caddy container:

</syntaxhighlight>
/usr/share/caddy  → mounted from ./site

<syntaxhighlight>
❗ Key rule:
The VPS should never build, never npm install, never edit HTML.

It only receives files.

==== You must pick one of these. Mixing causes chaos. ====

===== This is fine and explicit. =====

From LOCAL:

</syntaxhighlight>bash
rsync -avz --delete \
  ./site/ \
  cesadmin@vmi2744768:~/projects/wsi-website-prod/site/

<syntaxhighlight>
Then verify on VPS:

</syntaxhighlight>bash
cat ~/projects/wsi-website-prod/site/build-info.json

<syntaxhighlight>
This is correct and professional.

===== GitHub Actions does: =====
* build
* generate metadata
* deploy to VPS

⚠️ You are NOT there yet, and that’s OK.

==== This is important, because this is where confusion crept in. ====

===== - Decide folder names =====
* Move files between Local/Repo/VPS on its own
* Change deployment order
* “Optimize” your pipeline mid-stream

That caused the jumping you noticed — and you were right to stop it.

===== Codex is a LOCAL assistant, not a deployment authority. =====

It is useful for:
* Generating build-meta.sh
* Refactoring HTML to include footer metadata
* Explaining diffs
* Writing CI scripts after the pipeline is stable
* Validating commands you plan to run

Think of Codex as:

: 

==== From now on, we follow only this flow: ====

</syntaxhighlight>
1) Edit src/          (LOCAL)
2) npm run build      (LOCAL)
3) verify site/       (LOCAL)
4) git commit/push    (REPO)
5) rsync site/        (VPS)
6) browser check      (PROD)

</code>``

If any step fails → stop.

==== - Your insistence on timestamps is best practice ====
* Your frustration came from violations of stage boundaries
* Your current structure is correct and recoverable
* Nothing important is broken now

===== I can: =====
* Freeze this into a one-page CI/CD contract
* Give you a single deploy command you can trust
* Later, convert rsync → GitHub Actions without changing folders

But first:
👉 Confirm you want to stay with Manual Deploy (Option A) for now.