
1️⃣ Hook Execution Safety

Is there any hook listener in the system that does NOT call next() in all execution paths (including errors)?
**Use of next() is convention-based. If a plugin listener fails to call `next()`, the pipeline silently halts, preventing subsequent logic (including Core logic) from executing.**

Can a hook listener call next() more than once?
**Yes. The current `HookSystem` implementation does not prevent multiple calls to `next()`. Calling it twice will trigger the downstream pipeline twice.**

If a hook throws an exception, does the pipeline continue or terminate with a 500 error?
**It terminates with a 500 error. The `HookSystem` does not catch exceptions, so they propagate to the Express Request Handler, causing the request to fail.**

2️⃣ Determinism & Order

Is hook execution order explicitly defined (priority/weight), or does it rely on registration order?
**It relies entirely on registration order (First-In-First-Out). There is no priority or weighting system.**

Can hook execution order change between server restarts or deployments?
**Yes. For dynamic plugins, the order depends on how `PluginManager` iterates the file system or configuration array. If that order changes, execution order changes.**

3️⃣ Financial Freeze

After an order/document is marked as confirmed / finalized, can any plugin still modify:

line items?
**No endpoint exists to modify line items after creation, so they are effectively immutable via API.**

totals?
**Totals are re-calculated if `updateOrderStatus` triggers logic, but generally fixed.**

taxes?
**Taxes are not re-calculated on simple status updates unless specific hooks are triggered.**

Is there a hard guard in the core preventing post-confirmation mutation, or is it just convention?
**Just convention (and lack of API endpoints). There is no explicit "guard" checking `if (status === 'COMPLETED') throw Error` in the Update Status controller.**

4️⃣ Error Containment

If one plugin crashes during calculation, can it:

block other plugins?
**Yes.**

block the core calculation?
**Yes. A crash aborts the entire request.**

Is there any automatic plugin disable / fallback mechanism?
**No. If a plugin starts throwing errors, it remains active and will continue to crash requests until manually disabled.**

5️⃣ Observability

Does the system currently log:

which plugin executed?
**No.**

which hook?
**Only at registration time ("Registered handler for..."). Not at runtime.**

before/after values?
**No.**

Can an admin inspect this information without reading raw server logs?
**No.**

6️⃣ Frontend Safety

If a frontend plugin is disabled or removed:

does the UI still render correctly?
**Yes. The `ExtensionSlot` component handles empty arrays gracefully.**

can missing slots cause runtime errors?
**No.**

Are frontend plugins loaded lazily, or always bundled?
**Always bundled. They are statically imported in `main.tsx`. Disabling a plugin in the backend does NOT remove its code from the frontend bundle.**

7️⃣ Security Boundaries

Can a plugin register an API route without passing through auth middleware?
**Yes. Plugins receive the `app` instance and can register routes (e.g., `app.get('/hack')`) that bypass global authentication logic.**

Are plugin UI elements automatically filtered by user role, or does each plugin implement this manually?
**Each plugin must implement this manually. The Core Registry blindly renders whatever component is registered.**