[emmanuelmathot]

Stacked on #166.

Why

An exchange that asked for a dNBR of a wildfire failed: about 10 cycles of Accept → failed run → Ask, and no code that ran. The agent did not know how to load a second date window, what a reducer over time gets, or how to call the client. Each error showed only after Accept.

What

• Script contract (agents/script-contract.md):
  • "Dimensions": datacube is a stack of scenes, reduced has no time. A band function gets the bands, and a reducer over time gets the dates.
  • "Two dates": a second load_collection from load_collection_args, with other dates, merged into reduced.
  • The loader names that this uses (load_collection_args, default_bands, metadata, DataCube, PGNode).
  • New rules: call client methods with keywords; import other processes from openeo.processes; no slices in a callback.
• A dNBR sample (sentinel-2-dnbr): the 22 July 2026 Saumos / Le Porge wildfire. The post-fire window is the project's dates (August to September 2026), and the code loads the pre-fire window (1–21 July). It uses EOPF band names, like the other samples, and reads the band dimension from the loader's metadata. It has no thumbnail yet.
• Code cards checked before Accept: when a run ends, Studio builds the code of its code cards in Pyodide, with the configuration that the run proposes, and validates it with the backend. A card shows "The code runs" or "This code fails: …", with Ask to fix. This creates no map services and saves nothing.
• configuredBy() applies configuration changes in the same way as an accepted card. The acceptance and the check both use it.

Test

pnpm build, pnpm lint and pnpm test pass. The sample and the documented example build under the loader (openeo<0.50), with and without band metadata. Not tried in the browser with an agent.

🤖 Generated with Claude Code

[claude]

Claude finished @emmanuelmathot's task in 20s —— View job

---

✅ No blocking issues — safe to merge.

I read the diff statically. I did not run the build, lint or tests, and I did not try the check in a browser.

Non-blocking notes

• app/components/editor/assistant-tab.tsx (checkRun): the check calls runAndValidateScript on the shared Pyodide instance, and it starts automatically when a run ends. If the user presses Run while a check is in progress, two runPythonAsync calls can overlap. I did not confirm that getPythonCode uses Python globals such as map_graphs. If it does, the overlap could corrupt either result. If it can happen, serialize the two calls or skip the check while the editor is running.
• checkRun: the catch shows only the last two lines of the traceback. For validateGraphs backend errors, those two lines may be only the tail of a longer message. This is fine for Pyodide errors.
• app/stores/assistant-store.ts: dropping a checking state on rehydrate is correct. The pending card then has no check result and no retry, so the user sees nothing until Accept. This is acceptable, but worth knowing.

Simplify (ponytail)

• app/utils/agent.ts configuredBy: the max === undefined ? change.propertyFilters : withCloudCover(...) branch carries over the old behaviour. Keep it.
• app/components/editor/assistant-tab.tsx CheckResult: the three-way component could be a single Text with a ternary on the status. Cut the Stack and Button only if "Ask to fix" is dropped. It is requested, so leave it.
• app/algorithms/visualizations/dnbr.py: the sample writes out three classes(...) calls with hand-picked colour lists. It is one layer more than the doc example, but the sample is demo content, so there is nothing to cut.

---

💰 Estimated review cost: $0.14 · 0m20s · 7 turns

[github-actions]

🐳 Docker image built for this PR:

docker pull ghcr.io/developmentseed/openeo-studio:pr-167