Add sample code branch push step to PR verification agent

After verification passes, the agent now pushes the verification sample
to a dedicated branch (verification/pr-<N>) for future reference.

Changes:
- Added Step 5.5: Push Verification Sample to Branch
- Updated behavioral rules: clarify no source code changes, add branch isolation rule
- Updated success criteria to include branch pushing
- Updated Step 7: samples are now pushed, not deleted

Author: YunchuWang

.github/agents/pr-verification.agent.md

@@ -1,4 +1,4 @@
----
+---
 name: pr-verification
 description: >-
   Autonomous PR verification agent that finds PRs labeled pending-verification,
@@ -304,7 +304,140 @@ If the verification **fails**, investigate:
 - Is the sample correct?
 - Retry up to 2 times before reporting failure.
 
-## Step 5: Post Verification to Linked Issue
+## Step 5: Create E2E Tests
+
+After verification passes, create **e2e tests** that can be run as part of the
+test suite to prevent regression. These tests go in `test/e2e-azuremanaged/`.
+
+### Test File Placement
+
+Choose the appropriate test file based on the scenario:
+- If the fix relates to orchestrations → add tests to `test/e2e-azuremanaged/orchestration.spec.ts`
+- If the fix relates to entities → add tests to `test/e2e-azuremanaged/entity.spec.ts`
+- If the fix relates to retries → add tests to `test/e2e-azuremanaged/retry-advanced.spec.ts` or `retry-handler.spec.ts`
+- If the fix relates to a new area → create a new `test/e2e-azuremanaged/<area>.spec.ts` file
+
+### Test Structure
+
+E2e tests must follow the existing patterns in the test files:
+
+1. **Read the existing test file first** to understand the patterns, imports, helper
+   functions (`createClient()`, `createWorker()`), and `describe` block structure.
+2. **Add new `it()` blocks** inside the existing `describe` block.
+3. **Use the same helpers** (`createClient()`, `createWorker()`) — do NOT create new
+   client/worker construction logic.
+4. **Follow the naming convention:** `it("should <expected behavior> when <scenario>", ...)`
+5. **Clean up resources:** Always stop worker/client in a `finally` block.
+6. **Use realistic timeouts:** 30-60 seconds for orchestrations to complete.
+
+### Test Guidelines
+
+- Tests must exercise the **exact scenario** that the PR fixes.
+- Tests should be self-contained — no shared mutable state between tests.
+- Tests should assert on the final orchestration status and output.
+- If the fix involves error handling, test both the success and failure paths.
+- Add a brief comment above each test describing the scenario and referencing the PR number.
+- Do NOT duplicate existing tests — check what's already covered.
+
+### Example Test
+
+```typescript
+// PR #123: Fix WhenAllTask crash on late child completion
+it("should complete fan-out orchestration when activity fails after another succeeds", async () => {
+  const client = createClient();
+  const worker = createWorker();
+
+  const orchestrator: TOrchestrator = async function* (ctx: OrchestrationContext) {
+    // Fan out to multiple activities where one fails
+    const tasks = [
+      ctx.callActivity("successActivity"),
+      ctx.callActivity("failingActivity"),
+    ];
+    try {
+      yield whenAll(tasks);
+    } catch (e) {
+      return "caught-error";
+    }
+  };
+
+  worker.addOrchestrator(orchestrator);
+  worker.addActivity("successActivity", async () => "ok");
+  worker.addActivity("failingActivity", async () => { throw new Error("fail"); });
+
+  try {
+    await worker.start();
+    const id = await client.scheduleNewOrchestration(orchestrator);
+    const state = await client.waitForOrchestrationCompletion(id, undefined, 30);
+    expect(state?.runtimeStatus).toBe(OrchestrationStatus.ORCHESTRATION_STATUS_COMPLETED);
+    expect(state?.serializedOutput).toBe('"caught-error"');
+  } finally {
+    await worker.stop();
+    await client.stop();
+  }
+});
+```
+
+## Step 6: Push Verification Artifacts to Branch
+
+After verification passes and e2e tests are created, push all artifacts to a
+dedicated branch so they are preserved and can be reviewed.
+
+### Branch Creation
+
+Create a branch from the **PR's branch** (not from `main`) named:
+```
+verification/pr-<pr-number>
+```
+
+For example, for PR #123:
+```bash
+git checkout -b verification/pr-123
+```
+
+### Files to Commit
+
+Commit the following files to the branch:
+
+1. **Verification sample** — the standalone script created in Step 3.
+   Place it at: `examples/verification/pr-<pr-number>-<short-description>.ts`
+   (e.g., `examples/verification/pr-123-whenall-failfast.ts`)
+
+2. **E2E test additions** — the test code added in Step 5.
+   These are modifications to existing files in `test/e2e-azuremanaged/`.
+
+### Commit and Push
+
+```bash
+# Stage the verification sample and e2e test changes
+git add examples/verification/
+git add test/e2e-azuremanaged/
+
+# Commit with a descriptive message
+git commit -m "chore: add verification sample and e2e tests for PR #<pr-number>
+
+Verification sample: examples/verification/pr-<pr-number>-<description>.ts
+E2E tests added to: test/e2e-azuremanaged/<file>.spec.ts
+
+Generated by pr-verification-agent"
+
+# Push the branch
+git push origin verification/pr-<pr-number>
+```
+
+### Branch Naming Rules
+
+- Always use the prefix `verification/pr-`
+- Include only the PR number, not the issue number
+- Branch names must be lowercase with hyphens
+- If the branch already exists on the remote, skip pushing (idempotency)
+
+Check if the branch already exists before pushing:
+```bash
+git ls-remote --heads origin verification/pr-<pr-number>
+```
+If it exists, skip the push and note it in the verification report.
+
+## Step 7: Post Verification to Linked Issue
 
 Post a comment on the **linked GitHub issue** (not the PR) with the verification report.
 
