Split Web acceptance into four jobs and require focused validation

.github/workflows/check.yml

@@ -240,7 +240,7 @@ jobs:
     strategy:
       fail-fast: false
       matrix:
-        shard: [1, 2]
+        shard: [1, 2, 3, 4]
     runs-on: ${{ vars.OAC_USE_GITHUB_RUNNERS == 'true' && 'ubuntu-22.04' || 'blacksmith-2vcpu-ubuntu-2204' }}
     timeout-minutes: 15
     steps:
@@ -253,7 +253,7 @@ jobs:
           make node-deps
           pnpm exec playwright install --with-deps chrome
       - name: Verify Web workflows against isolated fixtures
-        run: make check-web-acceptance OAC_WEB_TEST_SHARD=${{ matrix.shard }}/2
+        run: make check-web-acceptance OAC_WEB_TEST_SHARD=${{ matrix.shard }}/${{ strategy.job-total }}
       - name: Upload browser failure evidence
         if: failure()
         uses: actions/upload-artifact@v6

CONTRIBUTING.md

@@ -102,7 +102,9 @@ Toolchain setup and focused commands are in [Develop OpenAgentCore](docs/develop
 
 ### Checks for a change
 
-Run the checks for the changed behavior and its consumers before completion, including database migration and cross-component tests when affected. Use the [CI selection policy](docs/maintainers.md#continuous-integration) to determine the relevant groups; record what passed and any validation limits. A small follow-up needs its relevant checks, not another unrelated full run. The [Makefile](Makefile) retains `make check` as the complete local gate; main CI follows the linked selection policy, and releases require the full gate. [Live acceptance](#live-acceptance) qualifies native execution beyond fixtures and builds.
+Validate only the current diff and the behavior and consumers it directly affects. Choose the smallest focused checks that establish the change is correct; include migration or cross-component tests only when those behaviors are affected. A code review, documentation edit or CI configuration change does not require a full repository test run. After a follow-up edit, rerun only checks affected by that edit. Record what passed and any validation limits.
+
+The [CI selection policy](docs/maintainers.md#continuous-integration) identifies affected groups; it does not require running every target in a selected group locally when narrower checks cover the change. The [Makefile](Makefile) keeps `make check` available for an explicitly requested full validation and release qualification. Releases require the full gate. [Live acceptance](#live-acceptance) applies when native execution behavior is affected.
 
 ### Test database
 

docs/development.md

@@ -79,7 +79,7 @@ Use the [protocol map](https://github.com/MiniMax-AI/OpenAgentCore/blob/main/AGE
 
 ## Validate a change
 
-Run checks for the affected boundary while developing. The repository [required checks](https://github.com/MiniMax-AI/OpenAgentCore/blob/main/CONTRIBUTING.md#required-checks) define completion, including `make check` and any changed native component's real acceptance.
+Choose focused checks for the current diff and its directly affected behavior using [Checks for a change](https://github.com/MiniMax-AI/OpenAgentCore/blob/main/CONTRIBUTING.md#checks-for-a-change). The table below lists entry points for each boundary; choose the relevant tests within them.
 
 | Change | Focused validation |
 | --- | --- |

docs/maintainers.md

@@ -158,7 +158,7 @@ The planner compares the PR event's tested merge commit with its verified first
 | `harness` | Claude SDK tests and packaging, MiniMax companion scripts |
 | `example` | Optional application typecheck, tests, build and isolated browser acceptance |
 | `web` | TypeScript, Web/client tests and Web build |
-| `web-acceptance` | Full Web browser suite in two isolated shards after Web unit/build success; each keeps one worker |
+| `web-acceptance` | Full Web browser suite in four isolated shards after Web unit/build success; each keeps one worker |
 | `api` | Reusable official-client acceptance against standalone commands and migrations; image acceptance when image/build/helper inputs change, and in every full gate |
 | `native` | Reusable Linux, macOS and Windows builds, filesystem/process/Harness checks and native installation; all three platforms can run concurrently |
 | `lint` | Reusable actionlint check, including local composite actions |
@@ -167,22 +167,22 @@ Known workflow changes select their consumers: the CI review and actionlint work
 
 Go module and workspace inputs select backend, API (including the container), native and distribution checks. Node manifests, lockfiles and package-manager configuration select Harness, example, Web, Web acceptance and native checks. The root TypeScript configuration selects Web and example checks; the adapter TypeScript configuration retains the Node consumer group. Each selected set includes hygiene. Mixed changes accumulate their consumers, and every job reads the same plan instead of maintaining its own path list. For example, a notification-only PR skips database, browser and native jobs, while a notification plus Core change adds backend and API checks.
 
-Ordinary Markdown and documentation-site configuration run hygiene only, including documentation inside source directories. Generated catalog files and configuration reference sections retain their distribution freshness checks. Core `.go`, `.sql`, helper scripts and configuration inputs select backend/API checks; Web source, styles and assets select Web checks. Embedded native assets and declared test fixture directories select their consumers regardless of suffix, including Markdown prompts and extensionless data. Installer changes add distribution checks. Web changes add Web checks and both browser shards; Core/DB changes add backend and official-client acceptance. Shared contracts, SDKs, Runtime inputs and dependencies propagate to their consumers according to the planner. Generated catalog and protocol inputs include the installer, client and UI consumers. Do not duplicate path lists in reusable workflows or put a `paths` filter on the required workflow.
+Ordinary Markdown and documentation-site configuration run hygiene only, including documentation inside source directories. Generated catalog files and configuration reference sections retain their distribution freshness checks. Core `.go`, `.sql`, helper scripts and configuration inputs select backend/API checks; Web source, styles and assets select Web checks. Embedded native assets and declared test fixture directories select their consumers regardless of suffix, including Markdown prompts and extensionless data. Installer changes add distribution checks. Web changes add Web checks and all browser shards; Core/DB changes add backend and official-client acceptance. Shared contracts, SDKs, Runtime inputs and dependencies propagate to their consumers according to the planner. Generated catalog and protocol inputs include the installer, client and UI consumers. Do not duplicate path lists in reusable workflows or put a `paths` filter on the required workflow.
 
 The final `check` runs even when planning or a dependency fails. It requires a successful, valid plan, every selected job to be successful, and every unselected job to be skipped. Failure, cancellation, a missing job, an unexpected skip or an unexpected execution fails the gate. API/native reusable workflows are direct dependencies of this gate. A newer run on the same PR cancels its predecessor. Release checks run at their requested immutable ref; native packaging executes once inside those checks, and the distribution build waits for them.
 
 Browser jobs own separate fixtures and servers; increasing workers against the shared mutable fixture is unsafe. Failed browser jobs retain reports/traces for seven days. Native failure phase summaries are retained for seven days and detailed output stays in the Actions logs; credentials and temporary installation trees are not uploaded. Successful native archives are uploaded only for explicit manual packaging or releases, without recompressing the compressed archive. Release distribution artifacts retain their existing recovery policy; failed publication can reuse the original build as described above.
 
 The local Node composite action installs the pinned pnpm and caches its package store by lockfile, OS, architecture, Node version and pnpm version. It caches downloaded packages, not `node_modules`; installs remain frozen. Go partitions retain the existing module/compiler caches described under [publication](#publish-a-version). Cache hits seed work and never replace tests. The three native platforms run independently; parallel execution reduces elapsed time without reducing total machine time.
 
-For a local change, inspect the selected groups and run their Makefile targets from the table and workflows:
+For a local change, inspect the selected groups and choose focused checks according to [Checks for a change](../CONTRIBUTING.md#checks-for-a-change):
 
 ```sh
 python3 scripts/ci_plan.py plan --base origin/main --head HEAD
 make check-ci
 ```
 
-`make check` remains the full local entry point with an unsharded Web suite and an unsharded store package. `make check-web-unit` and `make check-web-acceptance OAC_WEB_TEST_SHARD=1/2` expose the Web parts; `make check-core-packages` and `make check-core-store OAC_CORE_STORE_SHARD=1/3` expose the Core parts, with store tests assigned to shards by a stable hash of their names. The selection tests cover mixed changes, shared consumers, renames/deletions, unknown inputs, shallow merge checkouts and failed/cancelled/missing results. Changes to the map or workflow graph also require actionlint and replay of representative PR diffs; exercise real documentation, installer, Web and Core runs before relying on new selection rules.
+`make check` remains the full local entry point with an unsharded Web suite and an unsharded store package. `make check-web-unit` and `make check-web-acceptance OAC_WEB_TEST_SHARD=1/4` expose the Web parts; `make check-core-packages` and `make check-core-store OAC_CORE_STORE_SHARD=1/3` expose the Core parts, with store tests assigned to shards by a stable hash of their names. The selection tests cover mixed changes, shared consumers, renames/deletions, unknown inputs, shallow merge checkouts and failed/cancelled/missing results. For changes to the selection map, replay representative diffs for the affected rules. For workflow changes, run actionlint and validate the changed scheduling or partition behavior. Use real component runs only when needed to validate behavior affected by the change.
 
 Measure completed runs with `python3 scripts/ci_metrics.py RUN_ID ...`. It reports the latest attempt's summed runner minutes, elapsed time and initial queue delay from that attempt's start, peak concurrent jobs, platform breakdown and job outcomes/failure fraction. Only jobs assigned a runner in that attempt contribute machine time and execution concurrency; jobs cancelled while queued retain their outcome and wall time. Earlier attempts are not included. Failed-job reruns can carry earlier successful results: their outcomes appear separately and their old execution time is excluded. A missing rerun start timestamp stops measurement because reused jobs cannot be separated reliably. Keep run/head/attempt identities with comparisons, and report cancellations and unfinished runs separately. Raw runner minutes are not billed minutes; use each platform's published conversion and allowance rules before estimating cost. A small successful sample is not a long-term failure-rate estimate. Scheduled full runs are outside this policy.