TRADING-SOFTWARE BLUEPRINT | EDITABLE TEMPLATE

Free to copy, adapt and share with any developer. No purchase required.
Template only: not a code audit, test result or trading-performance assessment.

1. REQUEST
BUILD / FIX / PORT:
Platform and version:
Target platform (PORT only):
One function or one defect:
Current behaviour (FIX):
Expected behaviour:
Source rights and inputs available (no credentials):

2. SMALLEST USEFUL SCOPE
Included:
Not included:
When evaluation happens:
State that must survive restart:
Missing data / failure behaviour:

3. UP TO THREE DECISIONS
Decision / proposed option / confirmed by buyer:
Decision / proposed option / confirmed by buyer:
Decision / proposed option / confirmed by buyer:

4. THREE TAILORED ACCEPTANCE CASES (PLANNED, NOT EXECUTED)
Case 1: positive input / starting state / expected observation:
Case 2: negative input / starting state / action that must not occur:
Case 3: relevant failure or boundary / starting state / expected observation:

5. OPTIONAL TEST PATTERN LIBRARY
Select only what applies. Replace generic patterns with concrete inputs.
01 Valid event: one permitted action in an uninterrupted run.
02 Repeated event: specify whether the same event may act twice.
03 False condition: no action when a required condition is false.
04 Intrabar versus closed bar: define which signal state controls the action.
05 Next event: an earlier event must not accidentally block a new permitted one.
06 Restart: define what persisted state must be recovered.
07 First launch: define whether historical signals are ignored or replayed.
08 Missing data: do not replace absent values with invented valid inputs.
09 Reconnection: define the recovery point and whether backlog is processed.
10 Invalid settings: define the diagnostic and halted/safe behaviour.
11 Storage failure: define behaviour when state cannot be recorded safely.
12 Platform comparison: same inputs/times, explicitly agreed tolerances.

Not every pattern belongs in every project. No generic exactly-once delivery
guarantee: recording before an action can lose that action after a crash;
recording afterward can permit duplicates. Agree the required tradeoff.

6. ONE NEXT STEP
Resolve a decision / investigate a bounded defect / implement one function /
compare platforms / do not build yet:

7. REVIEW STATUS
Inputs actually read:
What was not inspected or tested:
Proposed assumptions not yet confirmed:
Reviewer / date / version:

Executed tests belong in a separate evidence record:
case ID / source version / environment / input / actual result / evidence / date.
Never mark an expected result as an executed PASS.