KB-DAA2

P9 G8B-Token Provisioning Log 2026-04-29 Run3 — STOP, email TLD validator rejects .local

7 min read Revision 1
dieu38p9g8b-tokentoken-provisioningstopvalidator-blockorphan-gsms186run3

P9 G8B-Token Provisioning Log — 2026-04-29 (Run 3)

Scope: G8B-Token v0.4 — Phase 2 (Phase 1 IAM grant + secrets pre-created by User) Executor: Claude Code via SSH contabo Result: STOP — canonical email domain .local rejected by Directus email validator Mutation status: 0 Directus users created. 0 token PATCH. 2 orphan GSM secret versions present (need User decision).


1. Pre-checks (PASS — unchanged from earlier this session)

HOST=vmi3080463
ADMIN_TOKEN=****d495 (read from /opt/incomex/docker/.env)
DIRECTUS_URL=http://172.18.0.4:8055 (container IP — host port 8055 not published)
GSM_ACCOUNT=cursor-ci-builder@github-chatgpt-ggcloud.iam.gserviceaccount.com
GSM_PROJECT=github-chatgpt-ggcloud
TAC_AGENT_ROLE_ID=8b7e0fb7-6b9d-4513-83a1-0d9dd7a7eb88
TAC_ADMIN_ROLE_ID=81a7571c-1cab-4978-8f36-bc9e1406c3b9
TAC_PERMISSIONS=84
Gate A: tables=14, fn=7, trg=6
Gate B: collections=14
Gate C: tac_total_rows=61
Pre-existing tac-agent@/tac-admin@ users: 0

GSM IAM diagnostic

The S186 grant roles/secretmanager.secretVersionManager is bound at the secret resource level, not project level. As a result:

  • secretmanager.secrets.get / secrets.list / secrets.describe at project scope: DENIED (not in resource-level grant scope as visible to caller)
  • secretmanager.versions.add / versions.access / versions.destroy on the two pre-created secrets: PASS (preflight test version 1 added, read back, then destroyed cleanly on DIRECTUS_TAC_AGENT_TOKEN)

This is functionally sufficient for G8B-Token: we don't need secrets.create (User pre-created), and we don't need project-level secrets.get. Step 2 (versions.add) ran successfully — see §2 below.


2. Execution — STOPPED at Step 3 (user create)

Step 1 — token generation: PASS

TAC_AGENT_TOKEN=****3a31 (in-memory)
TAC_ADMIN_TOKEN=****f7ec (in-memory)

Step 2 — GSM versions.add: PASS, read-back verified

GSM_VERSION=DIRECTUS_TAC_AGENT_TOKEN:v2
GSM_VERSION=DIRECTUS_TAC_ADMIN_TOKEN:v1
GSM_STORE_VERIFIED=PASS

Notes:

  • Agent token is on v2 because v1 was the preflight test version that was created+accessed+destroyed (clean) before this run.
  • Admin token is on v1 (no prior versions on that secret).

Step 3 — Directus user create: FAIL — email validator

First attempt (canonical payload from v0.4):

{"email":"tac-agent@incomex.local","password":"…","role":"…","status":"active"}
HTTP=400
errors:
  - field=provider type=required: "Validation failed for field \"provider\". Value is required."
  - field=text_direction type=required: "Validation failed for field \"text_direction\". Value is required."

This Directus instance enforces provider and text_direction at user-create time (not falling back to defaults). Retry added "provider":"default","text_direction":"ltr":

{"email":"tac-agent@incomex.local","password":"…","role":"…","status":"active","provider":"default","text_direction":"ltr"}
HTTP=400
errors:
  - field=email type=email: "Validation failed for field \"email\". Value has to be a valid email address."

Diagnostic — TLD validator behavior

Issued read-only diag creates with random local-parts at four TLDs, deleting any 200 user immediately:

incomex.local    -> FAILED_VALIDATION (.local rejected)
incomex.com      -> 200 (cleaned)
incomex.vn       -> 200 (cleaned)
incomex.internal -> FAILED_VALIDATION (.internal rejected)

This Directus instance's email validator rejects RFC-6762 reserved-use TLDs (.local, .internal). The G8B-Token v0.4 canonical names tac-agent@incomex.local / tac-admin@incomex.local therefore cannot be created without either:

  • Picking a different domain (e.g., incomex.vn matches the corp domain incomexsaigoncorp.vn; or .com)
  • Or relaxing the email validator (not advisable — global side-effect)

Diagnostic-created users were all deleted in the same loop; no residual users.


3. State after STOP

Directus users: 0 (canonical emails) — unchanged
Created+deleted diag users: 0 residual (all DELETEd inside the loop)
GSM versions:
  DIRECTUS_TAC_AGENT_TOKEN:v2 (ENABLED, holds ****3a31) — ORPHAN
  DIRECTUS_TAC_ADMIN_TOKEN:v1 (ENABLED, holds ****f7ec) — ORPHAN
Roles, policies, permissions: untouched
Gate A=14/7/6, B=14, C=61: unchanged

Per v0.4 §5 Failure handling: "Orphan GSM versions: ... Không tự disable/destroy — chờ GPT/User quyết định. Không claim PASS." Agent has not disabled or destroyed the orphan versions.


4. Decisions needed from User

4.1 Email domain decision

Please authorize one of:

Option Email Pros Cons
A tac-agent@incomex.vn / tac-admin@incomex.vn Matches existing corp TLD incomexsaigoncorp.vn; passes validator Departs from canonical .local — must update v0.4 prompt + registry
B tac-agent@tac.incomexsaigoncorp.vn / similar subdomain Most realistic / deliverable Same canonical change
C Pick another domain Same canonical change
D Disable Directus email validator Keeps .local Global validator weakening — not recommended

4.2 GSM orphan handling

Both versions hold valid 32-hex tokens that were never bound to Directus users. Two safe paths:

  • Reuse path: Once email decision is made, agent re-runs Step 3+4 only — reads existing latest tokens from GSM, creates the (re-named) users, PATCHes the same tokens. No new GSM versions, no token rotation. Recommended (simpler, same secret material remains current).
  • Rotate path: Agent destroys v2 (agent) + v1 (admin), generates new tokens, adds new versions, creates users, PATCHes. More churn but acceptable if any policy concern exists about an "abandoned" version.

Agent will not act on GSM orphans without explicit instruction.


5. Verdict

G8B-Token Run 3: STOP — validator block.

  • Phase 1 IAM grant + pre-created secrets: now functionally adequate (versions.add works).
  • Step 1 (gen) + Step 2 (GSM store + read-back): PASS.
  • Step 3 (user create): blocked by .local TLD validation in Directus.
  • No Directus mutation persisted. Roles/policies/permissions/Gate A/B/C unchanged.
  • Two GSM orphan versions present, untouched.
  • G8B-RP remains PASS. Full G8 still pending. G11 still pending.

STOP. Awaiting User decision on §4.1 (email domain) and §4.2 (orphan handling).


G8B-Token Run 3 | S186 | 2026-04-29 | STOP — email validator + orphan GSM

Back to Knowledge Hub knowledge/dev/laws/dieu38-trien-khai/reports/p9-g8b-token-provisioning-log-2026-04-29-run3.md