feat: profiles, skills, explain access and recent denials (phase c) #15

2026-10-13T19:10:52Z

KofTwentyTwo commented

2026-10-13 19:10:52 +00:00

(Migrated from github.com)

Owner (2026-10-13): "in the config for the AI settings, we should be able to set a name and personality and extra skills etc for the agent - and again - the agent should be limited to only using our UIUX API and being able to only do the things that the currently logged in user could do with the same UIUX API via the UIUX". The decisions are recorded in docs/DESIGN.md ("Owner decisions (2026-10-13)", item 4).

Profiles and skills (Assistant settings app: nav "Profiles", "Skills")

assistant_profile: display name, icon, personality (at most 2,000 chars), greeting and up to 6 starter prompts.
- One profile is the default. Others can be scoped to an app and/or a permission (a role), and the most specific one wins.
- Saving a profile as the default unmarks the others.
- /assistant/config returns profile to the panel.
assistant_skill: Markdown instruction packs (at most 6,000 chars each) with a description, an enabled flag, trigger keywords and apps.
- Skills are linked to profiles through assistant_profile_skill, a child list on the profile where admins can add links.
- A skill is read only when relevant, with at most 12,000 chars of skills per question.
The text goes into the per-user system block, framed as tone and know-how only. The new rule 10 says it never overrides the rules or grants tools, data or permissions. The prompt's rule 1 now describes confirmed writes.

Verify security and data access

Explain access: GET /qqq/v1/assistant/access?table=&prompt= and the new assistantAccess widget on the Assistant home show, per table and tool, whether it is allowed or why not (policy, data access, not visible, or no read/insert/edit/delete permission). The user's side comes from GET /qqq/v1/metaData made with their own session, so nothing is hard-coded.
Recent denials: a new card on the home lists who was refused, the table, and the UI API operation and HTTP status (or the assistant setting that refused it).
Explaining access for another user needs a core API that evaluates someone's permissions without their session. That part is documented as waiting on core. The assistant never builds or borrows a session.

Hard guarantee (enforced)

ArchUnit:
- tools, uiapi and access may not depend on QQQ table, process, reporting, dashboard or async actions, or on the core AI kernel.
- tools and uiapi may not use AssistantStore.
- The tool path may not touch the profile or skill classes.
- Only navigate and search_help (no records) stay on the kernel, and every toolbox operation is a spec'd v1 operation.
Runtime guard: AssistantStore refuses any table that is not assistant_*.
UiApiToolsSecurityTest.testDenialMatrix: for query, get, insert, update and delete, an analyst with no blog_post permission gets the identical status and message from the UI API directly and through the assistant (with READ_WRITE and confirmation off, so the UI API is what decides). Process row: there is no process or report tool, and every process's data access is NONE.
ProfilesSkillsAndAccessTest:
- persona and skill text reach the prompt;
- a skill that asks for deletes leaves the tool list unchanged;
- scope, default and bounds are validated;
- explain-access verdicts are correct for the editor, analyst and admin;
- the home shows the denial.

Gates

./mvnw verify is green, including checkstyle, JaCoCo and ArchUnit. The schema additions are in docs/schema-postgres.sql and UPGRADE.md.

🤖 Generated with Claude Code

Owner (2026-10-13): *"in the config for the AI settings, we should be able to set a name and personality and extra skills etc for the agent - and again - the agent should be limited to only using our UIUX API and being able to only do the things that the currently logged in user could do with the same UIUX API via the UIUX"*. The decisions are recorded in `docs/DESIGN.md` ("Owner decisions (2026-10-13)", item 4). ## Profiles and skills (Assistant settings app: nav "Profiles", "Skills") - **`assistant_profile`**: display name, icon, personality (at most 2,000 chars), greeting and up to 6 starter prompts. - One profile is the default. Others can be scoped to an app and/or a permission (a role), and the most specific one wins. - Saving a profile as the default unmarks the others. - `/assistant/config` returns `profile` to the panel. - **`assistant_skill`**: Markdown instruction packs (at most 6,000 chars each) with a description, an enabled flag, trigger keywords and apps. - Skills are linked to profiles through `assistant_profile_skill`, a child list on the profile where admins can add links. - A skill is read only when relevant, with at most 12,000 chars of skills per question. - The text goes into the per-user system block, framed as tone and know-how only. The new rule 10 says it never overrides the rules or grants tools, data or permissions. The prompt's rule 1 now describes confirmed writes. ## Verify security and data access - **Explain access:** `GET /qqq/v1/assistant/access?table=&prompt=` and the new `assistantAccess` widget on the Assistant home show, per table and tool, whether it is allowed or why not (policy, data access, not visible, or no read/insert/edit/delete permission). The user's side comes from `GET /qqq/v1/metaData` made with their own session, so nothing is hard-coded. - **Recent denials:** a new card on the home lists who was refused, the table, and the UI API operation and HTTP status (or the assistant setting that refused it). - Explaining access for *another* user needs a core API that evaluates someone's permissions without their session. That part is documented as waiting on core. The assistant never builds or borrows a session. ## Hard guarantee (enforced) - **ArchUnit:** - `tools`, `uiapi` and `access` may not depend on QQQ table, process, reporting, dashboard or async actions, or on the core AI kernel. - `tools` and `uiapi` may not use `AssistantStore`. - The tool path may not touch the profile or skill classes. - Only `navigate` and `search_help` (no records) stay on the kernel, and every toolbox operation is a spec'd v1 operation. - **Runtime guard:** `AssistantStore` refuses any table that is not `assistant_*`. - **`UiApiToolsSecurityTest.testDenialMatrix`:** for query, get, insert, update and delete, an analyst with no `blog_post` permission gets the identical status and message from the UI API directly and through the assistant (with READ_WRITE and confirmation off, so the UI API is what decides). Process row: there is no process or report tool, and every process's data access is NONE. - **`ProfilesSkillsAndAccessTest`:** - persona and skill text reach the prompt; - a skill that asks for deletes leaves the tool list unchanged; - scope, default and bounds are validated; - explain-access verdicts are correct for the editor, analyst and admin; - the home shows the denial. ## Gates `./mvnw verify` is green, including checkstyle, JaCoCo and ArchUnit. The schema additions are in `docs/schema-postgres.sql` and `UPGRADE.md`. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: QRun-IO/qbit-assistant#15