create-dataflow-model

Skill: Create Dataflow Model

A dataflow model is code that expresses how data moves through a method the analyzer can't trace through — an opaque call where the engine loses taint because it can't see the body. You write a small stand-in that reproduces the method's real propagation from its inputs to its outputs, so the analyzer can follow taint through it. Run it against the prepared test project and refine until the sample passes.

Inputs

Provided by the caller, fall back to the default value when omitted. Ask back only when a required input is missing and has no sensible default

• project-root (optional) — root of the target project. Opentaint keeps all analysis artifacts under the fixed <project-root>/.opentaint/ directory, so every .opentaint/... path below resolves there. Default: current directory
• language (required) — target language for this project and language-specific instructions
• batch (required) — the batch whose .opentaint/tracking/models/<batch>.yaml provides the dataflow methods to model and holds tracking state
• methods (optional) — a specific subset of the batch's dataflow methods to (re)model; default all not yet in build.done

Workflow

1. Understand the propagation

Find and read each dataflow method's real source: take methods not yet in build.done, or the specific methods handed for repair even when already built. Leave built methods outside that explicit subset and their model source unchanged. An app-internal method sits in the project's own sources, a library method's source comes from its dependency (the language reference has how to get it). Read it to see how data moves from the method's inputs (receiver, arguments) to its outputs (return value, arguments it writes into, state it stores), gathering the full context needed to understand the function's behavior.

2. Write the model

Reproduce that propagation in the language-specific code form in the batch's model project at .opentaint/dataflow/<batch> — scaffold it if it doesn't exist yet — following the language reference's artifact layout. Cover every assigned callable variant, repair an explicitly handed callable in the existing source, and add new ones there rather than rewriting the file. The engine is field-sensitive — taint is tracked per field — so route data field-to-field exactly as the source does rather than tainting the whole object. The test project's negative samples (if present) verify this by storing taint in one field and reading another, so an over-broad model makes them fire. The concrete constructs and patterns are in the language reference.