@agent-native/core 0.147.0 → 0.148.0

package/corpus/templates/factory/.agents/skills/frontend-design/SKILL.md

@@ -2,16 +2,19 @@
 name: frontend-design
 description: >-
   Sets the visual direction for a new or redesigned surface, with production
-  quality that avoids generic AI aesthetics. Use when building a new page,
-  app, or marketing surface, defining visual identity, or doing a design pass
-  ("make this look good"). Do not load it for routine UI edits: adding a field
-  to an existing form, fixing spacing, wiring a button, or changing copy.
+  quality that avoids generic AI aesthetics. Use when building, redesigning, or
+  cleaning up any user-facing UI, including screenshot-driven feedback, copy or
+  density reduction, settings, control placement, or a design pass ("make this
+  look good"). Do not load it only for purely mechanical wiring or formatting.
 scope: dev
 license: Complete terms in LICENSE.txt
 source: https://github.com/anthropics/skills/blob/main/skills/frontend-design/SKILL.md
 local-changes: >-
-  Description narrowed and Verification rescoped deliberately; an upstream sync
-  must not restore the broad auto-load triggers or screenshot-everything step.
+  Description deliberately widened on 2026-08-09 because the previous narrow
+  trigger excluded routine UI edits, including screenshot-driven cleanup, copy
+  and density changes, settings, and control placement. An upstream sync must
+  not re-narrow it. Verification remains deliberately rescoped; an upstream
+  sync must not restore screenshot-everything or broad browser-automation steps.
 metadata:
   internal: true
 ---
@@ -26,10 +29,12 @@ The user may ask for a component, page, full app, dashboard, marketing surface,
 
 Before coding, decide:
 
-- **Purpose**: What workflow does this surface make easier? What is the primary action?
+- **Purpose**: What workflow does this surface make easier? What does the user
+  need to understand, decide, or do next?
 - **Audience**: Who will use it repeatedly, and what should feel fast, calm, playful, premium, editorial, technical, or utilitarian?
 - **Tone**: Choose a concrete aesthetic direction: refined minimal, dense operations console, editorial, playful, industrial, warm handmade, high-contrast data tool, etc.
-- **Information hierarchy**: What must be visible in the first five seconds, and what should be progressively disclosed?
+- **Information hierarchy**: What must be visible to orient and act, and what
+  can wait until context or intent makes it relevant?
 - **Differentiation**: What makes this feel designed for this exact domain?
 
 Then implement working code that is cohesive, accessible, responsive, and polished in small details: typography, spacing, copy, motion, empty states, loading states, focus states, and error states.
@@ -50,46 +55,80 @@ before selecting its accent family. Shared behavior and semantic token names
 should stay consistent; palette, density, composition, type contrast, and
 shape language should not be identical by default.
 
-## Minimalism And Progressive Disclosure
-
-Default to Apple/Linear-level restraint: make the primary workflow obvious, then remove everything that does not help that workflow right now. A polished UI often has fewer visible controls, fewer borders, fewer labels, and fewer explanatory surfaces than the first reasonable implementation.
-
-### Progressive Disclosure Is A Design Requirement
-
-Treat an all-at-once interface as a defect to fix during design, not as a
-styling preference. Before coding, inventory every piece of content and action
-on the surface, then assign each one to the smallest useful visibility level:
-
-1. **Immediate** — the page title, current state, one primary action, and the
-   compact context needed to choose what to do next.
-2. **Expanded** — the details needed for the selected item or active workflow.
-3. **On demand** — advanced settings, diagnostics, credentials, metadata,
-   destructive actions, documentation, and rarely used tools.
-
-Use single-select accordions or simple disclosure rows for sibling panels when
-the user is choosing one item at a time. Inside an expanded panel, keep another
-layer for independent concerns instead of dumping every form, explanation, and
-secondary action into the first reveal. Prefer one flat panel with alignment,
-dividers, and whitespace over nested cards; provider or product icons should
-not receive decorative borders or containers unless the container communicates
-state or interaction. A collapsed row should still show the item name, status,
-and a concise summary so the user can scan the whole surface without opening
-everything.
-
-Before shipping, ask: “What can disappear until the user asks for it?” Then
-verify collapsed, expanded, loading, empty, error, and narrow-width states.
-If the first viewport contains multiple forms, repeated explanatory copy,
-documentation links, and controls for unrelated tasks, the surface has not
-passed this requirement yet.
-
-- **Start by subtracting**: Before adding a visible control, banner, toolbar row, card, or explanatory block, ask what can be removed, merged, renamed, or moved into an existing affordance.
-- **One primary action**: Each surface should have one dominant next action. Secondary actions belong in menus, popovers, command palettes, disclosure rows, or contextual hover/focus states unless they are used constantly.
-- **Progressively disclose rare work**: Advanced options, diagnostics, metadata, settings, import/export, destructive actions, and inspection tools should stay tucked away until requested. Prefer small icon triggers with tooltips, popovers, drawers, or detail panels over permanent chrome.
-- **Keep chrome quiet**: Avoid new always-visible bars, badges, callouts, helper text, and counters unless they prevent mistakes or are central to repeated use. Status can often be a dot, ring, muted count, or tooltip.
-- **Favor content over containers**: Do not wrap every section in a card. Use whitespace, alignment, typography, dividers, and full-width bands before adding boxes.
-- **Design for repeated use**: Production app UI should feel calm after the hundredth use. If a control shouts, animates, explains itself, or occupies a full row for an occasional action, hide or compress it.
-- **Make absence intentional**: Empty states should be sparse and action-oriented. Do not fill blank space with marketing copy, decorative art, or lists of features just because the screen feels empty.
-- **Use familiar primitives**: Icon buttons need clear tooltips. Menus, popovers, tabs, switches, and segmented controls should carry complexity instead of exposing every option at once.
+## High-Signal Minimalism And Progressive Disclosure
+
+Minimalism means fewer competing kinds of UI, not less useful information. Keep
+surfaces dense and scannable: reduce redundant prose, decorative containers,
+borders, badges, accent colors, and persistent controls before removing content
+that helps the user orient, compare, decide, or recover. The reference class is
+calm productivity software such as ChatGPT/Codex, Linear, and Vercel, not empty
+whitespace.
+
+### Product UX Philosophy
+
+Apply these principles as binding decision rules:
+
+- **Purpose over presence**: Every visible element must support orientation,
+  state comprehension, a decision, an action, or recovery. Before adding one,
+  name which; if it supports none or duplicates another element, remove or
+  defer it.
+- **Clarity over cleverness**: Use plain language, familiar patterns, explicit
+  hierarchy, and visible state. Do not make decoration or invented terminology
+  carry meaning. Preserve the labels, hit targets, focus states, and recovery
+  paths required for accessible use.
+- **Simple first, powerful on demand**: Keep the current task and state in the
+  default presentation. Put advanced, rare, diagnostic, and secondary work
+  behind contextual disclosure, menus, or Settings. Do not turn a discoverability
+  concern into permanent chrome, and do not hide information needed for the
+  current decision.
+- **Hierarchy over chrome**: Use typography, spacing, alignment, and restrained
+  emphasis to organize information. Treat prose, controls, borders, cards,
+  badges, and accent colors as a competition budget: reduce competing kinds of
+  elements before reducing useful information. When a surface has one clear
+  next decision, give it dominant emphasis and move secondary actions out of
+  the default path. Do not wrap every section in a card or add borders for
+  grouping alone; use spacing, alignment, typography, or dividers first. A
+  container must communicate grouping, state, or interaction.
+- **Coherence over novelty**: Reuse the product's primitives, interaction
+  patterns, and language. When given a screenshot or reference product, match
+  its underlying hierarchy, density, and behavior; do not copy decoration or
+  introduce a second visual language without a product reason.
+- **Quiet continuity**: Feedback must be immediate, contextual, and honest.
+  Preserve the user's place and layout, make loading, empty, and error states
+  understandable, and use motion only to explain a change.
+- **Respect repeated use**: Optimize for the hundredth use, not the first
+  impression. If a control repeats an explanation, occupies persistent space
+  for an occasional task, or turns routine work into ceremony, remove it or
+  move it to the contextual surface that owns it.
+
+### Progressive Disclosure And Information Timing
+
+Expose information and controls according to relevance, frequency, and
+consequence. Before coding, inventory the content and actions and assign them to
+the smallest useful visibility layer:
+
+1. **Orient and act**: location, current state, and context needed for the next
+   meaningful choice.
+2. **Support active work**: details and controls for the selected item or
+   current workflow.
+3. **Available on demand**: advanced settings, diagnostics, credentials,
+   metadata, destructive actions, documentation, and rare tools.
+
+Use a disclosure pattern that matches the task. Keep independent concerns easy
+to scan inside an expanded area instead of dumping every form, explanation,
+and secondary action into the first reveal. A collapsed row must retain its
+label and essential state; remove explanatory subtext unless it changes the
+next decision. For configuration with a known current state, show that state
+first and expose editing contextually instead of defaulting to a full form.
+
+Before shipping, verify collapsed, expanded, loading, empty, error, and
+narrow-width states. The default state fails review when its first viewport
+contains multiple unrelated forms, repeated explanatory copy, documentation
+links, or controls for unrelated tasks. It also fails when useful information
+has been replaced with empty whitespace or extra clicks solely to look minimal.
+The default state passes when users can identify their location, current state,
+current task, and relevant next choice without reading documentation, while
+the useful information remains dense and scannable.
 
 ## Aesthetic Guidelines
 
@@ -166,26 +205,28 @@ passed this requirement yet.
 
 ### Product Surface Review
 
-Before shipping a new app or a substantial redesign, review the first viewport
-as an operator would use it repeatedly:
-
-- Show one clear job title, the current state, and one primary next action.
-- Put optional inputs, provider choices, diagnostics, long explanations, and
-  secondary actions behind a disclosure, a later step, a menu, or the agent
-  sidebar. Do not put multiple unrelated forms side by side by default.
-- Prefer a short step flow or a focused page per domain job over one giant
-  dashboard. A route can have several states, but it should reveal one state
-  at a time and preserve the user's progress.
+Before shipping a new app or a substantial redesign, review the surface as an
+operator would use it repeatedly:
+
+- Can users identify where they are, what state they are in, and what
+  meaningful choices or next steps are available?
+- Remove competing or redundant elements, then place optional inputs, provider
+  choices, diagnostics, long explanations, and secondary actions where they
+  remain discoverable without crowding the current task.
+- Match the composition to the workflow. Use a focused page or step flow when
+  the work is sequential; use an overview when comparing or monitoring several
+  things is genuinely the job. Preserve the user's progress in either case.
 - Remove generic hero copy, feature tours, repeated helper text, nested cards,
   status-chip soup, and decorative AI treatment before adding more styling.
-- For review flows, stack the source/original first and the generated or safe
-  result second by default. Use side-by-side comparison only when the content
-  is short enough to scan without excessive horizontal reading.
+- For review flows, choose stacking, side-by-side comparison, or another
+  composition based on content length, scanability, and the user's comparison
+  task.
 - Compare the result with sibling apps. Shared toolkit behavior should feel
   consistent, but a repeated palette, hero composition, type pairing, and
   radius language without a product reason is visual drift, not consistency.
-- Check the result at the target desktop width and a narrow width. If the first
-  viewport feels like documentation instead of a tool, subtract again.
+- Check the result with realistic content at the target desktop width and a
+  narrow width. If it feels like documentation instead of a tool, reduce noise
+  or clarify the hierarchy.
 
 ## shadcn/ui Design Rules
 
@@ -203,18 +244,24 @@ as an operator would use it repeatedly:
   not show generic "Loading..." text for content loads; reserve `Spinner` for
   brief mutations, uploads, and progress actions. Use the app's existing
   loading primitive when it is a genuine design-system adapter. Empty states
-  should have one clear next action.
+  should communicate the state and offer the appropriate next step or small set
+  of choices.
 
 ## Anti-Patterns
 
-Avoid:
+Avoid patterns that add visual noise, obscure state, or compete with the user's
+task without a clear product reason:
 
 - Generic AI aesthetics: purple gradients, glassy cards everywhere, vague sparkle language, decorative blobs, and context-free hero sections.
 - Custom reimplementations of shadcn primitives.
 - Raw color overrides on shared components when semantic tokens or variants would work.
-- New always-visible controls for rare actions. Prefer menus, popovers, sheets, tabs, collapsibles, or advanced sections.
-- Full-width banners, persistent helper rows, decorative cards, or explanatory chrome for status that could be a compact affordance.
-- Treating progressive disclosure as optional. If a control is not part of the main daily workflow, hide it until context, hover, focus, or explicit user intent makes it relevant.
+- New always-visible controls for rare actions when a contextual surface would
+  preserve discoverability and reduce noise.
+- Full-width banners, persistent helper rows, decorative cards, or explanatory
+  chrome for status that could be communicated more clearly with less weight.
+- Hiding essential meaning or operability behind progressive disclosure. Defer
+  complexity when it is contextual or infrequent, but preserve labels, focus,
+  hit targets, accessibility, and recovery paths.
 - UI cards nested inside other cards.
 - Text or icons that resize or shift fixed-format UI on hover/loading.
 

package/corpus/templates/factory/AGENTS.md

@@ -11,42 +11,38 @@ ladder.
 
 ## Core rules
 
-- Keep app state in SQL via Drizzle and scope every read/write by org and
-  member. Use actions as the UI, agent, CLI, MCP, and A2A surface.
-- Keep migrations additive and portable. These tables intentionally use explicit
-  `ownerEmail`/`orgId` columns for org-visible data, not `ownableColumns()`;
-  do not call `accessFilter` on them without adding deliberate visibility data.
-- Resolve Slack through `server/connectors/credentials.ts`, passing caller
-  identity at the entrypoint. The dependency guard does not inspect nested
-  connector code, so a new direct `process.env.SLACK_BOT_TOKEN` read is a bug.
+- Keep app state in SQL via Drizzle, scope reads/writes by org and member, and
+  use actions as the UI, agent, CLI, MCP, and A2A surface.
+- Keep migrations additive and portable. These org-visible tables use explicit
+  `ownerEmail`/`orgId`, not `ownableColumns()`; add deliberate visibility data
+  before using `accessFilter`.
+- Resolve Slack through `server/connectors/credentials.ts` with caller identity
+  supplied at the entrypoint; never read `SLACK_BOT_TOKEN` directly.
 - A missing callback, partial thread, unreadable provider response, or missed
-  reconciliation is not success. Preserve typed failure or
+  reconciliation is not success; preserve typed failure or
   `reconciliation_required` state.
-- Hard guards are code, not prompt text: auth, session, identity,
-  credentials/vault, migrations, payments, security, and publishable
-  `packages/*` changes always require human review.
-- All work is deduped by Factory item and rule/run identity. Provider comment IDs
-  are not the idempotency boundary.
-- Slack interaction uses the generic Agent-Native Slack adapter. Clear-bug Slack
-  automations add 👀 and tag `@builderio` in the source thread; GitHub and Sentry
-  clear bugs use the Builder run API. Clips, Design, and Content are always
-  owner-managed and never enter autonomous dispatch or PR governance.
-- PR governance requires verified BuilderIO membership, a clear bug, passing
-  CI, and handled review feedback. Product or UX implications stay
-  manual. Auto-merge additionally requires a verified Factory Builder run.
-- Reuse the existing ai-services GitHub read and Builder execution APIs. Do not
-  duplicate GitHub installation/webhook infrastructure in this template.
+- Auth, identity, credentials/vault, migrations, payments, security, and
+  publishable `packages/*` changes are code-level guards requiring human review.
+- Deduplicate by Factory item and rule/run identity, not provider comment ID.
+- Use the generic Slack adapter: clear-bug automations add 👀 and tag
+  `@builderio`; GitHub/Sentry clear bugs use the Builder run API. Clips, Design,
+  and Content stay owner-managed outside autonomous dispatch and PR governance.
+- PR governance requires verified BuilderIO membership, a clear bug, passing CI,
+  and handled review feedback; product/UX implications stay manual. Auto-merge
+  also requires a verified Factory Builder run.
+- Reuse the ai-services GitHub read and Builder execution APIs; do not duplicate
+  GitHub installation/webhook infrastructure here.
 - Do not add CRUD routes under `server/routes/api/`; actions are the domain
-  surface. Provider callbacks are the only exception and must verify signatures.
-- Factory graph edits create immutable blueprint versions. AI proposes a graph
-  with `source=ai`; a person reviews and publishes it through
-  the same action surface as manual edits.
+  surface. Provider callbacks must verify signatures.
+- Graph edits create immutable blueprint versions. AI proposes with `source=ai`;
+  a person reviews and publishes through the same action surface.
 
 ## Application state
 
 - `navigation.view`: `factory` when the workspace is open.
 - `navigation.factoryId`: selected Factory id when present.
-- `navigation.factoryTab`: `map` | `inbox` | `rules` | `automations` | `settings`.
+- `navigation.factoryTab`: `map` | `inbox` | `rules` | `automations` | `audit` | `settings`.
+- `navigation.factoryAuditRunId`: selected automation run in the audit view when present.
 - `navigation.factoryNodeId` / `navigation.factoryEdgeId`: selected graph item.
 - A selected graph node or edge is part of `navigation` context. Read
   `view-screen` before answering why a route exists or changing the selected
@@ -65,37 +61,32 @@ ladder.
 | `evaluate-triage-item` | Append a decision. |
 | `record-triage-feedback` | Capture human correction for learning. |
 | `approve-factory-item` | Explicitly authorize one bounded run. |
-| `start-builder-for-item` | Govern clear-bug dispatch; Slack tags Builder in-thread, other sources use Builder API. |
-| `govern-agent-native-pull-request` | Apply CI, review, internal-author, product, and owner gates to PR approval/merge. |
-| `list-factory-automations` / `save-factory-automation` / `run-factory-automation` | Inspect and edit org-owned Factory prompts, models, schedules, and runs. |
-| `get-factory-automation-health` | Inspect the durable scheduler heartbeat and last scheduler error when runs appear stale. |
+| `start-builder-for-item` | Govern clear-bug dispatch through Slack or Builder API. |
+| `govern-agent-native-pull-request` | Apply CI, review, author, product, and owner gates. |
+| `list-factory-automations` / `save-factory-automation` / `run-factory-automation` | Inspect or edit org-owned prompts, schedules, and runs. |
+| `list-factory-audit` | Inspect automation runs, evidence, decisions, and provider actions. |
+| `get-factory-automation-health` | Inspect scheduler heartbeat and last error. |
 | `suggest-factory-rules` | Mine feedback and fast approvals into proposals. |
 | `reconcile-triage-run` | Persist callback/provider reconciliation. |
 | `list-factories` / `get-factory-graph` | Inspect Factory definitions, graph versions, and live evidence metrics. |
 | `save-factory-graph` | Create or version a complete visual graph; never starts provider work. |
 | `list-factory-comments` / `add-factory-comment` | Read or attach comments to a canvas, node, or edge. |
 
-Rules start in shadow mode; hard guards always apply. Editable organization
-automations execute stored prompts; every external mutation needs a durable run,
-idempotency key, and provider confirmation. The legacy observer is disabled
-once organization automations are seeded.
-
-Use the visual editor for direct blueprint changes. Use the agent chat for
-natural language design, explanations, and proposals; it must preserve a
-complete graph and use `save-factory-graph` rather than describing an
-unpersisted change. Rule or guard changes must go through the triage rule
-actions, never through graph JSON.
+Rules start in shadow mode; hard guards always apply. Organization automations
+execute stored prompts, and every external mutation needs a durable run,
+idempotency key, and provider confirmation. The legacy observer ends once org
+automations are seeded. Use the visual editor for graph changes and agent chat
+for proposals; persist complete graphs with `save-factory-graph`. Change rules
+through triage rule actions, never graph JSON.
 
 ## Scheduler identity
 
-`WORKSPACE_OWNER_EMAIL` is read only at startup to find the deployment org and
-stamp seeded automation `createdBy`; it is never caller identity and must not
-enter request authorization or credential resolution.
+`WORKSPACE_OWNER_EMAIL` is startup-only deployment-org and seed identity; never
+use it for request authorization or credential resolution.
 
 ## Hosting
 
 Production needs `DATABASE_URL`, `WORKSPACE_OWNER_EMAIL`, and
-`FACTORY_PUBLIC_URL`. Builder execution additionally needs the service URL,
-project ID, and workspace-resolved Builder credentials. GitHub and Sentry
-polling use workspace-resolved provider credentials. Provider callbacks and
-external writes must remain auditable and fail closed when evidence is partial.
+`FACTORY_PUBLIC_URL`; Builder execution also needs its service URL, project ID,
+and workspace credentials. GitHub/Sentry use workspace credentials. Callbacks
+and external writes stay auditable and fail closed on partial evidence.

package/corpus/templates/factory/actions/babysit-agent-native-pull-request.ts

@@ -11,6 +11,7 @@ import {
   workspaceMemberIdentityFromContext,
 } from "../server/lib/require-workspace-member.js";
 import { createAiServicesGitReadClient } from "../server/triage/ai-services-git.js";
+import { recordFactoryAudit } from "../server/triage/audit.js";
 import { createGitHubClient } from "../server/triage/github-client.js";
 import {
   metadataString,
@@ -140,6 +141,20 @@ export default defineAction({
         prBabysitState: "closed-or-draft",
         prBabysitLastCheckedAt: new Date().toISOString(),
       });
+      await recordFactoryAudit(
+        context,
+        { userEmail, orgId },
+        {
+          action: "babysit-agent-native-pull-request",
+          kind: "governance",
+          status: "skipped",
+          itemId,
+          source: "github",
+          sourceUrl: item.sourceUrl,
+          summary: "Skipped because the pull request is closed or a draft.",
+          details: { state: pullRequest.state, draft: pullRequest.draft },
+        },
+      );
       return { ok: true, action: "skipped", reason: "PR is closed or draft." };
     }
 
@@ -154,6 +169,20 @@ export default defineAction({
         prBabysitOwnerArea: ownerOwnedArea,
         prBabysitLastCheckedAt: new Date().toISOString(),
       });
+      await recordFactoryAudit(
+        context,
+        { userEmail, orgId },
+        {
+          action: "babysit-agent-native-pull-request",
+          kind: "governance",
+          status: "skipped",
+          itemId,
+          source: "github",
+          sourceUrl: item.sourceUrl,
+          summary: `${ownerOwnedArea} is owner-managed; no bot feedback was posted.`,
+          details: { ownerOwnedArea },
+        },
+      );
       return {
         ok: true,
         action: "skipped",
@@ -205,6 +234,30 @@ export default defineAction({
       mergeableState: pullRequest.mergeableState,
       snapshot: signal,
     });
+    await recordFactoryAudit(
+      context,
+      { userEmail, orgId },
+      {
+        action: "babysit-agent-native-pull-request",
+        kind: "governance",
+        status: needsBabysit ? "success" : "skipped",
+        itemId,
+        source: "github",
+        sourceUrl: item.sourceUrl,
+        summary: needsBabysit
+          ? "Review feedback, CI, or mergeability needs Builder attention."
+          : "The pull request is clean and needs no Builder feedback request.",
+        details: {
+          headSha: snapshot.headSha,
+          checks: snapshot.checks.length,
+          comments: snapshot.comments.length,
+          unresolvedReviewState,
+          mergeable: pullRequest.mergeable,
+          mergeableState: pullRequest.mergeableState,
+          reviewFeedbackClean: signal.isClean,
+        },
+      },
+    );
     const now = new Date();
     const nowIso = now.toISOString();
     const metadata = parseTriageMetadata(item.metadataJson);
@@ -261,6 +314,19 @@ export default defineAction({
       item.pullRequestNumber,
       BUILDER_BOT_REQUEST,
     );
+    await recordFactoryAudit(
+      context,
+      { userEmail, orgId },
+      {
+        action: "babysit-agent-native-pull-request",
+        kind: "external_action",
+        itemId,
+        source: "github",
+        sourceUrl: comment.htmlUrl,
+        summary: "Posted the bounded feedback-fix request to builder-io-bot.",
+        details: { commentUrl: comment.htmlUrl, quietForMinutes: 0 },
+      },
+    );
     await updateBabysitMetadata(itemId, orgId, {
       prBabysitState: "active",
       prBabysitFingerprint: fingerprint,

package/corpus/templates/factory/actions/evaluate-triage-item.ts

@@ -15,6 +15,7 @@ import {
   requireWorkspaceMember,
   workspaceMemberIdentityFromContext,
 } from "../server/lib/require-workspace-member.js";
+import { recordFactoryAudit } from "../server/triage/audit.js";
 import {
   normalizeTriagePolicyGuards,
   triageGuardCodeSchema,
@@ -70,6 +71,20 @@ export default defineAction({
         : `Observed failure taxonomy: ${failureTaxonomy.label} (${failureTaxonomy.code}; ${failureTaxonomy.regime}). `;
 
     if (rules.length === 0) {
+      await recordFactoryAudit(
+        context,
+        { userEmail, orgId },
+        {
+          action: "evaluate-triage-item",
+          kind: "decision",
+          status: "skipped",
+          itemId,
+          source: item.source,
+          sourceUrl: item.sourceUrl,
+          summary: "No enabled shadow rules were available for this item.",
+          details: { evaluated: 0 },
+        },
+      );
       return {
         ok: true,
         itemId,
@@ -119,6 +134,28 @@ export default defineAction({
         .where(and(eq(triageItems.id, itemId), eq(triageItems.orgId, orgId)));
     });
 
+    for (const decision of decisions) {
+      await recordFactoryAudit(
+        context,
+        { userEmail, orgId },
+        {
+          action: "evaluate-triage-item",
+          kind: "decision",
+          itemId,
+          source: item.source,
+          sourceUrl: item.sourceUrl,
+          summary: decision.reason,
+          details: {
+            decisionId: decision.id,
+            outcome: decision.outcome,
+            ruleId: decision.ruleId,
+            mode: decision.mode,
+            promptVersion: decision.promptVersion,
+          },
+        },
+      );
+    }
+
     return {
       ok: true,
       itemId,

package/corpus/templates/factory/actions/get-slack-feedback-context.ts

@@ -9,6 +9,7 @@ import {
   requireWorkspaceMember,
   workspaceMemberIdentityFromContext,
 } from "../server/lib/require-workspace-member.js";
+import { recordFactoryAudit } from "../server/triage/audit.js";
 import { createSlackReader } from "../server/triage/slack-client.js";
 
 const MAX_THREAD_PAGES = 5;
@@ -71,6 +72,25 @@ export default defineAction({
       cursor = result.next_cursor;
     }
 
+    await recordFactoryAudit(
+      context,
+      { userEmail, orgId },
+      {
+        action: "get-slack-feedback-context",
+        kind: "read",
+        itemId,
+        source: "slack",
+        sourceUrl: item.sourceUrl,
+        summary: `Read the Slack thread (${messages.length} message${messages.length === 1 ? "" : "s"}).`,
+        details: {
+          channelId: item.channelId,
+          threadTs: item.threadTs,
+          coverage: hasMore ? "partial" : "complete",
+          messageCount: messages.length,
+        },
+      },
+    );
+
     return {
       ok: true,
       itemId,

package/corpus/templates/factory/actions/get-triage-item.ts

@@ -13,6 +13,7 @@ import {
   requireWorkspaceMember,
   workspaceMemberIdentityFromContext,
 } from "../server/lib/require-workspace-member.js";
+import { recordFactoryAudit } from "../server/triage/audit.js";
 
 export default defineAction({
   description:
@@ -21,7 +22,7 @@ export default defineAction({
   http: { method: "GET" },
   readOnly: true,
   run: async ({ itemId }, context) => {
-    const { orgId } = await requireWorkspaceMember(
+    const { userEmail, orgId } = await requireWorkspaceMember(
       workspaceMemberIdentityFromContext(context),
     );
     const db = getDb();
@@ -55,6 +56,28 @@ export default defineAction({
       .where(and(eq(triageRuns.itemId, itemId), eq(triageRuns.orgId, orgId)))
       .orderBy(asc(triageRuns.startedAt));
 
+    const matchingFeedback = feedback.filter((entry) =>
+      decisions.some((decision) => decision.id === entry.decisionId),
+    );
+    await recordFactoryAudit(
+      context,
+      { userEmail, orgId },
+      {
+        action: "get-triage-item",
+        kind: "read",
+        itemId,
+        source: item.source,
+        sourceUrl: item.sourceUrl,
+        summary: `Inspected ${item.title}`,
+        details: {
+          decisionCount: decisions.length,
+          feedbackCount: matchingFeedback.length,
+          runCount: runs.length,
+          coverage: item.coverage,
+        },
+      },
+    );
+
     return {
       ...item,
       decisions: decisions.map((decision) => ({
@@ -65,9 +88,7 @@ export default defineAction({
         mode: decision.mode,
         createdAt: decision.createdAt,
       })),
-      feedback: feedback.filter((entry) =>
-        decisions.some((decision) => decision.id === entry.decisionId),
-      ),
+      feedback: matchingFeedback,
       runs,
     };
   },