GPT Review — 18b-P2 DOT-119 Script Rewrite Prompt rev2

Date: 2026-05-05 Reviewer: GPT-5.5 Thinking / Incomex Hội đồng AI Reviewed:

• knowledge/dev/laws/dieu44-trien-khai/prompts/18b-p2-dot119-script-rewrite-prompt.md rev2
• knowledge/dev/laws/dieu44-trien-khai/design/dot119-v2-script-content.sh rev1

Verdict

Rev2 is much stronger but not approved for dispatch. Rev3 required.

Opus fixed the ten rev1 issues well:

• smoke samples are metadata-selected, not placeholders;
• exact $DOT119 path is used;
• multiple CLI modes are rejected;
• birth_code_column is validated;
• sentinel is aligned to __birth_synthetic_id__;
• disabled/subordinate verify checks no trigger;
• execute no longer parses tail -1;
• drop is guarded;
• raw trigger definition is kept out of JSON;
• script is stored separately on KB.

However, one serious anti-hardcode issue remains.

Blocker B1 — Hardcoded function hash in script

The v2 script contains:

KNOWN_V2_FN_HASH="1f729b3571a74963089bb3ef388217f3"

and synthetic strategy requires the installed function hash to equal this exact value.

This is safer than the earlier fragile wildcard, but it violates the long-term anti-hardcode principle:

• future legitimate updates to fn_birth_registry_auto would break DOT-119 even if synthetic fallback remains compatible;
• a DOT tool should not hardcode a function implementation hash unless the hash comes from governed metadata;
• this repeats the same pattern we are trying to eliminate: a script knowing a specific runtime implementation forever.

Required rev3 fix for B1

Replace hardcoded function hash with one of these approaches:

Preferred approach — capability check, not implementation hash

Define a script function, for example assert_synthetic_fallback_capability, that checks the installed fn_birth_registry_auto source for required capability markers:

• function exists;
• source references TG_TABLE_NAME;
• source references an id fallback path;
• source constructs an entity code with :: or an explicitly equivalent synthetic shell behavior;
• no requirement that the entire function hash equals a fixed literal.

The check should be documented as a capability check, not a hash identity check.

The existing P2 smoke/report can still capture the function hash as audit evidence, but DOT-119 should not hardcode it as an execution gate.

Alternative approach — governed metadata value

If you strongly prefer exact hash gating, the expected hash must come from governed metadata, e.g. dot_config / DOT metadata / function capability registry, not a literal in script. But P2 currently does not seed such metadata, so this is not the fast path.

Required rev3 patch details

1. Remove KNOWN_V2_FN_HASH="..." from script.
2. Add capability-check function for synthetic fallback.
3. For synthetic_id, call the capability check.
4. Keep fn_hash_before / fn_hash_after only for no-clobber audit before/after operations.
5. Update P2 prompt smoke expectations:
   • fn hash unchanged is still verified against run-local baseline and known P1 value in the prompt/report;
   • script itself must not require exact hardcoded hash.
6. Update report requirements to include:
   • synthetic fallback capability check output;
   • function hash audit trail.

Non-blocking but recommended rev3 hardening

N1 — Exact script content integrity

Since prompt says “read script from KB and paste to temp file,” add an integrity step:

• compute md5 of the KB script content after writing temp file;
• include md5 in report;
• compare with the md5 shown in the prompt or report if provided.

N2 — --help behavior

--help exits 1 in current script. That is acceptable if documented, but conventional tooling usually exits 0 for explicit --help and 1 for no args/usage error. Opus can either keep current behavior and report it, or adjust:

• no args → exit 1;
• --help → exit 0.

Not blocking.

N3 — execute transaction formatting

Current execute SQL is:

BEGIN; ${CREATE_SQL} COMMIT;

This will likely work because CREATE_SQL ends with semicolon, but clearer is:

BEGIN;
${CREATE_SQL}
COMMIT;

Not blocking, but cleaner.

Hardcode assessment

Rev2 successfully removes hardcoded collection mapping. Good.

But it introduces/keeps a hardcoded function implementation hash. That must be removed or moved to governed metadata before dispatch.

Directive to Opus/Ocus

Patch:

• knowledge/dev/laws/dieu44-trien-khai/design/dot119-v2-script-content.sh to rev2;
• knowledge/dev/laws/dieu44-trien-khai/prompts/18b-p2-dot119-script-rewrite-prompt.md to rev3.

Required changes:

1. Remove hardcoded KNOWN_V2_FN_HASH from script.
2. Add synthetic fallback capability check instead of exact implementation hash gate.
3. Keep function hash only as audit/no-clobber before-after evidence.
4. Update smoke/report requirements accordingly.
5. Add script content md5/integrity step if convenient.
6. Do not dispatch yet.

Hard boundaries remain:

• no fn_birth_registry_auto edit;
• no IU trigger install;
• no IU rows;
• no Pack 2B;
• no seed/DDL changes.

After rev3, GPT/User will review again.