Owned generation recipes¶

Owned recipes bring research methods into Repo2RLEnv without installing or cloning the upstream research implementations at runtime. Each recipe has its own source pin, notices, algorithm, options and RFC. Harbor and ordinary libraries remain dependencies. Target repositories are input data and may be cloned remotely.

Start with the input you have. Each walkthrough below explains the algorithm, numbers every model call, shows retry edges, and links to complete prompts. The prompt guide explains how templates become actual requests recorded in a campaign.

Choose a generation route¶

flowchart TD
  I["What input do you have?"] --> R["Working repository"]
  I --> P["PRs or repository history"]
  I --> S["Questions, tasks or terminal recordings"]
  I --> N["Sampler or problem-family definition"]
  R --> SM["SWE-smith: introduce a source defect"]
  R --> SF["SWE-Flow / R2E: remove an implementation"]
  R --> CG["CLI-Gym: damage the environment"]
  P --> SG["SWE-gen: reverse supplied PR changes"]
  P --> HG["SWE-Next / R2E-Gym: mine historical changes"]
  S --> SE["SETA: synthesize from a question or evolve a parent"]
  S --> DA["DataArc: augment Harbor seeds"]
  S --> TW["TerminalWorld: reconstruct a recording"]
  N --> TE["TMax / Endless Terminals: sample requirements"]
  N --> SC["SCALER: expand reasoning instances"]

pipeline.name describes the generation family; recipe selects its research-inspired implementation. Existing native behavior remains available without a recipe. These 14 recipes are experimental. SEC-bench is deferred and is not implemented.

repo2rlenv pipelines list
repo2rlenv pipelines describe repo_mutate --recipe swe_smith --json

The catalog distinguishes planned methods from executable experimental implementations. An executable recipe is not a claim of training-quality output. The shared architecture and ownership policy are in RFC 0011.

Where each stage runs¶

sequenceDiagram
  participant C as Controller
  participant M as Model API
  participant W as Cloud worker
  participant H as Harbor containers
  C->>C: Preflight
  C->>W: Install runtime
  W->>W: Prepare source
  W-->>C: Candidate evidence
  opt Recipe needs a model
    C->>C: Reserve and log request
    C->>M: Prompt and schema
    M-->>C: Response and usage
    C->>C: Validate and account
  end
  C->>W: Materialize candidate
  W->>H: Build and check
  H-->>C: Execution evidence
  opt Recipe has a repair loop
    C->>M: Draft and failure
    M-->>C: Revised draft
    C->>W: Bounded retry
  end
  C->>C: Export bundle and lineage

This shows execution boundaries, not one universal stage order. Historical recipes establish contrast before instruction writing; TerminalWorld replays before test writing; SCALER has no model stage. SWE-smith's fresh Harbor checks are a separate campaign step. Follow each method's diagram for its exact order.

Preflight checks the source, recipe, budget and runtime hash. The model receives stage-specific system and user messages plus an output schema. Execution evidence includes test identities, rewards, logs and artifacts. The cloud worker is a Modal or Daytona sandbox running the owned wheel and Docker.

The controller performs metadata acquisition, parsing, model calls, accounting and file assembly. Image builds and target/generated-code execution happen remotely. Repository profiles reuse ensure_bootstrap with an explicit Dockerfile and its cache, without the bootstrap LLM agent. Terminal builders generate their task-specific setup and fixtures as part of the recipe. Dependencies are installed before the learner runs offline.

What a task contains¶

<task-name>/
  instruction.md             # Learner request
  task.toml                  # Harbor runtime, resources and artifacts
  environment/
    Dockerfile               # Starting state and build-time dependencies
    ...                      # Repository snapshot or fixtures
  solution/
    solve.sh                 # Private reference entrypoint
    ...                      # Original source, recovery script or answer
  tests/
    test.sh                  # Trusted verifier entrypoint
    ...                      # Tests, expected identities and reward code
    Dockerfile               # When using a separate verifier environment

The bundle is not copied wholesale into the learner container. Harbor uses its environment, solution and tests in their respective phases. Model receipts and generation traces stay outside it.

Generation checks establish runnable tasks and references. Independent instructional-quality and adversarial review remain a later phase.

Accounting and workers¶

