Document pending activity SDK and application upgrades

conformance/README.md

@@ -240,6 +240,34 @@ before startup. This qualifies the selected package pairs and helper changes;
 other durable operations, build routing and incompatible class adoption need
 their own cases.
 
+Use the separate [pending activity SDK/application command](https://github.com/durable-workflow/sample-app/blob/main/polyglot/activities/README.md#pending-activities-across-sdk-and-application-upgrades)
+for work scheduled before both package and business-helper replacement:
+
+```bash
+SDK_ACTIVITY_UPGRADES_COMPOSE_PROJECT_NAME=sample-app-activity-upgrades \
+  scripts/sdk-activity-upgrades.sh
+```
+
+Run from the prepared Sample App checkout with its published tuple resolved.
+Report eighteen originals separately: nine previous-package workflows with a
+genuinely unstarted activity, then nine fresh current-package controls covering
+every PHP/Python/Rust workflow/activity direction. Build and verify both package
+generations before admission. Old helpers record version `1` with bounds `1..1`
+and the original activity policy; cold current workers use revision-two helpers
+and execute that same pending work. Fresh controls select version `2`, bounds
+`1..2` and the new policy.
+
+Require the complete original history prefix, original run and activity/attempt
+identities, command sequences, full retry list/timeouts and exact typed activity
+and workflow results. Activities execute once on the selected current package,
+after worker replacement and inside the original total budget. Python's
+registered wrapper and recorded definition remain unchanged. Keep the command's
+pending/result observer bounds and automatic project/image cleanup. This covers
+the selected pending-activity package/helper pairs; incompatible class adoption,
+build routing, other durable operations and application side-effect recovery
+retain their separate gates. Record the actual packages, runner SHA, Server
+digest and all eighteen outcomes in the owning audit.
+
 The [Sample App Rust search-attribute experiment](https://github.com/durable-workflow/sample-app/blob/main/polyglot/search-attributes/README.md)
 authors all seven types through the published Rust workflow API. PHP and Python
 clients verify selected-run values and server-side equality, integer/float

conformance/sdk-coverage.md

@@ -48,6 +48,7 @@ Their SDK installation lists do not widen that scope.
 | Version introduction: Sample App `scripts/sdk-timers.sh --unversioned-upgrades` | Twelve separate originals: old and fresh single/concurrent runs in PHP, Python and Rust. Old code schedules timers without a marker. Cold replacement code introduces the numeric version helper with minimum -1 and maximum 2. The same old runs retain no marker, resolve legacy -1 and preserve their complete original prefixes, timer/barrier identities, sequences and deadlines. Fresh runs record version 2 before new timer commands. Typed results, stable registered wrappers and one completion remain required. | This covers introducing versioning around the selected timer operations. Keep its twelve outcomes separate from the default forty. Both helper implementations are bundled and selected before process startup. Other durable operations, SDK package upgrades, build routing and incompatible class adoption require separate cases. |
 | SDK package timer upgrades: Sample App `scripts/sdk-timers.sh --sdk-upgrades` | Twelve separate originals across PHP, Python and Rust: old-package single/concurrent histories replayed by cold current-package workers and fresh current-package controls. Both image generations are built before admission, with installed/compiled package identity and exact registered SDK checks. Every original timer fires during worker absence, then the same run completes once with unchanged complete prefix, timer/barrier identities, sequences, deadlines and typed result. Python's recorded class binding stays exact; no version marker is introduced. | Selected baseline versions and current qualified targets are explicit manifests. This covers only those actual pairs and timer operations with unchanged application code. Other durable operations, combined package/application changes, build routing and incompatible class adoption require separate cases. Keep these twelve outcomes separate from the forty timer and twelve version-introduction cases. |
 | Combined SDK and application timer upgrades: Sample App `scripts/sdk-timers.sh --sdk-application-upgrades` | Twelve separate originals across PHP, Python and Rust. Six old-package single/concurrent runs record helper version one with bounds 1..1. Their timers fire while workers are absent, then cold current-package workers use helper revision two to finish the same originals with the original decision, marker bounds, full prefix, timers, barriers, command sequences and deadlines. Six fresh controls use the new branch and bounds 1..2. Actual installed packages, original/replacement worker identities, typed results, one completion and Python's recorded definition binding are checked. | Both helpers ship under unchanged registered wrappers and are selected before startup. This covers the selected package pairs and helper changes, not arbitrary source or class adoption. Other durable operations, build routing and incompatible class adoption require separate cases. Report these twelve outcomes separately from the other timer commands. |
+| Pending activity SDK/application upgrades: Sample App `scripts/sdk-activity-upgrades.sh` | Eighteen separate originals across every PHP/Python/Rust workflow/activity direction. Nine previous-package workflows record version 1/range 1..1 and leave their activity unstarted. Cold current-package workers use revision-two helpers, execute the same original activity once and complete the same workflow with its full original prefix, marker, policy, command sequence, identities and typed results. Nine fresh controls select version 2/range 1..2 and the changed policy. Both image generations and installed/registered package identities are verified before admission; Python's recorded definition remains bound to the unchanged wrapper. | This covers the selected package pairs and versioned helper changes around one pending remote activity. It does not qualify incompatible class adoption, build routing, other durable operations, an activity callback interrupted by the upgrade or external side-effect recovery. Report all eighteen actual outcomes separately from timer and recovery experiments; source verifier tests alone establish no package replay. |
 | Sagas: Server `sagas-published-artifacts.sh`; Sample App `polyglot/sagas/` | Server's PHP/Python workflow-compensation directions; Sample App's five Rust-involving directions, typed compensation failure and restart before compensation. | Process loss during an external compensation side effect, duplicate delivery and external-effect recovery require explicit side-effect fixtures. Restart before compensation does not establish them. |
 | Schedules: Server `schedules-published-artifacts.sh`; Sample App `polyglot/schedules/` | PHP/Python creators and workers in Server; PHP and Python creators targeting Rust in Sample App. | The Rust examples check one automatic interval fire. Run cadence, restart, overlap/backfill and failure recovery for those directions. Calendar folds/gaps are temporal cases, not extra creator languages. |
 | Signals and queries: Server `signals-queries-published-artifacts.sh` | PHP/Python/Rust clients and workers, including cross-language calls, Rust query immutability and cold-restarted instance state. | Read the direction-specific scenarios and histories. The crate pin alone proves none of them. |