GPT Review — D28 Generated Table Map Design Prompt rev1

Date: 2026-05-08
Reviewer: GPT-5.5 Thinking / Incomex Hội đồng AI
Reviewed: knowledge/dev/laws/dieu28-trien-khai/prompts/d28-generated-table-map-design-review-prompt.md rev1

Verdict

REV2 REQUIRED — do not dispatch rev1.

Rev1 is directionally correct: it keeps work at design level, requires VPS-focused reverify, targets Option C generated map, and preserves hard boundaries. However several points need tightening before dispatch.

Accepted parts

• Scope is read + design only, no implementation.
• VPS reverify focuses on the correct three hardcoded map files:
  • pages/knowledge/registries/[entityType]/index.vue;
  • config/detail-sections.ts;
  • server/api/discovery/relations.get.ts.
• Prompt includes build/deploy scripts, generated conventions, and import alias checks.
• Prompt correctly identifies entityType derivation as the hardest design issue.
• DOT pair idea is correct:
  • dot-generate-table-maps as writer;
  • dot-verify-table-maps as verifier.
• Hard boundaries forbid code changes/generated file creation.

Required rev2 patches

P1 — Resolve contradiction: design review should recommend, not merely list options

Rev1 repeatedly says Agent should present options and not choose. That was correct for the previous inventory phase, but this prompt is now a design-review prompt. It should still avoid implementation, but it should produce a recommendation.

Patch:

Agent must present options, compare tradeoffs, and recommend a preferred design.
Agent must not implement.
GPT/User will approve or reject recommendation later.

This applies especially to:

• entityType derivation;
• build timing;
• draft handling;
• output format;
• rollback/drift strategy.

P2 — Include current table_registry schema/inventory in design inputs

The design depends on whether table_registry already has or can safely receive fields like page_url, collection, table_id, and possibly entity_type.

Patch VPS/Directus reverify to GET live table_registry rows and, if possible, schema/field metadata read-only:

GET /items/table_registry?fields=id,table_id,name,collection,status,page_url,module,fields&sort=id
GET /fields/table_registry

Agent must report whether an entity_type or similar field already exists.

No mutation.

P3 — EntityType derivation must consider “registry data fix” vs generated-code workaround

The strongest design may be to add an explicit entity_type field to table_registry later, but this would be a Directus/registry schema change, not for this design pack.

Patch design options to include:

1. derive from current hardcoded map and backfill future entity_type field later;
2. derive from page_url last segment where available, with exception map for non-standard routes;
3. add explicit entity_type column to table_registry in a future schema pack;
4. use current tableIdMap as seed only for initial generated artifact;
5. generated route key = normalized page_url path token, not collection.

Agent must recommend a migration-safe approach for Phase 1 and identify any future schema cleanup needed.

P4 — Need classify which rows belong in registry route map vs other maps

Not every table_registry row should necessarily appear in [entityType] registry route. Some live rows are workflow tabs or non-registry routes.

Patch:

Agent must classify each of 21 rows into:

REGISTRY_ENTITY_ROUTE
NON_REGISTRY_PAGE
WORKFLOW_TAB
ADMIN_PAGE
INDEX_PAGE
UNKNOWN

Then design which generated maps include which rows:

• tableIdMap for /knowledge/registries/[entityType] should likely include only REGISTRY_ENTITY_ROUTE rows.
• collectionMap/reverseCollectionMap may need a different scope.

This prevents “generate all 21 rows blindly” from creating invalid route entries.

P5 — Generated file shared between client and server must be safe

relations.get.ts is server-side. Nuxt page is client/SSR. A generated TS file imported by both must not include secrets/env access or browser-only/server-only code.

Patch:

• require design of a pure static data module, e.g. web/generated/table-maps.ts;
• confirm import from both client and server paths is safe;
• verify Nuxt/Vite alias allows this from server/api;
• if not, recommend separate generated outputs for client and server.

P6 — Build-time generation requires credentials; design must avoid leaking Directus admin secrets

Rev1 says Directus API input but does not discuss credentials.

Patch:

Agent must design credential strategy:

• which token/account can read table_registry during build;
• whether Public Access can read required fields;
• if admin token is needed, how it is stored and prevented from being bundled;
• whether generation should run on VPS/deploy environment only;
• whether the generated artifact should be committed or generated during deploy.

No secrets should be printed in report.

P7 — Draft handling must distinguish build artifact from production route exposure

Rev1 lists draft include/exclude options. Patch to require recommendation.

Expected default should likely be:

published/active rows included in production map;
draft rows excluded unless build target is preview/dev or explicitly whitelisted by pack.

For tbl_event_outbox, because it is draft but needs route smoke before publish, design must state how to test it safely:

• temporary preview build map?
• explicit include-draft flag in smoke environment?
• publish after generated map supports route but before production route exposure?

Agent should recommend a safe sequence.

P8 — CI/drift verification must be precise

Add design requirements:

• generate mode writes artifact;
• verify --check mode exits nonzero if generated output differs;
• CI/deploy must run verify;
• generated header includes source row count and hash of normalized registry input;
• no manual edit detected by hash/diff.

P9 — Prompt must require a row-by-row output table

Design report must include table:

id | table_id | collection | status | page_url | derived_entity_type | row_class | included_in_tableIdMap | included_in_collectionMap | notes

This is essential to avoid vague design decisions.

P10 — Report must include blockers and next pack recommendation

Add fields:

phase_status=PASS|BLOCKED|NEEDS_MORE_DATA
vps_reverify_status=PASS|FAIL|PARTIAL
table_registry_schema_status=PASS|FAIL|PARTIAL
entity_type_strategy_recommended=<...>
route_row_classification_complete=PASS|FAIL
generated_module_import_safe=PASS|FAIL|NEEDS_REVIEW
credential_strategy=PUBLIC_READ|BUILD_TOKEN|VPS_ENV_SECRET|BLOCKED
recommended_build_timing=PREBUILD|DEPLOY_HOOK|COMMIT_GENERATED|HYBRID|BLOCKED
draft_handling_strategy=<...>
recommended_next_pack=D28_GENERATED_MAP_IMPLEMENTATION_PROMPT_REVIEW|D28_TABLE_REGISTRY_SCHEMA_EXTENSION_DESIGN|BLOCKED|REVISION_REQUIRED

Directive to Opus

Patch the prompt to rev2 at:

knowledge/dev/laws/dieu28-trien-khai/prompts/d28-generated-table-map-design-review-prompt.md

Patch narrowly, do not expand into implementation. Do not dispatch after patch; return for GPT/User review.

Hard boundaries remain

• No Nuxt code modification.
• No generated file creation.
• No Directus mutation.
• No PG mutation.
• No publish.
• No deploy.
• No implementation.

Summary

Rev1 is close, but the design review must produce a recommendation and must handle the real hard parts: entityType source, row classification, shared client/server generated module safety, build credentials, draft handling for tbl_event_outbox, and exact drift verification.