Initialize an explicit budget once. Reinitializing with a different amount is rejected. Unknown model/provider outcomes retain their reservation; completed calls are accounted using recorded usage estimates rather than counted twice.

Set execution.campaign_dir in the generation config to this campaign directory. generate --max-spend-usd is a native-generation option; owned recipes reject it before dispatch and use the shared campaign ledger instead. --pipeline-opt overrides individual options even when the pipeline name comes from --config.

Owned generate --json emits JSON Lines progress; inspection commands such as tasksmith show --json and quality show --json emit one JSON result. CLI failures use {"error": "ExceptionType", "message": "description"} and exit 2. Logs go to stderr; --verbose adds a traceback there without changing machine output.

repo2rlenv campaign init workspace/my-campaign --budget-usd 25
repo2rlenv workers start --campaign workspace/my-campaign --provider modal \
  --name my-worker --reserve-usd 3 --timeout-sec 3600
repo2rlenv workers probe workspace/my-campaign/workers/my-worker.json \
  --out workspace/my-campaign/probes/first
repo2rlenv campaign status workspace/my-campaign --json
repo2rlenv workers stop workspace/my-campaign/workers/my-worker.json

Stopping a worker confirms cleanup but does not invent a bill. Reconcile a reservation with a usage/billing receipt or a clearly labelled conservative estimate:

repo2rlenv campaign settle workspace/my-campaign --operation worker:modal:my-worker \
  --cost-usd 0.30 --evidence workspace/my-campaign/worker-usage.json

The amount above illustrates the command; it is not a price quotation. Include failed requests, image builds and runtime in campaign accounting. Model receipts record requests, responses, schema, usage and the cost basis. Keep these private review artifacts outside learner-visible task directories.

Modal workers run Docker inside a VM. Daytona workers use its image build and Docker-in-Docker facilities; account limits can differ. Modal's timeout is a maximum lifetime. Daytona's configured auto-stop is an idle timeout, and the owned controller additionally stops dispatch after the recorded execution window. Always terminate workers explicitly after use; there is no local Docker fallback.

Output and acceptance¶

The current release target is 100 generated tasks for each of twelve methods, plus the approved smaller TMax collection of 55 and CLI-Gym collection of 25. The first 20-task milestones preceded this expansion. Tasksmith has its separate verified 50-task cohort. See the release inventory for completed datasets and remaining counts. Detailed attack and blind-rollout audits follow generation; they do not block implementing the next recipe. This sequencing does not change what a later quality-accepted label means.

flowchart LR
  G["Recipe generation and execution checks"] --> H["Exported Harbor bundles"]
  H --> M["100 per recipe; TMax 55 and CLI-Gym 25"]
  M -.-> Q["Later: reference, specification and attack audits"]
  Q --> R["Blind Sonnet and Opus traces"]
  R --> A["Artifact-bound acceptance report"]

Generation reports attempted and exported counts. Acceptance requires every mandatory quality criterion to pass with evidence for the current bundle hash; missing checks, failed checks and evidence for an older revision are not passes. Solver failure alone does not invalidate a task. The initial owned implementation is still collecting these audits; its generated tasks are labelled exported.

Harbor 0.22.0 parses the emitted schema 1.3 tasks. Some worker kernels do not support Harbor's nftables-based dynamic firewall. The owned repo2rlenv.execution.harbor_offline:OfflineDockerEnvironment adapter supports Linux Dockerfile tasks that remain offline in every phase, using Docker's network_mode: none. It rejects allowlists, network transitions and task-defined extra services. Other task shapes require another verified runtime route.

Implemented recipe guides: SWE-smith, SETA Seed2Synth, SETA Evol, SWE-gen, SWE-Flow and R2E, plus TMax and Endless Terminals, TerminalWorld, CLI-Gym, DataArc, SWE-Next, and R2E-Gym. SCALER adds algorithmic reasoning instances from released families. The active campaign covers these 14 recipes. SEC-bench remains a deferred design and is excluded from this integration milestone. Campaigns are still collecting generated outputs.

Contract references¶

• Harbor tasks, validated against the installed 0.22.0 task models and trial implementation.
• Modal VM sandboxes.
• Daytona sandbox management.
• LiteLLM structured outputs and Anthropic mapping.