issues-testing

A set of testing rules that chooses test commands based on which part of a project changed, from one affected test to the full backend and frontend checks.

In plain words
What is it for?
Use it to decide whether to run a single test class, endpoint and architecture tests, an Angular build and tests, or the full mvn verify check before finishing work.
Why use it?
It avoids missing regressions while keeping small changes from requiring every test immediately.

Cursor rule for Cursor

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

agentmods
npx agentmods add rules/vepo/issues/issues-testing
Clone the repo
git clone --depth 1 https://github.com/vepo/issues

Made for: Cursor.

Per session 647 This file is loaded in full into every session.
When invoked 647 The same file — it is already loaded in full.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5 $0.00647 $0.00647
Opus 5 $0.00324 $0.00324
Sonnet 5 $0.00129 $0.00129
Haiku 4.5 $0.00065 $0.00065

Measured yesterday against content hash 41347790fd5a, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

issues-testing scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured yesterday.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

.cursor/rules/issues-testing.mdc · 68 lines

How it starts

The opening of the file, as written. The whole thing — 68 lines — stays where its author put it; the contents beside it link to each section on GitHub.

Testing

Run the smallest scope that catches your regression after substantive edits. Full gate: mvn verify once before marking done — see issues-quality.mdc.

Session end: never stop with failing tests in your diff — run at least the affected test class, then mvn verify before handing off (development-process.mdc § Working code invariant).

Tiered ladder

When Command
Trivial / compile-only edit Skip until next substantive change
One backend package edited Single test class or mvn test -Dtest=ClassName
REST endpoint changed Related *EndpointTest + ArchitectureTest if DTOs changed
Angular component/service changed cd src/main/webui && npm run build then npm test -- --include='**/affected.spec.ts'
Task done (backend) mvn verify
Task done (full-stack) mvn verify + npm run build + Angular tests (CI runs both)
# All backend tests
mvn test

# Single test
mvn test -Dtest=TicketEndpointTest#methodName

# Architecture rules
mvn test -Dtest=ArchitectureTest

# Frontend (headless)
cd src/main/webui && npm run build
cd src/main/webui && npm test -- --no-watch --browsers=ChromeHeadless

# Dev mode (manual)
mvn quarkus:dev

Impact map

You changed Run
ticket/* TicketEndpointTest, TicketHistoryServiceTest
auth/*, user/* AuthenticationEndpointTest, UserEndpointTest
project/* ProjectEndpointTest
workflow/* WorkflowEndpointTest
*Request/*Response records ArchitectureTest + affected endpoint tests
Angular service Matching *.service.spec.ts
Angular component Matching *.component.spec.ts

Detail: issues-tests.mdc.

TDD development guidance: issues-model.mdc § TDD.

When tests fail

  1. Re-run smallest repro — issues-test-failure-diagnosis.mdc.
  2. Do not loop full mvn verify per fix.
  3. After green: one report under reports/ per that rule.

Read the full file on GitHub · 68 lines

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. yesterday First seen · 68 lines · 647 tokens per session scan A 41347790fd5a

Subscribe to this mod's changes

issues-testing is a cursor rule published in the GitHub repository vepo/issues (8 stars, last pushed 1mo ago), licensed Apache-2.0. It adds 647 tokens to every session, about $0.0032 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.