GPT Review — G8B-Token Provisioning Prompt v0.3

Date: 2026-04-29

Verdict

NOT READY — patch to v0.4 required before User GO.

v0.3 is much improved and correctly verifies registry evidence before selecting GSM names/project. However, because this is a token/secret gate, remaining issues are still blocking under Zero Trust.

Confirmed good points

• GSM project and naming are now evidence-based, not guessed.
• Names are separated from AI-agent naming while following Directus token registry style:
  • DIRECTUS_TAC_AGENT_TOKEN
  • DIRECTUS_TAC_ADMIN_TOKEN
• GSM-first ordering is conceptually correct.
• No admin write test against TAC data remains.
• Tokens are tested from GSM read-back.
• Passwords are temporary and unset.

Blocking issues

Blocker 1 — Negative tests still send write/delete requests to production TAC endpoints

v0.3 says “KHÔNG write/delete vào bất kỳ tac_* table”, but still performs:

• POST /items/tac_lu_lifecycle_vocab using agent token;
• DELETE /items/tac_logical_unit/nonexistent-id using agent token.

Even if expected 403, these are write/delete method calls against production TAC endpoints. If permissions are wrong, the POST could mutate data. This violates the hard exclusion.

v0.4 must replace these with non-mutating verification.

Acceptable alternatives:

• rely on already verified G8B-RP 84-tuple matrix for deny proof;
• verify token role binding via /users/me and admin-read of role/policy/permissions;
• if an endpoint supports permission/introspection for current user without mutation, use that;
• otherwise skip runtime negative write tests and state deny behavior is proven by G8B-RP matrix, not by attempted writes.

Blocker 2 — GSM preflight creates/deletes a real test secret with ambiguous shell precedence

The current preflight command mixes || and &&:

echo -n "preflight-test" | gcloud secrets versions add ... || \
  gcloud secrets create ... && \
  echo -n "preflight-test" | gcloud secrets versions add ...

This is hard to audit and may add versions unexpectedly due to shell precedence. It also creates/deletes a real test secret as preflight.

v0.4 should make this deterministic and simpler:

• explicitly set GCP_PROJECT=github-chatgpt-ggcloud;
• verify gcloud secrets list / describe permission;
• for target secrets only, check existence and create if absent;
• verify write by adding the actual token version to the target secret, not by creating a separate throwaway secret;
• capture version IDs returned by GSM.

If a separate preflight secret is retained, use explicit if/else, not chained || &&, and log cleanup result.

Blocker 3 — GSM version compensation is not explicit enough

v0.3 stores tokens in GSM first. This avoids active untracked tokens, but creates the inverse risk: secret versions may exist for users that fail to activate in Directus.

v0.4 must track GSM version IDs created in this run and define compensation:

• if Directus user creation/token activation fails, disable or destroy the newly created GSM versions if supported and safe;
• otherwise log the exact orphan version IDs as inactive/unactivated and require GPT/User decision;
• do not claim PASS with orphan active secret versions not tied to Directus users.

Blocker 4 — User/token API discovery remains too shallow

v0.3 checks has("token") on a user shape and relies on registry evidence that PATCH works. It still does not verify whether create-with-token is accepted in this specific instance before creating both users.

v0.4 should define a deterministic execution pattern that avoids guessing:

• create user without token first, if Directus requires user creation;
• PATCH token afterward using the proven registry pattern;
• authenticate via /users/me with GSM-read token;
• no reliance on token echo in create response.

This is simpler and closer to known registry evidence than create-with-token.

Blocker 5 — Existing secret handling and rotation semantics need to be explicit

If DIRECTUS_TAC_AGENT_TOKEN or DIRECTUS_TAC_ADMIN_TOKEN already exists, v0.3 adds a new version without clearly stating that this is an authorized rotation.

v0.4 must classify:

• target secret absent → create then add first version;
• target secret exists but no TAC users exist → adding new version is allowed for this gate;
• target secret exists and TAC users already exist → STOP unless this run is explicitly a rotation;
• never overwrite or destroy existing versions without authorization.

Law / constitutional check

No conceptual conflict with G8B-Token after patch, but v0.3 still conflicts with hard Zero Trust / no-production-write-test principles if run unchanged.

• Hiến pháp / Zero Trust: not ready because write/delete method tests are still present and GSM flow is not deterministic enough.
• Điều 33 / PG SSOT: do not attempt production TAC writes in a token gate.
• Điều 38: token provisioning supports governed operation, but must not mutate knowledge/vocab truth data.
• Secret governance: token storage and version lifecycle must be auditable.

Directive to Opus 4.6

Patch G8B-Token v0.3 → v0.4 with the blockers above.

Key target design for v0.4:

1. No POST/DELETE/PATCH/PUT calls to any /items/tac_* endpoint. Runtime tests are read-only only.
2. Use G8B-RP matrix as the deny-permission proof; token gate proves identity/role/token binding and allowed reads.
3. Simplify Directus token flow: create users without token, then PATCH token using proven registry pattern, then auth-test from GSM.
4. Make GSM flow deterministic: target secrets, explicit existence check/create, add version, capture version IDs, read-back verify.
5. Define compensation for GSM versions if Directus activation fails.
6. Define exact behavior for pre-existing target secrets/users to avoid accidental rotation.

Return v0.4 for GPT final review. No Agent execution yet.