Pith. sign in

REVIEW 2 major objections 5 minor 82 references

Pre-code responsibility IDs let AI code generators produce auditable traces and bounded repairs.

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

T0 review · deepseek-v4-flash

2026-08-03 01:39 UTC pith:2XLLK3R3

load-bearing objection Honest and coherent system for auditable code generation, but the headline repair gain is underdetermined by the paper's own audit numbers. the 2 major comments →

arxiv 2607.29529 v1 pith:2XLLK3R3 submitted 2026-07-31 cs.SE

AuditCoder: Responsibility-Preserving Task Graphs for Auditable Code Generation and Bounded Repair

Kangjie Huang , Chen Lyu This is my paper
classification cs.SE
keywords code generationauditabilityresponsibility task graphbounded repairfault localizationconstruction provenanceLLM code repaircontract annotation
verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

Most code generators return a program without the record of which planning decision produced which piece of code, so a failing test points to a symptom but not to the responsible construction choice. AuditCoder's claim is that this gap can be closed by issuing each planned subproblem a stable responsibility identity before code is written and keeping that identity attached to the code, evidence, and repair history. The program and an auditable construction trace are treated as joint outputs. When validation fails, a conservative locator maps heterogeneous evidence to an evidence-supported node or branch, or abstains, and bounded repair regenerates only that region while reusing the frozen complement. If right, this gives generated code a persistent index for validation and repair—useful for tasks with stable, locally testable boundaries, while tasks with tightly coupled global invariants remain a stated limitation.

Core claim

The paper's central claim is that decision–code responsibility misalignment—the gap between a generation-time commitment and the code that implements it—can be closed by allocating a stable responsibility identity to each planned subproblem before any code is sampled, and by keeping that identity attached to the owned implementation, validation evidence, and repair history. AuditCoder operationalizes this with a contract-annotated task graph and three pipeline invariants: pre-code identity, ownership-and-evidence binding, and identity-preserving intervention. The intended consequence is that a failed test maps to an evidence-supported node or dependency branch—or yields abstention—and repair

What carries the argument

The central machinery is the contract-annotated task graph: a planner-built, pre-code graph whose nodes are responsibility units, each carrying a stable ID, goal, interface contract, complexity budget, provenance map, owned code bundle, local validation evidence, and append-only repair history. A total ownership map binds every registered function or helper to exactly one node, and a conservative locator (traceback → resource evidence → local rejection → abstention) maps global failure evidence back to a node or branch. The repair operator then selects either the node or a dependency-branch subtree, freezes the complement, expands the boundary only through recorded integration exceptions, an

Load-bearing premise

The load-bearing premise is that a task can be decomposed before code exists into responsibility units whose boundaries align with real fault boundaries; the paper itself flags (Section G, Figure 3) that when correctness depends on a tightly coupled global invariant, locally complete records can be misleading.

What would settle it

Take a set of tasks whose correctness depends on a global invariant that spans multiple nodes, run AuditCoder with bounded repair, and compare against whole-program retry: if localized repairs repeatedly fail or regress while whole-program retry succeeds, the fault-boundary assumption collapses; a complementary check uses a benchmark with ground-truth root-cause labels and asks whether the locator's chosen node matches the true responsible node more often than chance.

Watch this falsifier. Get emailed when new claim-graph text bears on it.

Share X Bluesky LinkedIn Reddit HN

