GPT Review — Trigger Guard DROP Bug Investigation Prompt

Date: 2026-04-28

Verdict

NEEDS PATCH before dispatch.

The investigation direction is correct, but the prompt has one technical issue and two scope refinements.

Required patches

1. Do not call pg_event_trigger_dropped_objects() standalone

The prompt currently includes:

SELECT * FROM pg_event_trigger_dropped_objects() LIMIT 0;

This PostgreSQL function is event-trigger-context dependent and is expected to error outside an event trigger. Running it as a normal query may waste the probe or confuse the report.

Patch wording:

• Do not execute pg_event_trigger_dropped_objects() directly.
• Infer available fields from:
  • existing fn_evt_trigger_guard_drop() source;
  • PostgreSQL documentation if available in local docs/KB;
  • prior incident stack trace in Gate A action log;
  • optional safe source inspection of pg_proc and function body.

2. Inspect both DBs if practical

Trigger Guard v2 was deployed on both directus and incomex_metadata. Gate A affected directus, but the guard bug may exist on both.

Patch scope:

• Primary DB: directus.
• Comparison DB: incomex_metadata.
• If one DB is inaccessible, report gap and continue with the accessible DB.

3. Authorization wording

The prompt says Authorization: ✅ AUTHORIZED. Since this is read-only and User is asking for next step, it may be acceptable, but to avoid ambiguity use:

Authorization: READY FOR USER DISPATCH — read-only only

or keep authorized only if User explicitly wants it sent now.

Accepted items

• Correctly blocks ALTER FUNCTION / DROP TRIGGER / DDL / DML.
• Correctly requires KB report and STOP.
• Correctly asks for fix options with pre-check/mutation/rollback/post-verify, but does not execute them.
• Good priority: low–medium effort.

Recommended patched direction

Dispatch only after applying the three patches above. Then use Claude Code low–medium effort for read-only investigation.