| name | kst4contest-change |
| description | Analyze or implement KST4Contest Java/JavaFX changes, bug fixes, refactorings, protocol handling, contest workflow behaviour, callsign/band logic, AirScout/logging/rotor/DXCluster integrations, threading and state management. Use current code as source of truth and follow the mandatory concept-and-question gate before edits. |
KST4Contest change workflow
Read the relevant reference files before proposing a concept.
Phase 1: read-only analysis
- Inspect the current code and tests.
- Identify the current data flow and thread ownership.
- Identify user-visible and protocol-visible behaviour.
- Check relevant
docs/PROJECT_CONTEXT.md sections when they exist.
- Check whether the task overlaps a known invariant in the references.
- Do not modify files.
Phase 2: report understanding in German
Explain:
- what Marc wants changed;
- what must remain unchanged;
- which components appear affected;
- what evidence in the current code supports that understanding;
- any conflict between current code and historical project context.
Never resolve a conflict by guessing.
Phase 3: questions and final concept in German
Before finalizing the concept:
- identify all material implementation choices;
- ask Marc questions that are not already answered by code, project instructions or prior confirmed decisions;
- wait for answers when needed.
Then present:
- intended data/control flow;
- exact behavioural changes;
- compatibility impact;
- thread/UI impact;
- persistence impact;
- test strategy;
- likely documentation impact;
- likely durable project-context impact;
- related-project impact when relevant.
Ask for explicit concept approval and wait before editing.
Phase 4: implementation
After approval:
- implement the smallest coherent change;
- preserve unrelated behaviour;
- keep comments/Javadoc in English;
- add/update focused tests;
- keep external protocol parsing defensive;
- avoid hidden defaulting for unknown values.
Phase 5: verification and documentation impact
Run focused checks, then appropriate broader checks.
Because KST4Contest build configuration may ignore failures/findings, inspect summaries and reports rather than only command exit status.
Then use $software-project-context:
- do a low-cost documentation-impact classification;
- inspect only likely affected manual/README/website sections;
- update targeted documentation when clearly required by the approved implementation;
- update
docs/PROJECT_CONTEXT.md for significant durable technical decisions/state changes;
- do not perform a full manual audit unless there is a specific trigger.
Phase 6: report
Report in German:
- files changed;
- implementation summary;
- tests/checks;
- warnings/findings;
- documentation-impact result;
- documentation/context updates or why none were required;
- related-project impact when relevant;
- unresolved issues;
- no Git publication action unless explicitly requested.
