Change a Security-Training App With Planned Vulnerabilities, Keeping Its Challenges Intact
Use when editing a training app whose security holes are meant as lessons. Tells planned challenges from accidental bugs, keeps changes small, strips AI-generated clutter, runs the required tests and challenge safety net, and keeps fix files in sync.
To use this AI rule
## Tell Planned Challenges Apart From Accidental Vulnerabilities
Treat an intentionally vulnerable training application differently from an ordinary production application. Some insecure behavior is deliberate educational content, while other weaknesses are unintended defects.
- Identify whether the affected behavior is an intended challenge, supporting infrastructure, or an accidental vulnerability before changing it.
- Do not remove, weaken, or add challenge behavior based only on an automated suggestion.
- New vulnerabilities and new challenges require maintainer approval and clear documentation.
- Confirm that a proposed challenge is distinct, solvable, functional, and appropriate for the learning goals.
- Preserve challenge hints, metadata, solution paths, and security-relevant comments that explain non-obvious intent.
- Review generated code critically. The contributor and reviewer remain responsible for correctness, security, and educational value.
When intent is unclear, trace the execution path, tests, challenge metadata, and mirrored fix artifacts before deciding what should change.
## Plan a Change That Solves One Issue
Begin by locating the relevant component, tracing its data flow, and finding established implementation and test patterns.
1. Define the single issue the change will solve.
2. Identify server, client, API, data, template, configuration, and challenge artifacts affected by that issue.
3. Search for similar code and follow the repository's current patterns.
4. Review security implications before implementation.
5. Propose tests that distinguish the intended behavior from regressions.
6. Keep unrelated cleanup and trivial changes out of the same contribution.
Consult maintainers before creating challenges, changing architecture, or altering the dependency model. Verify any package update against every relevant dependency manifest and runtime range. Do not add speculative configuration options or dependencies without a demonstrated need and compatibility evidence.
Work from the repository's designated integration branch using a focused feature branch. Reference the relevant issue and keep the contribution limited to one coherent purpose.
## Strip AI-Generated Clutter and Pass the Linter
Clean automated output before review.
Remove verbose comments that restate obvious code, generic placeholders, excessive docstrings for simple functions, repetitive explanations, debugging logs, and other generated residue. Keep comments that explain complex logic, challenge intent, security constraints, or a necessary workaround.
Run the repository's linter for every code change unless the change is limited to documentation explicitly exempted by the repository. Generated code must follow the same style rules as handwritten code.
- Fix lint failures instead of assuming the suggestion is correct.
- Do not preserve unnecessary code merely because an assistant generated it.
- Check the diff for broad formatting churn and unrelated file changes.
- Use clear names and concise comments that help a future maintainer understand intent.
- Ensure documentation and commit text describe the actual change rather than the assistant's process.
## Run the Tests Each Kind of Change Requires
Testing requirements depend on the changed surface, but confidence from an assistant never replaces execution.
- Add or update unit tests for changed logic.
- Run API integration tests when request handling, persistence, authorization, or response behavior changes.
- Run frontend unit tests for client-side components and services.
- Run end-to-end tests for new or modified challenges and cross-layer behavior.
- Run the full repository test suite before submission unless the repository explicitly exempts the changed documentation.
- Manually verify the user-visible or challenge-solving flow.
- Run the challenge refactoring safety net whenever existing challenge-related source changes.
Use the smallest focused suite during iteration, then run the complete required matrix before review. Record the exact commands and results. Do not claim success from static analysis alone, and do not skip a slow suite because generated code appears plausible.
## Keep Challenge Code and Its Mirrored Fix Files in Sync
Challenge-related source may be mirrored in snippets, expected fixes, metadata, or cached safety-net artifacts. A refactor is incomplete if these representations diverge.
1. Run the repository's challenge refactoring safety net after changing challenge-related code.
2. If it fails, inspect every reported difference instead of refreshing the cache immediately.
3. Determine whether the difference is an unintended regression or an intentional part of the change.
4. For an intentional refactor, apply the equivalent change to corresponding fix artifacts and snippets.
5. Update the approved differences cache only after source, challenge behavior, and mirrored artifacts are consistent.
6. Re-run the safety net and the relevant challenge flow.
Never use a cache update to conceal unexplained differences. New or changed challenge behavior also requires end-to-end proof that the challenge remains reachable, solvable, and correctly detected.
## Send Translations Through the Approved Platform and Run Final Checks
Do not edit generated or externally managed localization files directly. Submit translation changes through the repository's approved localization platform so source text, review history, and generated files remain synchronized.
Before submission:
- Confirm style checks pass and generated noise is gone.
- Confirm unit, integration, frontend, end-to-end, and safety-net checks required by the change all pass.
- Verify the behavior manually and inspect the final diff for unintended changes.
- Confirm dependency and runtime compatibility.
- Ensure commits meet the repository's sign-off policy.
- Base the contribution on the required integration branch and reference related issues.
- Document complex logic, security intent, tests run, and any approved exception.
- Confirm all continuous-integration checks pass.
If any required check could not be run, state that limitation explicitly. Do not present a partial verification as a complete security or challenge-integrity review.