diff --git a/.claude/CLAUDE.md b/.claude/CLAUDE.md
index 6bbabda1..17b261d2 100644
--- a/.claude/CLAUDE.md
+++ b/.claude/CLAUDE.md
@@ -27,6 +27,7 @@ This file is the canonical source for shared workflows and documentation standar
 
 - Lead with what readers need to know or do. Include prerequisites before procedural steps.
 - Include a detail only when it helps readers understand behavior, recognize a relevant problem, or choose an action. A verified fact is not automatically useful documentation.
+- Do not restate what the product shows the reader. For command output, summaries, UI labels, log lines, and error messages, ask whether the reader will see the text anyway. If so, describe it only to add a cause, a dependency, or the action to take. "The dry run skips Sync Config validation because that check needs a running instance" adds a dependency. "The summary reports that a real deploy would provision the instance first" and a list of the errors shown for a missing permission add nothing.
 - For non-obvious behavior, explain the mechanism, consequence, observable signal, action, or trade-off that readers need. These are decision aids, not a mandatory five-part template. A reference entry often needs only its meaning and a useful next step.
 - Preserve necessary causal context when shortening an explanation. Correct broad claims with narrow, accurate wording rather than a list of exceptions. Remove repetition, internal mechanics, and rare cases that do not affect the reader's interpretation or action.
 - Explain why a recommendation helps when the reason is unclear. Use an example or contrast when it resolves a likely misunderstanding, such as a row in ten buckets being stored and synced ten times. Do not repeat explanations that are already clear.
