// Use when adding, modifying, or reviewing E2E test apps/skeletons to keep the test coverage report up to date.
| name | e2e-coverage |
| description | Use when adding, modifying, or reviewing E2E test apps/skeletons to keep the test coverage report up to date. |
Guidelines for maintaining dev/modern-tools/rspack/E2E_COVERAGE.md — a single-page report of what every E2E app and skeleton tests.
| Trigger | Action |
|---|---|
New app added to apps/ | Add a subsection under Apps with a coverage table |
New skeleton added to skeleton.test.js | Add a row to the Skeletons table |
| New npm package imported for compatibility testing | Add an entry under NPM Package Compatibility with the package name, file, and reason |
| New custom assertion added to a test file | Add a row to that app's coverage table |
| New feature tested across multiple apps | Add a row to the Feature Coverage Matrix |
| App or skeleton removed | Remove its entries from all sections |
The report has five sections, in this order:
apps/<name>/ with a short description and a | What is covered | Phase | table| Skeleton | Port | Language | Extra coverage |)| Feature | Apps | Skeletons |) showing where each capability is testedFor each app or skeleton, check these sources:
| Source | What to look for |
|---|---|
<name>.test.js | Test helper used, options (env, configFile, buildDir, testFullApp, checkBundleFilePaths), all customAssertions callbacks and what they assert |
skeleton.test.js | The testMeteorSkeleton({ skeletonName: '<name>' }) block for that skeleton |
apps/<name>/server/main.js | npm imports with comments explaining why (ESM-only, native bindings, etc.) |
apps/<name>/imports/ | Shared code with special imports (node: protocol, JSX packages) |
apps/<name>/rspack.config.* | Custom config features (compileWithRspack, compileWithMeteor, disablePlugins, custom rules) |
apps/<name>/package.json | Dependencies that exist solely for compatibility testing |
All (env prefix) in the phase columnUse when writing tests, debugging test failures, running the test suite, or setting up test infrastructure. Covers self-test, package tests, and modern E2E tests.
Use when bumping Meteor package versions for beta, RC, or official releases. Covers the two version schemes (meteor-tool vs all other packages), the update-semver automation tool, manual files the tool does not handle, and the full lifecycle from beta through official release. Applies to packages/*/package.js, scripts/admin/, npm-packages/meteor-installer/, and .meteor/versions in test apps.
Use for writing, reviewing, editing, or generating Meteor release changelog entries. Defines canonical file locations, naming rules, required section structure, formatting conventions, PR-based generation workflow (with gh CLI and web fallback), incremental updates, and common entry patterns. Applies to files under v3-docs/docs/generators/changelog/versions/.
Use when analyzing release branch changes for missing user-facing documentation. Compares the release branch against devel, filters for user-facing changes, scans v3-docs/docs/ for coverage, and produces a gap report (.md file) with prioritized documentation opportunities. Does NOT write documentation — only identifies gaps and outputs a plan for later action.
Use when creating, updating, or maintaining AI documentation files (AGENTS.md, CLAUDE.md, skills). Covers file structure, conventions, and guidelines for evolving AI context.
Use when understanding the build system, modifying CLI commands, working with isobuild, or navigating the tools/ directory. Covers build pipeline flow and file locations.
