# Command Palette, Action Panel, Quick Actions & Help Center — Feature & Functionality Guide

**Purpose of this document:** a single, code-grounded source of truth for four related productivity
systems built into GB5's shared application shell, organized so sections can be lifted directly into
audience-specific deliverables — developer reference, implementation/config guide, admin guide,
end-user help, and marketing/sales collateral. Every claim below is grounded in the actual backend
(`GB5Framework/FrameworkBLL|FrameworkDAL|FrameworkSL`, `GB5Solution/Enablement`,
`GB5Solution/WorkInstruction`) and frontend (`gb4.7mfe/features/common/components/gbactionpanel`,
`features/gbmetaquickaction`, `features/common/components/gbcommandpalette`,
`features/gblayout/gbformaction`, `features/gbgrid`, `features/gblayout/gbreportaction`,
`projects/enablement`, `projects/devadmin/master/commandpanel`) code as of 2026-08-18. Sections
marked **[Internal only — not for marketing]** describe known gaps and should not appear in
customer-facing material. Checkboxes (`[x]`/`[ ]`) throughout §2 mark built-and-verified vs.
still-open items at a glance; §3.3 and §7 give the fuller detail behind every open item.

---

## 1. Executive Summary (marketing/sales-friendly)

GB5 ships four connected productivity systems that make every screen in the application faster to
use and easier to learn, without asking screen developers to write extra code:

- **Command Palette** — a keyboard-driven, searchable command launcher (the same UX pattern as VS
  Code's Ctrl+Shift+P or Slack's Ctrl+K), now fully database-driven and tenant-configurable rather
  than a fixed, hardcoded shortcut list.
- **Action Panel** — a contextual "what can I do here" panel that resolves a live, per-screen list of
  actions (open a related report, launch a related form, run a command, open a help topic) purely
  from configuration keyed to the screen, with zero code change required in the screen itself.
- **Quick Actions** — small, metadata-driven mini-forms that pop up from any screen's toolbar,
  grid row, or report to capture a focused piece of data (a note, a status change, an approval) and
  submit it immediately, without leaving the current screen or navigating to a full form.
- **Help Center** — contextual, in-the-moment help that draws on GB5's existing mature Content
  Management (CMS) and Enablement systems, and — uniquely — can surface a real, versioned Work
  Instruction (SOP) as help content, not just a static help article. One screen's help can show a
  concept explainer, an FAQ, a step-by-step guide, and Dos/Don'ts, all resolved automatically for
  that screen's context.

The standout architectural decision behind all four: rather than requiring every one of GB5's ~600+
CRUD screens to add code to participate, the mechanisms live **once**, inside the shared toolbar
components every screen already renders (`GbFormActionComponent`, `gbgrid`, the report viewer
toolbar) — the same proven pattern GB5 already uses for Attachments, About, Comments, and To-Dos.
A screen gets Quick Actions, contextual help, and a resolvable action list automatically, the moment
an admin configures data for that screen's Menu — no frontend deploy, no per-screen wiring.

---

## 2. Functional Area Catalog

### 2.1 Command Palette

- [x] A global, keyboard-invoked overlay (existing UX, now backed by real data) listing available
      commands, grouped into three categories: **General**, **Form** (screen/default actions), and
      **Report**.
- [x] Each command carries: display name, a single-character key binding plus modifier flags
      (Ctrl/Alt/Shift/Special), a description, a display/sort order, and an enabled/disabled flag.
- [x] Commands are fetched live from the backend (`Framework.CommandPanel.GetAll`) on app load; if
      the fetch fails or returns nothing, the palette **falls back to its original static shortcut
      list** — existing shortcuts (Ctrl+S, Alt+N, etc.) never break even if the backend is
      unreachable.
