feat: starter defaults, setup card and table help (no empty config tables) #48

Merged
KofTwentyTwo merged 1 commits from feature/tables-populated-defaults into develop 2026-10-14 21:33:10 +00:00
KofTwentyTwo commented 2026-10-14 21:28:39 +00:00 (Migrated from github.com)

Owner requirement (2026-10-14): every qbit table should be populated and visibly used; an empty table should say what it is for and how to set it up.

Audit result (all 25 assistant tables)

Every table is already read or written by runtime code: budgets are enforced (BudgetService via ModelRouter/FallbackChain/PolicyService), skills reach the model through profiles (ProfileService.instructions in TurnEngine), prices feed per-call cost (ProviderService -> UsageRecorder), data access narrows every tool (DataAccessService), RAG sources and scheduled tasks have runners. The gap was that the config tables started empty, so nothing visibly happened and there was no guidance.

Changes

  • db/liquibase/qbit-assistant/assistant-defaults.changelog.sql (in the jar, host-included after the assistant DDL). Insert-only and self-guarding (INSERT ... SELECT ... WHERE NOT EXISTS + MARK_RAN preconditions), no secrets:
    • default policy row (only if the host has none): writes need confirmation, PII redaction, 50 rows per call
    • default profile (persona, greeting, starter prompts)
    • 4 starter skills (find-and-count, explain-a-record, safe-changes, access-questions) linked to the default profile
    • $50/month instance budget: warn 80%, downgrade 100%, stop 120%
    • Anthropic list prices (2026-10), adding fable-5, opus-4-7 and opus-4-6
    • disabled example scheduled task
  • Setup card on the Assistant home: each config area, its state (set up / needs setup / using defaults / optional) and the next step, linked to its table.
  • "Add rows for every table" action on assistant_data_access: writes the default access (READ, or NONE for sensitive tables) out as editable rows. It is a standard streamed ETL action and does not change behavior.
  • help/qbit-assistant.yaml (qqq#1198 bundle format): the app and every table get help saying what the table is for and how its rows get created. AssistantHelp applies it until core HelpBundles is in a pinned release (STAND-IN(core=#1198)).

Tests

  • AssistantTablesGuardrailTest: every assistant_* table must be (a) referenced by runtime code outside model, metadata and home, (b) seeded by the changelog or listed in STARTS_EMPTY with its reason, and (c) given help that says how its rows get created.
  • AssistantDefaultsChangelogTest: builds a fresh H2 (PostgreSQL mode) schema from docs/schema-postgres.sql. Running the changelog twice gives the same rows, edits survive, and an existing host policy is kept. The seeded rows drive the persona, the matching skill appears in the model request JSON of a real turn, the budget warns at 80%, and the policy is read.
  • AssistantSetupTest: Setup card states and rendering; the data-access action adds rows once and keeps existing ones.
  • ./mvnw verify: 268 tests, 0 failures, JaCoCo gate green.

Upgrade note

The budget is enforced from the next question. Hosts should check the $50 limit (see UPGRADE.md). kof22 values and the include line come in a separate Website-Backend PR.

Coordination: no overlap with #46 (indexes) or the durable-turns branch. This PR does not touch docs/schema-postgres.sql, TurnEngine, AssistantApi or AssistantQBitConfig.

🤖 Generated with Claude Code

Owner requirement (2026-10-14): every qbit table should be populated and visibly used; an empty table should say what it is for and how to set it up. ## Audit result (all 25 assistant tables) Every table is already read or written by runtime code: budgets are enforced (BudgetService via ModelRouter/FallbackChain/PolicyService), skills reach the model through profiles (ProfileService.instructions in TurnEngine), prices feed per-call cost (ProviderService -> UsageRecorder), data access narrows every tool (DataAccessService), RAG sources and scheduled tasks have runners. The gap was that the config tables started empty, so nothing visibly happened and there was no guidance. ## Changes - **`db/liquibase/qbit-assistant/assistant-defaults.changelog.sql`** (in the jar, host-included after the assistant DDL). Insert-only and self-guarding (`INSERT ... SELECT ... WHERE NOT EXISTS` + `MARK_RAN` preconditions), no secrets: - `default` policy row (only if the host has none): writes need confirmation, PII redaction, 50 rows per call - `default` profile (persona, greeting, starter prompts) - 4 starter skills (find-and-count, explain-a-record, safe-changes, access-questions) linked to the default profile - **$50/month instance budget**: warn 80%, downgrade 100%, stop 120% - Anthropic list prices (2026-10), adding fable-5, opus-4-7 and opus-4-6 - disabled example scheduled task - **Setup card** on the Assistant home: each config area, its state (set up / needs setup / using defaults / optional) and the next step, linked to its table. - **"Add rows for every table"** action on `assistant_data_access`: writes the default access (READ, or NONE for sensitive tables) out as editable rows. It is a standard streamed ETL action and does not change behavior. - **`help/qbit-assistant.yaml`** (qqq#1198 bundle format): the app and every table get help saying what the table is for and how its rows get created. `AssistantHelp` applies it until core `HelpBundles` is in a pinned release (`STAND-IN(core=#1198)`). ## Tests - `AssistantTablesGuardrailTest`: every `assistant_*` table must be (a) referenced by runtime code outside model, metadata and home, (b) seeded by the changelog or listed in `STARTS_EMPTY` with its reason, and (c) given help that says how its rows get created. - `AssistantDefaultsChangelogTest`: builds a fresh H2 (PostgreSQL mode) schema from `docs/schema-postgres.sql`. Running the changelog twice gives the same rows, edits survive, and an existing host policy is kept. The seeded rows drive the persona, the matching skill appears in the model request JSON of a real turn, the budget warns at 80%, and the policy is read. - `AssistantSetupTest`: Setup card states and rendering; the data-access action adds rows once and keeps existing ones. - `./mvnw verify`: 268 tests, 0 failures, JaCoCo gate green. ## Upgrade note The budget is enforced from the next question. Hosts should check the $50 limit (see UPGRADE.md). kof22 values and the include line come in a separate Website-Backend PR. Coordination: no overlap with #46 (indexes) or the durable-turns branch. This PR does not touch `docs/schema-postgres.sql`, TurnEngine, AssistantApi or AssistantQBitConfig. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
Sign in to join this conversation.