# NDC Core Assistant Access Policy

Status: draft source-evidenced slice.

This document defines assistant access as a thin policy overlay over the existing HUB/Launcher admin model. It does not replace Launcher roles, OPS Product permissions, Engine ACLs, or OPS Gateway grants.

## Roles

`assistant_blocked`

- no assistant icon;
- no assistant surface in HUB, OPS Product, ENGINE, or Gateway-mediated flows;
- no assistant capabilities.

`assistant_member`

- default for active users;
- matches the current personal assistant expectation;
- can use assistant in the user's allowed contexts;
- cannot manage users, invites, memberships, access requests, or other users' access.

`assistant_admin`

- enables assistant-mediated admin commands;
- works only when existing Launcher admin scope is present;
- never creates Launcher admin scope by itself;
- client admins stay inside their client scope;
- root-only backend operations stay root-only.

## Source-backed Launcher rules

Current HUB/Launcher source model has these authority inputs:

- `LauncherGlobalRole`: `root_admin`, `support_admin`, `client_owner`, `client_admin`, `member`;
- `LauncherUserStatus`: `invited`, `active`, `blocked`;
- `ClientMembershipRole`: `client_owner`, `client_admin`, `member`;
- `ClientMembershipStatus`: `active`, `disabled`.

Backend admin scope is source-backed by:

- root groups: `nodedc:superadmin`, `nodedc:launcher:admin`;
- active client admin membership: `client_owner` or `client_admin`;
- guard functions: `requireLauncherAdmin`, `requireRootLauncherAdmin`, `assertAdminCanManageClient`, `assertAdminCanManageUser`, `assertAdminCanManageAccessForUser`.

The important rule: `assistant_admin` can request only actions that the same user could already perform manually through Launcher admin endpoints.

## Practical first use case

The first useful implementation target is assistant-mediated access management:

- "block user X in Operational Core";
- "change user X to member/admin in this client";
- "show pending invites for today";
- "grant user X member access to this Operational Core workspace";
- "grant user X member/viewer access to this Operational Core project".

These are practical because Launcher already exposes equivalent manual flows in the admin overlay:

- MAIN status;
- MAIN role;
- service access matrix;
- Operational Core workspace/project memberships;
- invites;
- access requests.

## Hard denies

The assistant policy must keep these hard-deny rules:

- blocked assistant access hides all assistant UI and capabilities;
- blocked Launcher user means no effective assistant access;
- disabled membership removes context admin authority;
- `assistant_member` cannot administer users/access;
- `assistant_admin` does not bypass Launcher admin scope;
- protected `user_root` remains protected by source guards;
- Task Manager/Operational Core `admin` role is currently locked in Launcher mutation routes;
- root-only endpoints stay root-only.

## Planned HUB UI shape

The proposed Launcher admin UI addition is a column/control named `NDC Core Assistant`.

Initial values:

- `Blocked`;
- `Member`;
- `Admin`.

Recommended default:

- active ordinary users: `Member`;
- blocked users: effective `Blocked`;
- superadmin/root: effective `Admin`;
- explicit assignment should be stored later as assistant role assignment, not as a replacement for Launcher role.

## CLI checks

```text
npm run smoke:assistant-policy
npm run assistant:policy -- --input-json examples/assistant-access-member.example.json
npm run assistant:policy -- --input-json examples/assistant-access-admin-client.example.json
npm run assistant:policy -- --input-json examples/assistant-access-blocked.example.json
npm run assistant:policy -- --input-json examples/assistant-access-superadmin.example.json
```
