Troubleshooting

Use this page when the strategy is doing something concrete you want to explain more clearly. The goal here is not to hand you fifty possible causes and make you sort them out alone. The goal is to help you match the symptom to the smallest likely cause. That matters because most builder frustration comes from solving the wrong problem layer. People rewrite logic when the real issue is direction. They rewrite entries when the real issue is setup state. They blame the strategy when the real issue is a changed assumption in the properties tab. This page is here to shorten that loop.

The Best Troubleshooting Rule

Troubleshoot from broadest permission to narrowest detail. Use this order:

1. readiness
2. direction
3. setup state
4. package behavior
5. token meaning
6. report assumptions

If you start in the middle, you often end up doing unnecessary work.

Quick Symptom Map

If you already know which row matches your problem, jump to that section below.

No Trades At All

This is the most common symptom and usually the least dramatic once you sort it correctly.

Check in this order

1. did you review the properties and confirm that review?
2. is the active direction the one you actually populated?
3. is the populated side truly populated?
4. can the setup realistically become valid on this chart?
5. is a broader rail already blocking fresh participation?

What this usually means

Most no-trade states come from ordinary causes:

• runtime is not ready
• the wrong side is active
• the context never became valid
• the package never gained permission to act
• a broader participation rail already said stop

The important habit is to treat silence as information before treating it as a defect.

The YAML Looks Close, But The Strategy Disagrees

When the structure feels almost right, do not rewrite the whole workflow immediately. Check these things first:

Is it in the correct section?

A valid-looking field in the wrong section can still produce completely wrong behavior.

Does the section contain the right package family?

Setups, entries, take profits, and stop losses solve different jobs. If those jobs get mixed, the chart gets confusing fast.

Are the field names exact?

Near-miss field names create warnings, confusion, and non-working assumptions. The strategy does not guess what you meant.

Are you treating the box like a full document instead of a section snippet?

The builder expects each text area to hold its own list content. It is easy to carry the wrong structural habit into the panel. If the problem smells structural, go to YAML Section Reference and compare the package family carefully before changing the logic itself.

The Expression Looks Reasonable, But It Is Rejected

This is where many users accidentally import outside expectations. The expression layer is defined. It is not an open-ended coding surface.

High-frequency causes

• unsupported helper names
• assuming full parity with every familiar outside syntax habit
• token names that do not actually exist
• wrong value types for the job
• malformed history usage
• ternary logic that mixes incompatible result types

The best response

Read the error text exactly as written, then compare the expression to the supported contract rather than to your memory of another environment. If the thought in your head is, "This is almost like what I expected," that is usually a good sign that the near-miss is the problem. Use Expression Language Reference to resolve that layer cleanly.

The Token Seems Wrong

Token problems are often smaller and more specific than they feel. Work through them in this order:

1. does the token exist?
2. what token family is it from?
3. what does it actually mean?
4. is your workflow giving it more meaning than it deserves?

Common token issues

If token meaning is the real problem, Default Token Reference is usually the shortest path back to clarity.

The Setup Feels Wrong

When a setup looks wrong, resist the urge to inspect entries first. The setup layer deserves its own review.

Check these things

• can the setup become active on this chart at all?
• does the setup require confirmation you forgot about?
• is cancellation happening sooner than you expected?
• is cooldown preventing a quick return?
• does the setup need reset behavior you assumed it already had?

What setup confusion often looks like on the chart

• the entry never appears because the context never truly became valid
• the setup flashes in and out because cancellation is too sensitive
• the setup feels "late" because confirmation is doing more work than you remembered

When the setup is unclear, stop there. A fuzzy setup makes every later layer harder to interpret.

The Entry Feels Wrong

Entries are one of the richest places for misunderstanding because they combine context, permission, trigger logic, order behavior, and timing in one package.

Check entries in this order

1. ownership
2. gate
3. trigger
4. confirmation
5. order type
6. price behavior
7. expiry or cancellation
8. one-shot or add behavior

That order matters because an entry can fail before the trigger ever becomes relevant.

Common entry surprises

The Exit Feels Wrong

Exits often feel mysterious when one of these ideas is unclear:

• ownership
• entry targeting
• order type
• fixed versus monitored pricing
• coverage share

Questions that usually resolve exit confusion

1. is this management path broad or entry-specific?
2. should it act as market behavior, resting behavior, or a hybrid path?
3. should its price stay fixed once active?
4. does its coverage still make sense in the full ladder?

If an exit is surprising you, there is a good chance the problem is not the trade idea. It is the management structure around the trade idea.

The Result Changed More Than Expected

This is one of the highest-value troubleshooting categories because it saves people from blaming the wrong layer.

Compare these first

• capital
• sizing model
• sizing amount
• commission
• slippage
• pyramiding
• broader rails
• any custom-token changes upstream

If the report moved dramatically after what felt like a small edit, do not assume the edit was actually small. The properties posture may have changed the meaning of the whole test. Use Backtesting and Realism if the symptom feels more like "the result tells a different story now" than "the workflow is mechanically broken."

The Visible Timing Control Is Not Behaving The Way You Expected

If your workflow depends on working-order lifetime, verify the behavior on the chart instead of trusting memory alone. The best way to reduce uncertainty here is:

1. author the timing behavior explicitly where the workflow depends on it
2. test it in a small example
3. confirm the visual order path matches your expectation

This is a general troubleshooting principle: when timing matters, observation beats assumption.

The Chart Becomes Unstable With External Sources

This is less common, but it can happen. When a chart becomes unstable while the strategy is consuming external indicator sources, treat it as a recovery problem first and an interpretation problem second.

Recovery sequence

1. save the chart layout if possible
2. refresh the page
3. reopen the chart cleanly
4. simplify or remove external sources
5. add them back one at a time until the instability returns

If one particular source combination keeps reproducing the issue, avoid that combination until you can isolate it safely in a smaller test.

Diagnostics: When They Help And When They Hurt

Diagnostics are useful when you already know the question. They are much less useful when they become a substitute for deciding what the question is.

Good uses

• confirming that the strategy recognized the loaded structure
• checking whether a setup or token state is what you think it is
• inspecting why one live value behaved unexpectedly

Poor uses

• turning everything on before you know which layer is failing
• treating extra information as proof of understanding

The Smallest-Proof Reset

If you still feel lost after several checks, shrink the workflow aggressively. Move back to:

1. one setup
2. one entry
3. one management path

If that small case becomes clear, the strategy probably is too. If that small case stays unclear, stay there until it makes sense. This is not moving backward. It is returning to the smallest test that can still teach you something reliable.

Where To Go Next

• read Rules and Risk if the issue feels more like a permission or behavior-order problem
• read YAML Section Reference if the symptom points back to package structure or field placement
• read Default Token Reference if the symptom is really about vocabulary or custom-token behavior
• read Worked YAML Examples if you want a cleaner comparison case before rebuilding your own workflow