@objectstack/plugin-audit@16.0.0

github-actions released this 21 Jul 06:26

@objectstack/plugin-audit@16.0.0

f55be04

Patch Changes

2ea08ee: Flow trigger observability — kill the four-layer silence around record-change flows that never fire (2026-07-17 third-party eval).

A misauthored auto-launched flow (wrong objectName, missing requires: ['automation','triggers'], failing start condition) produced ZERO output at every layer: the engine's own registration/binding logs land inside the CLI's boot-quiet stdout window (which swallows debug/info/warn — only error/fatal reach stderr), and each "didn't happen" path was itself silent. Fixes:
- Startup banner Flows: section (os serve/os dev/os start): flow count, bound-to-trigger count, registered trigger types, draft count — plus loud ⚠ lines for flows declared with no automation engine enabled (requires missing), flows whose trigger type has no registered trigger, and bound record-change flows targeting an unknown object (dead binding). Printed after stdout is restored, so it is immune to the boot-quiet window.
- Trigger-fired run failures now log at ERROR (stderr — always visible): the automation engine no longer drops the AutomationResult of a trigger-fired execution; condition-evaluation faults and node failures surface with the flow name. Condition-not-met skips stay at debug (high-frequency, intentional).
- RecordChangeTrigger probes object existence at bind time and warns when a flow's objectName matches no registered object (exact-name matching), instead of silently arming a hook that can never fire.
- kernel:bootstrapped binding audit in the automation plugin: warns per enabled-but-unbound triggered flow with the reason, and reports registered/bound/draft counts (AutomationEngine.getTriggerBindingAudit(), extended getFlowRuntimeStates() with status/triggerType/object).
- os validate flow-wiring advisories (@objectstack/lint validateFlowTriggerReadiness): warns when a record-triggered flow targets an object the stack does not define, and when an auto-triggered flow's status is draft (authored or defaulted — draft flows still fire; declare active or obsolete).
- Removed leftover boot-debug writes (registerApp/AppPlugin/StandaloneStack/AuditPlugin stderr noise) that previous debugging of this same silence had left behind.
ee0a499: feat(i18n): localize collaboration notification titles and the storage objects; wire the notifications REST routes

Three gaps behind one report (a sys_file "repro.png" assigned to you
notification that was English on an all-Chinese workspace, opened an English
detail page, and never cleared its unread state):
- plugin-audit — the assignment (collab.assignment) and @mention
  (collab.mention) bell titles were hardcoded English literals built from the
  raw object API name. They now resolve through the i18n service with the same
  key shapes as the activity summaries (framework#3039): new
  messages.assignedToYou / messages.mentionedYou /
  messages.mentionedYouAnonymous templates (en / zh-CN / ja-JP / es-ES), the
  object named by its translated label (objects.{name}.label → authored def
  label → API name), and the locale resolved for the recipient (they read
  the bell), not the acting user. Every step stays best-effort: no locale / no
  i18n / key miss degrades to the English literal — which now also prefers the
  authored object label over the API name.
- service-storage — sys_file / sys_upload_session had no translation
  bundle at all, so the file detail page (labels, and the Pending Upload /
  Committed / Deleted status pipeline) rendered English on every locale. The
  service now ships its own ADR-0029 D8 bundle (en / zh-CN / ja-JP / es-ES,
  src/translations + scripts/i18n-extract.config.ts) and contributes it via
  i18n.loadTranslations on kernel:ready, matching service-messaging.
  (sys_attachment stays in platform-objects' bundles pending the
  storage-domain decomposition.)
- runtime — the in-app notifications REST surface (GET /api/v1/notifications, POST /api/v1/notifications/read, POST /api/v1/notifications/read/all; ADR-0030) had its handleNotification
  dispatch branch and discovery entry, but no server.<verb>() mount in
  dispatcher-plugin, so only the cloud hosts' hono catch-all reached it — the
  standalone / os dev server 404'd every request. That left mark-read with no
  working endpoint (the console's direct sys_notification_receipt write is
  rejected by ADR-0103's engine-owned gate), so unread notifications could never
  clear. The three routes are now mounted explicitly, guarded by the
  route-registration regression test.
Updated dependencies [f972574]
Updated dependencies [6289ec3]
Updated dependencies [22013aa]
Updated dependencies [3ad3dd5]
Updated dependencies [8efa395]
Updated dependencies [3a18b60]
Updated dependencies [a8aa34c]
Updated dependencies [e057f42]
Updated dependencies [a3823b2]
Updated dependencies [bc65105]
Updated dependencies [43a3efb]
Updated dependencies [524696a]
Updated dependencies [bfa3c3f]
Updated dependencies [5e3301d]
Updated dependencies [dd9f223]
Updated dependencies [46e876c]
Updated dependencies [5f05de2]
Updated dependencies [021ba4c]
Updated dependencies [158aa14]
Updated dependencies [62a2117]
Updated dependencies [d2723e2]
Updated dependencies [fefcd54]
Updated dependencies [beaf2de]
Updated dependencies [369eb6e]
Updated dependencies [06ff734]
Updated dependencies [b659111]
Updated dependencies [5754a23]
Updated dependencies [6c270a6]
Updated dependencies [290e2f0]
Updated dependencies [668dd17]
Updated dependencies [8abf133]
Updated dependencies [e0859b1]
Updated dependencies [04ecd4e]
Updated dependencies [4d5a892]
Updated dependencies [16cebeb]
Updated dependencies [86d30af]
Updated dependencies [8923843]
Updated dependencies [a2795f6]
Updated dependencies [f16b492]
Updated dependencies [4b6fde8]
Updated dependencies [2018df9]
Updated dependencies [fc5a3a2]
Updated dependencies [8ff9210]
- @objectstack/spec@16.0.0
- @objectstack/platform-objects@16.0.0
- @objectstack/core@16.0.0

Assets 2