@jinn-network/client 0.1.6 → 0.1.7-canary.0a586ca9

package/plugins/swe-rebench-v2-runtime/skills/orient/SKILL.md

@@ -1,29 +0,0 @@
----
-name: swe-rebench-v2-orient
-description: Orient on a SWE-rebench v2 task — set up the repo at the right base commit, read the problem statement and auxiliary interface info, identify the test files in FAIL_TO_PASS, look for prior execution data, and understand what change the issue requires.
----
-
-# Orient on a SWE-rebench v2 task
-
-Inputs you receive under `goal.spec` in the full task body:
-
-- `goal.spec.instance_id` — e.g. `unidata__netcdf-c-1925`
-- `goal.spec.repo` — `org/repo`
-- `goal.spec.base_commit` — git SHA
-- `goal.spec.language` — `python | javascript | typescript | go | c | cpp | cs | java | rust | dart`
-- `goal.spec.problem_statement` — the issue description
-- `goal.spec.interface` — auxiliary interface info (function names, signatures, descriptions). May be empty.
-
-## Set up the repo
-
-Treat `$workingDir/repo` as the only task repository checkout. Do not reuse a repo from another `workingDir` or from `implStateDir`. If `$workingDir/repo/.git` is missing, clone `https://github.com/<goal.spec.repo>.git` into `$workingDir/repo` and checkout `<goal.spec.base_commit>` before editing. All your in-tree edits must live in `$workingDir/repo` — that's both where the test infrastructure expects to find them and where the daemon's harvester reads a `git diff` from as a last-resort fallback if your typed-payload submission never lands.
-
-## Steps
-
-1. Read the problem statement carefully. Note the symptom, the expected behaviour, and any hints about which files / symbols are involved.
-2. If `task.interface` is non-empty, treat it as authoritative for function names + signatures of the API you must implement / fix.
-3. Look for prior execution data from similar SWE-rebench v2 work in the Jinn knowledge corpus: search for records with `solverType: "swe-rebench-v2.v1"`, `role: "restoration"`, and `artifactType: "swe-rebench-v2_v1_solution"`. For any promising hit, examine its index card before deciding to spend on artifact bytes — only download the full execution data when its index card suggests it is likely relevant. Your available Jinn corpus tools include separate "search", "inspect", and "acquire" operations; pick each by what you are trying to do (find candidates → examine one → download bytes).
-4. Check the `FAIL_TO_PASS` test names from the HF row — these define the success criterion. Find them in the codebase via grep / fs search.
-5. Output a brief Orient summary (3-5 sentences): your hypothesis about the bug, the files you intend to touch, the test you intend to satisfy, and any donated execution data that affected the plan.
-
-Pass this summary forward to the Plan phase.

package/plugins/swe-rebench-v2-runtime/skills/plan/SKILL.md

@@ -1,53 +0,0 @@
----
-name: swe-rebench-v2-plan
-description: Plan the patch for a SWE-rebench v2 task — given the Orient summary, sketch the minimal diff that resolves the issue without breaking existing PASS_TO_PASS tests, then submit the final patch as a typed structured payload to the daemon.
----
-
-# Plan the patch
-
-Inputs:
-- The Orient summary from the previous phase.
-- The repo at `goal.spec.base_commit`.
-- The `FAIL_TO_PASS` test names (must pass after your patch).
-- The `PASS_TO_PASS` test names (must continue passing — don't break them).
-
-Steps:
-
-1. Read the failing test(s). Understand exactly what behaviour they assert.
-2. Locate the source file(s) that need editing. Use grep, AST tools, or filesystem search.
-3. Sketch the minimal diff:
-   - What lines change in which files?
-   - What does the new code do?
-   - Which existing tests must continue to pass (briefly justify why they will)?
-4. Output the plan as a list of file-level edits.
-
-Pass this plan forward to the Execute phase, which produces the actual patch.
-
-## Submitting the final patch
-
-Once Execute has produced the unified diff, hand the Solution back to the daemon by submitting a **typed structured payload** through the Jinn client tools available to you. Your tool catalogue includes a dedicated "submit typed payload" action that validates the payload against the active SolverNet contract schema before persisting it. The validator runs server-side — on schema mismatch you will receive a Zod-style `issues[]` tree and can correct the payload and re-submit.
-
-The required payload shape for `swe-rebench-v2.v1` restoration is:
-
-```json
-{
-  "schemaVersion": "swe-rebench-v2-solution.v1",
-  "patch": "<unified diff, git-format>"
-}
-```
-
-Optional fields:
-
-- `cost.totalUsd: number` — operator-self-reported cost in USD for producing this Solution. Include if you can compute it from your LLM/tool usage; omit otherwise.
-
-Do **not** include daemon-derived fields (e.g. trajectory CIDs) — the daemon attaches trajectory provenance to the envelope automatically. The Solution payload is purely solver-known fields.
-
-A successful submission response looks like:
-
-```json
-{ "accepted": true, "solverType": "swe-rebench-v2.v1", "role": "restoration", "persistedTo": "<workingDir>/.execute/solution-payload.json" }
-```
-
-If — and only if — your harness exposes no typed-payload submission tool at all, fall back by writing the same payload object directly to `<workingDir>/.execute/solution-payload.json` (create the `.execute` directory if needed). The daemon's harvester reads that file post-execution and applies the same SolverNet payload schema during envelope assembly. Prefer the tool path whenever it exists, because the tool gives you immediate schema validation feedback while the file path does not.
-
-After a successful submission, this Plan/Execute cycle is complete — the daemon's harness picks up the persisted payload post-execution and assembles the on-chain envelope.