GPT Review S191 — P10D-2D Historical Deploy Path Verify

Date: 2026-04-30
Phase: P10D
Verdict: Direction approved, but prompt must be patched before dispatch.

---

1. Assessment

Opus correctly found historical evidence: S174-FIX-02 documented Nuxt local build on VPS. Therefore the previous conclusion “no local deploy path exists, create a new script immediately” was premature.

The new prompt correctly reframes the work as:

• verify the historical deploy mechanism;
• decide whether it still applies under current bind-mount runtime;
• activate only after the mechanism is proven.

This matches VPS-as-SSOT and the User principle: “Không chắc đúng = sai.”

---

2. Required patches before dispatch

Patch 1 — Phase A must be read-only only

The prompt title says “Verify Historical Deploy Path + Activate,” and Phase B allows activation in the same prompt. That is acceptable only if Phase A is conclusive, but because current runtime has bind-mount semantics, we should make the first Agent run discovery-first.

Patch wording:

Phase A is mandatory. If Phase A concludes Path 1 or Path 2 is safe, Agent may either continue only if the exact command is already authorized in this prompt and all preconditions pass, or STOP with a proposed activation command. If any uncertainty remains, STOP.

Patch 2 — Do not edit docker-compose unless separately authorized

S174 used image swap / compose update, but current runtime mounts /opt/incomex/deploys/nuxt-output to /app/.output. Editing compose to remove/update the mount is higher-risk than replacing the output directory.

Patch:

• Prefer Path 2 if bind mount is confirmed.
• Path 1 that edits docker-compose must be STOP + ask approval, not executed automatically.

Patch 3 — Verify package manager inside the build context

Do not assume host pnpm is available. Agent must verify whether historical S174 built with Dockerfile or host pnpm.

Check:

• host node, pnpm;
• Dockerfile build stages;
• package manager lockfile;
• whether docker build -f web/Dockerfile web/ still succeeds in dry/low-risk form is not possible without building, so inspect first.

Patch 4 — Backup command must capture exact backup path

The rollback snippet using wildcard nuxt-output.bak.*/ is unsafe if multiple backups exist.

Patch:

• create BACKUP=/opt/incomex/deploys/nuxt-output.bak.p10d-$(date +%Y%m%d%H%M%S);
• save the exact backup path in a file/report;
• rollback only from that exact backup path.

Patch 5 — Use rsync locally, not -z

For local copy, use:

rsync -a --delete .output/ /opt/incomex/deploys/nuxt-output/

No -z needed.

Patch 6 — Add build artifact sanity check before replacing production output

After build and before rsync, verify:

• .output/server/index.mjs exists or equivalent Nuxt output entry;
• .output/public exists if expected;
• .output is non-empty;
• current git HEAD is still 5ce3437.

Patch 7 — Commit only if script/file is created or modified

If Agent uses an existing historical path and no file changes are made, no commit is required. If a script is created/restored, commit it. Runtime deployment output should not be committed.

Patch 8 — Runtime verify should distinguish old catch-all from new route

HTTP 200 is not sufficient because old catch-all may return 200 with a not-found panel. Add a content check for route-specific evidence if SSR shows it; if not, require browser visual check and record as pending, not PASS.

---

3. Direction to Opus

Patch the prompt and dispatch Agent.

The preferred decision tree is:

1. Verify current runtime uses bind mount.
2. If bind mount is active, prefer building .output and replacing /opt/incomex/deploys/nuxt-output with backup.
3. Do not edit compose unless a separate approval is obtained.
4. If build/deploy commands are not fully confirmed, STOP with evidence.

No further GPT review required if Opus only applies these patches.

---

4. Boundary

No git pull/push/reset/checkout. No Directus/DB mutation. No feature code changes. No compose edit without separate approval. No invented build command. If unsure, STOP.