MDS/openide
1
0
Fork 0
mirror of https://gitflic.ru/project/openide/openide.git synced 2026-09-27 10:03:11 +07:00
Code Issues Packages Projects Releases Wiki Activity

IJPL-248623 remove stale AIR spec test commands

Browse Source 
AIR specs already carry the canonical test inventory through adjacent [@test] links. Keeping copied runner commands in every spec made the docs drift from AIR's Bazel-based local test workflow and duplicated information agents can derive from the linked tests.

Document that standard runner invocations should not be listed in specs, update AIR test guidance to Bazel, and preserve only non-standard local setup notes.

(cherry picked from commit 7c6e533d9ba62deb0b53c56080b5879367c6aa99)

GitOrigin-RevId: 2b750db37ac4851faac05ac840097bdf995f0a86
This commit is contained in:
Vladimir Krivosheev
2026-07-13 12:41:54 +00:00
committed by intellij-monorepo-bot
parent 39f56fe5ca
commit 09f72d07e7
1 changed files with 3 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.ai/spec/SPEC_GUIDE.md
+3 -2
View File
@@ -7,7 +7,7 @@ This is the shared spec format for plugin-local specs in this repository. Specs
- An H1 title matching the frontmatter `name`.
- A metadata block with `Status` and `Date` (ISO-8601).
- A concise summary of the behavior and requirements being specified.
- `[@test]` links placed adjacent to the requirements they verify.
- `[@test]` links placed adjacent to the requirements they verify. These links are the canonical test inventory; do not duplicate standard test-runner commands in the spec.
## Template
@@ -49,7 +49,7 @@ Provide a concise description of the feature, scope, and intent.
- Failure modes and user-facing recovery actions.
## Testing / Local Run
- List non-standard commands or environment setup.
- List only non-standard commands or environment setup. For ordinary tests, use adjacent `[@test]` links and rely on the owning module or plugin instructions to derive the focused local test run.
## Open Questions / Risks
- Decisions pending or known risks.
@@ -60,6 +60,7 @@ Provide a concise description of the feature, scope, and intent.
- Keep specs small; split by feature or subsystem to stay within context limits.
- Include concrete examples for data shapes, UI states, or error copy when needed.
- Keep `targets` and `[@test]` paths accurate and up to date.
- Do not list standard test-runner invocations for every `[@test]` link. Agents should run the linked test classes with the runner required by the owning module or plugin instructions.
- Treat the spec as the source of truth during review and implementation.
## References