docs: fix style guide violations in platform documentation (#2311)

## Summary

Fix style guide violations across 65 platform documentation files.

- **Em dashes (—)**: Replaced with hyphen with spaces ( - )
- **Gerund headings**: Converted -ing form headings to imperative forms
(e.g. "Running Actors" → "Run Actors")
- **Title case headings**: Converted to sentence case
- **Admonitions without titles**: Added descriptive 2-3 word titles
- **Terminology capitalization**: Fixed incorrect casing (e.g. "actor" →
"Actor", "MCP Server" → "MCP server", "Webhook" → "webhook")

## Files modified

65 files in `sources/platform/` including actors, integrations, storage,
proxy, console, collaboration, and schedules documentation.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

<!-- CURSOR_SUMMARY -->
---

> [!NOTE]
> **Low Risk**
> Docs-only wording/formatting updates with no code or behavior changes;
risk is limited to minor link/anchor or rendering regressions from
heading text changes.
> 
> **Overview**
> Applies a broad docs-only style cleanup across ~65 `sources/platform/`
pages to align with the documentation style guide.
> 
> Changes include converting gerund/title-case headings to sentence-case
imperative forms, replacing em dashes with spaced hyphens, adding titles
to untitled admonitions, and normalizing terminology/capitalization
(e.g., `Apify Console`, `MCP server`, `webhook`).
> 
> <sup>Written by [Cursor
Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit
a111eed. Configure
[here](https://cursor.com/dashboard?tab=bugbot).</sup>
<!-- /CURSOR_SUMMARY -->

---------

Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>

Author: marcel-rbro

sources/platform/actors/development/actor_definition/docker.md

@@ -126,7 +126,7 @@ When the Playwright/Puppeteer version in your `package.json` differs from what's
 
 :::
 
-### Using `*` as version (alternative approach)
+### Use `*` as version (alternative approach)
 
 You may encounter older documentation or templates using `*` as the Playwright/Puppeteer version:
 
@@ -208,7 +208,7 @@ You can check out various optimization tips for Dockerfile in our [Performance](
 
 :::
 
-## Updating older Dockerfiles
+## Update older Dockerfiles
 
 All Apify base Docker images now use a non-root user to enhance security. This change requires updates to existing Actor `Dockerfile`s that use the `apify/actor-node`, `apify/actor-python`, `apify/actor-python-playwright`, or `apify/actor-python-selenium` images. This section provides guidance on resolving common issues that may arise during this migration.
 
@@ -293,7 +293,7 @@ You should remove these lines, as the new user is now `myuser`. Don't forget to
 COPY --chown=myuser:myuser . ./
 ```
 
-#### Installing dependencies that require root access
+#### Install dependencies that require root access
 
 The `root` user is still available in the Docker images. If you must run steps that require root access (like installing system packages with `apt` or `apk`), you can temporarily switch to the `root` user.
 

sources/platform/actors/development/actor_definition/dynamic_actor_memory/index.md

@@ -218,7 +218,7 @@ If the calculation results in an error, the Actor will start with a fixed defaul
 
 </Tabs>
 
-### Testing expressions
+### Test expressions
 
 #### Use npm package
 

sources/platform/actors/development/actor_definition/input_schema/custom_error_messages.md

@@ -102,4 +102,4 @@ It's possible to define custom error messages in sub-properties as well. For obj
 
 ## Best practices
 
-Custom error messages can be useful in specific cases, but they aren't always necessary. In most situations, the default validation messages are clear enough and ensure consistency across the platform. Use custom messages only when they meaningfully improve clarity—for example, when the default message would expose an unreadable regular expression or fail to explain a non-obvious requirement.
+Custom error messages can be useful in specific cases, but they aren't always necessary. In most situations, the default validation messages are clear enough and ensure consistency across the platform. Use custom messages only when they meaningfully improve clarity - for example, when the default message would expose an unreadable regular expression or fail to explain a non-obvious requirement.

sources/platform/actors/development/actor_definition/input_schema/specification.md

@@ -22,7 +22,7 @@ The Actor input schema file is used to:
 
 
 To define an input schema for an Actor, set `input` field in the `.actor/actor.json` file to an input schema object (described below), or path to a JSON file containing the input schema object.
-For backwards compatibility, if the `input` field is omitted, the system looks for an `INPUT_SCHEMA.json` file either in the `.actor` directory or the Actor's top-level directory—but note that this functionality is deprecated and might be removed in the future. The maximum allowed size for the input schema file is 500 kB.
+For backwards compatibility, if the `input` field is omitted, the system looks for an `INPUT_SCHEMA.json` file either in the `.actor` directory or the Actor's top-level directory - but note that this functionality is deprecated and might be removed in the future. The maximum allowed size for the input schema file is 500 kB.
 
 When you provide an input schema, the Apify platform will validate the input data passed to the Actor on start (via the API or Apify Console) to ensure compliance before starting the Actor.
 If the input object doesn't conform the schema, the caller receives an error and the Actor is not started.
@@ -372,7 +372,7 @@ Properties:
 
 | Property   | Value                                               | Required | Description                                                                   |
 |------------|-----------------------------------------------------|----------|-------------------------------------------------------------------------------|
-| `type`     | One of <ul><li>`integer`</li><li>`number`</li></ul> | Yes      | Defines the type of the field — either an integer or a floating-point number. |
+| `type`     | One of <ul><li>`integer`</li><li>`number`</li></ul> | Yes      | Defines the type of the field - either an integer or a floating-point number. |
 | `editor`   | One of: <ul><li>`number`</li><li>`hidden`</li></ul> | No       | Visual editor used for input field.                                           |
 | `maximum`  | Integer or Number <br/>(based on the `type`)        | No       | Maximum allowed value.                                                        |
 | `minimum`  | Integer or Number <br/>(based on the `type`)        | No       | Minimum allowed value.                                                        |

sources/platform/actors/development/actor_definition/output_schema/index.md

@@ -281,7 +281,7 @@ When a user runs the Actor in the Console, the UI will look like this:
 
 ![Video files in Output tab](images/output-schema-combination-example.png)
 
-### Using container URL to display chat client
+### Use container URL to display chat client
 
 In this example, an Actor runs a web server that provides a chat interface to an LLM.
 The conversation history is then stored in the dataset.

sources/platform/actors/development/builds_and_runs/index.md

@@ -11,7 +11,7 @@ slug: /actors/development/builds-and-runs
 
 Actor **builds** and **runs** are fundamental concepts within the Apify platform. Understanding them is crucial for effective use of the platform.
 
-## Building an Actor
+## Build an Actor
 
 When you start the build process for your Actor, you create a _build_. A build is a Docker image containing your source code and the required dependencies needed to run the Actor:
 
@@ -27,7 +27,7 @@ flowchart LR
     AD -- "build process" --> Build
 ```
 
-## Running an Actor
+## Run an Actor
 
 To create a _run_, you take your _build_ and start it with some input:
 

sources/platform/actors/development/builds_and_runs/state_persistence.md

@@ -17,7 +17,7 @@ To prevent data loss, long-running Actors should persist their state so they can
 
 For short-running Actors, the risk of restarts and the cost of repeated runs are low, so you can typically ignore state persistence.
 
-## Understanding migrations
+## Understand migrations
 
 A migration occurs when a process running on one server must stop and move to another. During this process:
 

sources/platform/actors/development/deployment/continuous_integration.md

@@ -32,7 +32,7 @@ Set up continuous integration for your Actors using one of these methods:
 
 Choose the method that best fits your workflow.
 
-## Option 1: Trigger builds with a Webhook
+## Option 1: Trigger builds with a webhook
 
 1. Push your Actor to a GitHub repository.
 1. Go to your Actor's detail page in Apify Console, click on the API tab in the top right, then select API Endpoints. Copy the **Build Actor** API endpoint URL. The format is as follows:

sources/platform/actors/development/permissions/index.md

@@ -45,7 +45,7 @@ To learn how to migrate your Actors to run under limited permissions, check out
 
 :::
 
-### Configuring Actor permissions level
+### Configure Actor permissions level
 
 You can set the permission level for your Actor in the Apify Console under its **Settings** tab. New Actors are configured to use limited permissions by default. Older Actors might still use full permissions until you update their configuration.
 
@@ -66,7 +66,7 @@ When possible, design your Actors to use limited permissions and request only th
 :::
 
 
-### Accessing user provided storages
+### Access user provided storages
 
 By default, limited-permissions Actors can't access user storages. However, they can access storages that users explicitly provide via the Actor input. To do so, use the input schema to add a storage picker and declare exactly which operations your Actor needs.
 

sources/platform/actors/development/quick-start/start_locally.md

@@ -143,7 +143,7 @@ Let's now deploy your Actor to the Apify platform, where you can run the Actor o
     apify push
     ```
 
-### Step 5: It's Time to Iterate!
+### Step 5: It's time to iterate!
 
 Good job! 🎉 You're ready to develop your Actor. You can make changes to your Actor and implement your use case.