GPT Review — D28 Generated Table Map Implementation Prompt rev3

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

Verdict

REV4 REQUIRED — do not dispatch rev3.

Rev3 is close and incorporates the requested execution-safety patches. However, one high-risk runtime issue remains: sourcing .env does not guarantee the variables are exported to the Node/tsx child process. This can cause preflight to report token/runtime success while the generator sees process.env.NUXT_DIRECTUS_SERVICE_TOKEN as undefined.

There are also a few smaller command-safety issues around URL printing, CI secret detection, and server import verification.

Accepted rev3 fixes

• Directus URL check added.
• Token runtime check added.
• npx tsx replaced with local ./node_modules/.bin/tsx or npx --no-install.
• tsx binary + require.resolve check added.
• API request behavior clarified.
• Live status values check added.
• SKIP and STATIC_EXTRAS reasons required.
• Import alias safety added.
• CI blocked = PARTIAL + follow-up.
• Expected file whitelist added.
• Build/typecheck exit code capture improved.

Required rev4 patches

P1 — Export .env variables before running Node/tsx

Current pattern:

source ../.env 2>/dev/null && ./node_modules/.bin/tsx scripts/generate-table-maps.ts --check

This may not export shell variables to child processes unless the .env entries themselves use export.

Patch all runtime commands that invoke Node/tsx/build with .env to use:

set -a; source ../.env 2>/dev/null; set +a; ./node_modules/.bin/tsx scripts/generate-table-maps.ts --check

or explicitly pass env variables inline without printing values.

Report:

env_export_method=SET_A_SOURCE|INLINE_ENV|OTHER
generator_env_export_verified=true|false

P2 — Verify generator can actually access env, not just shell

Add a preflight Node check that does not print values:

set -a; source ../.env 2>/dev/null; set +a; node -e "console.log(process.env.NUXT_DIRECTUS_SERVICE_TOKEN?'TOKEN_NODE_RUNTIME=true':'TOKEN_NODE_RUNTIME=false'); console.log((process.env.DIRECTUS_URL||process.env.NUXT_PUBLIC_DIRECTUS_URL)?'URL_NODE_RUNTIME=true':'URL_NODE_RUNTIME=false')"

If either is false, STOP:

NODE_RUNTIME_ENV_UNAVAILABLE

P3 — Do not print Directus URL in preflight command output

Current URL check uses grep -oP ... which prints the URL. Even if usually public, prompt says not to print full URL if it contains credentials.

Patch to report only presence and source, not value:

grep -q '^DIRECTUS_URL=' ../.env && echo directus_url_source=DIRECTUS_URL || ...

If domain is needed, agent may redact:

https://<redacted-host>

P4 — CI secret detection must be evidence-based or marked unknown

The Agent generally cannot know whether GitHub secret DIRECTUS_SERVICE_TOKEN exists unless workflows or CI context expose it. Do not ask it to assert existence unless verifiable.

Patch:

ci_token_status=CONFIGURED_IN_WORKFLOW|UNKNOWN_NOT_VERIFIABLE|BLOCKED_TOKEN_REQUIRED

If adding CI step references a secret but actual secret existence cannot be verified, status should be:

ci_check_status=ADDED_ASSUMES_SECRET|BLOCKED_TOKEN_REQUIRED|NOT_MODIFIED

Avoid claiming PASS before CI runs.

P5 — Server import verification should be based on build/typecheck, not grep alone

The grep check for ~/ in server routes is only weak evidence. Patch wording:

• grep is only preliminary;
• final proof is typecheck/build after import replacement;
• if build/typecheck fails due alias in server route, switch to relative import and re-run.

Report:

server_import_alias_precheck=TILDE_FOUND|NO_TILDE_FOUND
server_import_final_verification=PASS_BY_BUILDCHECK|FIXED_RELATIVE_IMPORT|FAIL

P6 — Directus API status-values check should use normal GET, not uncertain groupBy[]

Current preflight uses:

/items/table_registry?fields=status&groupBy[]=status

Directus groupBy syntax/version may be uncertain. Patch to safer:

GET /items/table_registry?fields=status&limit=-1

Then the script/agent derives distinct statuses locally.

P7 — Default status filter should be explicit and report excluded rows

Patch generator requirements:

PRODUCTION_STATUSES=['active','published']

Report:

production_statuses_used=['active','published']
excluded_rows_by_status=[{table_id,status}]

If all expected production rows are excluded due unexpected statuses, STOP.

P8 — Build command should not leak env through logs

When running build after set -a; source, ensure commands do not echo env. Report:

build_log_secret_scan=PASS|FAIL|NOT_RUN

Agent should scan captured build logs for literal token only if it can do so without printing the token; otherwise at minimum verify no .env dump occurred.

P9 — Report must include no-deploy/no-publish attestation

Rev3 implies this, but add explicit fields:

no_deploy=true
no_live_route_smoke=true
no_directus_mutation=true
no_pg_mutation=true
no_publish_event_outbox=true
no_table_registry_mutation=true

Directive to Opus

Patch the prompt to rev4 at:

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

Patch narrowly. Keep Phase 1B no-deploy scope. Do not dispatch after patch; return for GPT/User review.

Hard boundaries unchanged

• No deploy.
• No live route smoke.
• No Directus mutation.
• No PG mutation.
• No publish tbl_event_outbox.
• No change permission 1483.
• No change table_registry row 21.
• No add entity_type column.
• No fix tbl_modules_list.collection in this pack.
• No deep Nuxt redesign.
• No touch Families 2–8.
• No notification-specific UI.
• No manual hardcoded map edit without generator.
• No secret in code/log/report.
• No ad hoc package install.

Summary

Rev3 is close. Rev4 must close the env-export/runtime gap and avoid accidental URL/secret leakage. After that, the prompt should be close to dispatch approval.