- [x] A dedicated **admin authoring screen** (MetaForm-based CRUD, no code needed to add/edit/disable
      a shortcut's binding, label, description, or ordering).
- [ ] No-code authoring of a *brand-new* command **behavior**. **[Internal only]** Adding a new row
      through the admin screen changes what's *displayed and how it's bound* — it does **not** by
      itself make the palette perform a new action. `ActionName` must match an existing `case` inside
      the palette's `executeCommand`/`handleKeyboardCommand` logic, which is compiled frontend code.
      Today, this system lets admins **re-label, re-bind, reorder, and enable/disable** existing
      developer-built commands from the database — it is not yet a no-code way to invent an entirely
      new command action. See §3.3 for what a developer must do to add a genuinely new command.

### 2.2 Action Panel

- [x] A contextual panel resolved per screen (keyed by `MenuId`) listing the actions relevant to that
      screen: open a related report, launch a related web form, run a named command, or jump to a
      related "Show" (see Help Center, §2.4).
- [x] Each configured action carries: label, icon, color, description, a comma-list of applicable
      screens, a channel tag, an action type (form / report / command / show), and — depending on
      type — the specific target (`EntityId`/`EntityName`, `ReportId`, `WebFormName`/
      `WebFormSecondURL`/`WebForm`, `Command`, `BizTransactionClassId`, `ModuleName`, `ListMenuId`,
      filter `Criteria`), plus a `Level` and sort order.
- [x] Actions are tenant-scoped (`TenantId`) and screen-scoped (`MenuId`, `-1` = global/every screen)
      — one action definition can apply to many screens, or just one.
- [x] Resolved through a single endpoint per screen (`GetActionsForScreen`) that returns **both** the
      screen's Actions and its Quick Actions in one call, so the toolbar only needs one round trip.
- [x] Previously entirely driven by a static frontend `config/admin.json` file — every action
      required a frontend code change and a deploy. Now fully database-driven; adding, hiding, or
      reordering an action for a screen is a data change, not a deploy.
- [x] **Admin authoring screen** — MetaForm-based CRUD (`projects/devadmin/master/actionpanel`,
      route `dev/action-panel`), backed by a new `GetAllActionPanel` endpoint. Live-verified: a real
      Save round-trip landed a row in `MACTIONPANEL` with the correct `TenantId`.
- [x] **`ActionType` numeric↔string mapping** — fixed 2026-08-19. **[Internal only]** this was a
      real, previously-undiscovered correctness gap, not just a documentation one:
      `gbactionpanel.component.ts`'s main navigational Action Panel (`getActions()`) was **still
      entirely driven by the static `config/admin.json` + Enablement Show actions only** — the
      backend `MACTIONPANEL` data fetched via `GetActionsForScreen` was being resolved by the three
      Quick-Action host locations but its `.Actions` half was silently discarded, never merged into
      the panel end users actually see. Fixed by (1) mapping `GetActionsForScreen`'s raw
      `ActionPanelDTO` rows into the frontend's `ActionDefinition` shape inside
      `gbactionpanel.service.ts` (including the `ActionType` tinyint→string mapping this item was
      originally about), and (2) merging that mapped list into `getActions()`'s existing
      static-config + Show-action result, keyed off the `formId` payload already carrying the
      screen's numeric `MenuId` (confirmed via `gbformaction.component.ts`'s
      `openActionPanel()`). Fails open to static-config-only behavior on any error, so no existing
      screen's Action Panel content can regress.

### 2.3 Quick Actions

- [x] Small, metadata-driven pop-up mini-forms (rendered by a shared `GbMetaQuickActionComponent`)
      launched from a screen's toolbar, a grid row's right-click menu, or a report's toolbar —
      without navigating away from the current screen.
- [x] Each Quick Action's field list is authored as JSON (`FieldsJSON`) and supports these field
      types out of the box: free text, number, date, textarea, checkbox, combobox/radio, and
      picklist (a lookup-backed choice field) — the same field-type vocabulary used elsewhere in
      GB5's metadata-driven forms, so no new authoring skill is required.
- [x] Submission posts to a configurable backend dot-code (`Api`, e.g. `Framework.Module.MethodName`)
      — the same convention used by every other GB5 API call — so a Quick Action can call into
      **any** existing save endpoint in the system, not just a purpose-built one.
- [x] Supports conditional visibility (`VisibleWhen`) — a real expression evaluated against the
      current form's live values (via GB5's shared rules-evaluation service), not a placeholder. A
      malformed expression fails open (the action stays visible) rather than silently hiding a valid
      action.
- [x] **Now self-contained in three shared host locations** — the standard form toolbar
      (`GbFormActionComponent`, reaching every `gbform` and `gbmetaform` screen with zero
      per-screen code), the grid's row context menu (`gbgrid`), and the report viewer toolbar
      (`gbreportaction`) — all three resolve and render Quick Actions the same way, purely from the
      screen's `MenuId`.
- [x] **`VisibleWhen` evaluation** — wired into `GbFormActionComponent` (evaluated against the
      screen's real reactive `FormGroup`, the same `FormDetails` instance `subscribeToFormChanges`
      already uses) and `gbgrid` (evaluated against the right-clicked row's data, wrapped in a
      throwaway `FormGroup` purely so the shared expression evaluator can read it — a grid row is
      plain data, not a reactive form). **`gbreportaction` is intentionally left unconditional** —
      its Quick Actions are report-wide, not tied to any single record, so there is no "current form
      values" for a visibility expression to evaluate against there; wiring it would require
      inventing a meaningless fake form. Both real hosts fail open (show the action) on a malformed
      expression, matching `gbmetaform`'s existing behavior.
- [x] **Admin authoring screen + `SaveQuickAction`/`DeleteQuickAction`/`GetAllQuickAction` endpoints**
      — MetaForm-based CRUD (`projects/devadmin/master/quickaction`, route `dev/quick-action`).
      Live-verified: a real Save round-trip landed a row in `MQUICKACTION` with the correct
      `TenantId`, confirmed via direct SQL, then cleaned up.

### 2.4 Help Center