If this is right

  • If a code generator returns both a program and a trace, a reviewer can answer which construction decision produced a failing region, not just which code looks suspicious.
  • When validation fails, the system can localize the failure to an evidence-supported node or branch, repair only that region, and reuse the frozen complement, reducing the blast radius of intervention.
  • The responsibility record becomes a persistent index: every owned code bundle, validation verdict, and repair transaction shares one ID, so history is queryable and rollback-restorable.
  • Evidence-guided repair can recover most of the accuracy lost to auditable decomposition: in the paper's matched evaluation, plan-only generation at 62.5% pass@1 rose to 83.0% after localized repair.
  • When evidence does not support a stable boundary, the system abstains rather than patching blindly, keeping the bounded-repair guarantee intact but shifting cost to a global fallback.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • The same responsibility identity could be reused after deployment to attach runtime incidents, security patches, or code-review comments to the construction-time decision, extending the audit trail beyond unit-test failures.
  • The paper's own audit shows trace links persist (0.9725 decision–code trace coverage) while only 26 of 60 failures support a node/branch boundary; this suggests the binding bottleneck is evidence strength rather than record persistence, so richer local checks (property-based tests, differential execution) should improve bounded-repair yield more than better generation.
  • Since abstention-triggered global fallback consumes about 58% of repair tokens, a cheaper fallback—such as a second, coarser responsibility level—could preserve conservative semantics while reducing cost.
  • Extending the graph to repository-scale code would require ownership records for files, imports, and shared state; the paper explicitly leaves this open, and its per-node evidence records suggest a natural extension.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit.

Referee Report

2 major / 5 minor

Summary. AuditCoder treats a generated program and an auditable construction trace as joint outputs. Before code generation, a contract-annotated task graph allocates stable responsibility IDs; node-local generation, assembly, global validation, evidence-to-responsibility localization, bounded repair, and the append-only repair history all reuse the same IDs. If the locator cannot find an evidence-supported node or branch, it abstains and a separately logged global fallback may follow outside the frozen-complement guarantee. The paper evaluates the pipeline on 200 APPS tasks and ClassEval, reporting pass@1 of 82.5–83.0 on APPS and 75.0–82.0 on ClassEval, below AgentCoder but above CoT+retry on ClassEval. A separate post-hoc audit of 200 deepseek-v4-flash APPS records reports task-macro DCTC 0.9725, localization coverage 26/60 failures, localized repair success 17/26, and governance metrics. The authors conclude that the bottleneck is evidence strong enough to justify a repair boundary, not record persistence.

Significance. If the empirical claims are confirmed, the paper contributes a reusable notion of process auditability for LLM code generation: stable responsibility IDs allocated before code, ownership/evidence binding, identity-preserving repair transactions, and explicit abstention. The design is detailed (Algorithm 1, serialized record schema, prompt corpus, failure taxonomy), and the authors are candid about limitations: DCTC measures record presence rather than truth, localization coverage is not accuracy, low-confidence evidence dominates, and the audit uses a different model/provenance from the functional runs. The submitted reproducibility package and exploratory cross-domain suites are strengths. However, the central functional claim is underdetermined because the headline pass@1 does not separate bounded repair from the separately logged global fallback, and no locator control is provided. These issues are fixable by re-analyzing the existing logs, so the contribution is defensible but the empirical support needs work.

