docs: catch up to response-cap rework and fix broken links

- Fix two pre-existing broken links that were failing Docs CI
  (access-log-spec.md → log-shipping/README.md; log-shipping
  README → GitHub URL for the JSON schema).
- Add orphan pages WIRE_PROTOCOL.md and porting-guide.md to the
  Guides nav so mkdocs --strict stops failing on them.
- Update hosting.md to document max_response_bytes and the new
  max_externalized_response_bytes knob.
- Rewrite the WIRE_PROTOCOL.md continuation-batch section for the
  soft/hard cap semantics.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: rustyconover

docs/WIRE_PROTOCOL.md

@@ -576,10 +576,15 @@ Response body:
   [IPC stream: output_schema, (log* + data)*, EOS]
 ```
 
-All produced data batches are included inline. If the response would exceed
-`max_stream_response_bytes`, the server truncates the output and appends a
-**continuation batch**: a zero-row batch with `vgi_rpc.stream_state#b64` in its
-custom metadata. The client then follows up with `/exchange` requests.
+All produced data batches are included inline. If the response body would
+exceed `max_response_bytes` (the operator-configured HTTP body cap), the
+server stops producing and appends a **continuation batch**: a zero-row
+batch with `vgi_rpc.stream_state#b64` in its custom metadata. The client
+then follows up with `/exchange` requests carrying that token. For
+producer streams the wire cap is *soft* — continuation tokens cover the
+overshoot. The companion cap `max_externalized_response_bytes` governs
+external-channel uploads independently and is *hard*: a producer that
+would exceed it surfaces an `RpcError` rather than continuing.
 
 #### Exchange stream init response
 

docs/access-log-spec.md

@@ -168,4 +168,4 @@ The exit code is `0` if every record passes, `1` if any record fails, `2` if the
 - Python JSON formatter: `vgi_rpc/logging_utils.py` (`VgiJsonFormatter`)
 - Python validator: `vgi_rpc/access_log_conformance.py`
 - Cross-language conformance overview: [`cross-language-conformance.md`](cross-language-conformance.md)
-- Reference shipper configs (Vector and Fluent Bit, S3/GCS/Azure): [`log-shipping/`](log-shipping/)
+- Reference shipper configs (Vector and Fluent Bit, S3/GCS/Azure): [`log-shipping/`](log-shipping/README.md)

docs/hosting.md

@@ -38,7 +38,8 @@ app = make_wsgi_app(
 | `signing_key` | HMAC-SHA256 key for stream state tokens | Random per-process (breaks multi-worker!) |
 | `prefix` | URL path prefix for RPC endpoints | `/vgi` |
 | `max_request_bytes` | Advertised request size limit | None (unlimited) |
-| `max_stream_response_bytes` | Split large producer stream responses | None (single response) |
+| `max_response_bytes` | HTTP body cap (every method).  Soft for producer streams (continuation tokens); hard for unary + exchange (200 + EXCEPTION batch on overshoot) | None (unlimited) |
+| `max_externalized_response_bytes` | Cap on bytes uploaded to external storage per HTTP response.  Always hard.  Pre-flighted before the upload | None (unlimited) |
 | `max_upload_bytes` | Advertised upload size limit | None (unlimited) |
 | `authenticate` | Auth callback `(Request) → AuthContext` | None (anonymous) |
 | `cors_origins` | Enable CORS for browser clients | None (disabled) |
@@ -312,7 +313,7 @@ handler = make_lambda_handler(app)
 - Set `externalize_threshold_bytes` well below the payload limit (512 KB is a good starting point) to leave headroom for log batches and metadata
 - Use zstd compression — it reduces S3 storage and fetch time
 - Store the signing key in AWS Secrets Manager and cache it in the Lambda init phase
-- For producer streams, enable `max_stream_response_bytes` to split large streaming responses across multiple exchanges
+- For producer streams, set `max_response_bytes` to split large streaming responses across multiple HTTP turns; the server mints continuation tokens at the cap and the client transparently resumes
 
 ### Cloudflare Workers
 

docs/log-shipping/README.md

@@ -39,4 +39,4 @@ vgi-rpc deliberately does **not** include an in-process uploader. Vector and Flu
 
 ## Validating downstream
 
-The access-log JSON Schema at [`vgi_rpc/access_log.schema.json`](../../vgi_rpc/access_log.schema.json) is authoritative. Use it to validate records after they land in your bucket — for example, with `jsonschema-cli` or DuckDB's `read_json_auto` plus a CHECK constraint.
+The access-log JSON Schema at [`vgi_rpc/access_log.schema.json`](https://github.com/Query-farm/vgi-rpc-python/blob/main/vgi_rpc/access_log.schema.json) is authoritative. Use it to validate records after they land in your bucket — for example, with `jsonschema-cli` or DuckDB's `read_json_auto` plus a CHECK constraint.

mkdocs.yml

@@ -134,7 +134,9 @@ nav:
     - Access Log: access-log.md
     - Access Log Specification: access-log-spec.md
     - Log Shipping: log-shipping/README.md
+    - Wire Protocol: WIRE_PROTOCOL.md
     - Conformance Testing: cross-language-conformance.md
+    - Cross-Language Porting Guide: porting-guide.md
   - About:
     - Benchmarks: benchmarks.md
     - Comparison: comparison.md