mirror of
https://github.com/praktimarc/kst4contest.git
synced 2026-08-25 19:46:53 +02:00
91 lines
2.9 KiB
Markdown
91 lines
2.9 KiB
Markdown
---
|
|
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.
|