chore: add Codex project context and agent guidance

This commit is contained in:
Marc Froehlich
2026-08-25 01:00:26 +02:00
parent 8c6ce6b402
commit 4601199587
24 changed files with 1719 additions and 0 deletions
@@ -0,0 +1,52 @@
---
name: kst4contest-review
description: Review current KST4Contest local changes or a proposed diff before commit. Check regressions, null safety, JavaFX threading, callsign/category semantics, band handling, protocol compatibility, tests, targeted documentation impact, durable project context and unintended scope. Report findings in German and do not modify files unless explicitly asked after the review.
---
# KST4Contest review
Review first; do not edit during the review.
Read the relevant KST4Contest change references.
## Review priorities
1. Behaviour matches the approved concept.
2. No unrelated changes.
3. Full callsign/category identity remains correct.
4. Base-call normalization is used only where intended.
5. Null/unknown values are not converted to fake defaults.
6. Worker threads do not manipulate JavaFX UI collections.
7. FX-thread boundaries are correct.
8. Protocol framing, CR/LF, XML and frequency formatting are unchanged unless explicitly intended.
9. External malformed input cannot kill long-running threads.
10. Tests cover the changed behaviour.
11. Maven test output was interpreted correctly despite ignored-failure settings.
12. A documentation-impact assessment was performed.
13. Any likely affected manual/README/website sections match the implementation.
14. `docs/PROJECT_CONTEXT.md` is updated when the change introduces a durable architectural/protocol/state/operational/integration decision.
15. Comments/Javadoc are English.
16. No unintended dependency/version/release changes.
Do not demand a full manual audit for an internal-only change when the impact assessment reasonably concludes there is no documentation effect.
## Report format
Report in German, ordered by severity.
For each finding include:
- affected file/location;
- concrete problem;
- consequence;
- recommended correction.
Then include:
- verification gaps;
- documentation-impact result;
- durable-context gaps;
- related-project gaps when relevant;
- overall assessment.
Do not fix findings until Marc explicitly asks for implementation and the normal concept gate has been satisfied for the fixes.
@@ -0,0 +1,7 @@
interface:
display_name: "KST4Contest Review"
short_description: "Review KST4Contest diffs before commit"
default_prompt: "Review the current KST4Contest changes only. Report findings in German and do not edit files."
policy:
allow_implicit_invocation: true
@@ -0,0 +1,61 @@
# Review checklist
## Scope
- Is every changed file necessary?
- Did unrelated formatting or refactoring slip in?
- Were user-authored local changes preserved?
## Architecture/threading
- Is canonical state owned outside JavaFX controls/lists?
- Does worker code avoid `ObservableList` access?
- Are UI mutations routed to the FX thread?
- Are parser/I/O/domain/UI responsibilities clearer or at least not more coupled?
## Domain
- Full callsign + category identity preserved?
- Base-call matching restricted to worked/monitoring or another explicitly approved feature?
- Unknown category/band values safe?
- NOT-QRV precedence preserved?
- Missing QRB/QTF remains unavailable rather than zero?
## Protocols
- ON4KST framing unchanged unless approved?
- CR/LF exact?
- UCX `contactreplace` compatibility preserved?
- Frequency strings verified rather than guessed?
- PSTRotator/AirScout transport/API assumptions checked against current code?
- Malformed input contained?
## UI
- Selection/focus/zoom/sorting preserved?
- `/cq callsign` prefill behaviour preserved where relevant?
- Main send-category fallback preserved where relevant?
- map WebView workaround preserved?
- null values displayed safely?
## Tests/build
- Focused regression test added or updated?
- Test summary checked?
- Ignored failures explicitly reported?
- PMD/SpotBugs output considered?
- packaging/module-list checks considered if modules changed?
## Documentation
- DE and EN manual both checked?
- website/README/changelog checked if user-visible?
- screenshot impact reported?
- writing style applied?
- no undocumented implementation or documented-but-unimplemented behaviour?
## Git/release
- No version bump unless requested?
- No generated release/update-feed changes by accident?
- No staging/commit/push without explicit authorization?