OneStream Debugger: a Claude Code plugin that traces any OneStream rule step by step

Overview#

When a OneStream rule gives the wrong answer, the usual method is to add logging by hand, run it, read the log, and repeat. In member formulas it is slower still, because they are fragments with limited tooling.

OneStream Debugger is a Claude Code plugin that does the instrumenting. Paste member formulas, conditional or confirmation rules, or whole business rules and ask for a trace. Claude returns the code with debug lines added, opens a viewer in the browser, and says where the trace file will appear. It also learns from use: what it discovers about OneStream's objects is saved for the whole team.

The Problem#

• Guess and re-run. Hand-written logging is slow, easy to get wrong and easy to forget to remove.
• Instrumenting can change behaviour. Edits made for debugging can alter the logic being debugged.
• Member formulas are awkward. They cannot carry the usual helper code or declarations.
• OneStream's objects are thinly documented. Each engineer rediscovers what an object contains.

How It Works#

Instrument Without Changing Logic#

Every original line comes back exactly as it was. Only lines are added, and each is indented and tagged, so deleting the tagged lines restores the original code exactly. The added code is self-contained, so it is valid even inside a member formula.

One Switch, a Real Trace File#

A single master switch turns every trace line and the file write on or off in one edit. When on, the run writes a real trace file, by default to the user's documents folder in OneStream, or to the file share if it needs to be browsed on the server.

See the Data, Not Just the Flow#

When the code runs a database query, the trace records the query text, the number of rows returned and each row as its own event. You can step through the data the same way you step through the logic.

The TraceViewer#

A single standalone page that works fully offline. Drag the trace file onto it and step through the run event by event, with a live panel showing the values right now. Claude opens it automatically at the start of a debugging session.

The Self-Learning Loop#

OneStream's object model is large, so the plugin learns it as the team works:

• Unknown type, one-time dump. If the code uses an object type the plugin has not seen, it adds a small, safe block that records the object's shape during the run.
• Bring the trace back. Claude reads that output and writes a knowledge file for the type, with a column where people can add the meaning of each property.
• Shared with the team. Claude commits and pushes that file, so everyone gets it on their next update. If the push fails, it stays local and Claude says what to do.
• Next time, no dump. The type is already known, so the trace goes straight to the useful values.

Known Limits#

• Elapsed time always reads zero in member formulas, because no stopwatch is available there.
• Per-cell formulas run very often, so writing a file for each one is costly. Ship them with tracing off.
• Per-entity rules need a filename discriminator, such as the entity name, or each run overwrites the last.

Results#

Soft outcomes:

• Safer debugging. The original logic is never edited.
• Knowledge that compounds. Every type learned is learned for everyone.
• No setup for the viewer. One offline page, no server.

Learnings#

What worked. Making the added code removable by design. Trust in a debugging tool depends on knowing the original logic is untouched, and tagged lines plus a master switch deliver that.

What I'd do differently. The known limits, such as elapsed time reading zero in member formulas, come from the environment. I would surface them in the viewer itself so a reader does not mistake them for real results.

Skill developed. Designing a Claude Code plugin where the AI writes the code but follows strict rules, and where its discoveries become shared team knowledge instead of staying in one session.