- [x] Contextual, per-screen help — rather than a single flat "help article" field, GB5 reuses two
      mature, existing systems together:
  - **CMS** (`TCONTENT`/`MCONTENTTYPE`) for authored, versioned, tenant-definable content bodies
    (concept explainers, overviews, FAQs, Dos & Don'ts — any content type a tenant chooses to define).
  - **Enablement's "Show" system** (`TSHOW` + `TSHOWCONTENTLINK` + `TSHOWRULE`) for assembling an
    ordered set of content pieces into one help "topic" and resolving *which* topic applies to the
    current screen/context via a rules engine (by menu, module, screen, client level, and more).
- [x] A single help topic can mix **six different content link types** in one ordered list: internal
      CMS content, an external URL, a file, a video, a document, and — the standout capability — a
      live **Work Instruction** (a real, versioned SOP/procedure from GB5's WorkInstruction module,
      complete with its own step-by-step structure), each renderable inline, in a side panel, in a
      new tab, or as a download, per link.
- [x] A help topic can be one of 14 distinct natures (Feature Tour, Announcement, Checklist, Banner,
      Micro-Lesson, Tips, News Item, Alert, Maintenance Notice, Knowledge Article, Portal Notice,
      Assessment, Work Instruction, and more) — the same taxonomy already used for GB5's broader
      in-app enablement/onboarding messaging, so Help Center content sits inside the same authoring
      system as product tours and announcements rather than a separate silo.
- [x] Wired into three real touchpoints: the previously-dead "Help" item in every screen's toolbar
      settings menu (`GbFormActionComponent`), the Action Panel's help box, and the IT Service Desk
      self-service dashboard (replacing what used to be a hardcoded static FAQ object).
- [x] All three touchpoints share one resolution helper (`getHelpContentForScreen`) so content
      targeting logic lives in exactly one place.
- [x] The Work-Instruction link type refreshes the linked WI's live title via
      `IWiMasterBLL.GetWiById`.
- [x] **`Show`/`ShowContentLink`/`ShowRule` screens wired to a menu/route** — added `showcontentlink`
      and `showrule` routes in `gbhost/src/app/app.routes.ts`, alongside the existing `show`/
      `showlist`. Both components need the same `MenuRights`/`selectedId`/`DrillDownDetails`
      injection tokens `GbTabContainerComponent` normally supplies from live menu navigation;
      supplied via route-level `providers` with a synthetic `MenuId: -1` sentinel (confirmed these
      components only use `MenuId` to build a local tab/draft-tracking key, not for any
      `MenuId`-keyed backend resolution, so a synthetic value is safe — unlike a real `gbform`
      screen). **[Internal only]** this route couldn't be live-browser-verified: `gbhost`'s dev
      build is blocked by a pre-existing, unrelated compile error in
      `projects/skillmanagement/master/workinstruction/workinstruction.component.ts` (calls
      `WorkInstructionService.SectionDelete`/`StepDelete`, which don't exist on that service) — out
      of scope for this work. The route mirrors the exact working pattern already proven live for
      `dev/currency-formaction-harness`, but treat as code-reviewed, not click-tested, until
      `gbhost` builds cleanly.
- [x] **`CK_TSHOW_SHOWNATURE` check constraint widened** — was `SHOWNATURE IN (0,1,2,3,4,5)`, now
      `SHOWNATURE BETWEEN 0 AND 13` (migration `V010__ShowNature_Constraint_Widen.sql`, applied to
      GB5DEMO). Verified directly: an insert with `SHOWNATURE = 13` (Work Instruction) no longer
      hits this constraint — the next error it hits is unrelated pre-existing schema gaps
      (`SPACEID`/`DISPLAYNAME`/`MODULEID` NOT NULL requirements, likely from concurrent, unrelated
      ShowSpace work also landing on GB5DEMO this week), confirming this specific fix is correct and
      isolating what's actually still blocking a full `SaveShow` round-trip (not this constraint).

---

## 3. For Developers

### 3.1 Backend layout
- `GB5Framework/FrameworkDAL/DTO|Query/{ActionPanel,CommandPanel}`, `FrameworkBLL/{ActionPanel,CommandPanel}`,
  `FrameworkSL/Endpoints/{ActionPanel,CommandPanel}` — standard GB5 3-tier module, hosted in the main
  Framework service.
- Tables: `MACTIONPANEL`, `MQUICKACTION`, `MCOMMANDPANEL` (migration:
  `DB/Migrations/20260816_ActionPanel_CommandPanel_Schema.sql`), all tenant-scoped
  (`TenantId`) with `AutoNumber`-backed IDs (entity codes `ActionPanel`/`QuickAction`/`CommandPanel`).
- Help Center backend changes live in `GB5Solution/Enablement/EnablementBLL/ShowContentLink` (added a
  `WorkInstruction` link-type resolution path that calls `IWiMasterBLL.GetWiById` to refresh a linked
  WI's live title) — no new tables were added for Help Center; it is entirely a reuse of existing
  `TSHOW*` and `TCONTENT` infrastructure.

### 3.2 Frontend layout
- Shared runtime components: `features/common/components/gbactionpanel` (Action Panel display +
  `ActionService`), `features/gbmetaquickaction` (Quick Action popup renderer),
  `features/common/components/gbcommandpalette`.
- Host integration points (where these are wired into every screen):
  `features/gblayout/gbformaction/formactionbar/gbformaction.component.ts` (forms),
  `features/gbgrid/gbgrid.component.ts` (grids),
  `features/gblayout/gbreportaction/reportactionscreen/gbreportaction.component.ts` (reports).
- Command Palette admin screen: `projects/devadmin/master/commandpanel` + metadata schema
  `projects/devadmin/public/metaform/commandpanel.meta.json`.
- Action Panel admin screen: `projects/devadmin/master/actionpanel` (route `dev/action-panel`) —
  built on `GBBaseFormGroup`, not `gb-metaform`; its schema is the legacy `ObjectFields`-shaped
  `projects/devadmin/public/formjson/actionpanel.json`, not a `.meta.json` file (a leftover, unused
  `projects/framework/public/metaform/actionpanel.meta.json` predates this rework).
- Quick Action admin screen: `projects/devadmin/master/quickaction` + metadata schema
  `projects/devadmin/public/metaform/quickaction.meta.json` (route `dev/quick-action`).
- API registry entries: `projects/gbhost/public/api/gb5api/framework.ts` (`Framework.ActionPanel.*`
  incl. `.GetAll`, `Framework.QuickAction.*`, `Framework.CommandPanel.*`),
  `projects/gbhost/public/api/gb5api/enablement.ts` (`Enablement.Resolver.Resolve`).

### 3.3 Remaining completion work (for the feature developer)

**Update 2026-08-19: items 1, 2, 3 (partially), 4, 6, and 7 below are now done** — see the ~~struck~~
entries and §2's checkboxes for what changed and how it was verified. Ordered roughly by
leverage/impact; §7's gap table is the status view of the same items.

1. ~~**Action Panel admin authoring screen.**~~ **Done.** `projects/devadmin/master/actionpanel`
   (route `dev/action-panel`), backed by a new `GetAllActionPanel` endpoint. Live-verified Save
   round-trip on GB5DEMO.
2. ~~**Quick Action admin authoring screen + save endpoints.**~~ **Done.**
   `SaveQuickAction`/`DeleteQuickAction`/`GetAllQuickAction`/`GetQuickAction` added
   (`FrameworkSL/Endpoints/QuickAction`), `MEVENTTYPE` seed rows added
   (`DB/Migrations/20260819_QuickAction_EventType_Seed.sql`), admin screen at
   `projects/devadmin/master/quickaction` (route `dev/quick-action`). Live-verified Save round-trip
   on GB5DEMO. **[Internal only]** hit — and fixed — a stale-deploy trap along the way: the
   deployed `GB5Shared.dll` on GB5DEMO predated the new `WebServiceConstant` entries this needed;
   the fix required redeploying `GB5Shared.dll` itself, not just `FrameworkDAL/BLL/SL` — a distinct
   assembly from the ones this session had been redeploying, easy to forget.
3. ~~**Wire `VisibleWhen` into the three newer Quick Action hosts.**~~ **Done for
   `GbFormActionComponent` and `gbgrid`** — evaluated against a real `FormGroup`
   (`gbformaction`) or a synthesized one wrapping the selected row (`gbgrid`).
   **Deliberately NOT done for `gbreportaction`** — its Quick Actions are report-wide, not tied to
   any single record, so there is no live form-values context for the expression to evaluate
   against; see the code comment left in `gbreportaction.component.ts` explaining this rather than
   inventing a meaningless fake form.
   backend `tinyint` (`1=form, 2=report, 3=command, 4=show`); the frontend's
   `ActionDefinition.actionType` is a string union (`"form"|"report"|"command"|"show"`). Turned out
   this mapping didn't exist **anywhere** — which meant `gbactionpanel.component.ts`'s main
   navigational Action Panel was still 100% static-config-driven despite the backend being built;
   fixed by adding the mapping in `gbactionpanel.service.ts` and merging the mapped result into
   `getActions()`. See §2.2 for the full explanation — this is the most consequential fix in this
   pass.
5. **Command Palette — new-command authoring path.** Still open. Today the admin screen can only
   re-label/re-bind/reorder/enable-disable *existing* developer-built commands; `ActionName` must
   match a compiled `case` in `executeCommand`/`handleKeyboardCommand`. Adding a genuinely new
   command still requires a frontend code change. A future improvement: let `ActionName`
   reference a dot-code API call directly (like Quick Actions do) for full data-driven authoring —
   not attempted this pass, since it changes the palette's core dispatch mechanism and deserves its
   own focused review rather than being folded into a gap-fixing pass.
6. ~~**Wire `ShowContentLink`/`ShowRule` screens to a menu/route.**~~ **Done** —
   `gbhost/src/app/app.routes.ts` now has `showcontentlink`/`showrule` routes with synthetic
   `MenuRights` providers (see §2.4). Not yet click-tested — `gbhost`'s dev build is blocked by an
   unrelated pre-existing compile error (see §2.4/§7).
7. ~~**Fix the `CK_TSHOW_SHOWNATURE` constraint drift.**~~ **Done** — widened to `BETWEEN 0 AND 13`
   via `V010__ShowNature_Constraint_Widen.sql`, applied to GB5DEMO, verified directly (see §2.4).
8. **Complete browser verification.** Partially done this pass: Action Panel and Quick Action admin
   screens both live-verified (real Save round-trips, DB-confirmed, cleaned up). Still open: Quick
   Actions on `gbgrid`/`gbreportaction` haven't been click-tested against a real grid/report screen
   (only code-reviewed); the `showcontentlink`/`showrule` routes haven't been click-tested (blocked
   on the unrelated `gbhost` build error); and the full Show → ShowContentLink → Help-button
   round-trip is still blocked — no longer by the constraint (item 7, now fixed), but by other
   pre-existing NOT NULL gaps on `TSHOW` (`SPACEID`/`DISPLAYNAME`/`MODULEID`) surfaced once the
   constraint stopped being the first blocker; likely related to concurrent, unrelated ShowSpace
   work also landing on GB5DEMO this week, not something to fix as part of this item.
9. ~~**Observability.**~~ **Done** — `SaveQuickAction`/`DeleteQuickAction` follow the same
   `GB5Trace.Step`/`EventLogPublish` pattern as ActionPanel Save/Delete, with their own
   `MEVENTTYPE` seed rows.

### 3.4 How other developers & metadata admins put these to use today

**Command Palette**
- To re-label, re-bind, reorder, or enable/disable an existing shortcut: use the Command Panel
  admin screen (`projects/devadmin/master/commandpanel`, metadata schema
  `projects/devadmin/public/metaform/commandpanel.meta.json`) — no code, no deploy.
- To add a genuinely new command behavior: add a `case` in `gbcommandpalette.component.ts`'s
  `executeCommand`/`handleKeyboardCommand`, then expose it via the admin screen for
  re-binding/labeling (see 3.3 item 5 — still open).

**Action Panel**
- Use the Action Panel admin screen (`projects/devadmin/master/actionpanel`, route
  `dev/action-panel`) — no code, no deploy. Set `MenuId = -1` for a global (every-screen) action, or
  a specific `MenuId` to scope it to one screen. Pick `ActionType` (Form/Report/Command/Show) and
  populate only the target field(s) relevant to that type (the "Target" page/section groups
  these).
- Screens automatically pick up new/changed Action Panel entries via `GetActionsForScreen` — no
  frontend change needed once data exists, and as of this pass the entries genuinely reach the
  visible Action Panel, not just the Quick Actions toolbar buttons.

**Quick Actions**
- Use the Quick Action admin screen (`projects/devadmin/master/quickaction`, route
  `dev/quick-action`) — no code, no deploy. Author `FieldsJson` using GB5's standard metadata-form
  field-type vocabulary (text, number, date, textarea, checkbox, combobox/radio, picklist).
- Set `Api` to any existing dot-code endpoint (`Module.MethodName`) the Quick Action should submit
  to — reuse an existing save endpoint rather than building a new one where possible.
- Author `VisibleWhen` as a real expression against the form's live field values — this now
  evaluates correctly in the form toolbar and grid row menu; the report toolbar intentionally
  ignores it (see 3.3 item 3 — no per-record context there to evaluate against).
- A Quick Action automatically appears in all three host locations (form toolbar, grid row menu,
  report toolbar) purely from the screen's `MenuId` — no per-host wiring needed.

**Help Center**
- Author CMS content bodies via GB5's existing CMS admin screens (`TCONTENT`/`MCONTENTTYPE`).
- Create a topic's identity via the routed `Show` admin screen (`/show`, `/showlist`) — nature
  (including `WORK_INSTRUCTION`, now that the constraint is fixed), scheduling, etc.
- Assemble that topic's content links (including linking a Work Instruction) via the now-routed
  `showcontentlink` screen, and define targeting rules via the now-routed `showrule` screen (3.3
  item 6) — both reachable without a developer, though not yet click-tested (see §2.4/§7).
- To surface a Work Instruction as help content: link it via `ShowContentLink`'s WorkInstruction
  link type; the title stays live-synced via `IWiMasterBLL.GetWiById`.

---

## 4. For Implementers / Admins — What's Configurable

**Configurable today through an admin UI, no code/deploy needed:**
- Command Palette: every shortcut's category, label, key binding, description, order, and
  enabled/disabled state (via the Command Panel admin screen).
- **Action Panel entries** (`dev/action-panel`) and **Quick Action definitions** (`dev/quick-action`)
  — both now have real MetaForm CRUD screens, as of 2026-08-19.
- Help Center: any `Show` topic's identity, nature (all 14 values, including `WORK_INSTRUCTION`,
  now that the constraint is fixed), and scheduling (via the routed `Show` admin screen at
  `/show`/`/showlist`); its content links and targeting rules (via the newly-routed
  `showcontentlink`/`showrule` screens — see the not-yet-click-tested caveat below); CMS content
  bodies (via GB5's existing, separately-documented CMS admin screens).

**Not yet reachable by a non-technical admin, or not yet fully verified:**
- **Command Palette new command *behaviors*** — the admin screen only re-labels/re-binds/reorders
  *existing* developer-built commands; a genuinely new command action still requires a frontend
  code change (§3.3 item 5).
- **`showcontentlink`/`showrule` routes** — wired and code-reviewed, but not yet click-tested in a
  browser: `gbhost`'s dev build is currently blocked by an unrelated pre-existing compile error in
  `projects/skillmanagement`. Confirm `gbhost` builds cleanly before treating these as production-
  ready, even though the routing itself mirrors an already-proven working pattern.
- **Full Show → ShowContentLink → Help-button round-trip** — no longer blocked by the
  `SHOWNATURE` constraint (fixed), but still blocked by other pre-existing `TSHOW` NOT NULL columns
  (`SPACEID`/`DISPLAYNAME`/`MODULEID`) surfaced once that constraint stopped being the first
  blocker — likely tied to concurrent, unrelated ShowSpace work also landing on GB5DEMO this week.

**Hardcoded (not admin-configurable via UI):** the palette's actual command *behaviors* (§3.3 item
5), the `ActionType`/`LinkType`/`ShowNature` taxonomies themselves (code-level constants — new
*values* of these enums require a developer), and the Quick Action field-type vocabulary
(text/number/date/textarea/checkbox/combobox/picklist — adding a new field-type renderer is a
developer task in `gbmetaquickaction.component.ts`).

**Rollout checklist for a new client/tenant wanting these systems:**
1. Confirm Command Panel rows exist/are seeded for this tenant (or copy from a template tenant).
2. Configure Action Panel entries directly via the `dev/action-panel` admin screen — no engineering
   hand-off needed.
3. Configure Quick Actions directly via the `dev/quick-action` admin screen — provide field lists
   (`FieldsJson`) and target API dot-codes; no engineering hand-off needed.
4. For Help Center: author CMS content first, then create `Show` topics and assemble their content
   links/rules via the routed screens — confirm `gbhost` builds cleanly in your environment first
   (see the caveat above) before relying on `showcontentlink`/`showrule` in a live rollout.
5. If a Work Instruction needs to appear as help content, confirm the WI itself is authored and
   versioned in the WorkInstruction module before linking it.
6. Communicate clearly to the client which pieces are fully click-tested vs. code-reviewed-only
   today (see the "not yet reachable / not yet fully verified" list above) so expectations match
   reality.

---

## 5. For End Users — Roles & Journeys

- **Command Palette**: press the configured shortcut (default keybindings unless a tenant admin
  has changed them) to open a searchable command list; type to filter; select or use the item's
  key binding to run it instantly, without touching the mouse.
- **Action Panel**: open it from any screen's toolbar to see a curated list of what's possible
  right here — related reports to view, related forms to launch, commands to run, or help topics
  to open — without hunting through menus.
- **Quick Actions**: from a screen's toolbar, a grid row's context menu, or a report's toolbar,
  open a Quick Action to log a note, change a status, or capture a small piece of data in a popup,
  then submit — no need to leave the current screen or open a full form. Only the Quick Actions
  relevant to the current screen appear (and, in the original form host, only ones whose
  visibility condition currently holds).
- **Help**: click Help from the toolbar, from the Action Panel's help box, or from the IT Service
  Desk self-service dashboard to see guidance specific to exactly the screen in view — this may be
  a short explainer, an FAQ, a Dos & Don'ts list, or a real step-by-step Work Instruction,
  depending on what's been configured for that screen.
- **Power users**: rely on Command Palette keyboard shortcuts as their primary navigation method
  once familiar with the system, rather than mouse-driven menu navigation.

---

## 6. For Marketing / Sales

**Lead with what's real, working, and differentiated:**
- **Zero-code screen enablement.** Every one of GB5's ~600+ existing forms and every grid and report
  gets contextual actions, quick data-entry popups, and contextual help automatically — the moment an
  admin configures data for that screen, with no frontend deploy and no per-screen developer work.
  This is a direct, quantifiable implementation-speed and total-cost-of-ownership advantage over
  competitors whose equivalent panels require code changes per screen.
- **Help Center reuses your existing content investment.** Rather than a bolt-on help-article system
  that becomes yet another content silo to maintain, GB5's Help Center is built directly on top of the
  same CMS and Enablement platform already used for in-app tours, announcements, and onboarding — so
  a company's investment in one enriches the other.
- **A real Work Instruction can BE the help content.** Uniquely, contextual help can surface a live,
  versioned, step-by-step Work Instruction/SOP — not just a static article — closing the gap between
  "here's some help text" and "here's the actual procedure our own operations team follows,"
  including any skill-eligibility gating already configured on that Work Instruction.
- **A keyboard-driven Command Palette** (the same category of feature power users expect from
  best-in-class developer tools like VS Code and Slack) is fully tenant-configurable, not fixed by
  the vendor.

**Now also true as of 2026-08-19** (previously listed as not-yet-promised, now safe to lead with):
- Fully self-service, no-code authoring of Action Panel entries and Quick Action definitions — both
  have real admin screens now (moved into the dedicated DevAdmin portal on 2026-09-05, see §7).
- The full 14-value ShowNature taxonomy (including Work Instruction) is usable — the schema
  constraint that blocked it is fixed.

**Now also true as of 2026-09-05** (previously listed as not-yet-promised, now safe to lead with):
- A complete, click-tested Help Center authoring flow including Work Instruction linking —
  `showcontentlink`/`showrule` are routed and click-tested working, and the full Show →
  ShowContentLink → WI round-trip is confirmed end-to-end (see §7).

**Do not yet promise** (see §7 for exact current status of each):
- Fully self-service, no-code authoring of brand-new Command Palette command *behaviors*.
- Conditional (rules-based) Quick Action visibility everywhere — guaranteed today in the form
  toolbar and grid row menu; the report toolbar's Quick Actions are report-wide and don't have a
  per-record condition to evaluate by design, not as a gap.
- A fully click-tested `gb-grid` right-click Quick Actions interaction, or any Quick Actions
  click-test on `gbreportaction` — neither has a live production screen exercising it yet (see §7).

---

## 7. Known Gaps / Roadmap Items — [Internal only, not for marketing]

| Area | Status |
|---|---|
| ~~Action Panel admin authoring screen~~ | **Fixed 2026-08-19.** `dev/action-panel`, backed by a new `GetAllActionPanel` endpoint. Live-verified Save round-trip on GB5DEMO. |
| ~~Quick Action admin authoring screen~~ | **Fixed 2026-08-19.** Full CRUD added (`SaveQuickAction`/`DeleteQuickAction`/`GetAllQuickAction`/`GetQuickAction`), admin screen at `dev/quick-action`. Live-verified Save round-trip on GB5DEMO. |
| ~~Action Panel/Quick Action/Command Panel admin screens lived in a throwaway `framework` project `dev/*` route~~ | **Moved 2026-09-05.** These are DevAdmin-tier configuration screens (no MMENU/MROLEVSMENU wiring, unlike end-user ERP screens), so they belong in the dedicated `projects/devadmin` portal, not `framework`'s dev-only routes. Moved to `dev/action-panel`/`dev/quick-action`/`dev/command-panel` in `projects/devadmin`. Surfaced and fixed two real bugs along the way: (1) `devadmin`'s `angular.json` esbuild config shipped with `assets: []` — not even mirroring its own `public/` folder — so every formjson/metaform asset 404'd when served standalone; added the base `public/` glob and the dev-mode `formjson-modules` mirror, matching `gbhost`'s existing config. (2) `ActionPanelAdminComponent` used a plain `OnPush` field (`rows`/`selectedId`) mutated from inside a raw `.subscribe()` callback, so the grid never re-rendered after save/delete without an unrelated change-detection trigger firing elsewhere in the app — a real admin would see an empty grid with no indication anything was wrong. Converted both to `signal()`, matching the pattern already used by the sibling QuickAction/CommandPanel components. All three routes live-verified end-to-end post-move: render correctly, and Action Panel's save+delete round-trip confirmed via real network response bodies (`Status:200` both ways) with the grid updating immediately, no manual intervention. |
| ~~`VisibleWhen` conditional visibility outside `gbmetaform`~~ | **Fixed for `GbFormActionComponent`/`gbgrid` 2026-08-19** (real FormGroup / synthesized-from-row-data FormGroup, respectively). **Deliberately left unconditional for `gbreportaction`** — its Quick Actions are report-wide with no per-record context to evaluate a visibility expression against; see the code comment in `gbreportaction.component.ts`. |
| ~~Action Panel `ActionType` numeric↔string mapping~~ | **Fixed 2026-08-19 — and was a bigger fix than the name suggests.** Fixing this surfaced that `gbactionpanel.component.ts`'s main navigational Action Panel had been 100% static-`config/admin.json`-driven all along; the backend `MACTIONPANEL` data was fetched but silently discarded. Now genuinely merged in, with graceful fail-open to static-config-only on any error. |
| Command Palette new-action authoring | **Still open.** Admin screen can re-label/re-bind/reorder/disable existing commands only; a genuinely new command action still requires a frontend code change (`executeCommand`/`handleKeyboardCommand`). Not attempted this pass — deserves its own focused review, not a gap-fixing-pass add-on. |
| ~~`ShowContentLink`/`ShowRule` admin screens~~ | **Routed 2026-08-19, click-tested working 2026-09-05.** `gbhost`'s `skillmanagement` compile error that blocked verification has since been fixed by someone else (that file path no longer exists — it's been restructured); confirmed by live-testing both routes against a running `gbhost` instance: `showrule` renders its full Resolver Rules UI (rule counts, Add Rule, etc.) with zero console errors; `showcontentlink` renders its form + toolbar with zero errors (its content grid is legitimately empty until a Show is picked via the picklist — expected, not a bug). Both fully working. |
| ~~`CK_TSHOW_SHOWNATURE` constraint (0–5 vs 14 enum values)~~ | **Fixed 2026-08-19.** Widened to `BETWEEN 0 AND 13` (`V010__ShowNature_Constraint_Widen.sql`), applied to GB5DEMO, verified directly — an insert with `SHOWNATURE=13` (Work Instruction) no longer hits this constraint. |
| ~~Full Show → ShowContentLink → WI round-trip~~ | **Confirmed working end-to-end 2026-09-05.** The real `SaveShow` BLL path does supply `SpaceId`/`DisplayName`/`ModuleId` itself (confirmed in `show.component.ts`), sidestepping the raw-SQL NOT NULL issue entirely — a real `ShowNature=13` Show already existed on GB5DEMO (`ShowId=14`, created via the actual UI), proving this. Completed the verification by linking it to a real Work Instruction via `SaveShowContentLink` (`LinkType=6`), then confirmed `GetShowContentLinkList` correctly live-resolves the WI's current title (`"Show Player Verification WI"`) rather than a stale stored value. **Found and fixed a real, separate production bug along the way** — see the new row below; every `ShowContentLink` endpoint was silently returning 404 until that fix. The one remaining piece (a `ShowRule` actually targeting this Show, so `ResolveShowMatches`/the Help button would surface it) is normal authoring work, not a gap — Shows need a rule to be targeted anywhere, by design. |
| ~~**NEW: `IQuizBLL` cross-host DI gap silently broke all `ShowContentLink` endpoints**~~ | **Found and fixed 2026-09-05, live-verified.** Someone added `LinkType=8` (Quiz) support to `ShowContentLinkBLL` (injecting `TMSBLL.Quiz.IQuizBLL`) without registering it in `EnablementModule.Register()` — the same cross-host pattern already documented and correctly handled for `LinkType=7`/Training right above it, just missed for Quiz. This didn't crash `gb5-engagementhost` (its `/health` endpoint + `ModuleLoader` DI pre-flight check catches unresolvable endpoints and excludes just them from routing instead of crash-looping the whole process) but silently 404'd `SaveShowContentLink`/`GetShowContentLink`/`GetShowContentLinkList`/`DeleteShowContentLink` — confirmed via `/health`'s `Excluded` list, which named the exact resolution failure. Fixed by registering `IQuizDAL`/`IQuizBLL` the same way `ITrainingProgrammeSessionTopicDAL`/`BLL` already were. **Deploy note for future reference**: the first deploy attempt (built from a locally-stale checkout, ~10 commits behind `origin/dev`) crash-looped the whole host with an unrelated-looking `NSwag.AspNetCore` `FileNotFoundException` on startup — root-caused to the local build being out of sync with the actually-deployed dependency graph, not a real code or file-transfer issue (MD5-verified transfer was intact). Rebuilding from a freshly-rebased-onto-`origin/dev` tree resolved it; redeployed and confirmed stable. |
| gbgrid Quick Actions browser click-test | **Partially resolved 2026-09-05 — with an important correction.** `GbGridComponent` (`<gb-grid>`) turns out to have **zero real callers anywhere in this monorepo** — independently confirmed by `admin/entitlement/audit/audit.component.ts`'s own code comment explaining why it deliberately avoids `gb-grid` — so there was never a live screen to click-test this against, and the doc's earlier claim that gbgrid is "already used by every list/report screen" was aspirational, not verified fact. It also wasn't even compiling: `Rowservice`'s signature had gained a required `drilldown` parameter that this file's one call site was never updated for (fixed to match the identical, already-updated call in `gbslickgrid.component.ts`). Built a verification-only harness (`dev/gbgrid-harness` in the `framework` project) and confirmed the core previously-unproven integration point live: `GetActionsForScreen` correctly resolves a real `MQUICKACTION` row keyed to the grid's `MenuId` (confirmed via network log). Full right-click→button-render interaction wasn't achieved in this automated pass — plausibly related to a separate, real `AG Grid: you are mixing modules and packages` console warning surfaced during testing, not a Quick Actions defect; worth a manual click-through once someone actually wires `gb-grid` into a real screen. **Report viewer** Quick Actions (`gbreportaction`, a genuinely live, used component) remain untested — still open, no evidence anyone has done this either. |
| Action Panel admin screen — real breakage found and fixed | **New finding, fixed 2026-09-05.** A teammate's rework (switching the screen from `gb-metaform` to a hand-rolled `GBBaseFormGroup` form) left it completely non-functional for ~1 day: mock hardcoded list data, detail form commented out, no Save method. Root causes: (1) `GBBaseFormGroup` needs a legacy `ObjectFields`-shaped JSON at `public/formjson/actionpanel.json`, which never existed (the newer `gb-metaform` schema I'd authored doesn't work with it); (2) the route was never updated to supply the `MenuRights` DI token the reworked constructor now requires; (3) `proxy.conf.js` had silently lost the `/fws/ActionPanel`/`/fws/CommandPanel`/`/fws/QuickAction` entries — they were only ever added via a live, uncommitted `sed` on a build server back in August. All three fixed and live-verified with a real Save round-trip. |

---

*Compiled 2026-08-18, consolidated 2026-08-19 (merged with the companion detailed-task breakdown
into this single document — §2's checkboxes, §3.3's completion list, §3.4, and §4's rollout
checklist are the result), gap-fixing pass 2026-08-19 (Action Panel + Quick Action admin screens,
the Action Panel `ActionType`/backend-data-not-actually-reaching-the-panel fix, `VisibleWhen` wiring
for the form toolbar and grid, `ShowContentLink`/`ShowRule` routing, and the `CK_TSHOW_SHOWNATURE`
constraint widen — see the struck-through items in §2/§3.3/§7 for what changed and how each was
verified), from direct code inspection of `gbBE/gb5` (`GB5Framework`,
`GB5Solution/Enablement`, `GB5Solution/WorkInstruction`) and `gb/gb4.7mfe`
(`features/common/components/gbactionpanel`, `features/gbmetaquickaction`,
`features/common/components/gbcommandpalette`, `features/gblayout`, `features/gbgrid`,
`projects/enablement`, `projects/devadmin/master/commandpanel`), including live verification against
GB5DEMO for the backend save/read round-trips described above. Re-verify against current code before
reuse if significant time has passed — several items in §7 are mid-remediation and may have changed.*