major comments (2)
  1. [§4.2, Table 1; cf. §3.4, §4.3] The headline APPS gain (Qwen 70.0→83.0) is not attributable to the bounded-repair mechanism as defined. §3.4 states that when z=⊥ bounded repair stops and a separately logged global fallback may follow, outside the frozen-complement guarantee. §4.3 reports that 34/60 audit failures take that fallback and are excluded from localized-repair metrics, yet §4.2/Table 1 reports the 83.0% row as 'evidence-guided repair' without stating whether fallback paths are included. If the Table 2 localization rate (17 localized passes among 60 failures) applied, bounded repair alone could add at most 17/200 = 8.5 points, so reaching +13 points would require at least 9 recovered tasks from the fallback. Since Table 2 is a separate deepseek-v4-flash audit, the exact split cannot be inferred, but the row composition is unspecified. Please report, for the same runs: pass@1 after bounded repair only (abstenti
  2. [§4.2, RQ1; cf. §3.3] The causal claim that 'evidence-guided repair' recovers accuracy lacks a control for the locator. The table includes Direct+retry (85.0 Qwen), a whole-program retry, but not a bounded-repair arm with random-node selection or with the locator disabled under the same graph pipeline and budget. Without such an ablation, the 70.0→83.0 gain could be due to the extra repair attempt budget or to the global fallback rather than to the evidence-to-responsibility mapping. At minimum, add a random-node bounded-repair baseline and a same-budget global-retry arm on the same 200 tasks; this also addresses the acknowledged lack of node-level ground truth, since a random-node control provides a lower-bound reference for 'evidence-supported'.
minor comments (5)
  1. [§4.1, Tables 1–2] All functional numbers are single-run point estimates without variance or significance tests. On 200/100 records, report bootstrap confidence intervals or at least binomial standard errors for the key comparisons, especially ClassEval (75.0/82.0 vs. 86.0/88.0) and the CoT+retry comparisons.
  2. [§4.3, Table 2] The median column 'DCTC-leaf, task macro' shows '1.0→1.0' while the means are 0.9625 and 0.9725. This is opaque; report the distribution (e.g., quartiles) or explain why the median is exactly 1.0.
  3. [§3.3, R3] The rule 'compatible with the global failure' is not operationally defined. Specify how compatibility is checked (e.g., matching failing input, shared variable references, or a diff against the failing case) so the locator behavior is reproducible.
  4. [Algorithm 1, §3.4] Algorithm 1 returns at line 19 when z=⊥, but §4.3 discusses 34 abstention-triggered global fallbacks. Clarify where the fallback is invoked and how it is recorded, since those paths are a significant part of the pipeline's observed behavior.
  5. [§4.3, Appendix E, Table 7] The exclusion of 'five legacy transactions' is described slightly differently in §4.3, Appendix E, and Table 7 ('five legacy repair cases have no acceptance record'). Make the exclusion criteria and the 55-transaction denominator consistent across all three places.

Circularity Check

0 steps flagged

No circular derivation: functional gains are measured against external hidden tests, and the audit metrics are explicitly disclosed as record-presence/coverage/policy-consistency measures rather than validated predictions.

full rationale

AuditCoder contains no fitted parameters, no equations that are reused as predictions, and no self-citation chain; all cited works are external. The functional claims (APPS 82.5–83.0%, ClassEval 75.0–82.0%) are measured against held-out external tests and compared with independent baselines, so the central recovery result is not equivalent to its inputs by construction. The audit layer is self-referential in a loose sense: DCTC counts field presence in the pipeline's own records, localization coverage counts the pipeline's own recorded node/branch selections, and decision compliance compares recorded decisions with recorded ranks. However, the manuscript repeatedly and explicitly disclaims stronger interpretations: 'Because any nonempty validation verdict counts, DCTC measures record completeness rather than the truth of the fields or the correctness of the program'; '26/60 is a coverage measure, not localization accuracy or correct-abstention accuracy'; and the governance checks 'establish consistency with the recorded policy and snapshots; they do not establish test completeness, repair optimality, or restoration of all runtime and intermediate state.' These are honest limitations of internal-process evidence, not circular derivations. The one substantive numerical concern is attribution of the 83.0% row: Section 3.4 states a separately logged global fallback lies 'outside the frozen-complement guarantee and is reported separately in Sections 4.3 and 4.4,' yet Section 4.2 does not state whether the headline Qwen row includes fallback paths. That is a reporting/underdetermination issue, not a reduction of the result to its own inputs. No load-bearing step qualifies as circular under the required standard.

Axiom & Free-Parameter Ledger

2 free parameters · 3 axioms · 1 invented entities

The ledger is light on numeric fitting—there are no fitted constants and no equations that reduce to trained parameters. The load-bearing assumptions are structural: decomposability of tasks into responsible units, validity of the locator's evidence mapping, and meaningfulness of record-presence metrics. The main invented entity is the responsibility ID itself, an internal data structure with no independent empirical handle.

free parameters (2)
  • repair budget K = not reported
    Algorithm 1 caps localized repair attempts at K; the value used in experiments is not reported and no sensitivity analysis is given, so the headline pass@1 depends on an unexamined hand-chosen budget.
  • locator confidence labels = high / low (discrete)
    R1–R4 assign discrete confidence labels (high, low-to-medium) with no calibration; 20 of 26 localized cases rely on low-confidence verification reports, so the localization evidence threshold is a hand-set design choice.
axioms (3)
  • domain assumption A pre-code task decomposition can expose real fault boundaries (stable, locally testable units).
    Section 3.1 commits the planner to a task graph before code; Section G and Figure 3 acknowledge tightly coupled global invariants break this. If false, records persist but mislead.
  • ad hoc to paper Locator rules R1–R4 map failure evidence to the node/branch that caused the failure.
    Section 3.3 defines fixed-priority rules, but APPS has no responsibility-node ground truth; the paper reports coverage (26/60) rather than accuracy, so this mapping is assumed, not established.
  • domain assumption Nonempty record fields are meaningful audit evidence.
    DCTC (Section D) counts any nonempty validation verdict as coverage, and contract-signature consistency checks only one function with matching positional params; semantic correctness of the records is not checked.
invented entities (1)
  • Responsibility node identity (idi) no independent evidence
    purpose: Stable address binding commitment, owned code, provenance, validation evidence, and repair history
    A software bookkeeping construct, not a physical entity; its persistence is measured only by the pipeline's own records (DCTC), with no external ground truth. Not a graviton-style empirical postulate.

pith-pipeline@v1.3.0-daily-deepseek · 36164 in / 13936 out tokens · 141638 ms · 2026-08-03T01:39:52.881060+00:00 · methodology

0 comments
Cite this review

Pith. "Pith review of AuditCoder: Responsibility-Preserving Task Graphs for Auditable Code Generation and Bounded Repair." pith.science (2026). https://pith.science/paper/2XLLK3R3

@misc{pith2026260729529,
  author       = {Pith},
  title        = {Pith review of: AuditCoder: Responsibility-Preserving Task Graphs for Auditable Code Generation and Bounded Repair},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/2XLLK3R3}},
  note         = {Machine review of arXiv:2607.29529}
}
Share X Bluesky LinkedIn Reddit HN
read the original abstract

Code generators return programs, but typically do not preserve the construction record needed to connect a failure to the decision that produced the affected code or to delimit a justified repair. We present AuditCoder, which treats the program and an auditable construction trace as joint outputs. Before code generation, a contract-annotated task graph assigns stable responsibility identities that remain attached to each commitment, its owned implementation, provenance, validation evidence, and intervention history. When validation fails, a conservative locator maps heterogeneous evidence to a node or dependency branch---or abstains---and bounded repair regenerates only that region while reusing the frozen complement. On APPS, \method{} reaches $82.5$--$83.0\%$ \texttt{pass@1}, recovering much of the loss caused by unrepaired graph decomposition but trailing AgentCoder by $7.5$--$8.5$ points. On ClassEval, it reaches $75.0$--$82.0\%$, outperforming CoT + retry while remaining below AgentCoder. A separate audit of 200 APPS records yields $0.9725$ task-macro decision--code trace coverage; the locator identifies an evidence-supported node or branch for 26 of 60 failures, and 17 of those localized repairs pass. For tasks with stable, locally testable boundaries, the graph functions not only as a decomposition structure but also as a persistent index for validation and repair.

Figures

Figures reproduced from arXiv: 2607.29529 by Chen Lyu, Kangjie Huang.

Figure 1
Figure 1. Figure 1: Decision–code responsibility misalignment. Plan [PITH_FULL_IMAGE:figures/full_fig_p001_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: Overview of the responsibility-preserving lifecycle in [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: Two diagnostic cases illustrating the scope of graph-based responsibility boundaries. Stable, locally testable artifacts [PITH_FULL_IMAGE:figures/full_fig_p007_3.png] view at source ↗
Figure 4
Figure 4. Figure 4: Task breakdown and critical-audit records for the permutation-construction example. Solid black arrows show task [PITH_FULL_IMAGE:figures/full_fig_p013_4.png] view at source ↗
Figure 5
Figure 5. Figure 5: Responsibility boundary used in the APPS 3103 audit transaction. The locator selects the subtree rooted at [PITH_FULL_IMAGE:figures/full_fig_p016_5.png] view at source ↗
Figure 6
Figure 6. Figure 6: Exploratory cross-domain fixed-run Resolved@1 under frozen external tests using deepseek-v4-flash. A task is resolved only when the final retained candidate passes every test. Labels report resolved tasks over suite size; because each suite contains only six or eight tasks, the counts rather than percentage differences should guide interpretation. and standardized-unexpected-earnings calculation, split/div… view at source ↗

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

82 extracted references · 1 linked inside Pith

  1. [1]

    Derive time complexity upper bounds based on data ranges: - n <= 20 -> O(2^n) or O(n!) is acceptable - n <= 1000 -> O(n^2) is acceptable - n <= 10^5 -> O(n log n) or O(n) is required - n <= 10^6 -> O(n) or O(n log n) is required ( with small constant) - n <= 10^7 -> strictly O(n) is required

  2. [2]

    Derive space complexity targets (based on memory limit and data scale)

  3. [3]

    time_complexity_upper_bound

    Identify special constraint features (e.g., small value range allows counting sort, sparse graph allows adjacency list, monotonicity allows binary search / monotonic stack) Prompt group Templates Pipeline role Plan agent Analyzer,decomposer,designer,parser, reviewer, selector, thinker Builds constraints, algorithm choices, task graph, interfaces, and revi...

  4. [4]

    Maximum decomposition depth: 3 levels (S0 -> S1 -> S1_1 -> S1_1_1)

  5. [5]

    S0", type is

    The root node ID is "S0", type is "orchestration ", and is_leaf is false

  6. [6]

    S1", "S2

    Level-1 subtask IDs are "S1", "S2", ...; level-2 are "S1_1", "S1_2", ...; level-3 are "S1_1_1",

  7. [7]

    Decomposition criteria: - If a subtask can be completed by a single algorithm Agent in one function -> is_leaf: true, fill in agent_type - If a subtask requires collaboration of multiple different algorithm types -> is_leaf: false, continue decomposing

  8. [8]

    [Test Coverage] Are there at least 1 sample test and 2 boundary tests?

  9. [9]

    No more than 5 child nodes per level

  10. [10]

    The dependencies list of each node contains only **same-level or lower-level** subtask IDs (tasks that must be completed before this node executes)

  11. [11]

    S1_1.query

    The parent field points to the ID of the direct parent node ## Data Flow Rules Each node must declare inputs and outputs, **both as JSON arrays** (use [] even for a single item): - inputs: input data required by the node; each item contains name, type, description, source - source is null: comes from external input ( problem input or passed from parent no...

  12. [12]

    S1", "S1_1

    task_id -- the node's id (use the given id directly, e.g., "S1", "S1_1")

  13. [13]

    name": str,

    interface: - function_name -- function name (following Python naming conventions) - params -- parameter list, **must be a JSON array**, each item: {{"name": str, "type": str, " description": str}} Parameters should correspond to the node's inputs (strip source reference metadata, keep actual parameters) - return_type -- return value type (consistent with ...

  14. [14]

    title -- problem title

  15. [15]

    description -- core problem description (remove formatting noise, preserve mathematical expressions)

  16. [16]

    input_format -- precise description of the input format

  17. [17]

    output_format -- precise description of the output format

  18. [18]

    1s", "2s

    constraints -- constraint conditions: - time_limit -- time limit (e.g., "1s", "2s") - memory_limit -- memory limit (e.g., "256MB") - data_ranges -- data ranges for each variable, format: [{{"var": "n", "min": 1, "max": 100000}}]

  19. [19]

    input":

    sample_cases -- sample input/output, format: [{{" input": "...", "output": "...", "explanation": "..."}}] ## Output Example Input problem text (Two Sum) -> Output: ```json {{ "title": "Two Sum", "description": "Given an integer array nums and a target value target, find the indices of the two numbers in the array that add up to target.", "input_format": "...

  20. [20]

    input":

    sample_test_cases -- test cases extracted directly from the problem examples, **must be an object array** Each item format: {{"input": "...", " expected_output": "..."}} Note: the field name is expected_output, not output

  21. [21]

    description

    edge_cases -- derived boundary/extreme test cases (at least 3), **must be an object array** Each item format: {{"description": "...", "input ": "...", "expected_output": "..."}} Note: each item must have all three fields: description, input, and expected_output

  22. [22]

    4", "0",

    invariants -- invariants that a correct solution must satisfy, **must be a string array** Boundary cases should cover: - Minimum input (n=1 or empty) - Boundary of maximum input scale - All identical elements - Special values (0, negative numbers, extreme values) - Sorted / reverse-sorted input **Important requirements for input and expected_output format...

  23. [23]

    [Problem Information Completeness] Are title, description, input_format, output_format, constraints, and sample_cases in the problem all non -empty?

  24. [24]

    [Constraint-Algorithm Consistency] Is the complexity of the selected algorithms ( complexity_budget of each leaf node) within the overall complexity budget derived from the constraints?

  25. [25]

    [Tree Structure Validity] - Do all IDs referenced in parent fields exist in task_nodes? - Does the node corresponding to root_id exist? - Are there any isolated nodes (nodes without a parent other than the root)? - Note: S1 depending on S1_1, with S1_1's parent being S1, does NOT violate acyclicity -- this simply means S1_1 is a subtask of S1

  26. [26]

    [Dependency Acyclicity] Do all IDs in dependencies exist? Do they form a DAG (no cycles)?

  27. [27]

    [Leaf Node Completeness] For all nodes where is_leaf is true: - Do they all have an agent_type? - Do they all have a complete interface definition (function_name, params, return_type, preconditions, postconditions)?

  28. [28]

    taskID.outputName

    [Data Flow Connectivity] For all inputs where source is not null (format "taskID.outputName"): - Does the referenced task ID exist? - Does the referenced output name exist in that task's outputs?

  29. [29]

    [Execution Order Validity] Does execution_order include all leaf nodes? Does the order satisfy dependency constraints (dependencies before dependents)?

  30. [31]

    status":

    [Reasoning Chain Auditability] Is the reasoning_chain clear and logically coherent? ## Output Example Review passed -> Output: ```json {{ "status": "pass", "issues": [], "retry_node": "", "reason": "All checks passed. The IR structure is complete, data flow is connected, and dependencies are acyclic." }} ``` Review failed (missing interface) -> Output: ``...

  31. [32]

    problem_category -- problem classification (e.g., Graph Theory, Dynamic Programming, Greedy, Data Structures, Number Theory, String, Geometry, Search, etc.)

  32. [33]

    key_observations -- key properties and observations (list at least 2-3 observations that have a decisive impact on solving the problem)

  33. [34]

    dp ", "greedy

    algorithm_selection -- list of selected algorithms, each item containing: - algorithm_type: algorithm identifier (e.g., "dp ", "greedy", "binary_search", "bfs", "dfs", " union_find", etc.) - agent_id: identifier of the corresponding algorithm Agent, format: "agent_<algorithm_type>" - subtask: description of the subproblem this algorithm is responsible for...

  34. [35]

    problem_category

    reasoning_chain -- complete reasoning chain ( logical steps from observations to conclusion, one string per step) Notes: - A problem may require multiple algorithms working together (e.g., sorting for preprocessing, DP for the core logic) - Each algorithm selection must be feasible within the complexity constraints - The reasoning chain must be auditable ...

  35. [36]

    problem_nature -- the essential nature of the problem in one sentence (what makes it hard / interesting)

  36. [37]

    surface_traps -- common misreadings or naive approaches that would fail, and why

  37. [38]

    structural_insights -- deep observations about the problem's mathematical or algorithmic structure (e.g., monotonicity, convexity, graph properties, recurrence structure, symmetry)

  38. [39]

    solution_space -- the space of plausible solution families (do NOT commit to one; enumerate 2-4 candidates with rough pros/cons)

  39. [40]

    Is the graph guaranteed to be connected?

    critical_questions -- open questions that must be answered before committing to a strategy (e.g., "Is the graph guaranteed to be connected?", "Can weights be negative?")

  40. [41]

    O(n^2) DP looks correct but TLEs

    thinking_summary -- a concise paragraph synthesizing the above into a directional recommendation for the downstream constraint analyzer and algorithm selector ## Thinking Guidelines - Think broadly before narrowing. Resist the temptation to jump to the first recognizable pattern . - Explicitly consider and then reject sub-optimal paths; this prevents down...

  41. [44]

    Clearly comment the loop invariant: the meaning of left/right after the loop terminates

  42. [45]

    Comments in the code should only explain boundary semantics, not provide line-by-line explanations

  43. [46]

    "" Prompt for Binary Search Agent User BINARY_SEARCH_AGENT_USER =

    complexity_budget is the upper bound on complexity; the implementation must satisfy this constraint ## Output Format Output a JSON object with a single field: - code_snippet: The complete Python function source code string (including the function definition; may include helper functions) Output strictly JSON, do not add any extra text.""" Prompt for Binar...

  44. [50]

    Comments in the code should only explain non- obvious logic, not provide line-by-line explanations

  45. [51]

    "" Prompt for DP Agent User DP_AGENT_USER =

    complexity_budget is the upper bound on complexity; the implementation must satisfy this constraint ## Output Format Output a JSON object with a single field: - code_snippet: The complete Python function source code string (including the function definition; may include helper functions) Output strictly JSON, do not add any extra text.""" Prompt for DP Ag...

  46. [54]

    Prefer adjacency list representation for graphs (`dict[int, list[int]]`or`list[list[int]]`)

  47. [55]

    Explicitly initialize`visited`to prevent revisiting nodes

  48. [56]

    "" Prompt for Graph BFS Agent User GRAPH_BFS_AGENT_USER =

    complexity_budget is the upper bound on complexity; the implementation must satisfy this constraint ## Output Format Output a JSON object with a single field: - code_snippet: The complete Python function source code string (including the function definition; may include helper functions) Output strictly JSON, do not add any extra text.""" Prompt for Graph...

  49. [59]

    When recursion depth may exceed the limit, switch to an explicit stack to simulate DFS

  50. [60]

    During backtracking, correctly restore state ( undo the choice)

  51. [61]

    "" Prompt for Graph Dfs Agent User GRAPH_DFS_AGENT_USER =

    complexity_budget is the upper bound on complexity; the implementation must satisfy this constraint ## Output Format Output a JSON object with a single field: - code_snippet: The complete Python function source code string (including the function definition; may include helper functions) Output strictly JSON, do not add any extra text.""" Prompt for Graph...

  52. [64]

    The sorting / comparison logic for the greedy strategy should be clear and readable

  53. [65]

    Comments in the code should only explain the basis of greedy decisions, not provide line-by-line explanations

  54. [66]

    "" Prompt for Greedy Agent User GREEDY_AGENT_USER =

    complexity_budget is the upper bound on complexity; the implementation must satisfy this constraint ## Output Format Output a JSON object with a single field: - code_snippet: The complete Python function source code string (including the function definition; may include helper functions) Output strictly JSON, do not add any extra text.""" Prompt for Greed...

  55. [69]

    When modular arithmetic is involved, take the modulus on intermediate results promptly to prevent overflow

  56. [70]

    Precomputations (factorial tables, inverse tables , etc.) should be done inside the function; do not use global variables

  57. [71]

    "" Prompt for Math Agent User MATH_AGENT_USER =

    complexity_budget is the upper bound on complexity; the implementation must satisfy this constraint ## Output Format Output a JSON object with a single field: - code_snippet: The complete Python function source code string (including the function definition; may include helper functions) Output strictly JSON, do not add any extra text.""" Prompt for Math ...

  58. [74]

    Prefer Python's built-in`sorted()`/`.sort()`( Timsort, O(n log n)); use the`key=`parameter for custom comparisons

  59. [75]

    When discretizing, ensure deduplication and order preservation using`sorted(set(arr))`+ binary search

  60. [76]

    "" Prompt for Sorting Agent User SORTING_AGENT_USER =

    complexity_budget is the upper bound on complexity; the implementation must satisfy this constraint ## Output Format Output a JSON object with a single field: - code_snippet: The complete Python function source code string (including the function definition; may include helper functions) Output strictly JSON, do not add any extra text.""" Prompt for Sorti...

  61. [79]

    If the function needs to read standard input, use `input()`or`sys.stdin.read()`; if parameters are already passed by the caller, process them directly

  62. [80]

    Do not use global variables; all state must be declared inside the function

  63. [81]

    "" Prompt for String Agent User STRING_AGENT_USER =

    complexity_budget is the upper bound on complexity; the implementation must satisfy this constraint ## Output Format Output a JSON object with a single field: - code_snippet: The complete Python function source code string (including the function definition; may include helper functions) Output strictly JSON, do not add any extra text.""" Prompt for Strin...

  64. [84]

    Clearly state the loop invariant: the meaning of window [left, right) at the start of each iteration

  65. [85]

    Pointer movement logic must ensure no cases are missed and no cases are double-counted

  66. [86]

    "" Prompt for Two Pointer Agent User TWO_POINTER_AGENT_USER =

    complexity_budget is the upper bound on complexity; the implementation must satisfy this constraint ## Output Format Output a JSON object with a single field: - code_snippet: The complete Python function source code string (including the function definition; may include helper functions) Output strictly JSON, do not add any extra text.""" Prompt for Two P...

  67. [87]

    Only implement the function defined in the interface; do not add extra code

  68. [88]

    The function signature must exactly match the function_name, params, and return_type in the interface

  69. [89]

    Prefer encapsulating the Union-Find structure as a helper class (`parent`,`rank`arrays +`find`/` union`methods), then call it inside the main function

  70. [90]

    find must implement path compression; union must implement union by rank / size

  71. [91]

    "" Prompt for Union Find Agent User UNION_FIND_AGENT_USER =

    complexity_budget is the upper bound on complexity; the implementation must satisfy this constraint ## Output Format Output a JSON object with a single field: - code_snippet: The complete Python function source code string (including the function definition; may include helper classes or helper functions) Output strictly JSON, do not add any extra text.""...

  72. [92]

    Problem information and overall solving strategy

  73. [93]

    Function interfaces and implemented code snippets for each leaf node task

  74. [94]

    __main__

    Data flow relationships between task nodes (the` source`field of DataSlot) You need to output a complete Python source file containing: - All sub-function code (**preserved as-is**, without any modifications) - A top-level`solve()`function that orchestrates sub-function calls in execution order and correctly passes cross-task data according to the DataSlo...

  75. [95]

    The order of functions must follow execution_order (dependencies appear first) 2.`solve()`must call each sub-function in execution_order sequence, passing upstream outputs as downstream inputs

  76. [96]

    TASK_ID.slot_name

    The`source`field of DataSlot has the format`" TASK_ID.slot_name"`, indicating a reference to an output variable of a task;`source=null`indicates external input (read from the problem input)

  77. [97]

    __main__

    The`if __name__ == "__main__":`block must parse input according to the problem's input_format, and the output must conform to output_format

  78. [98]

    Do not introduce any new dependency libraries not already used in the code snippets

  79. [99]

    "" Prompt for Assembler User ASSEMBLER_USER =

    The code must pass the sample test cases ## Output Format Output a JSON object with a single field: - final_code: The complete Python source code string Output strictly JSON, do not add any extra text.""" Prompt for Assembler User ASSEMBLER_USER = """\\ ## Problem Information Problem title: {title} Problem description: {description} Input format: {input_f...

  80. [100]

    A brute-force / exhaustive reference solution ( Python function) that is guaranteed to be correct but does not need to be efficient

Showing first 80 references.