create-pass-through-approximation

Skill: Create PassThrough Approximation

Model a dropped method's taint propagation as a passThrough approximation — a config that tells the engine how data moves from a method's inputs to its outputs, so a flow the analyzer lost through the opaque call is restored.

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 id; its passthrough entries live in .opentaint/tracking/approximations/<batch>.yaml, and you append the ones you build to that file's build.done
• methods (optional) — a specific { method, signature } subset to (re)work instead of the whole passthrough bucket, when the caller needs only those

Workflow

1. Understand the propagation

Take the batch's passthrough methods not yet in build.done (or the specific methods you were handed) and study each from its real code: read the source (per the language reference). Model each method purely from what its own code does, independent of how the project uses it — the config describes the method's intrinsic propagation. Answer: where does the input data go? Data that arrives on the receiver or an argument — does it come back out, through the return value, an argument the method writes into, the receiver, or an object or field it stores into? Note too whether the object holds the data between calls (a setter stashes it and a getter hands it back later, or a builder accumulates it) — that needs a virtual field. That shape is what the config expresses.

2. Write the config

Write one passThrough config per package under .opentaint/pass-through (the format and patterns are in the language reference). A method already in build.done and not explicitly handed in methods is built and trusted — leave it and its config as-is. Repair an explicitly handed method in its existing config; add a new method to its existing package config rather than rewriting the file. Two ideas drive the copy: