code-completion-NO-ORCHESTRATION

Code Completion (flat, recovery-looped) — NO ORCHESTRATION (Ablation B)

What is ablated: the Orchestration pattern. The full skill choreographs the work as a fixed pipeline — Step 1 analyse, Step 2 route, Step 3 load context, Step 4 classify into one of five tiers, Step 5 pre-gen gate, Step 6 doctests, Step 7 validate doctests, Step 8 code, Step 9 recovery loop, Step 10 post-gate, Step 11 inject — spread across four files loaded progressively. None of that staging survives here. There is no step list, no routing step, no tier table, no separate reference files, no staged gates.

What is preserved: the Recovery Loop. You still write doctests as an oracle, generate code, execute the doctests with the runner, and fix-and-rerun until they pass or you run out of attempts. This isolates the marginal contribution of Orchestration: comparing this variant against the full skill measures exactly what the structured pipeline buys on top of "doctests + a repair loop."

The task

You are given a JSON record with a prompt (Python code that stops where code is missing) and metadata. Complete the missing code.

• If metadata has function_name: the prompt ends after a function signature/ docstring and the body is missing — produce the full indented body.
• If metadata has line_no: the prompt ends mid-line — produce only the characters that finish that one line (no newline, no extra lines).

Do not change the signature or the existing docstring. Match the file's existing imports, indentation, and naming. Do not load the repo's test files.

How to do it

Work however you judge best to arrive at correct code — there is no prescribed sequence. The one mechanism you must use is the doctest recovery loop, because that is what is being held constant in this ablation:

1. Write one or more doctests that capture what the completed code must do (concrete input → expected output; an exception case if relevant). If the target genuinely cannot be tested with a doctest in isolation (e.g. an import line, a bare constant, a class-attribute line, or code that needs live external state), say so and fall back to a plain syntax check instead of inventing a meaningless test.

2. Write the candidate completion.

3. Write a complete runnable file — the prompt's imports and globals, the target function with its docstring containing your doctests, and your candidate body — to /tmp/completion_candidate.py.

4. Run the runner:

   python run_doctest.py /tmp/completion_candidate.py
   

5. If it reports failures, read the EXPECTED vs GOT, fix the code (not the test, unless you realize your expected value was genuinely wrong), and run it again. Keep going until all doctests pass or you have made about 5 attempts. If you run out of attempts, deliver the best attempt you have and say what still fails.

The runner prints STATUS: PASSED | FAILED | ERROR | SKIPPED with TOTAL/PASSED/ FAILED and per-failure TEST / EXPECTED / GOT lines. Use that output to drive your fixes.

Doctest format reminders

• >>> then the call; the expected output on the very next line (no blank line between).
• Continuation lines start with ... .
• Exceptions:

  >>> f(bad)
  Traceback (most recent call last):
      ...
  ValueError: message
  

• Use # doctest: +ELLIPSIS on the >>> line if the output has an unpredictable part (e.g. a memory address) and put ... where it varies.
• For non-deterministic output, test the type/length/shape instead of an exact value.

Delivering

Once the doctests pass (or you have exhausted attempts), append your completion to the prompt at the correct position (for a line task, attach directly to the last character with no separator). Keep passing doctests in the docstring if you generated any; replace any still-failing doctest with a short TODO comment rather than shipping a broken example.

Report: the completion, whether the doctests passed, how many attempts the recovery loop took, and — if anything still fails — what and why.