diffgenome 0.1.0__py3-none-any.whl

diffgenome/genome_prompt.py

@@ -0,0 +1,33 @@
+# ruff: noqa: E501
+"""The genome proposer's instructions (the schema the checker and predictor implement).
+
+Identical to the text given to the proposers of Experiments 11-13 (v5 schema): Outcome,
+boundary bindings, value and literal identity, execution-structure constraints, repeated
+regions with occurrence facts, descriptive branch `calls`, evidence and eligibility rules.
+"""
+
+HEAD = """\
+# Task: propose the semantic layer of a Behavioral Genome for a real code change
+
+You are an abstraction engine. The change is {spec} in the repository {repo} (runtime
+{runtime}). Changed symbols: {symbols}.
+
+Deterministic machinery has ALREADY established the mechanics below. Do not re-derive them
+and do not contradict them:
+- decision sites (`if`) with stable ids `br:...`, source predicate, operand origins (local
+  def-use), and the (site, outcome) pairs required to reach them;
+- for every call and store: which (site, outcome) pairs it requires;
+- for the tests: the ordered event log of the relevant calls, each call's argument shapes with
+  value digests (`#abcd12`: equal digests = equal values; contents are not recorded), results,
+  every call's observed EXIT, and the observed outcome (T/F) of every decision site in those
+  calls. {null_note}
+
+Your job is MEANING: name the variables that matter, abstract the predicates, and give compact
+rules that GENERATE the observed behavior (which calls happen, which decisions go which way,
+how each entry call exits). A machine checks everything you cite and assigns status; you assign
+none. Write a scenario for every test listed, keyed by its exact test id as written in the
+event logs; each is predicted from your genome and compared with what executed.
+
+"""
+
+FORMAT = '## The genome format (fixed; the checker and predictor implement exactly this)\n\nReturn ONLY one JSON object:\n\n{\n "variables": [{"id", "name", "origin": "state|setting|input|derived", "description",\n                "observed_as": null\n                  | {"fact": "<receiver/global state fact>", "kind": "is_set|sign|bool"}\n                  | {"at": {"entity": "<function>", "point": "arg:<name>" | "result"},\n                     "kind": "is_set" | "changed_from:arg:<name>" | "size" | "bool"}\n                  | {"at": {...}, "kind": "identity", "scope": "call" | "execution"}\n                  | {"at": {...}, "kind": "equals_literal", "scope": "call" | "execution",\n                     "literal": {"lang": "go", "type": "string|int|uint8|...|bool|nil", "value": <v>,\n                                 "source": {"file": "<repo path>", "line": N}}}\n                  | [<several of the above>],\n                "definition": "<predicate over other variables>" | null,\n                "evidence": [...]}],\n "decisions": [{"id", "entity", "site": "br:... (a HEAD site id)", "inputs": [...],\n                "predicate": "<over variable names>", "order": <int>,\n                "true_branch":  {"steps": [...], "calls": [...], "absent": [...], "stops": bool,\n                                 "outcome": {"entity": "<function>", "is": "<exit>"} | null, "effect": "..."},\n                "false_branch": {...}, "evidence": [...]}],\n "transitions": [{"id", "entity", "when": "<predicate or true>", "sets": {"<variable>": "<expr>"},\n                  "state_before", "action", "state_after", "evidence": [...]}],\n "regions": [{"id", "entity": "<the enclosing function>", "head": "<the observed family that starts each repetition: a function name or site:br:...>",\n              "steps": ["call:<entity>", "T:<transition id>", "D:<decision id>", ...], "evidence": [...]}],\n "procedures": [{"id", "entity", "steps": ["call:<entity>", "T:<transition id>", "D:<decision id>", "R:<region id>", ...],\n                 "outcome": {"entity": "<function>", "is": "<exit>"} | null, "evidence": [...]}],\n "rules": [{"id", "name", "inputs", "relevant_state", "condition", "consequences": [...], "decision": "<id>|null", "evidence": [...]}],\n "regimes": [{"id", "name", "facts": {...}, "members": ["<test name>"], "evidence": [...]}],\n "scenarios": {"<test name>": {"state": {<variable>: value},\n                               "calls": [{"entity": "<entity>", "facts": {<variable>: value},\n                                          "occurrences": {"<region id>": [{"facts": {<variable>: value}}, ...]}}],\n                               "phenotype": {"head": "<exit of the entry call>", "why": "<one sentence from your rules>"}}},\n "unknowns": [{"what", "why"}]\n}\n\n**Boundary bindings.** A variable may be bound to an identity-level fact at a call boundary of\nan entity: `is_set` (the argument/result is not None), `changed_from:arg:<name>` (the result\'s\ndigest differs from that argument\'s digest), `size` (an argument\'s collection size), `bool`.\nThe checker reads these from the digests and shapes you see in the logs, per call. Argument\nfacts are known when the call starts; result and change facts when it ends. A transition of\nan entity that sets a boundary-bound variable is checked against that call\'s observed\nboundary: when the entry state cannot decide the path, the checker follows the branches that\nactually executed in that call (a decision with an atomic predicate `v` / `!v` then binds v).\n\n**Value identity and literals.** A binding of kind `identity` gives the variable an OPAQUE\nvalue: the digest seen at that boundary, never decoded. With `scope: "execution"`, the value is\ntaken from that boundary\'s occurrences earlier in the same test (it must be unique there, or it\nis unknown); with `scope: "call"` (default) from the call being judged. A variable with a LIST\nof two or more `identity` bindings claims the SAME value appears at all of them in one test:\nthe checker verifies that from observed digest equality (equal in at least 2 tests carrying at\nleast 2 different values), rejects it if any test shows them different, and never infers flow\n(only equality). Identity variables are compared only with `==` / `!=`. In scenarios, give an\nidentity variable a LABEL (any string, e.g. "access"): for shown tests the checker requires\nequal labels exactly where the observed identities are equal. A binding of kind\n`equals_literal` is true when the boundary value equals a literal WRITTEN in the source at the\ncited line (bool, nil, an integer, or a short plain string); the checker confirms the literal on\nthat line and compares digests, it never decodes other values. Scenario facts for any bound\nvariable (boundary, identity, literal) are checked against the matching call in shown tests.\n\n**Evidence and prediction eligibility.** Every item must cite checkable evidence; an item\nwith none stays a hypothesis and cannot drive a prediction. A supported item that some shown\ntest contradicts (e.g. its replayed outcome sequence differs) cannot drive a prediction either.\nA variable with two or more identity bindings is evidenced by its bindings themselves.\n\n**Outcome.** An exit is one of `returned`, `returned-error[:<kind>]`, `raised[:<kind>]`,\n`panic[:<kind>]`, `cancelled` (`completed` = `returned`). `<kind>` is the runtime type name,\ne.g. `raised:django.db.utils.DataError`. A branch\'s outcome names the function whose exit it\ndetermines, which may be the deciding function or one ENCLOSING it (an effect that surfaces\nlater in the same call). A procedure\'s outcome is its entity\'s exit when its steps complete\nwithout a stopping branch. Exits are compared with the observed exit of that function\'s calls,\nnever with test results.\n\n**Repeated regions and occurrence facts.** Repeated region placement is supplied by mechanics.\nConcrete occurrence facts are supplied by the scenario. Do not invent occurrence count, nesting\nor order. A region (`regions`) is ONE body that runs once per occurrence of an OBSERVED repeated\nregion of its enclosing function (`entity`); its `head` must be the family that the observed\nstructure says starts every repetition, and its steps must follow the observed order inside one\nrepetition. The enclosing function\'s procedure places it with the step `"R:<region id>"`. The\ngenome never states how many times a region runs: a scenario\'s call of the enclosing function\nsupplies `occurrences: {"<region id>": [...]}`, one item per concrete occurrence in order, each\nwith that occurrence\'s facts (read them from the test\'s input; the k-th item is the k-th\nrepetition). For the shown tests the checker aligns your k-th item with the observed k-th\nrepetition and checks every fact it can observe there (boundary facts of the calls inside it,\nand variables your atomic decisions `v` / `!v` bind from their observed outcomes); a\ncontradicted fact or a wrong count makes that prediction indeterminate.\n\n**Execution structure is a constraint, not yours to choose.** The section "Observed execution\nstructure" below is derived mechanically from the shown executions: which function runs\nduring which (containment), the order of phases inside a function, which calls form a\nrepeated region, and the order of calls and decisions inside one repetition. Call nesting and\nrelative procedural placement supplied by mechanics are constraints. Do not reorder calls, and\ndo not hoist a call or a decision outside its observed enclosing function. The checker judges\nevery procedure\'s structure (which calls and decisions it places inside which function, and\nthe order of consecutive steps) against these facts, and a prediction that places a call or a\ndecision where it was never observed is indeterminate. Express a repetition inside its enclosing function as a region (see Repeated regions and occurrence facts, above), never by hoisting it.\n\n**Not available** (deliberately): relation-valued variables, derived orders, iteration over\ncollections (loop variables, item identity across calls). If the behavior needs them, say so\nprecisely in `unknowns`; do not simulate them with per-instance variable names.\n\nSemantics used by the predictor:\n- A scenario\'s `calls` are the entry calls in order. A call of an entity with a procedure runs\n  it; a call of an entity the genome says nothing about is recorded and skipped; a call of an\n  entity that has decisions but no procedure stops the prediction (so give every entity whose\n  decisions you list a procedure, or reach its decisions through another entity\'s procedure).\n  "call:X" records a call and, if X has a procedure, runs it; "T:id" applies a transition\n  (literals true/false/none/integers, `var`, `!var`, `var + k`, `var - k`, `max(0, var - k)`);\n  "D:id" evaluates a decision and runs the taken branch\'s `steps` ONLY (a branch\'s\n  `calls` are descriptive, what it reaches, and are never executed); a branch\n  with `stops: true` ends the entity (inside a region too: there is no `continue`). "R:id"\n  runs region id once per occurrence the current scenario call supplies, in order: that\n  occurrence\'s facts hold during its body only (they are restored afterwards; variables bound\n  to receiver/global state persist); a region with no supplied occurrences stops the prediction.\n  Predicates: booleans/integers, `!name`, comparisons (identities: `==` / `!=` only),\n  `&&`, `||`, no parentheses. A scenario\n  lists every entry call, in order, with the facts that hold for that call and, for repeated\n  regions inside it, per-occurrence facts.\n- SCORING covers every observed evaluation of EVERY site listed under "Required sites" below\n  (the changed functions and functions nested in them), in order, per test. A site no decision\n  covers makes the prediction indeterminate. Predicted exits are compared per entity with the\n  observed exits of that entity\'s calls.\n- `phenotype` is your claim about the entry call\'s exit; scored separately.\n- Use only site ids given. Evidence ref kinds (JSON):\n  {"kind":"source","file":"<repo-relative path>","line":N,"text":"<exact text>"}\n  {"kind":"branch","site":"br:...","test":"<shown test name>","outcome":true|false}\n  {"kind":"control","site":"br:...","outcome":true|false,"callee":"<call expression>"}\n  {"kind":"dataflow","site":"br:...","origin":"<e.g. param:req>"}\n  {"kind":"boundary","entity":"<function>","point":"arg:<name>|result","binding":"is_set|changed_from:arg:<name>|size|bool","value":<value>,"test":"<shown test name>"}\n  {"kind":"outcome","entity":"<function>","exit":"<exit>","test":"<shown test name>"}\n  Cite only shown tests, and only head sites, in branch/boundary/outcome evidence.\n- Prefer few, generative rules. Be honest in `unknowns`.\n\n\n'