Crude-oil research from global news and market data

I wanted help following global events and thinking through what they might mean for crude oil. The research question was whether new developments changed the outlook enough to revisit my view, alongside what the market was actually doing.

I used the tracker for a few days while following the Iran conflict and made a small gain. It was a short personal experiment, not a test that established predictive accuracy.

I brought global news research, market data and position values into one assessment, with a separate job for each part. The code fetches prices, and Python calculates P/L, the modeled profit or loss of a position, plus distances and risk/reward. Claude Code receives those numbers and researches the surrounding news and possible implications. Its prompt tells it to use the supplied values when writing the assessment.

What reaches the assessment

assess.sh gathers prices, optional open/high/low/close data and RSS news intelligence before invoking Claude Code. The division of work is:

That keeps the arithmetic available to check alongside the news explanation.

A triage script decides whether another assessment is due. It examines elapsed time, price movement, critical flags, new important items and a configured contract-change window. Its configurable rules are intended to produce one of two outcomes: proceed or skip.

Keeping recent context small

Sending every previous assessment back to the model would keep growing its input. The compressor sorts the assessments and retains the last six in state.json.

Keeping a fixed count means those six cover less time when assessments happen more frequently. Older selected numeric fields go into history.csv, with timestamps deduplicated before appending. A daily summary preserves score changes, deduplicated developments and alerts.

The CSV keeps the longer numeric trail: selected prices, spread, scores, regime and alert count. The recent assessments and daily summary carry the written context.

There is also compatibility handling for older score shapes. score_val() accepts a number directly or reads the score field from a dictionary. Missing or unsupported values become zero. That keeps both shapes usable, but zero can also hide malformed data, so it needs to be interpreted with care.

The reviewed execution controls need work

The intended skip return code is 42. In assess.sh, Bash's set -e exits on that nonzero result before the next line can inspect it:

# Shortened example of the current control-flow problem.
set -e
python3 triage.py  # Intended skip returns 42.
status=$?         # Not reached for that return code.

A skip can consequently look like a failed attempt to the wrapper. It needs explicit conditional handling before the integrated path can be said to skip correctly.

The wrapper's file lock has a separate ownership problem. Cleanup is registered before the existing-lock check, so a second process can exit and remove the first process's lock. JSON writes also go directly to their destination rather than using a temporary file followed by replacement.

The next corrections are specific: distinguish a skip from a failure, remove only the lock owned by the current process and replace JSON files safely. Those execution controls were unfinished in the reviewed version.