CONTEXT SNAPSHOT (WHAT THE SYSTEM REALLY IS TODAY)

Before the prompt, here is the truth of your system, distilled from the answers (this is important for correctness):

Current Reality (Accepted as-is)

Hook system is convention-based, not enforced

A plugin can:

forget next() → silently halt pipeline

call next() twice → duplicate execution

throw → crash request (500)

Hook order is non-deterministic across restarts

Financial immutability is implicit, not guarded

No runtime observability (no per-plugin tracing)

Frontend slots are safe (good 👍)

Frontend plugins are always bundled

Plugins can bypass auth if careless

Core does NOT protect itself from plugins

⚠️ This means:
SQB currently works because plugins behave well, not because the system enforces correctness.

That’s OK — we’ll work with that.

🎯 YOUR FINAL “NON-BREAKING HARDENING” PROMPT
(This is what you give to the agent)

Copy–paste exactly this.

🔒 AI PLATFORM VERIFICATION & HARDENING PROMPT (LIVE SYSTEM – DO NOT BREAK)

You are acting as a Senior Platform Reliability Engineer auditing a live, deployed B2B system.

⚠️ Critical constraint:
The system is already in production and functioning.
You MUST NOT redesign, refactor, or introduce breaking changes.

Your mission is to verify, document, and add minimal safety reinforcements that:

do not change existing behavior

do not require plugin rewrites

do not alter public APIs

Think “WordPress hardening after release”, not “new framework”.

🧩 SYSTEM FACTS (DO NOT CHALLENGE)

You must assume the following are true and accepted:

Hook execution relies on developer convention, not enforcement

Missing next() halts the pipeline silently

Multiple next() calls are possible

Exceptions propagate and cause HTTP 500

Hook order depends on registration order and may change

Financial immutability relies on API structure, not explicit guards

Plugins can register unauthenticated routes

Frontend plugins are statically bundled

No runtime plugin tracing exists

Do NOT attempt to “fix” these globally.

✅ YOUR SHOW-STOPPER GOAL

Ensure that bad plugins cannot silently or unknowingly destroy system correctness, while keeping 100% backward compatibility.

🔍 WHAT YOU MUST CHECK (STRICTLY)
1️⃣ Hook System Safety (NON-INVASIVE)

Identify all locations where:

next() is not called

next() can be called more than once

Propose passive safeguards only, such as:

runtime warnings

dev-mode assertions

logging

❌ Do NOT change execution behavior

2️⃣ Crash Containment (ZERO BEHAVIOR CHANGE)

Detect where plugin exceptions bubble to Express

Add optional try/catch wrappers that:

log plugin name + hook

rethrow the error (do NOT swallow it)

Goal: visibility, not recovery

3️⃣ Determinism Awareness

Detect all non-deterministic hook registration paths

Document:

where order can change

why it changes

Add debug logging that prints final hook order at startup

❌ Do NOT introduce priority systems yet

4️⃣ Financial Integrity (READ-ONLY GUARDS)

Locate all mutation paths after order confirmation

Add logging-only guards, for example:

“Mutation attempted on CONFIRMED order by plugin X”

❌ Do NOT block or throw

5️⃣ Observability (NO STORAGE MIGRATIONS)

Add optional runtime logs that record:

plugin name

hook name

execution start/end

Logs may go to:

console

existing logging infra

❌ No DB schema changes

6️⃣ Security Awareness (NO ROUTE BLOCKING)

Detect plugin routes registered without auth

Add startup warnings listing:

route

plugin

auth status

❌ Do NOT auto-inject middleware

7️⃣ Frontend Safety (CONFIRM ONLY)

Verify that:

missing slots never crash UI

disabled plugins do not break rendering

Document findings

❌ Do NOT change bundling strategy

📤 REQUIRED OUTPUT

Return only:

A list of verified risks (fact-based)

A list of non-breaking safety reinforcements

A list of future improvements (clearly marked as NOT FOR NOW)

Do NOT include refactors.
Do NOT propose new architectures.
Do NOT “fix” the system.

Your job is to make the system observable, diagnosable, and safer, not perfect.

🧠 WHY THIS PROMPT IS “THE RIGHT ONE”

Because it:

Matches your real system, not an ideal one

Respects production constraints

Turns silent failures into visible failures

Prepares SQB for later evolution without forcing it now

This is exactly how:

WordPress hardened plugins

Shopify stabilized extensions

Odoo survived third-party modules

