GPT Review — P2B-INV Birth Pipeline Inventory Prompt

Date: 2026-05-05 Reviewer: GPT-5.5 Thinking / Incomex Hội đồng AI Reviewed: knowledge/dev/laws/dieu44-trien-khai/prompts/p2b-inv-birth-pipeline-inventory-prompt.md

Verdict

Direction PASS, but patch before dispatch.

The prompt correctly tells Agent to inventory what already exists and not design anything new. However, it is not yet strong enough to force a complete answer. It may miss existing mechanisms because it mostly greps names and does not require source reading or schema-first guards.

Required patches

P1 — Add mandatory reading list

Agent should read existing KB docs before touching VPS:

• knowledge/ops/processes/birth-process-v1.md
• knowledge/dev/architecture/birth-registry-law.md
• knowledge/dev/laws/law-04-birth-process.md
• knowledge/dev/laws/dieu44-trien-khai/reports/dot119-repair-p2-script-rewrite-report.md
• knowledge/dev/laws/dieu44-trien-khai/reports/iu-birth-trigger-install-18c-report.md
• knowledge/dev/laws/dieu44-trien-khai/reports/19-p2b-p1-iu-pilot-insert-and-birth-fire-report.md
• knowledge/dev/laws/dieu44-trien-khai/reviews/iu-birth-philosophy-and-p2b-p1-interpretation-2026-05-05.md

P2 — Add schema-first guard

The query for system_health_checks assumes columns check_code, check_name, status, last_run_at, but previous reports often used code, name, executor_type, executor_ref, is_active.

Add:

SELECT column_name, data_type
FROM information_schema.columns
WHERE table_name='system_health_checks'
ORDER BY ordinal_position;

Then Agent must adapt the query to actual columns. Column absence is not a failure; it must be reported.

P3 — Require full source for relevant DB functions

Q4 currently only lists function names. Agent must read actual definitions:

SELECT proname, pg_get_functiondef(oid)
FROM pg_proc
WHERE proname LIKE '%birth%'
   OR proname LIKE '%registry_auto%'
   OR proname LIKE '%orphan%'
   OR proname LIKE '%ghost%'
ORDER BY proname;

This is necessary to answer what actually runs.

P4 — Require source inspection for relevant DOT tools

For every relevant tool found in Q1/Q2, Agent must run:

head -80 /opt/incomex/dot/bin/<tool>
grep -nEi 'birth|backfill|orphan|ghost|registry|trigger|health|scan|reconcile|ON CONFLICT|birth_registry' /opt/incomex/dot/bin/<tool> | head -80

If the tool is short, cat full source. If long, summarize with exact grep lines and note line count.

P5 — Search codebase, not just bin filenames

Existing mechanisms may live outside /opt/incomex/dot/bin. Add:

grep -RInE 'birth_registry|fn_birth_registry_auto|trg_birth_|orphan|ghost|backfill|retrofit|reconcile' /opt/incomex 2>/dev/null | head -300

P6 — Query birth_registry coverage/orphans directly

Agent should not only list tools; it should measure current state read-only.

Add queries:

-- Birth rows by collection
SELECT collection_name, count(*)
FROM birth_registry
GROUP BY collection_name
ORDER BY count(*) DESC;

-- Collections with birth trigger but no birth rows
SELECT t.tgrelid::regclass::text AS table_name, count(br.*) AS birth_rows
FROM pg_trigger t
LEFT JOIN birth_registry br ON br.collection_name = t.tgrelid::regclass::text
WHERE t.tgname LIKE 'trg_birth_%' AND NOT t.tgisinternal
GROUP BY t.tgrelid::regclass::text
ORDER BY table_name;

For true orphan detection across arbitrary collections, Agent should not generate unsafe dynamic SQL unless prompt explicitly says so. It can report whether existing tools/checks implement it.

P7 — Inspect trigger definitions fully

Q3 should include pg_get_triggerdef(oid), not only function name:

SELECT tgname, tgrelid::regclass AS table_name, tgfoid::regproc AS function, pg_get_triggerdef(oid) AS trigger_def
FROM pg_trigger
WHERE tgname LIKE 'trg_birth_%' AND NOT tgisinternal
ORDER BY table_name, tgname;

P8 — Add tool registry queries

Disk tools and DB registry can diverge. Add:

SELECT code, name, status, operation, file_path
FROM dot_tools
WHERE code ILIKE '%BIRTH%'
   OR name ILIKE '%birth%'
   OR operation ILIKE '%birth%'
   OR file_path ILIKE '%birth%'
   OR code ILIKE '%REGISTRY%'
   OR name ILIKE '%registry%'
   OR operation ILIKE '%registry%'
   OR file_path ILIKE '%registry%'
   OR code ILIKE '%ORPHAN%'
   OR name ILIKE '%orphan%'
   OR code ILIKE '%GHOST%'
   OR name ILIKE '%ghost%'
ORDER BY code;

If some columns are absent, schema-first adapt.

P9 — Search KB/history explicitly

The User specifically said these mechanisms exist in history. Agent should search Agent Data / KB for:

• QT-001
• QT-002
• birth-first
• backfill birth_registry
• orphan
• ghost
• fn_birth_registry_auto
• dot-birth-trigger-setup
• DOT-119

If Agent cannot use KB search directly, Opus should add a pre-read list and require report to distinguish “found on VPS” vs “found in KB/history”.

P10 — Output must answer the exact business questions

Add final section with direct answers:

1. What is the main birth channel currently implemented?
2. What is the auxiliary/backfill channel currently implemented?
3. What warning/health signal fires when auxiliary channel is used?
4. What orphan detector exists?
5. What ghost detector exists?
6. What code/tools are responsible?
7. What hardcode remains, if any, and in which code path?
8. Which parts are runtime-active vs only documented/design?

Directive to Opus

Patch the prompt with P1–P10 before dispatch. Do not design new systems in the prompt. The investigation is read-only.

If Opus wants to keep the prompt shorter, at minimum add P2, P3, P4, P8, P9, and P10; without those, the Agent may miss the actual mechanisms.

Hard boundaries

• read-only only;
• no DDL/DML;
• no tool execution that mutates state;
• no design proposal unless explicitly separated as “observed gaps”;
• no Pack 2C or IU workflow work.