{"owner":"gfx-rs","repo":"wgpu","hasSkills":true,"totalSkillsCount":4,"totalTokensCount":4681,"categories":["root-instruction","anthropic-skill","claude-rule"],"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md",".claude/skills/webgpu-specs/SKILL.md",".claude/skills/webgpu-specs/download.sh",".claude/skills/cts-triage/SKILL.md"],"skills":{"AGENTS.md":"# wgpu Project Structure\n\nwgpu is a GPU API written in pure rust. Changes of any significance need to apply across the stack.\n\n- `naga` is our shader translator. It is responsible for consuming and translating untrusted shaders to trusted shader code.\n- `wgpu-types` are the common types used on both Native and WASM.\n- `naga-types` holds the shader-language types, such as target versions and binding maps, that `naga` and `wgpu-core` both use.\n- `wgpu-naga-bridge` converts between `naga` and `wgpu-types`. It maps wgpu features and downlevel flags to naga validation capabilities.\n- `wgpu-sync` are the common synchronization primitives that abstract over platform differences.\n- `wgpu-hal` does not provide the validation required for safety. Its callers must satisfy its safety contracts.\n- `wgpu-core` does all the validation and provides a coherent interface.\n- `wgpu-core-remote` provides the ID abstraction needed by Firefox and Deno.\n- `wgpu-core-remote-types` holds the IPC types that `wgpu-core-remote` sends between the untrusted content process and the trusted GPU process. They are defined separately from the `wgpu-core` types, so untrusted content cannot express non-standard features.\n- `wgpu` is an ergonomic Rust interface to `wgpu-core`\n- `deno_webgpu` contains the WebGPU bindings for Deno.\n\n`wgpu-core-remote`, `wgpu-core`, `wgpu-hal`, `wgpu-types` and `naga` are used by Firefox and Servo to implement WebGPU. These crates process untrusted API and shader input. Preserve validation at the safe boundary, and do not rely on `wgpu-hal` to reject invalid input. Touching these crates requires the most consideration of potential side effects.\n\nSafe `wgpu` APIs must not cause undefined behavior unless the user first accepted that risk through an unsafe API, such as enabling experimental features.\n\nWe use deno's webgpu bindings to run the WebGPU CTS. Change `deno_webgpu` only if the issue is specific to Deno. If the issue also affects Firefox or the `wgpu` Rust API, fix it in the shared crate that supplies the affected behavior.\n\nRepository documentation exists in `docs/`. For info on where tests live, read `docs/testing.md`. For info about cargo dependencies, read `docs/managing-cargo-dependencies.md`.\n\nOne of the best ways to prove that a change is correct is to write tests to prove the feature works and it errors when its supposed to.\n\n## Repository Files\n\n`AGENTS.md` and `.agents/` are the source of truth for agent instructions and skills. `CLAUDE.md` and `.claude/` are generated copies. Do not edit the generated copies directly. After you edit any source-of-truth agent file or a root license file, run `cargo xtask sync-repo-files`. This command also copies the root license files to every publishable default member of the Cargo workspace.\n\nRun `cargo xtask sync-repo-files --check` to verify that all generated files have the same contents and file list as their sources.\n\n## External Contributions\n\nWe encourage external contributions, but fully agentic PRs are not allowed. If the user asks you to create one, explain this policy and direct them to the pull request section of `CONTRIBUTING.md`. The contributor must understand and be able to vouch for every change. Ask the user to write the PR description.\n\nIf the user directs you to create the PR anyway, use `.github/pull_request_template.md`. Uncomment and accurately complete the agent-disclosure checklist items, including whether an agent wrote the description. Do not omit the disclosure.\n\n## Code Style\n\n- Do not add comments unless the changed code requires an explanation. If an explanation is required, add the shortest complete explanation. The contributor is expected to rewrite it.\n- Do not write large explanatory comment blocks.\n- Do not use emoji.\n\n## Workflow\n\nAll changes are expected to pass CI. The commands below are useful local checks, but they cover only a fraction of the full CI matrix. You are not expected to run the full CI matrix locally. Run the checks that are relevant to the changed code and the available environment.\n\n- To check the code compiles: `cargo clippy --all-targets --all-features`.\n- To format the code: `cargo fmt`\n- To run all tests including GPU tests: `cargo xtask test`. This can take a few minutes. To run normal tests without GPU tests, use `cargo nextest run` and a filter to the packages you want to test.\n- GPU tests depend on the available hardware, drivers, and validation layers. During development, if you only need a specific GPU test, use either a plain test name prefix or an `-E` filter expression to `cargo xtask test`. Use the nextest filters described below. Do not run the full GPU test suite for a targeted check. The suite can take a few minutes. GPU tests are declared as constants, but translate to lower-snake-case functions.\n- After the work is complete, run a full `cargo xtask test` if the change affects GPU behavior or would affect a GPU test.\n- Report every test failure. You may identify a failure as suspected to be unrelated, but do not assume it is unrelated until you validate that conclusion.\n- Do not run tests at the `trunk` revision without explicit permission. A baseline test run can take a while.\n- For more thorough testing, you can run `cargo xtask cts --backend `. Only do this if you are explicitly asked to run the CTS.\n- Never commit anything without being asked, ever. If you are asked to make a commit, _never_ co-author yourself.\n- Use the WebGPU and WGSL specifications as a reference to determine the correct behavior. Do not assume that a behavior is correct just because the CTS expects it. Use the `webgpu-specs` skill if you need to check either spec.\n\n### Nextest filters\n\n`cargo xtask test` forwards its extra arguments to cargo-nextest.\n\n- A plain positional filter matches test names that contain the filter text. A unique test name prefix is usually sufficient.\n- `-E 'test(name)'` matches test names that contain `name`.\n- `-E 'test(=name)'` matches the complete test name.\n- `-E 'test(/expression/)'` matches test names with a regular expression.\n- In an `-E` expression, `package(name)` restricts the package and `binary(name)` restricts the test binary. Restricting binaries can make test startup quicker.\n- Use `&` for intersection, `|` for union, and `!` for exclusion. Use parentheses to group expressions.\n- For example, `-E 'binary(wgpu-gpu) & test(buffer) & !test(map)'` selects tests in the `wgpu-gpu` binary whose names contain `buffer` but not `map`.\n- Quote each `-E` expression so the shell does not interpret its operators.\n\n## Changelog\n\nWe maintain a changelog in CHANGELOG.md. Changes should be noted in the changelog if they are user-visible (changes to documented public APIs, significant bug fixes, or new functionality). We generally do not consider changes to wgpu-core, wgpu-hal, wgpu-core-remote, or wgpu-core-remote-types worthy of changelogs, unless a `wgpu` user is expected to interface with them directly. Changelog descriptions should be concise. If you are not sure whether something should be in the CHANGELOG or you are not sure how to describe the change, ask the user for guidance.\n",".claude/skills/webgpu-specs/SKILL.md":"---\nname: webgpu-specs\ndescription: Download WebGPU and WGSL specifications for use as a reference\nallowed-tools: \"Bash(sh .agents/skills/webgpu-specs/download.sh)\"\n---\n\nRun `sh .agents/skills/webgpu-specs/download.sh` to download the\nWebGPU and WGSL specifications if they are not present or if they have\nbeen updated. You do not need to change directory before running the script.\n\nAfter the specs are downloaded, you can search in `target/claude/webgpu-spec.bs`\nand `target/claude/wgsl-spec.bs` for relevant sections of the specification.\n\nWhen referencing the specifications, prefer to use named anchors rather than\nline numbers. For example, to reference the \"Object Descriptors\" section, which has the\nfollowing header:\n\n```\n### Object Descriptors ### {#object-descriptors}\n```\n\nUse the URL so the user\ncan click to navigate directly to that section.\n\nFor the WGSL specification, the base URL is .\n\nIf necessary, read additional content from the file to find the header preceding\nthe text you want to reference. You may provide line numbers as additional\ncontext, but always make every effort to provide the user with a clickable link.\n",".claude/skills/webgpu-specs/download.sh":"#!/bin/sh\n\nset -e\n\nTARGET_DIR=\"$(cargo metadata --format-version 1 | jq -r \".target_directory\")\"\n\nWEBGPU=\"$TARGET_DIR/claude/webgpu-spec\"\nWGSL=\"$TARGET_DIR/claude/wgsl-spec\"\nmkdir -p \"$TARGET_DIR/claude\"\n\nif [ -f \"$WEBGPU.etag\" ]; then\n curl --etag-save \"$WEBGPU.etag.new\" --etag-compare \"$WEBGPU.etag\" -fsSL https://raw.githubusercontent.com/gpuweb/gpuweb/main/spec/index.bs -o \"$WEBGPU.bs\"\n [ -s \"$WEBGPU.etag.new\" ] && mv \"$WEBGPU.etag.new\" \"$WEBGPU.etag\" || rm \"$WEBGPU.etag.new\"\nelse\n curl --etag-save \"$WEBGPU.etag\" https://raw.githubusercontent.com/gpuweb/gpuweb/main/spec/index.bs -o \"$WEBGPU.bs\"\nfi\n\nif [ -f \"$WGSL.etag\" ]; then\n curl --etag-save \"$WGSL.etag.new\" --etag-compare \"$WGSL.etag\" -fsSL https://raw.githubusercontent.com/gpuweb/gpuweb/main/wgsl/index.bs -o \"$WGSL.bs\"\n [ -s \"$WGSL.etag.new\" ] && mv \"$WGSL.etag.new\" \"$WGSL.etag\" || rm \"$WGSL.etag.new\"\nelse\n curl --etag-save \"$WGSL.etag\" https://raw.githubusercontent.com/gpuweb/gpuweb/main/wgsl/index.bs -o \"$WGSL.bs\"\nfi\n",".claude/skills/cts-triage/SKILL.md":"---\nname: cts-triage\ndescription: Run CTS test suites and investigate failures\n---\n\n# Triage Process\n\nWhen working on a category of CTS tests, follow this systematic process to identify issues, prioritize fixes, and document findings.\n\n## Step 0: Divide Into Manageable Chunks\n\nList all the tests matching a selector:\n\n```bash\ncargo xtask cts -- --list 'webgpu:api,validation,*' 2>&1 | wc -l\n```\n\nIf there is a reasonable number of tests matching the selector (less than a\ncouple hundred or so, but this isn't a hard cutoff), then you can proceed with\ntriage. Otherwise, make a list of more detailed wildcards that match fewer\ntests, verify that each wildcard matches a reasonable number of tests, and\ntriage each wildcard separately.\n\n## Step 1: Get Overall Statistics\n\nRun the full test suite for the category to understand the scope:\n\n```bash\ncargo xtask cts 'webgpu:api,validation,category:*' 2>&1 | grep -E \"(Summary|Passed|Failed)\" | tail -5\n```\n\nThis gives you the pass rate and number of failures. Document this as your baseline.\n\n## Step 2: Identify Test Subcategories\n\nReview the output from the running the CTS (with or without `--list`) to\nidentify any subcategories that may exist within the suite being analyzed.\nSubcategories typically have an additional `:`- or `,`-delimited word in the\ntest name. Running tests by subcategory may be more manageable than running\nwith the entire suite at once or running individual tests.\n\n## Step 3: Run Each Subcategory\n\nTest each subcategory individually to identify which ones are passing vs failing:\n\n```bash\ncargo xtask cts 'webgpu:api,validation,category:subcategory:*' 2>&1 | grep -E \"(Passed|Failed|Skipped)\" | tail -3\n```\n\nTrack the pass rate for each subcategory. This helps you identify:\n\n- What's already working (don't break it!)\n- Where the failures are concentrated\n- Which issues affect multiple categories\n\n## Step 4: Analyze Failure Patterns\n\nFor failing subcategories, look at what tests are failing:\n\n```bash\ncargo xtask cts 'webgpu:api,validation,category:subcategory:*' 2>&1 | grep \"\\[fail\\]\" | head -20\n```\n\nLook for patterns:\n\n- **Format-specific failures**: May indicate missing format capability checks\n- **Parameter-specific failures**: Validation missing for specific parameter combinations\n\n## Step 5: Examine Specific Failures\n\nPick a representative failing test and run it individually to see the error:\n\n```bash\ncargo xtask cts 'webgpu:api,validation,category:subcategory:specific_test' 2>&1 | tail -30\n```\n\nLook for:\n\n- **\"EXPECTATION FAILED: DID NOT REJECT\"**: wgpu is accepting invalid input (validation gap)\n- **\"Validation succeeded unexpectedly\"**: Similar to above\n- **\"Unexpected validation error occurred\"**: wgpu is rejecting valid input\n- **Error message content**: Tells you what validation is triggering or missing\n\n## Step 6: Check CTS Test Source\n\nTo understand what the test expects, read the TypeScript source:\n\n```bash\ngrep -A 40 \"test_name\" cts/src/webgpu/api/validation/path/file.spec.ts\n```\n\nThe test source shows:\n\n- What configurations are being tested\n- What the expected behavior is (pass/fail)\n- The validation rules from the WebGPU spec\n- Comments explaining the rationale\n\n## Step 7: Categorize Issues\n\nGroup failures into categories:\n\n**High Priority - Validation Gaps:**\n\n- wgpu accepts invalid configurations that should fail\n- Security or correctness implications\n- Example: Accepting wrong texture formats, missing aspect checks\n\n**Medium Priority - Spec Compliance:**\n\n- Edge cases not handled correctly\n- Optional field validation issues\n- Example: depthCompare optional field handling\n\n**Low Priority - Minor Gaps:**\n\n- Less common scenarios\n- Limited real-world impact\n- Example: Depth bias with non-triangle topologies\n\n**Known Issues - Skip:**\n\n- Known failure patterns (documented in Common Patterns below)\n- Track count but don't try to fix\n\n## Step 8: Identify Root Causes\n\nFor validation gaps, find where validation should happen:\n\n1. **Search for existing validation:**\n\n ```bash\n grep -n \"relevant_keyword\" wgpu-core/src/device/resource.rs\n ```\n\n2. **Look for render/compute pipeline creation:**\n - Render pipeline: `wgpu-core/src/device/resource.rs` around `create_render_pipeline`\n - Compute pipeline: Similar location\n - Look for existing validation patterns you can follow\n\n3. **Check for helper functions:**\n\n ```bash\n grep \"fn is_\" wgpu-types/src/texture/format.rs\n ```\n\n4. **Find error enums:**\n ```bash\n grep \"pub enum.*Error\" wgpu-core/src/pipeline.rs\n ```\n\n## Step 9: Implement Fixes\n\nWhen implementing fixes:\n\n1. **Add error variants if needed** (in `wgpu-core/src/pipeline.rs`)\n2. **Add helper methods** (in `wgpu-types` if checking properties)\n3. **Add validation checks** (in `wgpu-core/src/device/resource.rs`)\n4. **Test the fix** with specific failing tests\n5. **Run full subcategory** to verify all related tests pass\n6. **Check you didn't break passing tests**\n\n## Step 10: Document Findings\n\nCreate or update a triage document (e.g., `category_triage.md`).\n\nDo not write information about changes you have made to the triage document. Only capture the state of the tests and any investigation into open issues.\n\n````markdown\n# Category CTS Tests - Triage Report\n\n**Overall Status:** XP/YF/ZS (%/%/%)\n\n## Passing Sub-suites ✅\n\n[List sub-suites that have no failures (all pass or skip)]\n\n## Remaining Issues ⚠️\n\n[List sub-suites that have failures and if it can be stated concisely, a summary of the issue]\n\n## Issue Detail\n\n[List detail of any investigation into failures. Do not go into detail about passed suites, just list the failures.]\n\n### 1. title, e.g. a distinguishing word from the test selector\n\n**Test selector:** `webgpu:api,validation,render_pipeline,depth_stencil_state:format:*`\n**What it tests:** [Description]\n**Example failure:**\n[a selector for a single failing test, e.g.:]\n\n```\nwebgpu:api,validation,render_pipeline,depth_stencil_state:depthCompare_optional:isAsync=false;format=\"stencil8\"\n```\n\n**Error:**\n[error message from the failing tests, e.g.:]\n\n```\nUnexpected validation error occurred: Depth/stencil state is invalid:\nFormat Stencil8 does not have a depth aspect, but depth test/write is enabled\n```\n\n**Root cause:**\n[Your analysis of the root cause. Do not speculate. Only include the results of specific investigation you have done.]\nThe validation is triggering incorrectly. When `depthCompare` is undefined/missing in JavaScript, it's getting translated to a default value that makes `is_depth_enabled()` return true, even for stencil-only formats.\n\n**Fix needed:**\n[Your proposed fix. Again, do not speculate. Only state the fix if it is obvious from the root cause analysis, or if you have done specific investigation into how to fix it.]\n\n### 2. title\n\n[repeat as needed for additional issues]\n````\n\n## Step 11: Update CTS Result Lists\n\nThe result lists have these purposes:\n\n- `cts_runner/test.lst` contains sets of tests with no failures. It is not an\n exhaustive list of passing sets of tests.\n- `cts_runner/fail.lst` contains sets of tests with failures. A comment can record\n the pass rate, especially when the pass rate is high.\n- `cts_runner/skip.lst` contains sets of tests in which at least 90% of the tests\n are skipped.\n\nIf you fix a set of tests, add it to `cts_runner/test.lst` only when all of its\ntests pass or skip. Do not add a set of tests that has any failures.\n\nUse wildcards to minimize the number of selectors:\n\n```\nwebgpu:api,validation,category:subcategory:isAsync=false;*\n```\n\nUse a higher-level wildcard only when all tests that it matches belong in the\nsame result list. Do not use a wildcard that also matches tests from another\nresult list.\n\nKeep the selectors in the order that the `lst_files_are_sorted` integration\ntest requires. This rule also applies to selectors in comments.\n\n## Step 12: Verify and Build\n\nBefore finishing:\n\n```bash\n# Format code\ncargo fmt\n\n# Check for errors\ncargo clippy --tests\n\n# Build to ensure no compilation errors\ncargo build\n\n# Run the tests you added to test.lst\ncargo xtask cts 'webgpu:api,validation,category:subcategory:isAsync=false;*'\n```\n\n# Common Patterns\n\nIf the user asked to investigate a failure, and the cause of the failure is\nnoted here with \"do not attempt to fix\", then stop and ask the user before\nattempting to fix.\n\n**Pattern: Format-specific failures**\n\n- Check if format validation is missing\n- Look for `is_depth_stencil_format()`, `is_color_format()` etc.\n- May need to add format capability checks\n\n**Pattern: Aspect-related failures**\n\n- Check if code validates format aspects (DEPTH, STENCIL, COLOR)\n- Use `hal::FormatAspects::from(format)` to check\n- Validate operations match available aspects\n\n**Pattern: Optional field failures**\n\n- May be WebGPU optional field semantics issue\n- Check if undefined in JS becomes a default value in Rust\n- May need to distinguish \"not set\" from \"set to default\"\n\n**Pattern: Atomics accepted incorrectly**\n\n- Naga allows referencing an atomic directly in an expression\n- Should only allow accessing via `atomicLoad`, `atomicStore`, etc.\n- Only investigate as necessary to confirm this is the issue. Do not attempt to fix. Refer user to https://github.com/gfx-rs/wgpu/issues/5474.\n\n**Pattern: Error reporting for destroyed resources**\n\n- Tests that check for validation errors when a destroyed resource is used. `wgpu` often reports these errors later than WebGPU requires, causing the tests to fail.\n- `wgpu` may report these errors earlier than it should, causing the test to fail with an unexpected validation error.\n- Look for:\n - Tests with `state=\"destroyed\"` parameter\n - Tests checking that operations on destroyed buffers or textures should fail\n- Example failing tests:\n - `webgpu:api,validation,encoding,cmds,compute_pass:indirect_dispatch_buffer_state:` with `state=\"destroyed\"` subcases\n- Only investigate as necessary to confirm this is the issue. Do not attempt to fix. Refer user to https://github.com/gfx-rs/wgpu/issues/7881.\n\n# Tips\n\n- **Start with high-impact fixes**: Validation gaps with security implications\n- **Look for existing patterns**: Other validation code shows the style\n- **Test incrementally**: Fix one category at a time, verify it works\n- **Document as you go**: Don't wait until the end to write the triage\n- **Ask for clarification**: If test expectations are unclear, check the WebGPU spec or test source\n- **Track your progress**: Update pass rates as you fix issues\n"},"files":{"AGENTS.md":"# wgpu Project Structure\n\nwgpu is a GPU API written in pure rust. Changes of any significance need to apply across the stack.\n\n- `naga` is our shader translator. It is responsible for consuming and translating untrusted shaders to trusted shader code.\n- `wgpu-types` are the common types used on both Native and WASM.\n- `naga-types` holds the shader-language types, such as target versions and binding maps, that `naga` and `wgpu-core` both use.\n- `wgpu-naga-bridge` converts between `naga` and `wgpu-types`. It maps wgpu features and downlevel flags to naga validation capabilities.\n- `wgpu-sync` are the common synchronization primitives that abstract over platform differences.\n- `wgpu-hal` does not provide the validation required for safety. Its callers must satisfy its safety contracts.\n- `wgpu-core` does all the validation and provides a coherent interface.\n- `wgpu-core-remote` provides the ID abstraction needed by Firefox and Deno.\n- `wgpu-core-remote-types` holds the IPC types that `wgpu-core-remote` sends between the untrusted content process and the trusted GPU process. They are defined separately from the `wgpu-core` types, so untrusted content cannot express non-standard features.\n- `wgpu` is an ergonomic Rust interface to `wgpu-core`\n- `deno_webgpu` contains the WebGPU bindings for Deno.\n\n`wgpu-core-remote`, `wgpu-core`, `wgpu-hal`, `wgpu-types` and `naga` are used by Firefox and Servo to implement WebGPU. These crates process untrusted API and shader input. Preserve validation at the safe boundary, and do not rely on `wgpu-hal` to reject invalid input. Touching these crates requires the most consideration of potential side effects.\n\nSafe `wgpu` APIs must not cause undefined behavior unless the user first accepted that risk through an unsafe API, such as enabling experimental features.\n\nWe use deno's webgpu bindings to run the WebGPU CTS. Change `deno_webgpu` only if the issue is specific to Deno. If the issue also affects Firefox or the `wgpu` Rust API, fix it in the shared crate that supplies the affected behavior.\n\nRepository documentation exists in `docs/`. For info on where tests live, read `docs/testing.md`. For info about cargo dependencies, read `docs/managing-cargo-dependencies.md`.\n\nOne of the best ways to prove that a change is correct is to write tests to prove the feature works and it errors when its supposed to.\n\n## Repository Files\n\n`AGENTS.md` and `.agents/` are the source of truth for agent instructions and skills. `CLAUDE.md` and `.claude/` are generated copies. Do not edit the generated copies directly. After you edit any source-of-truth agent file or a root license file, run `cargo xtask sync-repo-files`. This command also copies the root license files to every publishable default member of the Cargo workspace.\n\nRun `cargo xtask sync-repo-files --check` to verify that all generated files have the same contents and file list as their sources.\n\n## External Contributions\n\nWe encourage external contributions, but fully agentic PRs are not allowed. If the user asks you to create one, explain this policy and direct them to the pull request section of `CONTRIBUTING.md`. The contributor must understand and be able to vouch for every change. Ask the user to write the PR description.\n\nIf the user directs you to create the PR anyway, use `.github/pull_request_template.md`. Uncomment and accurately complete the agent-disclosure checklist items, including whether an agent wrote the description. Do not omit the disclosure.\n\n## Code Style\n\n- Do not add comments unless the changed code requires an explanation. If an explanation is required, add the shortest complete explanation. The contributor is expected to rewrite it.\n- Do not write large explanatory comment blocks.\n- Do not use emoji.\n\n## Workflow\n\nAll changes are expected to pass CI. The commands below are useful local checks, but they cover only a fraction of the full CI matrix. You are not expected to run the full CI matrix locally. Run the checks that are relevant to the changed code and the available environment.\n\n- To check the code compiles: `cargo clippy --all-targets --all-features`.\n- To format the code: `cargo fmt`\n- To run all tests including GPU tests: `cargo xtask test`. This can take a few minutes. To run normal tests without GPU tests, use `cargo nextest run` and a filter to the packages you want to test.\n- GPU tests depend on the available hardware, drivers, and validation layers. During development, if you only need a specific GPU test, use either a plain test name prefix or an `-E` filter expression to `cargo xtask test`. Use the nextest filters described below. Do not run the full GPU test suite for a targeted check. The suite can take a few minutes. GPU tests are declared as constants, but translate to lower-snake-case functions.\n- After the work is complete, run a full `cargo xtask test` if the change affects GPU behavior or would affect a GPU test.\n- Report every test failure. You may identify a failure as suspected to be unrelated, but do not assume it is unrelated until you validate that conclusion.\n- Do not run tests at the `trunk` revision without explicit permission. A baseline test run can take a while.\n- For more thorough testing, you can run `cargo xtask cts --backend `. Only do this if you are explicitly asked to run the CTS.\n- Never commit anything without being asked, ever. If you are asked to make a commit, _never_ co-author yourself.\n- Use the WebGPU and WGSL specifications as a reference to determine the correct behavior. Do not assume that a behavior is correct just because the CTS expects it. Use the `webgpu-specs` skill if you need to check either spec.\n\n### Nextest filters\n\n`cargo xtask test` forwards its extra arguments to cargo-nextest.\n\n- A plain positional filter matches test names that contain the filter text. A unique test name prefix is usually sufficient.\n- `-E 'test(name)'` matches test names that contain `name`.\n- `-E 'test(=name)'` matches the complete test name.\n- `-E 'test(/expression/)'` matches test names with a regular expression.\n- In an `-E` expression, `package(name)` restricts the package and `binary(name)` restricts the test binary. Restricting binaries can make test startup quicker.\n- Use `&` for intersection, `|` for union, and `!` for exclusion. Use parentheses to group expressions.\n- For example, `-E 'binary(wgpu-gpu) & test(buffer) & !test(map)'` selects tests in the `wgpu-gpu` binary whose names contain `buffer` but not `map`.\n- Quote each `-E` expression so the shell does not interpret its operators.\n\n## Changelog\n\nWe maintain a changelog in CHANGELOG.md. Changes should be noted in the changelog if they are user-visible (changes to documented public APIs, significant bug fixes, or new functionality). We generally do not consider changes to wgpu-core, wgpu-hal, wgpu-core-remote, or wgpu-core-remote-types worthy of changelogs, unless a `wgpu` user is expected to interface with them directly. Changelog descriptions should be concise. If you are not sure whether something should be in the CHANGELOG or you are not sure how to describe the change, ask the user for guidance.\n",".claude/skills/webgpu-specs/SKILL.md":"---\nname: webgpu-specs\ndescription: Download WebGPU and WGSL specifications for use as a reference\nallowed-tools: \"Bash(sh .agents/skills/webgpu-specs/download.sh)\"\n---\n\nRun `sh .agents/skills/webgpu-specs/download.sh` to download the\nWebGPU and WGSL specifications if they are not present or if they have\nbeen updated. You do not need to change directory before running the script.\n\nAfter the specs are downloaded, you can search in `target/claude/webgpu-spec.bs`\nand `target/claude/wgsl-spec.bs` for relevant sections of the specification.\n\nWhen referencing the specifications, prefer to use named anchors rather than\nline numbers. For example, to reference the \"Object Descriptors\" section, which has the\nfollowing header:\n\n```\n### Object Descriptors ### {#object-descriptors}\n```\n\nUse the URL so the user\ncan click to navigate directly to that section.\n\nFor the WGSL specification, the base URL is .\n\nIf necessary, read additional content from the file to find the header preceding\nthe text you want to reference. You may provide line numbers as additional\ncontext, but always make every effort to provide the user with a clickable link.\n",".claude/skills/webgpu-specs/download.sh":"#!/bin/sh\n\nset -e\n\nTARGET_DIR=\"$(cargo metadata --format-version 1 | jq -r \".target_directory\")\"\n\nWEBGPU=\"$TARGET_DIR/claude/webgpu-spec\"\nWGSL=\"$TARGET_DIR/claude/wgsl-spec\"\nmkdir -p \"$TARGET_DIR/claude\"\n\nif [ -f \"$WEBGPU.etag\" ]; then\n curl --etag-save \"$WEBGPU.etag.new\" --etag-compare \"$WEBGPU.etag\" -fsSL https://raw.githubusercontent.com/gpuweb/gpuweb/main/spec/index.bs -o \"$WEBGPU.bs\"\n [ -s \"$WEBGPU.etag.new\" ] && mv \"$WEBGPU.etag.new\" \"$WEBGPU.etag\" || rm \"$WEBGPU.etag.new\"\nelse\n curl --etag-save \"$WEBGPU.etag\" https://raw.githubusercontent.com/gpuweb/gpuweb/main/spec/index.bs -o \"$WEBGPU.bs\"\nfi\n\nif [ -f \"$WGSL.etag\" ]; then\n curl --etag-save \"$WGSL.etag.new\" --etag-compare \"$WGSL.etag\" -fsSL https://raw.githubusercontent.com/gpuweb/gpuweb/main/wgsl/index.bs -o \"$WGSL.bs\"\n [ -s \"$WGSL.etag.new\" ] && mv \"$WGSL.etag.new\" \"$WGSL.etag\" || rm \"$WGSL.etag.new\"\nelse\n curl --etag-save \"$WGSL.etag\" https://raw.githubusercontent.com/gpuweb/gpuweb/main/wgsl/index.bs -o \"$WGSL.bs\"\nfi\n",".claude/skills/cts-triage/SKILL.md":"---\nname: cts-triage\ndescription: Run CTS test suites and investigate failures\n---\n\n# Triage Process\n\nWhen working on a category of CTS tests, follow this systematic process to identify issues, prioritize fixes, and document findings.\n\n## Step 0: Divide Into Manageable Chunks\n\nList all the tests matching a selector:\n\n```bash\ncargo xtask cts -- --list 'webgpu:api,validation,*' 2>&1 | wc -l\n```\n\nIf there is a reasonable number of tests matching the selector (less than a\ncouple hundred or so, but this isn't a hard cutoff), then you can proceed with\ntriage. Otherwise, make a list of more detailed wildcards that match fewer\ntests, verify that each wildcard matches a reasonable number of tests, and\ntriage each wildcard separately.\n\n## Step 1: Get Overall Statistics\n\nRun the full test suite for the category to understand the scope:\n\n```bash\ncargo xtask cts 'webgpu:api,validation,category:*' 2>&1 | grep -E \"(Summary|Passed|Failed)\" | tail -5\n```\n\nThis gives you the pass rate and number of failures. Document this as your baseline.\n\n## Step 2: Identify Test Subcategories\n\nReview the output from the running the CTS (with or without `--list`) to\nidentify any subcategories that may exist within the suite being analyzed.\nSubcategories typically have an additional `:`- or `,`-delimited word in the\ntest name. Running tests by subcategory may be more manageable than running\nwith the entire suite at once or running individual tests.\n\n## Step 3: Run Each Subcategory\n\nTest each subcategory individually to identify which ones are passing vs failing:\n\n```bash\ncargo xtask cts 'webgpu:api,validation,category:subcategory:*' 2>&1 | grep -E \"(Passed|Failed|Skipped)\" | tail -3\n```\n\nTrack the pass rate for each subcategory. This helps you identify:\n\n- What's already working (don't break it!)\n- Where the failures are concentrated\n- Which issues affect multiple categories\n\n## Step 4: Analyze Failure Patterns\n\nFor failing subcategories, look at what tests are failing:\n\n```bash\ncargo xtask cts 'webgpu:api,validation,category:subcategory:*' 2>&1 | grep \"\\[fail\\]\" | head -20\n```\n\nLook for patterns:\n\n- **Format-specific failures**: May indicate missing format capability checks\n- **Parameter-specific failures**: Validation missing for specific parameter combinations\n\n## Step 5: Examine Specific Failures\n\nPick a representative failing test and run it individually to see the error:\n\n```bash\ncargo xtask cts 'webgpu:api,validation,category:subcategory:specific_test' 2>&1 | tail -30\n```\n\nLook for:\n\n- **\"EXPECTATION FAILED: DID NOT REJECT\"**: wgpu is accepting invalid input (validation gap)\n- **\"Validation succeeded unexpectedly\"**: Similar to above\n- **\"Unexpected validation error occurred\"**: wgpu is rejecting valid input\n- **Error message content**: Tells you what validation is triggering or missing\n\n## Step 6: Check CTS Test Source\n\nTo understand what the test expects, read the TypeScript source:\n\n```bash\ngrep -A 40 \"test_name\" cts/src/webgpu/api/validation/path/file.spec.ts\n```\n\nThe test source shows:\n\n- What configurations are being tested\n- What the expected behavior is (pass/fail)\n- The validation rules from the WebGPU spec\n- Comments explaining the rationale\n\n## Step 7: Categorize Issues\n\nGroup failures into categories:\n\n**High Priority - Validation Gaps:**\n\n- wgpu accepts invalid configurations that should fail\n- Security or correctness implications\n- Example: Accepting wrong texture formats, missing aspect checks\n\n**Medium Priority - Spec Compliance:**\n\n- Edge cases not handled correctly\n- Optional field validation issues\n- Example: depthCompare optional field handling\n\n**Low Priority - Minor Gaps:**\n\n- Less common scenarios\n- Limited real-world impact\n- Example: Depth bias with non-triangle topologies\n\n**Known Issues - Skip:**\n\n- Known failure patterns (documented in Common Patterns below)\n- Track count but don't try to fix\n\n## Step 8: Identify Root Causes\n\nFor validation gaps, find where validation should happen:\n\n1. **Search for existing validation:**\n\n ```bash\n grep -n \"relevant_keyword\" wgpu-core/src/device/resource.rs\n ```\n\n2. **Look for render/compute pipeline creation:**\n - Render pipeline: `wgpu-core/src/device/resource.rs` around `create_render_pipeline`\n - Compute pipeline: Similar location\n - Look for existing validation patterns you can follow\n\n3. **Check for helper functions:**\n\n ```bash\n grep \"fn is_\" wgpu-types/src/texture/format.rs\n ```\n\n4. **Find error enums:**\n ```bash\n grep \"pub enum.*Error\" wgpu-core/src/pipeline.rs\n ```\n\n## Step 9: Implement Fixes\n\nWhen implementing fixes:\n\n1. **Add error variants if needed** (in `wgpu-core/src/pipeline.rs`)\n2. **Add helper methods** (in `wgpu-types` if checking properties)\n3. **Add validation checks** (in `wgpu-core/src/device/resource.rs`)\n4. **Test the fix** with specific failing tests\n5. **Run full subcategory** to verify all related tests pass\n6. **Check you didn't break passing tests**\n\n## Step 10: Document Findings\n\nCreate or update a triage document (e.g., `category_triage.md`).\n\nDo not write information about changes you have made to the triage document. Only capture the state of the tests and any investigation into open issues.\n\n````markdown\n# Category CTS Tests - Triage Report\n\n**Overall Status:** XP/YF/ZS (%/%/%)\n\n## Passing Sub-suites ✅\n\n[List sub-suites that have no failures (all pass or skip)]\n\n## Remaining Issues ⚠️\n\n[List sub-suites that have failures and if it can be stated concisely, a summary of the issue]\n\n## Issue Detail\n\n[List detail of any investigation into failures. Do not go into detail about passed suites, just list the failures.]\n\n### 1. title, e.g. a distinguishing word from the test selector\n\n**Test selector:** `webgpu:api,validation,render_pipeline,depth_stencil_state:format:*`\n**What it tests:** [Description]\n**Example failure:**\n[a selector for a single failing test, e.g.:]\n\n```\nwebgpu:api,validation,render_pipeline,depth_stencil_state:depthCompare_optional:isAsync=false;format=\"stencil8\"\n```\n\n**Error:**\n[error message from the failing tests, e.g.:]\n\n```\nUnexpected validation error occurred: Depth/stencil state is invalid:\nFormat Stencil8 does not have a depth aspect, but depth test/write is enabled\n```\n\n**Root cause:**\n[Your analysis of the root cause. Do not speculate. Only include the results of specific investigation you have done.]\nThe validation is triggering incorrectly. When `depthCompare` is undefined/missing in JavaScript, it's getting translated to a default value that makes `is_depth_enabled()` return true, even for stencil-only formats.\n\n**Fix needed:**\n[Your proposed fix. Again, do not speculate. Only state the fix if it is obvious from the root cause analysis, or if you have done specific investigation into how to fix it.]\n\n### 2. title\n\n[repeat as needed for additional issues]\n````\n\n## Step 11: Update CTS Result Lists\n\nThe result lists have these purposes:\n\n- `cts_runner/test.lst` contains sets of tests with no failures. It is not an\n exhaustive list of passing sets of tests.\n- `cts_runner/fail.lst` contains sets of tests with failures. A comment can record\n the pass rate, especially when the pass rate is high.\n- `cts_runner/skip.lst` contains sets of tests in which at least 90% of the tests\n are skipped.\n\nIf you fix a set of tests, add it to `cts_runner/test.lst` only when all of its\ntests pass or skip. Do not add a set of tests that has any failures.\n\nUse wildcards to minimize the number of selectors:\n\n```\nwebgpu:api,validation,category:subcategory:isAsync=false;*\n```\n\nUse a higher-level wildcard only when all tests that it matches belong in the\nsame result list. Do not use a wildcard that also matches tests from another\nresult list.\n\nKeep the selectors in the order that the `lst_files_are_sorted` integration\ntest requires. This rule also applies to selectors in comments.\n\n## Step 12: Verify and Build\n\nBefore finishing:\n\n```bash\n# Format code\ncargo fmt\n\n# Check for errors\ncargo clippy --tests\n\n# Build to ensure no compilation errors\ncargo build\n\n# Run the tests you added to test.lst\ncargo xtask cts 'webgpu:api,validation,category:subcategory:isAsync=false;*'\n```\n\n# Common Patterns\n\nIf the user asked to investigate a failure, and the cause of the failure is\nnoted here with \"do not attempt to fix\", then stop and ask the user before\nattempting to fix.\n\n**Pattern: Format-specific failures**\n\n- Check if format validation is missing\n- Look for `is_depth_stencil_format()`, `is_color_format()` etc.\n- May need to add format capability checks\n\n**Pattern: Aspect-related failures**\n\n- Check if code validates format aspects (DEPTH, STENCIL, COLOR)\n- Use `hal::FormatAspects::from(format)` to check\n- Validate operations match available aspects\n\n**Pattern: Optional field failures**\n\n- May be WebGPU optional field semantics issue\n- Check if undefined in JS becomes a default value in Rust\n- May need to distinguish \"not set\" from \"set to default\"\n\n**Pattern: Atomics accepted incorrectly**\n\n- Naga allows referencing an atomic directly in an expression\n- Should only allow accessing via `atomicLoad`, `atomicStore`, etc.\n- Only investigate as necessary to confirm this is the issue. Do not attempt to fix. Refer user to https://github.com/gfx-rs/wgpu/issues/5474.\n\n**Pattern: Error reporting for destroyed resources**\n\n- Tests that check for validation errors when a destroyed resource is used. `wgpu` often reports these errors later than WebGPU requires, causing the tests to fail.\n- `wgpu` may report these errors earlier than it should, causing the test to fail with an unexpected validation error.\n- Look for:\n - Tests with `state=\"destroyed\"` parameter\n - Tests checking that operations on destroyed buffers or textures should fail\n- Example failing tests:\n - `webgpu:api,validation,encoding,cmds,compute_pass:indirect_dispatch_buffer_state:` with `state=\"destroyed\"` subcases\n- Only investigate as necessary to confirm this is the issue. Do not attempt to fix. Refer user to https://github.com/gfx-rs/wgpu/issues/7881.\n\n# Tips\n\n- **Start with high-impact fixes**: Validation gaps with security implications\n- **Look for existing patterns**: Other validation code shows the style\n- **Test incrementally**: Fix one category at a time, verify it works\n- **Document as you go**: Don't wait until the end to write the triage\n- **Ask for clarification**: If test expectations are unclear, check the WebGPU spec or test source\n- **Track your progress**: Update pass rates as you fix issues\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","rawUrl":"https://raw.githubusercontent.com/gfx-rs/wgpu/HEAD/AGENTS.md","title":"AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"# wgpu Project Structure\n\nwgpu is a GPU API written in pure rust. Changes of any significance need to apply across the stack.\n\n- `naga` is our shader translator. It is responsible for consuming and translating untrusted shaders to trusted shader code.\n- `wgpu-types` are the common types used on both Native and WASM.\n- `naga-types` holds the shader-language types, such as target versions and binding maps, that `naga` and `wgpu-core` both use.\n- `wgpu-naga-bridge` converts between `naga` and `wgpu-types`. It maps wgpu features and downlevel flags to naga validation capabilities.\n- `wgpu-sync` are the common synchronization primitives that abstract over platform differences.\n- `wgpu-hal` does not provide the validation required for safety. Its callers must satisfy its safety contracts.\n- `wgpu-core` does all the validation and provides a coherent interface.\n- `wgpu-core-remote` provides the ID abstraction needed by Firefox and Deno.\n- `wgpu-core-remote-types` holds the IPC types that `wgpu-core-remote` sends between the untrusted content process and the trusted GPU process. They are defined separately from the `wgpu-core` types, so untrusted content cannot express non-standard features.\n- `wgpu` is an ergonomic Rust interface to `wgpu-core`\n- `deno_webgpu` contains the WebGPU bindings for Deno.\n\n`wgpu-core-remote`, `wgpu-core`, `wgpu-hal`, `wgpu-types` and `naga` are used by Firefox and Servo to implement WebGPU. These crates process untrusted API and shader input. Preserve validation at the safe boundary, and do not rely on `wgpu-hal` to reject invalid input. Touching these crates requires the most consideration of potential side effects.\n\nSafe `wgpu` APIs must not cause undefined behavior unless the user first accepted that risk through an unsafe API, such as enabling experimental features.\n\nWe use deno's webgpu bindings to run the WebGPU CTS. Change `deno_webgpu` only if the issue is specific to Deno. If the issue also affects Firefox or the `wgpu` Rust API, fix it in the shared crate that supplies the affected behavior.\n\nRepository documentation exists in `docs/`. For info on where tests live, read `docs/testing.md`. For info about cargo dependencies, read `docs/managing-cargo-dependencies.md`.\n\nOne of the best ways to prove that a change is correct is to write tests to prove the feature works and it errors when its supposed to.\n\n## Repository Files\n\n`AGENTS.md` and `.agents/` are the source of truth for agent instructions and skills. `CLAUDE.md` and `.claude/` are generated copies. Do not edit the generated copies directly. After you edit any source-of-truth agent file or a root license file, run `cargo xtask sync-repo-files`. This command also copies the root license files to every publishable default member of the Cargo workspace.\n\nRun `cargo xtask sync-repo-files --check` to verify that all generated files have the same contents and file list as their sources.\n\n## External Contributions\n\nWe encourage external contributions, but fully agentic PRs are not allowed. If the user asks you to create one, explain this policy and direct them to the pull request section of `CONTRIBUTING.md`. The contributor must understand and be able to vouch for every change. Ask the user to write the PR description.\n\nIf the user directs you to create the PR anyway, use `.github/pull_request_template.md`. Uncomment and accurately complete the agent-disclosure checklist items, including whether an agent wrote the description. Do not omit the disclosure.\n\n## Code Style\n\n- Do not add comments unless the changed code requires an explanation. If an explanation is required, add the shortest complete explanation. The contributor is expected to rewrite it.\n- Do not write large explanatory comment blocks.\n- Do not use emoji.\n\n## Workflow\n\nAll changes are expected to pass CI. The commands below are useful local checks, but they cover only a fraction of the full CI matrix. You are not expected to run the full CI matrix locally. Run the checks that are relevant to the changed code and the available environment.\n\n- To check the code compiles: `cargo clippy --all-targets --all-features`.\n- To format the code: `cargo fmt`\n- To run all tests including GPU tests: `cargo xtask test`. This can take a few minutes. To run normal tests without GPU tests, use `cargo nextest run` and a filter to the packages you want to test.\n- GPU tests depend on the available hardware, drivers, and validation layers. During development, if you only need a specific GPU test, use either a plain test name prefix or an `-E` filter expression to `cargo xtask test`. Use the nextest filters described below. Do not run the full GPU test suite for a targeted check. The suite can take a few minutes. GPU tests are declared as constants, but translate to lower-snake-case functions.\n- After the work is complete, run a full `cargo xtask test` if the change affects GPU behavior or would affect a GPU test.\n- Report every test failure. You may identify a failure as suspected to be unrelated, but do not assume it is unrelated until you validate that conclusion.\n- Do not run tests at the `trunk` revision without explicit permission. A baseline test run can take a while.\n- For more thorough testing, you can run `cargo xtask cts --backend `. Only do this if you are explicitly asked to run the CTS.\n- Never commit anything without being asked, ever. If you are asked to make a commit, _never_ co-author yourself.\n- Use the WebGPU and WGSL specifications as a reference to determine the correct behavior. Do not assume that a behavior is correct just because the CTS expects it. Use the `webgpu-specs` skill if you need to check either spec.\n\n### Nextest filters\n\n`cargo xtask test` forwards its extra arguments to cargo-nextest.\n\n- A plain positional filter matches test names that contain the filter text. A unique test name prefix is usually sufficient.\n- `-E 'test(name)'` matches test names that contain `name`.\n- `-E 'test(=name)'` matches the complete test name.\n- `-E 'test(/expression/)'` matches test names with a regular expression.\n- In an `-E` expression, `package(name)` restricts the package and `binary(name)` restricts the test binary. Restricting binaries can make test startup quicker.\n- Use `&` for intersection, `|` for union, and `!` for exclusion. Use parentheses to group expressions.\n- For example, `-E 'binary(wgpu-gpu) & test(buffer) & !test(map)'` selects tests in the `wgpu-gpu` binary whose names contain `buffer` but not `map`.\n- Quote each `-E` expression so the shell does not interpret its operators.\n\n## Changelog\n\nWe maintain a changelog in CHANGELOG.md. Changes should be noted in the changelog if they are user-visible (changes to documented public APIs, significant bug fixes, or new functionality). We generally do not consider changes to wgpu-core, wgpu-hal, wgpu-core-remote, or wgpu-core-remote-types worthy of changelogs, unless a `wgpu` user is expected to interface with them directly. Changelog descriptions should be concise. If you are not sure whether something should be in the CHANGELOG or you are not sure how to describe the change, ask the user for guidance.\n","isInternal":false,"tokens":1611,"sizeBytes":7142},{"name":"SKILL.md","path":".claude/skills/cts-triage/SKILL.md","rawUrl":"https://raw.githubusercontent.com/gfx-rs/wgpu/HEAD/.claude/skills/cts-triage/SKILL.md","title":"cts-triage","category":"anthropic-skill","format":"markdown","content":"---\nname: cts-triage\ndescription: Run CTS test suites and investigate failures\n---\n\n# Triage Process\n\nWhen working on a category of CTS tests, follow this systematic process to identify issues, prioritize fixes, and document findings.\n\n## Step 0: Divide Into Manageable Chunks\n\nList all the tests matching a selector:\n\n```bash\ncargo xtask cts -- --list 'webgpu:api,validation,*' 2>&1 | wc -l\n```\n\nIf there is a reasonable number of tests matching the selector (less than a\ncouple hundred or so, but this isn't a hard cutoff), then you can proceed with\ntriage. Otherwise, make a list of more detailed wildcards that match fewer\ntests, verify that each wildcard matches a reasonable number of tests, and\ntriage each wildcard separately.\n\n## Step 1: Get Overall Statistics\n\nRun the full test suite for the category to understand the scope:\n\n```bash\ncargo xtask cts 'webgpu:api,validation,category:*' 2>&1 | grep -E \"(Summary|Passed|Failed)\" | tail -5\n```\n\nThis gives you the pass rate and number of failures. Document this as your baseline.\n\n## Step 2: Identify Test Subcategories\n\nReview the output from the running the CTS (with or without `--list`) to\nidentify any subcategories that may exist within the suite being analyzed.\nSubcategories typically have an additional `:`- or `,`-delimited word in the\ntest name. Running tests by subcategory may be more manageable than running\nwith the entire suite at once or running individual tests.\n\n## Step 3: Run Each Subcategory\n\nTest each subcategory individually to identify which ones are passing vs failing:\n\n```bash\ncargo xtask cts 'webgpu:api,validation,category:subcategory:*' 2>&1 | grep -E \"(Passed|Failed|Skipped)\" | tail -3\n```\n\nTrack the pass rate for each subcategory. This helps you identify:\n\n- What's already working (don't break it!)\n- Where the failures are concentrated\n- Which issues affect multiple categories\n\n## Step 4: Analyze Failure Patterns\n\nFor failing subcategories, look at what tests are failing:\n\n```bash\ncargo xtask cts 'webgpu:api,validation,category:subcategory:*' 2>&1 | grep \"\\[fail\\]\" | head -20\n```\n\nLook for patterns:\n\n- **Format-specific failures**: May indicate missing format capability checks\n- **Parameter-specific failures**: Validation missing for specific parameter combinations\n\n## Step 5: Examine Specific Failures\n\nPick a representative failing test and run it individually to see the error:\n\n```bash\ncargo xtask cts 'webgpu:api,validation,category:subcategory:specific_test' 2>&1 | tail -30\n```\n\nLook for:\n\n- **\"EXPECTATION FAILED: DID NOT REJECT\"**: wgpu is accepting invalid input (validation gap)\n- **\"Validation succeeded unexpectedly\"**: Similar to above\n- **\"Unexpected validation error occurred\"**: wgpu is rejecting valid input\n- **Error message content**: Tells you what validation is triggering or missing\n\n## Step 6: Check CTS Test Source\n\nTo understand what the test expects, read the TypeScript source:\n\n```bash\ngrep -A 40 \"test_name\" cts/src/webgpu/api/validation/path/file.spec.ts\n```\n\nThe test source shows:\n\n- What configurations are being tested\n- What the expected behavior is (pass/fail)\n- The validation rules from the WebGPU spec\n- Comments explaining the rationale\n\n## Step 7: Categorize Issues\n\nGroup failures into categories:\n\n**High Priority - Validation Gaps:**\n\n- wgpu accepts invalid configurations that should fail\n- Security or correctness implications\n- Example: Accepting wrong texture formats, missing aspect checks\n\n**Medium Priority - Spec Compliance:**\n\n- Edge cases not handled correctly\n- Optional field validation issues\n- Example: depthCompare optional field handling\n\n**Low Priority - Minor Gaps:**\n\n- Less common scenarios\n- Limited real-world impact\n- Example: Depth bias with non-triangle topologies\n\n**Known Issues - Skip:**\n\n- Known failure patterns (documented in Common Patterns below)\n- Track count but don't try to fix\n\n## Step 8: Identify Root Causes\n\nFor validation gaps, find where validation should happen:\n\n1. **Search for existing validation:**\n\n ```bash\n grep -n \"relevant_keyword\" wgpu-core/src/device/resource.rs\n ```\n\n2. **Look for render/compute pipeline creation:**\n - Render pipeline: `wgpu-core/src/device/resource.rs` around `create_render_pipeline`\n - Compute pipeline: Similar location\n - Look for existing validation patterns you can follow\n\n3. **Check for helper functions:**\n\n ```bash\n grep \"fn is_\" wgpu-types/src/texture/format.rs\n ```\n\n4. **Find error enums:**\n ```bash\n grep \"pub enum.*Error\" wgpu-core/src/pipeline.rs\n ```\n\n## Step 9: Implement Fixes\n\nWhen implementing fixes:\n\n1. **Add error variants if needed** (in `wgpu-core/src/pipeline.rs`)\n2. **Add helper methods** (in `wgpu-types` if checking properties)\n3. **Add validation checks** (in `wgpu-core/src/device/resource.rs`)\n4. **Test the fix** with specific failing tests\n5. **Run full subcategory** to verify all related tests pass\n6. **Check you didn't break passing tests**\n\n## Step 10: Document Findings\n\nCreate or update a triage document (e.g., `category_triage.md`).\n\nDo not write information about changes you have made to the triage document. Only capture the state of the tests and any investigation into open issues.\n\n````markdown\n# Category CTS Tests - Triage Report\n\n**Overall Status:** XP/YF/ZS (%/%/%)\n\n## Passing Sub-suites ✅\n\n[List sub-suites that have no failures (all pass or skip)]\n\n## Remaining Issues ⚠️\n\n[List sub-suites that have failures and if it can be stated concisely, a summary of the issue]\n\n## Issue Detail\n\n[List detail of any investigation into failures. Do not go into detail about passed suites, just list the failures.]\n\n### 1. title, e.g. a distinguishing word from the test selector\n\n**Test selector:** `webgpu:api,validation,render_pipeline,depth_stencil_state:format:*`\n**What it tests:** [Description]\n**Example failure:**\n[a selector for a single failing test, e.g.:]\n\n```\nwebgpu:api,validation,render_pipeline,depth_stencil_state:depthCompare_optional:isAsync=false;format=\"stencil8\"\n```\n\n**Error:**\n[error message from the failing tests, e.g.:]\n\n```\nUnexpected validation error occurred: Depth/stencil state is invalid:\nFormat Stencil8 does not have a depth aspect, but depth test/write is enabled\n```\n\n**Root cause:**\n[Your analysis of the root cause. Do not speculate. Only include the results of specific investigation you have done.]\nThe validation is triggering incorrectly. When `depthCompare` is undefined/missing in JavaScript, it's getting translated to a default value that makes `is_depth_enabled()` return true, even for stencil-only formats.\n\n**Fix needed:**\n[Your proposed fix. Again, do not speculate. Only state the fix if it is obvious from the root cause analysis, or if you have done specific investigation into how to fix it.]\n\n### 2. title\n\n[repeat as needed for additional issues]\n````\n\n## Step 11: Update CTS Result Lists\n\nThe result lists have these purposes:\n\n- `cts_runner/test.lst` contains sets of tests with no failures. It is not an\n exhaustive list of passing sets of tests.\n- `cts_runner/fail.lst` contains sets of tests with failures. A comment can record\n the pass rate, especially when the pass rate is high.\n- `cts_runner/skip.lst` contains sets of tests in which at least 90% of the tests\n are skipped.\n\nIf you fix a set of tests, add it to `cts_runner/test.lst` only when all of its\ntests pass or skip. Do not add a set of tests that has any failures.\n\nUse wildcards to minimize the number of selectors:\n\n```\nwebgpu:api,validation,category:subcategory:isAsync=false;*\n```\n\nUse a higher-level wildcard only when all tests that it matches belong in the\nsame result list. Do not use a wildcard that also matches tests from another\nresult list.\n\nKeep the selectors in the order that the `lst_files_are_sorted` integration\ntest requires. This rule also applies to selectors in comments.\n\n## Step 12: Verify and Build\n\nBefore finishing:\n\n```bash\n# Format code\ncargo fmt\n\n# Check for errors\ncargo clippy --tests\n\n# Build to ensure no compilation errors\ncargo build\n\n# Run the tests you added to test.lst\ncargo xtask cts 'webgpu:api,validation,category:subcategory:isAsync=false;*'\n```\n\n# Common Patterns\n\nIf the user asked to investigate a failure, and the cause of the failure is\nnoted here with \"do not attempt to fix\", then stop and ask the user before\nattempting to fix.\n\n**Pattern: Format-specific failures**\n\n- Check if format validation is missing\n- Look for `is_depth_stencil_format()`, `is_color_format()` etc.\n- May need to add format capability checks\n\n**Pattern: Aspect-related failures**\n\n- Check if code validates format aspects (DEPTH, STENCIL, COLOR)\n- Use `hal::FormatAspects::from(format)` to check\n- Validate operations match available aspects\n\n**Pattern: Optional field failures**\n\n- May be WebGPU optional field semantics issue\n- Check if undefined in JS becomes a default value in Rust\n- May need to distinguish \"not set\" from \"set to default\"\n\n**Pattern: Atomics accepted incorrectly**\n\n- Naga allows referencing an atomic directly in an expression\n- Should only allow accessing via `atomicLoad`, `atomicStore`, etc.\n- Only investigate as necessary to confirm this is the issue. Do not attempt to fix. Refer user to https://github.com/gfx-rs/wgpu/issues/5474.\n\n**Pattern: Error reporting for destroyed resources**\n\n- Tests that check for validation errors when a destroyed resource is used. `wgpu` often reports these errors later than WebGPU requires, causing the tests to fail.\n- `wgpu` may report these errors earlier than it should, causing the test to fail with an unexpected validation error.\n- Look for:\n - Tests with `state=\"destroyed\"` parameter\n - Tests checking that operations on destroyed buffers or textures should fail\n- Example failing tests:\n - `webgpu:api,validation,encoding,cmds,compute_pass:indirect_dispatch_buffer_state:` with `state=\"destroyed\"` subcases\n- Only investigate as necessary to confirm this is the issue. Do not attempt to fix. Refer user to https://github.com/gfx-rs/wgpu/issues/7881.\n\n# Tips\n\n- **Start with high-impact fixes**: Validation gaps with security implications\n- **Look for existing patterns**: Other validation code shows the style\n- **Test incrementally**: Fix one category at a time, verify it works\n- **Document as you go**: Don't wait until the end to write the triage\n- **Ask for clarification**: If test expectations are unclear, check the WebGPU spec or test source\n- **Track your progress**: Update pass rates as you fix issues\n","frontmatter":{"name":"cts-triage","description":"Run CTS test suites and investigate failures"},"isInternal":false,"tokens":2456,"sizeBytes":10451},{"name":"SKILL.md","path":".claude/skills/webgpu-specs/SKILL.md","rawUrl":"https://raw.githubusercontent.com/gfx-rs/wgpu/HEAD/.claude/skills/webgpu-specs/SKILL.md","title":"webgpu-specs","category":"anthropic-skill","format":"markdown","content":"---\nname: webgpu-specs\ndescription: Download WebGPU and WGSL specifications for use as a reference\nallowed-tools: \"Bash(sh .agents/skills/webgpu-specs/download.sh)\"\n---\n\nRun `sh .agents/skills/webgpu-specs/download.sh` to download the\nWebGPU and WGSL specifications if they are not present or if they have\nbeen updated. You do not need to change directory before running the script.\n\nAfter the specs are downloaded, you can search in `target/claude/webgpu-spec.bs`\nand `target/claude/wgsl-spec.bs` for relevant sections of the specification.\n\nWhen referencing the specifications, prefer to use named anchors rather than\nline numbers. For example, to reference the \"Object Descriptors\" section, which has the\nfollowing header:\n\n```\n### Object Descriptors ### {#object-descriptors}\n```\n\nUse the URL so the user\ncan click to navigate directly to that section.\n\nFor the WGSL specification, the base URL is .\n\nIf necessary, read additional content from the file to find the header preceding\nthe text you want to reference. You may provide line numbers as additional\ncontext, but always make every effort to provide the user with a clickable link.\n","frontmatter":{"name":"webgpu-specs","description":"Download WebGPU and WGSL specifications for use as a reference","allowed-tools":"Bash(sh .agents/skills/webgpu-specs/download.sh)","allowedTools":["Bash(sh",".agents/skills/webgpu-specs/download.sh)"]},"allowedTools":["Bash(sh",".agents/skills/webgpu-specs/download.sh)"],"isInternal":false,"tokens":282,"sizeBytes":1235},{"name":"download.sh","path":".claude/skills/webgpu-specs/download.sh","rawUrl":"https://raw.githubusercontent.com/gfx-rs/wgpu/HEAD/.claude/skills/webgpu-specs/download.sh","title":"Claude Directive: download.sh","category":"claude-rule","format":"markdown","content":"#!/bin/sh\n\nset -e\n\nTARGET_DIR=\"$(cargo metadata --format-version 1 | jq -r \".target_directory\")\"\n\nWEBGPU=\"$TARGET_DIR/claude/webgpu-spec\"\nWGSL=\"$TARGET_DIR/claude/wgsl-spec\"\nmkdir -p \"$TARGET_DIR/claude\"\n\nif [ -f \"$WEBGPU.etag\" ]; then\n curl --etag-save \"$WEBGPU.etag.new\" --etag-compare \"$WEBGPU.etag\" -fsSL https://raw.githubusercontent.com/gpuweb/gpuweb/main/spec/index.bs -o \"$WEBGPU.bs\"\n [ -s \"$WEBGPU.etag.new\" ] && mv \"$WEBGPU.etag.new\" \"$WEBGPU.etag\" || rm \"$WEBGPU.etag.new\"\nelse\n curl --etag-save \"$WEBGPU.etag\" https://raw.githubusercontent.com/gpuweb/gpuweb/main/spec/index.bs -o \"$WEBGPU.bs\"\nfi\n\nif [ -f \"$WGSL.etag\" ]; then\n curl --etag-save \"$WGSL.etag.new\" --etag-compare \"$WGSL.etag\" -fsSL https://raw.githubusercontent.com/gpuweb/gpuweb/main/wgsl/index.bs -o \"$WGSL.bs\"\n [ -s \"$WGSL.etag.new\" ] && mv \"$WGSL.etag.new\" \"$WGSL.etag\" || rm \"$WGSL.etag.new\"\nelse\n curl --etag-save \"$WGSL.etag\" https://raw.githubusercontent.com/gpuweb/gpuweb/main/wgsl/index.bs -o \"$WGSL.bs\"\nfi\n","isInternal":false,"tokens":332,"sizeBytes":1010}],"systemPromptSnippet":"\n\n# wgpu Project Structure\n\nwgpu is a GPU API written in pure rust. Changes of any significance need to apply across the stack.\n\n- `naga` is our shader translator. It is responsible for consuming and translating untrusted shaders to trusted shader code.\n- `wgpu-types` are the common types used on both Native and WASM.\n- `naga-types` holds the shader-language types, such as target versions and binding maps, that `naga` and `wgpu-core` both use.\n- `wgpu-naga-bridge` converts between `naga` and `wgpu-types`. It maps wgpu features and downlevel flags to naga validation capabilities.\n- `wgpu-sync` are the common synchronization primitives that abstract over platform differences.\n- `wgpu-hal` does not provide the validation required for safety. Its callers must satisfy its safety contracts.\n- `wgpu-core` does all the validation and provides a coherent interface.\n- `wgpu-core-remote` provides the ID abstraction needed by Firefox and Deno.\n- `wgpu-core-remote-types` holds the IPC types that `wgpu-core-remote` sends between the untrusted content process and the trusted GPU process. They are defined separately from the `wgpu-core` types, so untrusted content cannot express non-standard features.\n- `wgpu` is an ergonomic Rust interface to `wgpu-core`\n- `deno_webgpu` contains the WebGPU bindings for Deno.\n\n`wgpu-core-remote`, `wgpu-core`, `wgpu-hal`, `wgpu-types` and `naga` are used by Firefox and Servo to implement WebGPU. These crates process untrusted API and shader input. Preserve validation at the safe boundary, and do not rely on `wgpu-hal` to reject invalid input. Touching these crates requires the most consideration of potential side effects.\n\nSafe `wgpu` APIs must not cause undefined behavior unless the user first accepted that risk through an unsafe API, such as enabling experimental features.\n\nWe use deno's webgpu bindings to run the WebGPU CTS. Change `deno_webgpu` only if the issue is specific to Deno. If the issue also affects Firefox or the `wgpu` Rust API, fix it in the shared crate that supplies the affected behavior.\n\nRepository documentation exists in `docs/`. For info on where tests live, read `docs/testing.md`. For info about cargo dependencies, read `docs/managing-cargo-dependencies.md`.\n\nOne of the best ways to prove that a change is correct is to write tests to prove the feature works and it errors when its supposed to.\n\n## Repository Files\n\n`AGENTS.md` and `.agents/` are the source of truth for agent instructions and skills. `CLAUDE.md` and `.claude/` are generated copies. Do not edit the generated copies directly. After you edit any source-of-truth agent file or a root license file, run `cargo xtask sync-repo-files`. This command also copies the root license files to every publishable default member of the Cargo workspace.\n\nRun `cargo xtask sync-repo-files --check` to verify that all generated files have the same contents and file list as their sources.\n\n## External Contributions\n\nWe encourage external contributions, but fully agentic PRs are not allowed. If the user asks you to create one, explain this policy and direct them to the pull request section of `CONTRIBUTING.md`. The contributor must understand and be able to vouch for every change. Ask the user to write the PR description.\n\nIf the user directs you to create the PR anyway, use `.github/pull_request_template.md`. Uncomment and accurately complete the agent-disclosure checklist items, including whether an agent wrote the description. Do not omit the disclosure.\n\n## Code Style\n\n- Do not add comments unless the changed code requires an explanation. If an explanation is required, add the shortest complete explanation. The contributor is expected to rewrite it.\n- Do not write large explanatory comment blocks.\n- Do not use emoji.\n\n## Workflow\n\nAll changes are expected to pass CI. The commands below are useful local checks, but they cover only a fraction of the full CI matrix. You are not expected to run the full CI matrix locally. Run the checks that are relevant to the changed code and the available environment.\n\n- To check the code compiles: `cargo clippy --all-targets --all-features`.\n- To format the code: `cargo fmt`\n- To run all tests including GPU tests: `cargo xtask test`. This can take a few minutes. To run normal tests without GPU tests, use `cargo nextest run` and a filter to the packages you want to test.\n- GPU tests depend on the available hardware, drivers, and validation layers. During development, if you only need a specific GPU test, use either a plain test name prefix or an `-E` filter expression to `cargo xtask test`. Use the nextest filters described below. Do not run the full GPU test suite for a targeted check. The suite can take a few minutes. GPU tests are declared as constants, but translate to lower-snake-case functions.\n- After the work is complete, run a full `cargo xtask test` if the change affects GPU behavior or would affect a GPU test.\n- Report every test failure. You may identify a failure as suspected to be unrelated, but do not assume it is unrelated until you validate that conclusion.\n- Do not run tests at the `trunk` revision without explicit permission. A baseline test run can take a while.\n- For more thorough testing, you can run `cargo xtask cts --backend `. Only do this if you are explicitly asked to run the CTS.\n- Never commit anything without being asked, ever. If you are asked to make a commit, _never_ co-author yourself.\n- Use the WebGPU and WGSL specifications as a reference to determine the correct behavior. Do not assume that a behavior is correct just because the CTS expects it. Use the `webgpu-specs` skill if you need to check either spec.\n\n### Nextest filters\n\n`cargo xtask test` forwards its extra arguments to cargo-nextest.\n\n- A plain positional filter matches test names that contain the filter text. A unique test name prefix is usually sufficient.\n- `-E 'test(name)'` matches test names that contain `name`.\n- `-E 'test(=name)'` matches the complete test name.\n- `-E 'test(/expression/)'` matches test names with a regular expression.\n- In an `-E` expression, `package(name)` restricts the package and `binary(name)` restricts the test binary. Restricting binaries can make test startup quicker.\n- Use `&` for intersection, `|` for union, and `!` for exclusion. Use parentheses to group expressions.\n- For example, `-E 'binary(wgpu-gpu) & test(buffer) & !test(map)'` selects tests in the `wgpu-gpu` binary whose names contain `buffer` but not `map`.\n- Quote each `-E` expression so the shell does not interpret its operators.\n\n## Changelog\n\nWe maintain a changelog in CHANGELOG.md. Changes should be noted in the changelog if they are user-visible (changes to documented public APIs, significant bug fixes, or new functionality). We generally do not consider changes to wgpu-core, wgpu-hal, wgpu-core-remote, or wgpu-core-remote-types worthy of changelogs, unless a `wgpu` user is expected to interface with them directly. Changelog descriptions should be concise. If you are not sure whether something should be in the CHANGELOG or you are not sure how to describe the change, ask the user for guidance.\n\n\n---\nname: cts-triage\ndescription: Run CTS test suites and investigate failures\n---\n\n# Triage Process\n\nWhen working on a category of CTS tests, follow this systematic process to identify issues, prioritize fixes, and document findings.\n\n## Step 0: Divide Into Manageable Chunks\n\nList all the tests matching a selector:\n\n```bash\ncargo xtask cts -- --list 'webgpu:api,validation,*' 2>&1 | wc -l\n```\n\nIf there is a reasonable number of tests matching the selector (less than a\ncouple hundred or so, but this isn't a hard cutoff), then you can proceed with\ntriage. Otherwise, make a list of more detailed wildcards that match fewer\ntests, verify that each wildcard matches a reasonable number of tests, and\ntriage each wildcard separately.\n\n## Step 1: Get Overall Statistics\n\nRun the full test suite for the category to understand the scope:\n\n```bash\ncargo xtask cts 'webgpu:api,validation,category:*' 2>&1 | grep -E \"(Summary|Passed|Failed)\" | tail -5\n```\n\nThis gives you the pass rate and number of failures. Document this as your baseline.\n\n## Step 2: Identify Test Subcategories\n\nReview the output from the running the CTS (with or without `--list`) to\nidentify any subcategories that may exist within the suite being analyzed.\nSubcategories typically have an additional `:`- or `,`-delimited word in the\ntest name. Running tests by subcategory may be more manageable than running\nwith the entire suite at once or running individual tests.\n\n## Step 3: Run Each Subcategory\n\nTest each subcategory individually to identify which ones are passing vs failing:\n\n```bash\ncargo xtask cts 'webgpu:api,validation,category:subcategory:*' 2>&1 | grep -E \"(Passed|Failed|Skipped)\" | tail -3\n```\n\nTrack the pass rate for each subcategory. This helps you identify:\n\n- What's already working (don't break it!)\n- Where the failures are concentrated\n- Which issues affect multiple categories\n\n## Step 4: Analyze Failure Patterns\n\nFor failing subcategories, look at what tests are failing:\n\n```bash\ncargo xtask cts 'webgpu:api,validation,category:subcategory:*' 2>&1 | grep \"\\[fail\\]\" | head -20\n```\n\nLook for patterns:\n\n- **Format-specific failures**: May indicate missing format capability checks\n- **Parameter-specific failures**: Validation missing for specific parameter combinations\n\n## Step 5: Examine Specific Failures\n\nPick a representative failing test and run it individually to see the error:\n\n```bash\ncargo xtask cts 'webgpu:api,validation,category:subcategory:specific_test' 2>&1 | tail -30\n```\n\nLook for:\n\n- **\"EXPECTATION FAILED: DID NOT REJECT\"**: wgpu is accepting invalid input (validation gap)\n- **\"Validation succeeded unexpectedly\"**: Similar to above\n- **\"Unexpected validation error occurred\"**: wgpu is rejecting valid input\n- **Error message content**: Tells you what validation is triggering or missing\n\n## Step 6: Check CTS Test Source\n\nTo understand what the test expects, read the TypeScript source:\n\n```bash\ngrep -A 40 \"test_name\" cts/src/webgpu/api/validation/path/file.spec.ts\n```\n\nThe test source shows:\n\n- What configurations are being tested\n- What the expected behavior is (pass/fail)\n- The validation rules from the WebGPU spec\n- Comments explaining the rationale\n\n## Step 7: Categorize Issues\n\nGroup failures into categories:\n\n**High Priority - Validation Gaps:**\n\n- wgpu accepts invalid configurations that should fail\n- Security or correctness implications\n- Example: Accepting wrong texture formats, missing aspect checks\n\n**Medium Priority - Spec Compliance:**\n\n- Edge cases not handled correctly\n- Optional field validation issues\n- Example: depthCompare optional field handling\n\n**Low Priority - Minor Gaps:**\n\n- Less common scenarios\n- Limited real-world impact\n- Example: Depth bias with non-triangle topologies\n\n**Known Issues - Skip:**\n\n- Known failure patterns (documented in Common Patterns below)\n- Track count but don't try to fix\n\n## Step 8: Identify Root Causes\n\nFor validation gaps, find where validation should happen:\n\n1. **Search for existing validation:**\n\n ```bash\n grep -n \"relevant_keyword\" wgpu-core/src/device/resource.rs\n ```\n\n2. **Look for render/compute pipeline creation:**\n - Render pipeline: `wgpu-core/src/device/resource.rs` around `create_render_pipeline`\n - Compute pipeline: Similar location\n - Look for existing validation patterns you can follow\n\n3. **Check for helper functions:**\n\n ```bash\n grep \"fn is_\" wgpu-types/src/texture/format.rs\n ```\n\n4. **Find error enums:**\n ```bash\n grep \"pub enum.*Error\" wgpu-core/src/pipeline.rs\n ```\n\n## Step 9: Implement Fixes\n\nWhen implementing fixes:\n\n1. **Add error variants if needed** (in `wgpu-core/src/pipeline.rs`)\n2. **Add helper methods** (in `wgpu-types` if checking properties)\n3. **Add validation checks** (in `wgpu-core/src/device/resource.rs`)\n4. **Test the fix** with specific failing tests\n5. **Run full subcategory** to verify all related tests pass\n6. **Check you didn't break passing tests**\n\n## Step 10: Document Findings\n\nCreate or update a triage document (e.g., `category_triage.md`).\n\nDo not write information about changes you have made to the triage document. Only capture the state of the tests and any investigation into open issues.\n\n````markdown\n# Category CTS Tests - Triage Report\n\n**Overall Status:** XP/YF/ZS (%/%/%)\n\n## Passing Sub-suites ✅\n\n[List sub-suites that have no failures (all pass or skip)]\n\n## Remaining Issues ⚠️\n\n[List sub-suites that have failures and if it can be stated concisely, a summary of the issue]\n\n## Issue Detail\n\n[List detail of any investigation into failures. Do not go into detail about passed suites, just list the failures.]\n\n### 1. title, e.g. a distinguishing word from the test selector\n\n**Test selector:** `webgpu:api,validation,render_pipeline,depth_stencil_state:format:*`\n**What it tests:** [Description]\n**Example failure:**\n[a selector for a single failing test, e.g.:]\n\n```\nwebgpu:api,validation,render_pipeline,depth_stencil_state:depthCompare_optional:isAsync=false;format=\"stencil8\"\n```\n\n**Error:**\n[error message from the failing tests, e.g.:]\n\n```\nUnexpected validation error occurred: Depth/stencil state is invalid:\nFormat Stencil8 does not have a depth aspect, but depth test/write is enabled\n```\n\n**Root cause:**\n[Your analysis of the root cause. Do not speculate. Only include the results of specific investigation you have done.]\nThe validation is triggering incorrectly. When `depthCompare` is undefined/missing in JavaScript, it's getting translated to a default value that makes `is_depth_enabled()` return true, even for stencil-only formats.\n\n**Fix needed:**\n[Your proposed fix. Again, do not speculate. Only state the fix if it is obvious from the root cause analysis, or if you have done specific investigation into how to fix it.]\n\n### 2. title\n\n[repeat as needed for additional issues]\n````\n\n## Step 11: Update CTS Result Lists\n\nThe result lists have these purposes:\n\n- `cts_runner/test.lst` contains sets of tests with no failures. It is not an\n exhaustive list of passing sets of tests.\n- `cts_runner/fail.lst` contains sets of tests with failures. A comment can record\n the pass rate, especially when the pass rate is high.\n- `cts_runner/skip.lst` contains sets of tests in which at least 90% of the tests\n are skipped.\n\nIf you fix a set of tests, add it to `cts_runner/test.lst` only when all of its\ntests pass or skip. Do not add a set of tests that has any failures.\n\nUse wildcards to minimize the number of selectors:\n\n```\nwebgpu:api,validation,category:subcategory:isAsync=false;*\n```\n\nUse a higher-level wildcard only when all tests that it matches belong in the\nsame result list. Do not use a wildcard that also matches tests from another\nresult list.\n\nKeep the selectors in the order that the `lst_files_are_sorted` integration\ntest requires. This rule also applies to selectors in comments.\n\n## Step 12: Verify and Build\n\nBefore finishing:\n\n```bash\n# Format code\ncargo fmt\n\n# Check for errors\ncargo clippy --tests\n\n# Build to ensure no compilation errors\ncargo build\n\n# Run the tests you added to test.lst\ncargo xtask cts 'webgpu:api,validation,category:subcategory:isAsync=false;*'\n```\n\n# Common Patterns\n\nIf the user asked to investigate a failure, and the cause of the failure is\nnoted here with \"do not attempt to fix\", then stop and ask the user before\nattempting to fix.\n\n**Pattern: Format-specific failures**\n\n- Check if format validation is missing\n- Look for `is_depth_stencil_format()`, `is_color_format()` etc.\n- May need to add format capability checks\n\n**Pattern: Aspect-related failures**\n\n- Check if code validates format aspects (DEPTH, STENCIL, COLOR)\n- Use `hal::FormatAspects::from(format)` to check\n- Validate operations match available aspects\n\n**Pattern: Optional field failures**\n\n- May be WebGPU optional field semantics issue\n- Check if undefined in JS becomes a default value in Rust\n- May need to distinguish \"not set\" from \"set to default\"\n\n**Pattern: Atomics accepted incorrectly**\n\n- Naga allows referencing an atomic directly in an expression\n- Should only allow accessing via `atomicLoad`, `atomicStore`, etc.\n- Only investigate as necessary to confirm this is the issue. Do not attempt to fix. Refer user to https://github.com/gfx-rs/wgpu/issues/5474.\n\n**Pattern: Error reporting for destroyed resources**\n\n- Tests that check for validation errors when a destroyed resource is used. `wgpu` often reports these errors later than WebGPU requires, causing the tests to fail.\n- `wgpu` may report these errors earlier than it should, causing the test to fail with an unexpected validation error.\n- Look for:\n - Tests with `state=\"destroyed\"` parameter\n - Tests checking that operations on destroyed buffers or textures should fail\n- Example failing tests:\n - `webgpu:api,validation,encoding,cmds,compute_pass:indirect_dispatch_buffer_state:` with `state=\"destroyed\"` subcases\n- Only investigate as necessary to confirm this is the issue. Do not attempt to fix. Refer user to https://github.com/gfx-rs/wgpu/issues/7881.\n\n# Tips\n\n- **Start with high-impact fixes**: Validation gaps with security implications\n- **Look for existing patterns**: Other validation code shows the style\n- **Test incrementally**: Fix one category at a time, verify it works\n- **Document as you go**: Don't wait until the end to write the triage\n- **Ask for clarification**: If test expectations are unclear, check the WebGPU spec or test source\n- **Track your progress**: Update pass rates as you fix issues\n\n\n---\nname: webgpu-specs\ndescription: Download WebGPU and WGSL specifications for use as a reference\nallowed-tools: \"Bash(sh .agents/skills/webgpu-specs/download.sh)\"\n---\n\nRun `sh .agents/skills/webgpu-specs/download.sh` to download the\nWebGPU and WGSL specifications if they are not present or if they have\nbeen updated. You do not need to change directory before running the script.\n\nAfter the specs are downloaded, you can search in `target/claude/webgpu-spec.bs`\nand `target/claude/wgsl-spec.bs` for relevant sections of the specification.\n\nWhen referencing the specifications, prefer to use named anchors rather than\nline numbers. For example, to reference the \"Object Descriptors\" section, which has the\nfollowing header:\n\n```\n### Object Descriptors ### {#object-descriptors}\n```\n\nUse the URL so the user\ncan click to navigate directly to that section.\n\nFor the WGSL specification, the base URL is .\n\nIf necessary, read additional content from the file to find the header preceding\nthe text you want to reference. You may provide line numbers as additional\ncontext, but always make every effort to provide the user with a clickable link.\n\n\n#!/bin/sh\n\nset -e\n\nTARGET_DIR=\"$(cargo metadata --format-version 1 | jq -r \".target_directory\")\"\n\nWEBGPU=\"$TARGET_DIR/claude/webgpu-spec\"\nWGSL=\"$TARGET_DIR/claude/wgsl-spec\"\nmkdir -p \"$TARGET_DIR/claude\"\n\nif [ -f \"$WEBGPU.etag\" ]; then\n curl --etag-save \"$WEBGPU.etag.new\" --etag-compare \"$WEBGPU.etag\" -fsSL https://raw.githubusercontent.com/gpuweb/gpuweb/main/spec/index.bs -o \"$WEBGPU.bs\"\n [ -s \"$WEBGPU.etag.new\" ] && mv \"$WEBGPU.etag.new\" \"$WEBGPU.etag\" || rm \"$WEBGPU.etag.new\"\nelse\n curl --etag-save \"$WEBGPU.etag\" https://raw.githubusercontent.com/gpuweb/gpuweb/main/spec/index.bs -o \"$WEBGPU.bs\"\nfi\n\nif [ -f \"$WGSL.etag\" ]; then\n curl --etag-save \"$WGSL.etag.new\" --etag-compare \"$WGSL.etag\" -fsSL https://raw.githubusercontent.com/gpuweb/gpuweb/main/wgsl/index.bs -o \"$WGSL.bs\"\n [ -s \"$WGSL.etag.new\" ] && mv \"$WGSL.etag.new\" \"$WGSL.etag\" || rm \"$WGSL.etag.new\"\nelse\n curl --etag-save \"$WGSL.etag\" https://raw.githubusercontent.com/gpuweb/gpuweb/main/wgsl/index.bs -o \"$WGSL.bs\"\nfi\n"}