Kk2406/Ll huggingface dataset:
Chisel-to-Verilog Source Location Alignment
Domain: engineering — Semiconductor & Microelectronics Design

Summary: Given a Chisel hardware design (Fifo.scala) and its firtool-optimized SystemVerilog output, identify the exact set of Chisel source locations that a specific sub-expression semantically corresponds to.

Task prompt:
You are a hardware design engineer specializing in Chisel and SystemVerilog.

## Your Task

Given a Chisel hardware design (Fifo.scala) and its firtool-optimized SystemVerilog output, identify the exact set of Chisel source locations (Fifo.scala:line:col) that a specific sub-expression of the optimized Verilog semantically corresponds to.

The optimized Verilog's @[...] source-location comment is both noisy (lists unrelated locations) and incomplete (misses real locations), so answering requires genuine analysis — not comment-reading.

## Working Directory

All materials are under: `base/input/workdir/`

- `TASK.md` — detailed instructions and rules
- `src/main/scala/Fifo.scala` — original Chisel source (DoubleBuffer FIFO, 87 lines)
- `generated/optimized.sv` — firtool emission (target: line 21, sub-expression `stateReg == 2'h2`)
- `generated/DoubleBufferFifo.fir` — FIRRTL intermediate (you may regenerate alternative emissions)

## Tools Available

Use the canonical task-local CLI entry points under `base/software/`:

- `base/software/yosys` — Yosys 0.33+
- `base/software/firtool` — CIRCT firtool 1.138.0
- `base/software/sbt` — sbt 1.9.9 with Chisel 6.5.0 dependencies prewarmed
- `base/software/python` — Python 3.10
- `base/software/jq` — jq 1.x

The VM has no internet access during solve time.

## Rules

1. Do NOT edit any file under `src/`, `generated/`, or `TASK.md`. Writes are only allowed under the task output directory.
2. Focus on the sub-expression `stateReg == 2'h2` at line 21, columns 23-39 of optimized.sv.
3. Approach is unconstrained (formal verification, simulation, semantic analysis — whatever works).

## Output

Write a single file: `base/output/answer.json`

```json
{
  "target_signal": "stateReg == 2'h2",
  "target_location_in_optimized_sv": "21.23-39",
  "chisel_sources": ["Fifo.scala:<L1>:<C1>", ...]
}
```


Required actions:
Read TASK.md for the detailed query
Examine Fifo.scala and optimized.sv
Perform genuine semantic analysis (not just read annotations)
Write output/answer.json with the correct chisel_sources set

Software: Yosys 0.33+
firtool 1.138.0 (CIRCT)
sbt 1.9+ with Chisel 6.5.0
Python 3.10

Input files:
name: Task instructions
format: md
description: Restates the query and includes firtool annotation noisiness disclaimer
name: Chisel source
format: scala
description: Original Chisel source — DoubleBuffer FIFO with 3-state enum
name: Optimized SystemVerilog
format: sv
description: firtool-optimized emission; target line 21 contains stateReg == 2'h2
name: FIRRTL intermediate
format: fir
description: FIRRTL intermediate for optional re-emission via firtool
Humanoid Velocity Tracking Policy
Domain: engineering — Robotics & Autonomous Systems

Summary: Produce a deterministic Isaac Lab humanoid locomotion policy that tracks commanded planar velocities and satisfies fixed API, stability, and rollout metric gates.

Task prompt:
You are producing a policy submission for an Isaac Lab humanoid velocity-tracking benchmark.

## Variant
`base`: Humanoid velocity tracking policy

## Input Files
- Task brief: `base\input\task_brief.md`
- Success criteria and exact evaluation command: `base\input\SUCCESS.md`
- Observation/action ordering: `base\input\PROPRIO_SPEC.md`
- Robot asset and articulation config: `base\input\assets`
- Evaluation harness: `base\input\eval`
- Starter template: `base\input\submission_template`

## What You Must Do
1. Read the staged task brief, proprioceptive-state spec, and success criteria.
2. Train, distill, hand-author, or otherwise produce a deterministic policy that implements the required `Policy` API.
3. Save exactly two files in `base\output`: `policy.py` and `checkpoint.pt`.

## Output Requirements
- `policy.py` must define `Policy(checkpoint_path: str, device: str)`.
- `Policy.inference(obs)` must return exactly `{"action": tensor}`.
- The action tensor must have shape `(N, 23)`, dtype `torch.float32`, and live on the same device as `obs["command"]`.
- Do not write final answers outside `base\output`.

Required actions:
Read the staged task brief, proprioceptive-state spec, and success criteria.
Produce a deterministic `Policy` implementation that maps `(command, state)` tensors to 23 humanoid joint actions.
Save exactly `policy.py` and `checkpoint.pt` in the runtime output directory.

Software: Isaac Lab
Isaac Sim
PyTorch
CUDA

Input files:
name: task_brief.md
format: md
description: Agent-facing summary of the policy submission task.
name: SUCCESS.md
format: md
description: Hard gates, reference evaluation command, metrics, and acceptance thresholds.
name: PROPRIO_SPEC.md
format: md
description: Fixed observation vector and 23-DOF action ordering.
name: assets/
format: directory
description: Humanoid URDF, meshes, and articulation configuration.
name: eval/
format: directory
description: Isaac Lab evaluation environment and `run_eval.py` entry point.
Domain: engineering — Robotics & Autonomous Systems

Summary: Run mjlab whole-body-control rollouts for 8 Unitree G1 humanoid policy cases, classify each as successful/nearly_successful/failed, and emit a schema-conformant `policy_evaluation_report.json` with per-case visual demo artifacts.

Task prompt:
You are evaluating whole-body-control policy rollouts for a Unitree G1 humanoid in mjlab.

## Variant
``: 

## Input Files
- Task brief: `/input/task_brief.md`
- Policy case list: `/input/policy_cases.json`
- Required JSON output schema: `/input/output_schema.json`
- mjlab runtime archive and exported package list: `/input/runtime_env`
- Offline motion and checkpoint archives: `/input/runtime_env/motions-1.zip`
  and `/input/runtime_env/policies.zip`

## What You Must Do
1. Inspect the 8 policy cases in `/input/policy_cases.json`.
2. Use mjlab and the listed `play_command` or `video_command` values to observe
   each policy against its reference motion. The runtime archive, motion files,
   and policy checkpoints are staged under `/input/runtime_env` if you
   need to install mjlab locally on the VM.
3. For each case, save a visible motion demo artifact. The supplied
   `video_command` adds mjlab's existing `--video` flag; mjlab writes those
   videos under the run/checkpoint log directory, so copy or rename the
   recorded artifact into `/output/visual_demos`.
4. Classify every case as exactly one of `successful`, `nearly_successful`, or
   `failed`, using the definitions in `/input/task_brief.md`.
5. Save the final JSON report at `/output/policy_evaluation_report.json` and one visible motion
   demo artifact per case under `/output/visual_demos`.

## Output Requirements
- The final answer must include `policy_evaluation_report.json` and a
  `visual_demos/` directory.
- It must validate against `/input/output_schema.json`.
- Include all 8 case IDs exactly once.
- Preserve the exact `case_id`, `motion`, `mjlab_task`, `motion_file`, and `checkpoint_file`
  values from `/input/policy_cases.json`.
- Each evaluation item must include `evidence.visual_demo_path`, pointing to a
  visible playback artifact under `visual_demos/`. Accepted formats are
  `.mp4`, `.webm`, `.gif`, and `.html`.
- Do not write final answers outside `/output`.


Required actions:

Software: mjlab
MuJoCo
PyTorch
wandb

Input files:
KiCad Navswitch Library Integration
Domain: engineering — Electronics Engineering

Summary: Repair a SparkFun Qwiic Navigation Switch KiCad project by restoring the local symbol and footprint integration for U4 and producing release artifacts.

Task prompt:
You are repairing a KiCad project for the SparkFun Qwiic Navigation Switch board.

## Input
- Broken KiCad project: `input/project/SparkFun_Qwiic_Navigation.kicad_pro`
- Project files and local libraries: `input/project`
- Datasheets: `input/datasheets`
- KiCad launcher: `software/OpenKiCad.bat`

## Your Task
1. Open the project in the KiCad desktop UI.
2. Inspect U4 (`PCA9554`) and the project-local symbol/footprint libraries.
3. Restore U4's schematic Footprint field to the correct project-local footprint.
4. Update the PCB from the schematic so U4 is restored to the board.
5. Save the repaired KiCad project and leave it release-ready.
6. Do not change circuit intent, non-target component values, non-target footprint assignments, unrelated nets, board outline, connectors, or mounting holes.
7. Do not solve this by directly editing raw KiCad source text files.

## Required Deliverables
Save all deliverables under `output/`, including the repaired KiCad project files, local symbol and footprint libraries, ERC/DRC reports, netlist, fabrication outputs, `board.xml`, and `board.d356`.

Required actions:
Use KiCad UI to inspect and repair the project.
Restore U4's footprint assignment to the correct project-local footprint.
Update the PCB from the schematic and preserve unrelated design intent.
Export the required project, library, ERC/DRC, netlist, Gerber, drill, XML, and D356 deliverables.

Software: KiCad
Python

Input files:
name: SparkFun_Qwiic_Navigation project
format: KiCad project
description: Broken KiCad project and local libraries.
name: datasheets
format: directory
description: Reference datasheets for the board components.
name: OpenKiCad.bat
format: batch
description: Launcher for opening KiCad on the VM.
OpenROAD SKY130 Ibex PnR Signoff
Domain: engineering — Semiconductor & Microelectronics Design

Summary: Tune the lowRISC Ibex SKY130HD OpenROAD-flow-scripts configuration, rerun the pinned Docker flow, and submit the final config plus pass-audit evidence needed for signoff review.

Task prompt:
You are working on Linux on an RTL-to-GDSII signoff-closure task for lowRISC ibex on sky130hd.

## Task Root
- `base`

## Visible Inputs
- Task brief: `base/input/task_instructions.md`
- Starter tree: `base/input/starter_project`
- Workspace helper: `base/software/prepare_workspace.sh`

## What You Should Do
1. Read `base/input/task_instructions.md`.
2. Create a writable workspace by running:
   `bash base/software/prepare_workspace.sh`
3. Work only inside `base/output/workspace`.
4. Tune only the allowed files described in the staged task brief.
5. When finished, copy the required deliverables into `base/output`.

## Final Deliverables
- `base/output/config.mk`
- `base/output/JOURNAL.md`
- `base/output/flow/logs/sky130hd/ibex/base/config.mk.pass*` if any completed pass exists
- `base/output/flow/logs/sky130hd/ibex/base/pass*.stamp` if any completed pass exists

Do not modify files under `base/input`.
Do not rely on hidden evaluator-only data.


Required actions:
Read the staged task brief and create a writable workspace with `software/prepare_workspace.sh`.
Edit only `output/workspace/flow/designs/sky130hd/ibex/config.mk` and `output/workspace/JOURNAL.md`.
Run the pinned OpenROAD-flow-scripts Docker flow from the writable workspace.
Copy `config.mk`, `JOURNAL.md`, and any completed-pass audit files into `output/`.

Software: OpenROAD-flow-scripts
Docker
Python

Input files:
name: task_instructions.md
format: Markdown
description: Staged task brief defining the allowed edits, pass budget, and required handoff files.
name: starter_project
format: directory
description: Read-only OpenROAD starter tree copied into the agent's writable workspace before tuning.
name: prepare_workspace.sh
format: shell script
description: Helper that creates `output/workspace/` from the staged starter tree.
Mini Encabulator KiCad PCB Layout
Domain: engineering — Electronics Engineering

Summary: Create a routed KiCad PCB layout from the staged Mini Encabulator schematic.

Task prompt:
You are designing a KiCad PCB layout for a Mini Encabulator.

## Input
- Schematic: `base\input\mini_encabulator.kicad_sch`
- KiCad launcher: `base\software\OpenKiCad.bat`

## Your Task
1. Open the schematic in KiCad and create a PCB layout from it.
2. Import all assigned footprints from the schematic.
3. Place all components for a compact board sized for an SN25 Polycase enclosure.
4. Add exactly four M3 mounting holes on a 1.575 inch by 1.26 inch rectangular spacing pattern.
5. Draw the board outline on `Edge.Cuts`.
6. Route all electrical connections.
7. Add GND copper zones on both `F.Cu` and `B.Cu`, fill them, and add ground stitching vias.
8. Run KiCad DRC and resolve all errors and unconnected items.

## Output
Save the final board layout as:
`base\output\mini_encabulator.kicad_pcb`

Required actions:
Open the staged Mini Encabulator schematic in KiCad.
Create and complete a PCB layout from the assigned footprints.
Add the required board outline, mounting holes, routed traces, GND pours, and stitching vias.
Run DRC and save the final .kicad_pcb output.

Software: KiCad

Input files:
name: mini_encabulator.kicad_sch
format: KiCad schematic
description: Agent-visible schematic with assigned footprints
10kV Feeder Reliability Indices
Domain: engineering — Energy, Power & Nuclear Engineering

Summary: Compute IEEE/IEC supply reliability indices for a 10kV distribution feeder from staged CIM/RDF XML, SVG topology, and parameter data, then write the structured JSON result to the canonical output path.

Task prompt:
You are computing IEEE/IEC supply reliability indices for a 10kV distribution feeder.

## Your Task
Read the staged feeder model, the SVG topology drawing, and the reliability parameters.
Compute the feeder reliability indices and the section-level contribution tables.

## Visible Inputs
- CIM/RDF XML: `base/input/gis.null.xml`
- SVG topology: `base/input/gis.null.svg`
- Reliability parameters: `base/input/params.json`
- Agent-facing dependency manifests: `base/input/pyproject.toml` and `base/input/uv.lock`

## Software
- Use the staged Python environment manifests under `input/` if you need packages.
- Do not preinstall task-specific Python packages system-wide.
- The benchmark runtime should stay isolated from any global package state.

## What You Must Do
1. Produce one JSON file exactly at `base/output/reliability_indices.json`.
2. The JSON must include the feeder-level totals and the section-level breakdown tables.
3. Keep the answer schema consistent with the staged reliability reference data.
4. Write `ASAI` as a fraction between 0 and 1.

## Output Requirements
- Required top-level keys:
  `feeder, N_T, SAIFI_F, SAIDI_F_h, SAIDI_F_min, SAIFI_D, SAIDI_D_h, SAIDI_D_min, SAIFI_S, SAIDI_S_h, SAIDI_S_min, SAIFI, SAIDI_h, SAIDI_min, CAIDI_h, CAIDI_min, ASAI, fault_rows, device_fault_rows, scheduled_rows`
- Keep the section tables in the JSON output.
- Do not write any extra files into `base/output`.

## Practical Note
The task is designed for Python-based network analysis and data processing. If you need additional Python packages, install them from the staged manifests under `input/` using `uv`.


Required actions:
Parse the staged CIM/RDF XML, SVG topology, and parameter JSON.
Build a section-level feeder model and compute the required reliability indices.
Write the structured result to `output/reliability_indices.json`.
Preserve the staged input and evaluator-only reference data.

Software: Python 3.12
pandas
openpyxl

Input files:
name: gis.null.xml
format: XML
description: CIM/RDF feeder model.
name: gis.null.svg
format: SVG
description: Single-line topology drawing.
name: params.json
format: JSON
description: Regional reliability parameters.
name: pyproject.toml
format: TOML
description: Agent-facing dependency manifest staged for uv.
name: uv.lock
format: TOML lockfile
description: Locked agent-facing dependency set staged for uv.
Blender Tabletop Workspace Reconstruction
Domain: engineering — 3D, Animation & Interactive Media

Summary: Reconstruct a tabletop robotic-manipulation workspace in Blender from a floor plan, a reference render, and staged mesh assets, then save the scene, render a verification image, and export the required OBJ files.

Task prompt:
You are a robotics-focused 3D scene artist using Blender.

Your task is to reconstruct a tabletop robotic-manipulation workspace from staged assets.

Agent-visible inputs:
- Export contract: `base\input\export_spec.json`
- Floor plan: `base\input\floor_plan.png`
- Reference render: `base\input\reference_render.png`
- Mesh assets: `base\input\meshes`

Software:
- Launch Blender through the staged task-local wrapper: `base\software\run_blender_portable.ps1`

Required outputs under `base\output`:
- `scene.blend`
- `verification_render.png`
- `mustard_bottle.obj`
- `mug.obj`
- `potted_meat_can.obj`
- `full_scene.obj`

Requirements:
- Use the floor plan for explicit spatial values and camera setup
- Infer rotations, materials, and lighting from the reference render
- Keep the coordinate system z-up and 1 Blender unit = 1 meter
- Save the rendered image as `verification_render.png`


Required actions:
Reconstruct the tabletop manipulation scene in Blender using the floor plan, reference render, and staged mesh assets.
Place the table and three YCB objects at the positions specified by the visible floor plan.
Infer rotations, materials, and lighting from the reference render.
Save `scene.blend`, render `verification_render.png`, and export `mustard_bottle.obj`, `mug.obj`, `potted_meat_can.obj`, and `full_scene.obj`.

Software: Blender

Input files:
name: export_spec.json
format: JSON
description: Defines the required render and export filenames.
name: floor_plan.png
format: PNG image
description: Provides explicit spatial values for object placement, table dimensions, and camera setup.
name: reference_render.png
format: PNG image
description: Visible visual target used to infer rotations, materials, and lighting.
name: meshes/
format: OBJ assets
description: Source geometry for the table and three YCB objects.
Sanding Performance Image Scoring
Domain: engineering — Manufacturing & Industrial Systems

Summary: Compute pixel-level paint-removal scores from reference and sanded panel images, then write a structured CSV with quantity, uniformity, and composite metrics.

Task prompt:
You are completing a sanding-performance image scoring task on a Windows VM.

Input files are staged in:
`base\input`

Read `algorithm_spec.md` in that directory. It defines how to use the reference images `panel_painted.png` and `panel_unpainted.png` to score:
- `panel_sanded_01.png`
- `panel_sanded_02.png`
- `panel_sanded_03.png`

Use RGB image values and follow the formulas in `algorithm_spec.md`.

Write exactly one output file:
`base\output\sanding_scores.csv`

The CSV must have this header:
`panel_id,quantity_pct,uniformity_pct,composite_pct`

It must contain exactly one row for each sanded panel:
- `panel_sanded_01`
- `panel_sanded_02`
- `panel_sanded_03`

Round the three numeric metric columns to one decimal place. Do not modify the files under `input/`.


Required actions:
Read the visible algorithm specification and five panel images from the staged input directory.
Compute quantity, uniformity, and composite sanding scores for each of the three sanded panels.
Write `sanding_scores.csv` under the runtime output directory with the required schema and one row per sanded panel.

Software: Python

Input files:
name: algorithm_spec.md
format: Markdown
description: Visible task algorithm and output schema.
name: panel_painted.png
format: PNG image
description: Painted reference panel.
name: panel_unpainted.png
format: PNG image
description: Unpainted reference panel.
name: panel_sanded_01.png, panel_sanded_02.png, panel_sanded_03.png
format: PNG images
description: Sanded panel images to score.
Clinical Variant Annotation
Domain: health_medicine — Genomics & Sequence Analysis

Summary: Analyze a staged clinical VCF, identify the pathogenic BRCA1-like candidate, and document the supporting evidence in the required output tables.

Task prompt:
You are given a small clinical VCF containing 200 candidate variants from a breast-cancer case.

Your task is to identify the single pathogenic BRCA1-like candidate and document the evidence in the required output files.

Task directory:
- `base`

Input:
- `base/input/patient_variants.vcf`

Available tools:
- a Linux terminal is open at `base`
- `python3`
- `curl`
- `jq`

External resources:
1. gnomAD GraphQL API
2. Ensembl VEP REST API
3. NCBI ClinVar / E-utilities

Required outputs under `base/output`:
- `variant_count.txt` with a single integer
- `vep_results.csv`
- `gnomad_results.csv`
- `clinvar_results.csv`
- `final_candidates.csv`

Rules:
- Append rows to the pre-created CSV files without changing headers.
- It is acceptable to use `NA` for unavailable fields.
- The final candidate file must include the pathogenic evidence in the justification column.
- Do not ask for confirmation. Execute directly.

Required actions:
Read a small patient VCF, count variants, annotate candidates against public knowledge bases, and write a final pathogenic BRCA1-like candidate.
Write outputs only under `output/` while keeping committed fixtures untouched.
Work directly on Ubuntu; Windows + WSL is no longer the canonical runtime.


Input files:
name: patient_variants.vcf
format: vcf
IHDP ITE Estimation
Domain: health_medicine — Economics & Quantitative Social Research

Summary: Build a reusable hidden-test inference script for the IHDP semi-synthetic benchmark that estimates individualized treatment effects and emits the required diagnostics artifacts.

Task prompt:
You are working on a Linux causal-inference benchmark.

Read these staged solve-time inputs first:
- `base/input/task_brief.md`
- `base/input/task_readme.md`
- `base/input/feature_schema.json`
- `base/input/train.csv`
- `base/input/dummy_test/test.csv`

If you want the pinned scientific Python stack, use:
- `base/software/python_with_task_deps.sh`

Your job is to author `base/output/predict.sh` so that the evaluator can later run:

`bash output/predict.sh <hidden_test_dir> output/output.csv`

from the task root.

When your script runs, it must create these required files:
- `base/output/output.csv`
- `base/output/artifacts/model_selection.csv`
- `base/output/artifacts/overlap_diagnostics.csv`
- `base/output/artifacts/subgroup_ite.csv`
- `base/output/artifacts/run_notes.txt`

`output/output.csv` must have exactly these columns:
`replication,unit_id,mu0_hat,mu1_hat,ite_hat`

Rules:
- `ite_hat` must equal `mu1_hat - mu0_hat` row by row.
- You may keep helper code under `output/` and may emit extra artifact files if you want.
- Do not modify files under `input/`.
- During solve time, treat `input/` plus `software/` as your visible task surface; `reference/`, `output_test_pos/`, and `output_test_neg/` are evaluator-side paths, not solve-time inputs.
- Write solver-created files only under `base/output`.


Required actions:
Read the staged IHDP training data, schema, benchmark brief, and task readme from `input/`.
Build a reusable individualized treatment-effect estimator over the 100 IHDP replications.
Author `output/predict.sh` so the evaluator can rerun hidden-test inference from the task root.
Write `output/output.csv` plus the required diagnostics artifacts under `output/artifacts/`.

Software: Python
uv
bash
numpy
pandas
scipy
scikit-learn

Input files:
name: task_brief.md
format: Markdown
description: Canonical agent-facing task brief with the exact `predict.sh` delivery contract.
name: task_readme.md
format: Markdown
description: Normalized solve-time instructions derived from the original submission materials.
name: feature_schema.json
format: JSON
description: Covariate schema and feature metadata.
name: train.csv
format: CSV
description: IHDP observational training data with factual outcomes across 100 replications.
name: dummy_test/test.csv
format: CSV
description: Schema-and-order stand-in for the hidden official test set.
name: runtime_env/
format: Python runtime bundle
description: Pinned offline scientific-runtime manifest and wheelhouse exposed through `software/python_with_task_deps.sh`.