Check stock strategy data and execution requirements
Before generating stock strategy code, decide whether its required data and execution model exist. Translate every requested rule into inputs and matching behavior, then accept, reject or name the missing extension explicitly. A daily long-only simplification is not an implementation of an intraday shorting request unless the user deliberately adopts a revised specification.
This guide adjudicates six rules against a small authored cash-stock fixture. CoTrading implementation capabilities remain planned or unverified. The example demonstrates actual local data checks and matcher rejections; it does not certify all A-share, Hong Kong or US workflows, or claim that reference code proves a product feature is available.
Break the request into independently testable rules
Start with the original wording and retain every meaningful condition. Separate indicator frequency, field history, availability, position direction, entry event, exit event, quantity rules and special fill assumptions. A sentence containing both a daily moving average and intraday queue priority contains multiple requirements with different evidence needs.
For each rule record required fields, resolution, historical coverage, availability timestamps, market permission and the code path that would consume it. Use a status such as supported in this fixture, requires external data, requires data and model extension or reject. Unknown requirements must not be interpreted as ordinary supported rules.
Keep the evidence column concrete. “There is a volume field” does not demonstrate an order-book queue, and “the engine has slippage” does not demonstrate realistic limit-board execution. A capability table should point to actual supplied data and implemented behavior rather than repeat the desired feature in more technical language.
Establish the fixture’s actual boundary
The supplied capabilities are daily OHLCV, cash-long positions, no same-session resale, no shorting, no queue replay and no historical fundamentals. These are declared limits of the local example. They are not a survey of every market or a promise about an existing CoTrading configuration.
The first supported rule compares completed closes with a trailing mean. The second requests a cash-long entry at a separately supplied next open. The example actually calculates the three-close signal and executes a positive-quantity purchase through its small matcher. Support is therefore narrower than “all strategies compile,” but more concrete than a checklist without execution.
Removing the open field from the capability input must change next-open entry to an external-data requirement. The script asserts that negative case. A schema with only closes cannot create an opening fill merely because the code needs a number, and a source name alone cannot establish all required fields exist.
Reject unsupported intraday and short rules
The requested intraday same-session round trip is rejected because daily bars lack the required intraday order and the fixture blocks same-session resale. The requested sale without sufficient owned inventory is also rejected because the matcher has no short capability or borrowing model. These failures are not replaced with an overnight long trade under the original label.
The SSE 2026 trading rules distinguish resale before settlement and specified turn-around exceptions. They are a reason to verify the selected instrument’s rules, not to assume that every security follows one unrestricted daily model. The local fixture deliberately uses a limited cash-stock rule.
The official publication notice identifies the 2026 revision’s effective date and notes deferred provisions. A historical study must match its relevant version and implementation status. Reading a current overview is not evidence that all past board, special-status and instrument rules have been modeled.
Identify data and model extensions separately
Queue-fill-at-limit requires both appropriate order-book history and a queue model; neither exists in the fixture. The decision is requires model and data, not supported with larger slippage. An OHLC price touching a limit does not describe the orders ahead of the strategy or establish that it filled.
Point-in-time earnings require external historical facts and usable timestamps, absent here. That decision is requires external data. A recent earnings value must not be copied backward to make the requirement appear satisfied. If the user removes that condition, retain a revised strategy name that no longer implies a fundamental filter.
These two extensions differ. More market bars alone do not implement queue matching, while a complete matcher cannot create historical financial facts. Assign each missing item its own owner or next evidence requirement. Avoid collapsing all gaps into “needs better data,” which hides whether code, economic definition or source acquisition is missing.
Execute the matcher counterexamples
The local matcher starts with 1,000, buys forty shares at ten and pays a fictional fee of one. It then has 599 cash and forty shares. Those numbers are asserted before testing unsupported requests, so rejections are tied to a real synthetic account state.
Selling forty in the same session is rejected. Selling fifty in a later session is rejected because only forty are owned. Requesting queue-replay mode is rejected because the only implemented convention is next-open. Each failure must leave cash and quantity unchanged; an error must not partially apply an order before returning rejection.
The matcher also rejects invalid direction, zero or Boolean quantity and nonfinite or nonpositive prices. These are input gates, not market simulation. The account represents a simplified single-position path and does not claim a full per-lot settlement system, broker margin service or partial-fill engine.
Write a revised specification without hiding deletions
The permitted revision retains only the trailing-close rule and next-open cash-long entry. Name it daily_cash_long_next_open_only. The original six-rule request remains marked not fully supported. That separation prevents a successful reduced example from being reported as fulfillment of the original strategy.
For the supplied closes ten, ten and twelve, the revised indicator returns one. This verifies the retained rule’s calculation, not its future economic value. No earnings, queue or shorting feature is silently inferred. If those conditions were central to the user’s hypothesis, the correct result may be to pause implementation until they are available.
Record each retained, removed or deferred rule with its consequence. Removing an intraday stop, changing a short to a long or replacing a same-day exit with tomorrow’s open materially changes the strategy. Such revisions need a clear specification even when they make the code easier to run.
Run the feasibility adjudication pack
Download the complete example, save it as R582.py and run python R582.py with Python 3.12 or later. It uses only the standard library and synthetic inputs. The source is docs/growth/research/round-5/examples/R582.py.
Assertions require the six expected dispositions, missing-open downgrade, unknown-rule rejection, the actual matcher failures, unchanged account state after rejection and the retained indicator result. The output says product verified false. It does not pretend that a rule table alone proves support in an unrun system.
Reassess when evidence changes
Archive the original request, capability snapshot, source versions, adjudication table, explicit revision and executed assertions. If a provider adds a field or a matcher adds a feature, rerun the affected negative test rather than merely change its status text. Data coverage and method implementation need evidence from their own layers.
Keep markets separate. A single Hong Kong lot-size shortcut does not establish per-stock board lots, and an A-share code prefix does not establish every special-status rule. Completion means each original requirement has an honest disposition and the revised supported subset is executable within stated boundaries, not a blanket promise that all stock strategies can be realized.
Treat a capability flag as a statement to verify, not as the implementation itself. Changing a table cell from false to true cannot add borrowing, intraday history or queue matching. The retained signal calculation and matcher are tested as local components; a complete data-to-order integration is not claimed. When extending support, replace the relevant rejecting fixture with a new correctly executed path while retaining negative cases for unsupported variants. This keeps the adjudication tied to observable behavior rather than a progressively more optimistic feature list.
FAQ
Can daily slippage stand in for queue matching?
No. It does not supply order-book history or queue-position behavior.
Is a simplified revision the original strategy?
Only if its changed rules are explicitly adopted; keep the original request and the revision distinct.