KB-25C9

GPT Review — File 15 Option 1 Execution Pack rev1

7 min read Revision 1
gpt-reviewfile15description-policyoption1execution-packnot-approvedrev2-requirediu-0

GPT Review — File 15 Option 1 Execution Pack rev1

Date: 2026-05-04 Reviewer: GPT-5.5 Thinking / Incomex Hội đồng AI Reviewed: knowledge/dev/laws/dieu44-trien-khai/design/15-description-policy-option1-execution-pack.md rev 1

Verdict

Direction PASS, execution NOT approved. Rev2 required.

File 15 is a solid first execution-design draft, but it is not yet safe enough to become a Claude Code prompt. This package touches DDL, Directus metadata, a PG function, and H11 health-check SQL. Under Đ20/NT15 and the “all domain work must follow its law/tooling” rule, the execution pack must be more exact and must resolve legal/tooling paths before runtime.

What is good

  • Includes the 12 requested sections.
  • Preserves Pack 2B hard stop.
  • Correctly separates current description write path, future entity_enrichment, and description_policy.
  • Defines Tier A/B/C and seed intent.
  • Includes rollback and STOP conditions.
  • Does not execute anything.

Blockers before execution prompt

B1 — DDL/legal tooling path is not sufficiently resolved

The pack proposes raw ALTER TABLE. This may be acceptable only if the applicable PostgreSQL/schema-change law/tooling allows it in this context, but rev1 does not prove that.

Need a Legal/Tooling section that checks Đ33/Đ35/Đ36 and available DOT/migration conventions for schema changes. If a DOT/migration tool exists, use it. If not, document the approved admin/migration path and audit requirement. Do not let Claude Code infer.

B2 — Directus field registration assumption is too optimistic

Rev1 says Directus auto-detects new PG columns. Prior Pack 2A lessons show assumptions about runtime/Directus metadata are dangerous. The pack must require preflight:

  • inspect directus_fields before;
  • after DDL verify field visibility;
  • identify legal DOT/tool for field registration if auto-detect fails;
  • STOP if unclear.

This is partly present but not yet concrete enough.

B3 — Function amendment is pseudocode, not execution-safe

For fn_description_birth_guard, rev1 has pseudocode but not an exact replacement plan. Function edits are high risk.

Need:

  • exact pre-capture command;
  • exact generated replacement SQL or exact diff constraints;
  • transaction strategy;
  • compile/validation query;
  • fallback restore from captured function source;
  • explicit handling if description_policy column is absent or function is called before DDL completes.

B4 — H11 amendment is too underspecified

H11a/H11b are KB query docs plus system_health_checks executor refs. Rev1 must specify exact files to patch and exact SQL blocks, or else make it a separate doc patch phase.

Need:

  • current file paths;
  • exact intended SQL change;
  • whether H11b Option B is included now or deferred;
  • update/report mechanism for KB docs;
  • after-patch execution/verify path.

B5 — unclassified behavior is inconsistent across birth guard and H11

Rev1 says birth guard for unclassified warns and continues normal logic, but H11a skips unclassified critical findings. This can be acceptable, but it must be intentional and documented as a transitional policy with a separate health check or report for unclassified collections.

Otherwise unclassified can hide missing descriptions from H11a.

B6 — Seed list needs runtime preflight and missing-collection handling clarified

Tier B includes TAC collections that may not exist/registered yet. Rev1 says expected ~12 and missing TAC rows can be skipped. This is fine, but the execution prompt must print exactly which collections were missing and not treat approximate counts as PASS without evidence.

B7 — Smoke tests may be unsafe/ambiguous

Insert tests into governed Tier A/Tier B/Tier C tables require exact target tables and safe test rows. Rev1 says wrap in transaction, but not which tables/columns/values. This is too open-ended.

Safer alternative: make Pack 15 execution focus on DDL/seed/function/H11 verify only, then run separate, explicitly designed smoke tests if needed. Or define exact disposable test rows for known safe tables.

B8 — Law/docs amendment scope not separated

Rev1 includes law/guide wording drafts but no exact patch plan. Do not mix runtime execution and law patch in one Claude Code run. The pack should sequence:

  1. runtime schema/function/H11 execution;
  2. report;
  3. separate doc/law patch if runtime succeeds and GPT/User approve.

Directive to Opus/Ocus

Patch File 15 to rev2. Do not execute.

Required changes:

  1. Add Legal/Tooling Gate section:

    • cite Đ20, Đ33, Đ35, Đ36, Đ3, Đ4, Đ43;
    • state the legal path for DDL/function/H11 changes;
    • list any DOT/migration tools to inspect/use;
    • if unclear, execution prompt must STOP before DDL.
  2. Make DDL/Directus phase exact:

    • preflight column absent;
    • preflight directus_fields state;
    • exact DDL;
    • verify PG column;
    • verify Directus field;
    • legal fallback/STOP if Directus field absent.
  3. Make function amendment execution-safe:

    • capture original function source;
    • exact replacement/diff strategy;
    • validation query;
    • restore plan;
    • STOP if source differs materially from expected.
  4. Make H11 patch exact:

    • exact file paths;
    • exact SQL patch or old/new blocks;
    • choose H11b Option B now or explicitly defer;
    • verify executor refs still match KB files.
  5. Resolve unclassified policy:

    • either create/describe a separate warning/report for unclassified, or explicitly accept that H11a skips it temporarily;
    • do not leave ambiguity.
  6. Tighten seed preflight:

    • exact expected Tier A list must all exist or STOP;
    • Tier B missing collections are recorded as SKIPPED with names;
    • expected counts computed from actual updates, not approximate.
  7. Replace ambiguous smoke tests with either:

    • exact safe transactional test cases; or
    • defer insert smoke tests to a later controlled test pack.
  8. Separate runtime vs doc/law patches:

    • file 15 rev2 may include draft wording, but execution prompt must not patch laws/docs unless separately approved.
  9. Keep hard boundaries:

    • no Pack 2B;
    • no IU rows;
    • no entity_enrichment deploy;
    • no execution before GPT/User approve.

Current decision

Do not approve execution. Ask Opus for File 15 rev2 with the above fixes.

Back to Knowledge Hub knowledge/dev/laws/dieu44-trien-khai/reviews/gpt-review-file15-option1-execution-pack-rev1-2026-05-04.md