🤖 Update activity docs to reflect changes in #43437, for #34288

[iansltx]

Zed + Sonnet 4.6; prompt: Update audit-logs.md to reflect the new fields introduced in d3666ab

[claude]

Claude Code Review

This repository is configured for manual code reviews. Comment @claude review to trigger a review and subscribe this PR to future pushes, or @claude review once for a one-time review.

_{Tip: disable this comment in your organization's Code Review settings.}

[qodo-code-review]

Review Summary by Qodo

Document new from_setup_experience field in audit logs

📝 Documentation

Walkthroughs

Description

• Add from_setup_experience field to script execution activity
• Add from_setup_experience field to package installation activity
• Add from_setup_experience field to app installation activity
• Update example JSON payloads for all three activities

Diagram

flowchart LR
  A["Audit Logs Documentation"] -->|Add field| B["script_execution Activity"]
  A -->|Add field| C["package_installation Activity"]
  A -->|Add field| D["app_installation Activity"]
  B -->|Update example| B1["JSON payload"]
  C -->|Update example| C1["JSON payload"]
  D -->|Update example| D1["JSON payload"]

Loading

File Changes

1. docs/Contributing/reference/audit-logs.md 📝 Documentation +9/-3

Document from_setup_experience field across activities

• Added from_setup_experience field documentation to three activity types: script_execution,
 package_installation, and app_installation
• Updated field descriptions to indicate whether each activity was triggered as part of the setup
 experience
• Updated example JSON payloads for all three activities to include the new from_setup_experience
 field set to false

docs/Contributing/reference/audit-logs.md

---

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (2)   📘 Rule violations (0)   📎 Requirement gaps (0)

🐞\ ≡ Correctness (1) ⚙ Maintainability (1)

1. Docs list non-emitted field 🐞 ≡

Description

audit-logs.md documents a from_setup_experience field for multiple activities, but the server
excludes FromSetupExperience from JSON serialization, so the key will never appear in audit log
details. This will mislead consumers parsing audit logs/webhooks and expecting that field to
exist.

Code

docs/Contributing/reference/audit-logs.md[1040]

+- "from_setup_experience": Whether the script was run as part of the setup experience.

Evidence

The docs now claim from_setup_experience exists in details, but the activity detail structs
explicitly omit FromSetupExperience from JSON (json:"-"), and NewActivity persists/sends
details via json.Marshal(activity), so omitted fields cannot be present.

docs/Contributing/reference/audit-logs.md[1027-1056]
docs/Contributing/reference/audit-logs.md[1409-1444]
docs/Contributing/reference/audit-logs.md[1691-1721]
server/fleet/activities.go[871-897]
server/fleet/activities.go[1078-1103]
server/fleet/activities.go[1321-1346]
server/activity/internal/service/new_activity.go[33-44]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The docs add `from_setup_experience`, but the backend activity structs mark `FromSetupExperience` as `json:"-"`, so the key is never serialized into audit-log `details`.

## Issue Context
`NewActivity` stores/sends activity `details` by `json.Marshal(activity)`, which respects struct tags.

## Fix Focus Areas
Choose one:
1) **Docs-only fix** (keep current backend behavior): remove `from_setup_experience` from the affected sections/examples.
2) **Backend+docs fix** (make docs true): change `FromSetupExperience` JSON tags to `json:"from_setup_experience"` (and ensure it’s populated where activities are created).

- docs/Contributing/reference/audit-logs.md[1027-1056]
- docs/Contributing/reference/audit-logs.md[1409-1444]
- docs/Contributing/reference/audit-logs.md[1691-1721]
- server/fleet/activities.go[871-897]
- server/fleet/activities.go[1078-1103]
- server/fleet/activities.go[1321-1346]
- server/activity/internal/service/new_activity.go[33-44]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. App install fields undocumented 🐞 ⚙

Description

The installed_app_store_app audit-log docs omit fields that the backend serializes into details
(host_platform and from_auto_update). This makes the reference incomplete for consumers trying
to fully parse the activity payload.

Code

docs/Contributing/reference/audit-logs.md[R1702-1705]

- "command_uuid": UUID of the MDM command used to install the app.
- "policy_id": ID of the policy whose failure triggered the install. Null if no associated policy.
- "policy_name": Name of the policy whose failure triggered the install. Null if no associated policy.
+- "from_setup_experience": Whether the app was installed as part of the setup experience.

Evidence

ActivityInstalledAppStoreApp includes host_platform and from_auto_update JSON fields (not
omitempty), so they will be present in emitted details, but the corresponding docs section
doesn’t list them.

docs/Contributing/reference/audit-logs.md[1691-1721]
server/fleet/activities.go[1321-1334]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The `installed_app_store_app` activity docs don’t list all fields that are actually serialized in `details` (`host_platform`, `from_auto_update`).

## Issue Context
`ActivityInstalledAppStoreApp` includes these fields with JSON tags and without `omitempty`, so they are part of the payload.

## Fix Focus Areas
- docs/Contributing/reference/audit-logs.md[1691-1721]
- server/fleet/activities.go[1321-1334]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

ⓘ The new review experience is currently in Beta. Learn more