zsb/fidc-backtest-engine
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

docs: specify buy-constrained amendment behavior and validation scope

Browse Source
This commit is contained in:
boris
2026-09-08 01:09:14 +08:00
parent fa6f189cdd
commit 3784246e6b
2 changed files with 7 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/evidence/decision-buy-denial-foundation-20260908.json
+4 -2
View File
@@ -1,8 +1,8 @@
{
"date": "2026-09-08",
"host": "192.168.31.177",
"candidateCommit": "7d293f0",
"unitTestsPassed": 451,
"candidateCommit": "fa6f189",
"unitTestsPassed": 453,
"integrationTestsPassed": 122,
"ignoredManualBenchmarks": 8,
"failed": 0,
@@ -12,5 +12,7 @@
"factorCompilerConnected": false,
"paperLivePlanConnected": false,
"orderAmendmentAcceptanceComplete": false,
"brokerAmendmentTestsPassed": true,
"amendmentPolicy": "Deny buy quantity increases or limit-price increases; allow validated reductions; preserve original state and queue order on rejection.",
"realStrategyAcceptanceComplete": false
}
docs/factor-decision-phase-contract.md
+3 -3
View File
@@ -18,7 +18,7 @@ Status: broker foundation implemented; factor compiler, evaluator and runtime-pl
New positive buy quantities and target-buy planning respect the map after standard market/risk checks. Sells remain permitted. The actual execution price determines whether a value/portfolio target requires buying: a target below the signal-day holding value can become a buy after a lower next open, so signal-day direction alone is insufficient.
Existing resting orders are not automatically canceled by this primitive. Cancellation and exposure-increasing order amendment need an explicit policy and further integration tests.
Existing resting orders are not automatically canceled by this primitive. A buy amendment is denied if it increases total quantity or raises the limit price, even if the other dimension decreases. Reductions in both dimensions remain allowed after normal validation. A rejected amendment emits an update-rejection process event without replacing the original order state or queue priority. Full runtime-plan integration still requires testing.
## Required Integration
@@ -26,11 +26,11 @@ Existing resting orders are not automatically canceled by this primitive. Cancel
2. Evaluate buy expressions at the declared decision clock using typed field availability, units and frozen data identity. Missing data must retain its own diagnostic, not silently become a false trading signal.
3. Populate denials for every symbol a decision can buy, including portfolio targets, retained-target reentry and top-ups. Do not infer execution direction from signal-day value.
4. Preserve/consume constraints in Paper/Live strategy-plan conversion. No consumer may silently discard a nonempty denial map.
5. Define and test pending-order amendment behavior separately; validate source-date and execution-date risk independently.
5. Carry the tested amendment policy through runtime-plan conversion; validate source-date and execution-date risk independently.
6. Verify same-bundle baseline parity when no buy constraint is configured, then test explicit buy failures across share, value, target and algorithmic orders.
## Current Evidence
On 177, broker tests verify blocked target top-ups, permitted sells, context restoration, existing pending-order preservation, and a next-open target direction flip. Full `fidc-core` tests passed: 451 unit tests and 122 integration tests, with 8 manual benchmarks ignored. The backtest runner compiles against the changed API.
On 177, broker tests verify blocked target top-ups, permitted sells, context restoration, existing pending-order preservation, a next-open target direction flip, and risk-increasing/reducing amendments with unchanged state on rejection. Full `fidc-core` tests passed: 453 unit tests and 122 integration tests, with 8 manual benchmarks ignored. The backtest runner previously compiled against the changed API.
The candidate is not deployed. The current OmniQuant compiler still needs the above integration, and no production readiness claim follows from these low-level tests.