diff --git a/.claude/agents/document-reviewer.md b/.claude/agents/document-reviewer.md
index e8ba7d51..06f904ea 100644
--- a/.claude/agents/document-reviewer.md
+++ b/.claude/agents/document-reviewer.md
@@ -10,11 +10,13 @@ Read [the canonical standards](../CLAUDE.md) in full, including [Style Authority
 
 ## Scope and Method
 
-- Review added or modified content unless the user requests a full-page audit. Read surrounding content when needed to interpret the change.
-- Apply all canonical standards. Focus on claims and platform scope, minimum useful explanation, clear actors and actions, necessary consequences or trade-offs, and suitable examples and components.
-- Flag missing context only when readers need it. Also flag unnecessary mechanics, exceptions, and repetition. Do not require every entry to explain a mechanism, consequence, signal, action, and trade-off.
-- Use available Vale and link-check results. Do not duplicate their findings about spelling, terminology, capitalization, first-person usage, or links. If results are unavailable, report that limitation rather than assuming checks passed.
-- State uncertainty about technical accuracy and give evidence for findings. Do not invent problems or approve unverified claims as correct.
+Review added or modified content unless the user requests a full-page audit. Read surrounding content when needed to interpret the change. Use available Vale and link-check results instead of repeating their spelling, terminology, capitalization, first-person, and link findings. If results are unavailable, report that limitation rather than assuming the checks passed.
+
+Apply the canonical standards in three passes and report findings from each:
+
+1. **Accuracy:** claims, platform scope, versions, and consistency with the surrounding page. Before reporting a claim as unverified, check the sources the PR or the user cites, such as the source PR, divergence issue, release notes, or code at the merged commit, and follow the links inside them. If nothing is cited, look up the release the text names. Report a claim as unverified only when no source covers it or a source contradicts it. Give evidence, do not invent problems, and do not approve unverified claims as correct.
+2. **Necessity:** list every sentence that describes what the product prints, displays, logs, or says in an error. Treat each one as a finding to remove unless it passes the restating rule in [Content Strategy](../CLAUDE.md#content-strategy), and report it even when the sentence is accurate. Describing visible output is not a mechanism, consequence, or signal. Also flag internal mechanics, rare exceptions, and repetition. Flag missing context only when readers need it, and do not require every entry to explain a mechanism, consequence, signal, action, and trade-off.
+3. **Clarity and format:** plain technical English, clear actors and actions, and suitable examples and components.
 
 ## Default Output
 
diff --git a/.github/workflows/docs-review.yaml b/.github/workflows/docs-review.yaml
index ff87de10..05dcb4f6 100644
--- a/.github/workflows/docs-review.yaml
+++ b/.github/workflows/docs-review.yaml
@@ -41,6 +41,10 @@ jobs:
             Apply their canonical standards and review method to the changes from
             `gh pr diff ${{ github.event.pull_request.number }}`. Review only added or
             modified content; use surrounding files and available CI results for context.
+            Read the PR description with `gh pr view` and follow the issues, source PRs,
+            and releases it cites, and the links inside them, before reporting a
+            verification gap. `gh issue view`, `gh release view`, `gh pr view`, `gh pr diff`,
+            and read-only `gh api` calls on powersync-ja repositories are available for this.
 
             CI reporting (replaces the reviewer's default output format):
             - Post each specific issue as an inline comment on the relevant line using
@@ -57,4 +61,4 @@ jobs:
               changes pass the writing standards review).
           claude_args: |
             --model claude-sonnet-5
-            --allowedTools "mcp__github_inline_comment__create_inline_comment,Bash(gh pr diff:*),Bash(gh pr view:*),Bash(gh pr comment:*)"
+            --allowedTools "mcp__github_inline_comment__create_inline_comment,Bash(gh pr diff:*),Bash(gh pr view:*),Bash(gh pr comment:*),Bash(gh issue view:*),Bash(gh release view:*),Bash(gh api repos/powersync-ja/:*)"
diff --git a/configuration/powersync-service/self-hosted-instances.mdx b/configuration/powersync-service/self-hosted-instances.mdx
index d1dc6259..af5f292e 100644
--- a/configuration/powersync-service/self-hosted-instances.mdx
+++ b/configuration/powersync-service/self-hosted-instances.mdx
@@ -505,6 +505,12 @@ storage:
   Read preference for bulk checksum and bucket data reads: `primary`, `primaryPreferred`, `secondary`, `secondaryPreferred`, or `nearest`. If unset, MongoDB driver defaults are used. This is an experimental option and may be removed in a future release. Available since Service version 1.23.2.
 </ResponseField>
 
+<ResponseField name="chunk_compaction_concurrency" type="number">
+  Maximum number of buckets that chunk-merge compaction processes at the same time on [storage version 4](/sync/advanced/storage-version-4). Defaults to `4` when `object_storage` is configured, otherwise `2`. Must be between 1 and 64. Full compaction still processes one bucket at a time.
+
+  Chunk-merge compaction runs after initial replication, before the new Sync Config becomes active, and as part of scheduled [`compact`](/maintenance-ops/compacting-buckets) runs. With object storage, request latency, not processing, takes most of the time per bucket. A higher value lets the Service merge more buckets during those waits, which shortens the delay before activation. All compaction jobs in a Service process share this limit. Available since Service version 1.26.1.
+</ResponseField>
+
 <ResponseField name="object_storage" type="object">
   Stores large blocks of bucket data in Amazon S3 or an S3-compatible object store instead of MongoDB. Requires Service version 1.26.0 or later with [storage version 4](/sync/advanced/storage-version-4) (Beta), which is not currently the default. Sync Configs on version 2 keep all data in MongoDB even when this is configured.
 
@@ -535,8 +541,8 @@ storage:
     <ResponseField name="secret_access_key" type="string">
       Secret access key for authentication.
     </ResponseField>
-    <ResponseField name="concurrency_limit" type="number" default="16">
-      Maximum number of concurrent object storage requests.
+    <ResponseField name="concurrency_limit" type="number" default="64">
+      Maximum number of concurrent object storage requests. Service versions before 1.26.1 default to `16`.
     </ResponseField>
     <ResponseField name="defaults_mode" type="string" default="standard">
       Sets the timeouts for all object storage requests at once, based on the expected latency between the Service and the object storage endpoint, mirroring the AWS SDK's [smart configuration defaults](https://docs.aws.amazon.com/sdkref/latest/guide/feature-smart-config-defaults.html). `standard` is safe for most deployments, so you can usually leave this unset. Use `in-region` when the Service and the bucket run in the same region and you want stalled requests to fail faster, or `mobile` when the endpoint is slow enough that the standard timeouts cause spurious failures. `cross-region` is accepted for compatibility with the AWS SDK.