GPT Review — G8B-Token Provisioning Prompt v0.2

Date: 2026-04-29

Verdict

CONDITIONALLY READY — patch to v0.3 required before User GO.

v0.2 fixed the major v0.1 issues: no TAC data writes, GSM primary, better secret handling, exact users, and read-only auth tests. However, token provisioning is a high-risk secret gate. Two remaining issues are blockers before execution.

Confirmed inputs

• G8B-RP read-only reverify: PASS.
• Index update is acceptable if it marks G8B-RP PASS, G8B-Token pending, full G8 pending, G11 pending.
• knowledge/other/specs/ai-agent-registry.md shows existing Directus agent token convention uses GSM and names like DIRECTUS_AGENT_XXX_TOKEN, with project github-chatgpt-ggcloud in examples.

Law / constitutional check

No conceptual blocker for G8B-Token, but v0.2 still violates Zero Trust in two places if dispatched unchanged.

• Hiến pháp / Zero Trust: token storage path/names/project must not be guessed.
• Secret hygiene: an active Directus token must never be created before the approved secret-storage path is proven.
• Điều 33 / PG SSOT: v0.2 correctly avoids TAC data writes.
• Điều 38 / Gate separation: aligned if token gate remains only users/tokens and no G11/migration.

Accepted improvements in v0.2

1. Removed all write/delete tests against tac_* data.
2. GSM is primary; no automatic VPS plaintext fallback.
3. Payloads use temp files instead of inline curl args.
4. Existing users are classified by exact target emails.
5. Tests are auth/read/deny focused and do not mutate TAC data.
6. G8B-RP prerequisite is clear.

Required v0.3 patches

Patch 1 — Do not guess GSM secret names/project

v0.2 uses tac-agent-token and tac-admin-token, but existing registry convention uses names like DIRECTUS_AGENT_XXX_TOKEN, and examples include project github-chatgpt-ggcloud.

v0.3 must explicitly resolve and verify the secret path before execution:

• Proposed names should follow existing convention, e.g.:
  • DIRECTUS_TAC_AGENT_TOKEN
  • DIRECTUS_TAC_ADMIN_TOKEN
• Verify or specify GCP project explicitly, likely github-chatgpt-ggcloud if that remains canonical.
• Confirm whether secrets already exist:
  • if exist → add new version only if token rotation is intended/authorized;
  • if absent → create then add version;
  • if project/path uncertain → STOP.
• Do not invent new lowercase secret names without User/GPT approval.

Patch 2 — Reorder storage vs Directus activation to avoid active untracked tokens

v0.2 creates Directus users/tokens first, then stores tokens in GSM. If GSM store fails after Directus user creation, active tokens may exist without approved storage.

v0.3 must use a safer sequence:

Preferred sequence:

1. Preflight GSM project/auth and secret names.
2. Generate tokens without logging.
3. Store token values in GSM first, or otherwise prove GSM write succeeds before tokens become active in Directus.
4. Create/PATCH Directus users to set tokens.
5. Auth-test tokens from GSM.

If storing before Directus activation is rejected because it creates unused secret versions on later Directus failure, the prompt must define exact compensation. But do not allow active Directus tokens with failed GSM storage.

Patch 3 — Stronger failure cleanup for users/tokens

v0.2 says cleanup users created by this run, but token PATCH/user creation partial states need explicit handling.

v0.3 should require:

• Track CREATED_BY_THIS_RUN user IDs.
• If user creation/PATCH fails after a token has been generated or stored, either:
  • delete only users created by this run; or
  • PATCH token to null / rotate to inert value if deletion is unsafe;
  • report any GSM secret version created but not activated.
• If auth test fails after tokens are active, STOP and report; do not auto-broaden permissions.

Patch 4 — API discovery must verify create/PATCH response safely

v0.2 still relies on response .data.token to determine whether token was set. Directus may omit token from responses for safety.

v0.3 should treat auth via /users/me using the GSM-stored token as the source of truth. Response token echo should not be required. If create-with-token returns 2xx but /users/me fails, use the predefined PATCH-token fallback once, then re-test. If still fails, cleanup/report.

Patch 5 — Password handling

Passwords are not used for API token workflow. v0.3 should either:

• use a random password generated inside a secure temp/node process and never logged; or
• explicitly set password only if Directus requires it for user creation.

Do not log password, do not keep password in payload files after use, and do not store password unless there is a defined need.

Non-blocking note

The negative tests using POST/DELETE that are expected to return 403 are acceptable because they should be denied before mutation. Still, post-check Gate C total=61 is required.

Directive to Opus 4.6

Patch G8B-Token v0.2 → v0.3 with the 5 required fixes above.

Do not execute yet. Return v0.3 for GPT final review.

No TAC data mutation, no automatic VPS fallback, no guessed GSM secret names, no G11, no Nuxt, no corpus migration.