The client called its gate "the DEV-PHASE gate (tool_gateway_admin)", which
reads as though Skill Sync is gated on an unrelated service's admin right.
It isn't. NAS populates that claim from Permissions.ADMIN_ACCESS — the global
portal admin permission that guards /admin/* — so the gate is "is this user a
Nous admin?". The claim is simply named for its first consumer, the tool
gateway.
Renamed on this side to say what it means, while keeping the wire string
(other services read it):
- DEV_GATE_CLAIM -> NOUS_ADMIN_CLAIM (value unchanged: "tool_gateway_admin",
with a comment recording why the wire name differs).
- identity/status key dev_gate_ok -> nous_admin, across the client, the CLI
consumers, and the tests.
- The module docstring now states where the claim comes from, that the wire
name is misleading, and that this gate is pre-launch containment rather
than the shipping entitlement — admin status conflates "may administer
Nous" with "has Skill Sync enabled" and has no middle setting for a beta
cohort. Choosing the real entitlement is left as a separate decision.
Naming only — no behaviour change, and no change to which accounts can sync.
The user-facing messages stay deliberately vague ("not enabled for your
account yet") rather than telling users they need portal admin.
Verified: 2346 passed / 0 failed across 56 suites via scripts/run_tests.sh;
`hermes sync status` against a live token reports "nous_admin": true. Zero
stale dev_gate_ok / DEV_GATE_CLAIM references remain.
Ben Barclay
f9c4d835f9