docs: settle hf permission introspection strategy

plans/harborforge-cli-go-plan.md

@@ -423,6 +423,54 @@ For leaf commands, this behaves the same as `--help`:
 
 ---
 
+## Permission Introspection Strategy
+
+The permission introspection strategy is now considered **decided**.
+
+### Normal command permission model
+
+For normal authenticated commands, the CLI should determine permissions through the authenticated user context derived from the token:
+
+1. resolve the current user from the token
+2. obtain the user's role
+3. obtain that role's permissions
+4. use those effective permissions to determine:
+   - `--help` output
+   - `--help-brief` output
+   - whether a subcommand is shown normally or marked `(not permitted)`
+
+This applies to normal command groups such as:
+- `user` (except `user create`)
+- `role`
+- `project`
+- `milestone`
+- `task`
+- `meeting`
+- `support`
+- `propose`
+- `monitor`
+
+### Special-flow exception: `hf user create`
+
+`hf user create` does **not** use the normal user-token permission model.
+It remains a special account-manager-token flow.
+
+That means:
+- normal permission introspection from the current user token should not be the gating mechanism for `hf user create`
+- `hf user create` help visibility should be handled independently of ordinary `user.write` capability
+
+### Backend implication
+
+Backend support for this strategy should ensure the CLI can derive:
+- current user identity
+- current user's role
+- current role permissions
+
+Whether this comes from one endpoint or multiple backend calls is an implementation detail.
+The strategy itself is settled: **token → user → role → permissions**.
+
+---
+
 ## Credential / Auth Rules
 
 ## Normal authenticated commands