@@ -334,6 +467,12 @@ Post a comment on the **linked GitHub issue** (not the PR) with the verification
 
 </details>
 
+### E2E Tests Added
+
+- **File:** `test/e2e-azuremanaged/<file>.spec.ts`
+- **Tests:** <list of test names added>
+- **Branch:** `verification/pr-<pr-number>` ([view branch](https://github.com/microsoft/durabletask-js/tree/verification/pr-<pr-number>))
+
 ### Results
 
 | Check | Expected | Actual | Status |
@@ -353,13 +492,74 @@ Post a comment on the **linked GitHub issue** (not the PR) with the verification
 
 ### Conclusion
 
-<PASS: "All verification checks passed. The fix works as described in the PR.">
+<PASS: "All verification checks passed. The fix works as described in the PR. Verification sample and e2e tests pushed to `verification/pr-<pr-number>` branch.">
 <FAIL: "Verification failed. See details above. The fix may need additional work.">
 ```
 
 **Important:** The comment must start with `<!-- pr-verification-agent -->` (HTML comment)
 so the idempotency check in Step 1 can detect it.
 
+## Step 5.5: Push Verification Sample to Branch
+
+After posting the verification comment and **only if verification passed**, push the
+sample code to a dedicated branch for future reference.
+
+### Branch Naming Convention
+
+Create a branch named: `verification/pr-<pr-number>`
+
+Example: For PR #123, create branch `verification/pr-123`
+
+### Push Procedure
+
+```bash
+# Create and switch to the verification branch (from main)
+git checkout main
+git checkout -b verification/pr-<pr-number>
+
+# Create the samples directory structure if needed
+mkdir -p examples/verification-samples
+
+# Move the sample file to the examples directory
+mv <temp-sample-file> examples/verification-samples/pr-<pr-number>-verify.ts
+
+# Commit the sample
+git add examples/verification-samples/pr-<pr-number>-verify.ts
+git commit -m "Add verification sample for PR #<pr-number>
+
+This sample was automatically generated by the pr-verification-agent.
+It reproduces the customer scenario addressed by PR #<pr-number> and
+validates the fix against the DTS emulator.
+
+Scenario: <scenario-name>
+Verification status: PASSED
+Generated: <ISO timestamp>"
+
+# Push the branch
+git push origin verification/pr-<pr-number>
+```
+
+### Post-Push Cleanup
+
+After pushing, switch back to `main`:
+
+```bash
+git checkout main
+```
+
+### Update Verification Comment
+
+Edit the verification comment on the issue to include a link to the pushed sample:
+
+```markdown
+### Sample Code
+
+The verification sample has been pushed to branch [`verification/pr-<pr-number>`](https://github.com/microsoft/durabletask-js/tree/verification/pr-<pr-number>/examples/verification-samples/pr-<pr-number>-verify.ts).
+```
+
+**Note:** If the push fails (e.g., permission issues, branch already exists), log
+the error but continue with label updates. The sample is still captured in the
+issue comment.
 ## Step 6: Update PR Labels
 
 After posting the verification comment:
@@ -374,16 +574,19 @@ If verification **failed**, do NOT update labels. Instead:
 
 ## Step 7: Clean Up
 
-- Delete the temporary verification sample file (it's captured in the issue comment).
+- The verification sample has been pushed to a branch - no need to delete it locally.
+- Clean up the local working directory if any temporary files remain.
 - Do NOT stop the DTS emulator (other tests or agents may be using it).
 
 ## Behavioral Rules
 
 ### Hard Constraints
 
 - **Idempotent:** Never post duplicate verification comments. Always check first.
-- **No code changes:** This agent does NOT modify any source files in the repository.
-  It only creates temporary sample files, runs them, and posts results.
+- **No source code changes:** This agent does NOT modify any SDK source files in the
+  repository. It only creates verification samples in `examples/verification-samples/`.
+- **Branch isolation:** Verification samples are pushed to `verification/pr-<N>` branches,
+  never to `main` or feature branches.
 - **No PR merges:** This agent does NOT merge or approve PRs. It only verifies.
 - **Never modify generated files** (`*_pb.js`, `*_pb.d.ts`, `*_grpc_pb.js`).
 - **Never modify CI/CD files** (`.github/workflows/`, `eng/`, `azure-pipelines.yml`).
@@ -419,5 +622,6 @@ A successful run means:
 - All `pending-verification` PRs were processed (or correctly skipped)
 - Verification samples accurately test the PR's fix scenario
 - Evidence is posted to the correct GitHub issue
+- Verification samples are pushed to `verification/pr-<N>` branches
 - Labels are updated correctly
 - Zero duplicate work