Adopt descriptive task names and streamline task contributions

.agents/AGENTS.md

@@ -11,10 +11,10 @@ Markdown links.
   workflow, references, and validation gates. If no native skill loader is
   available, open that `SKILL.md` directly. It can also be invoked independently
   as `$create-searchswe-task`.
-- **Review, promote or finalize a task PR as maintainer:** load
+- **Review or finalize a task PR as maintainer:** load
   [maintain-searchswe-task](skills/maintain-searchswe-task/SKILL.md), independently
   invocable as `$maintain-searchswe-task`. Default to read-only gh evidence review;
-  use its bundled offline promotion/HF staging helpers only at approved stages.
+  use its bundled offline HF staging helper only at approved stages.
 - **Run an existing task:** use `docs/quickstart.md`; do not scaffold a task.
 - **Restore fixed inputs:** use `docs/assets.md` and the existing download tools.
 - **Edit project documentation:** keep `README.md` and `README_zh.md` aligned.
@@ -37,20 +37,19 @@ Markdown links.
    acceptance criteria and optimization objective in natural prose. Preserve
    practical context without self-introductions or invented identities; the
    skill defines the rewrite and validation gates.
-   Before scaffolding, inspect one or two closest reviewed packages under
-   `tasks/` as read-only structural precedents, selected by engineering objective,
+   Before scaffolding, inspect one or two closest reviewed packages already merged
+   into the base branch under `tasks/` as read-only structural precedents, selected
+   by engineering objective,
    grading shape, resources and hardware. Apply current repository contracts
    and validators, and independently establish the new task's data, thresholds,
    licenses and access policy.
-   A PR may add multiple tasks at `task-submissions/<task-name>`. Choose a
-   descriptive lowercase name with at most five hyphen-separated words, without
-   a `task-` prefix; `all` is reserved. Keep that name when promoting to
-   `tasks/<task-name>`. Do not reuse a submission path within the same PR. Follow
-   `CONTRIBUTING.md` and `docs/contributing.md`: require actual authors and
-   explicit `--task-path` for local trials, then promote every task with its own
-   same-PR pure rename and any necessary finalization commits before a merge
-   commit (no squash/rebase). Track which stage is complete and which inputs or approvals
-   are missing.
+   A PR may add multiple tasks at `tasks/<task-name>` in its contribution branch.
+   Choose a descriptive lowercase name with at most five hyphen-separated words;
+   the `task-` prefix and `all` are reserved. Check names against the base and
+   active PRs. Follow `CONTRIBUTING.md` and `docs/contributing.md`: record actual
+   authors, use `--task <task-name>` for local trials, and finish task review and
+   official asset publication before merging with a merge commit. Track completed
+   stages, validation evidence and missing inputs or approvals.
    Do not duplicate the skill's specifications in this file.
 3. Keep changes within the selected task plus directly necessary integration
    changes. Updating a website, publishing a dataset, pushing images, and opening

.agents/skills/create-searchswe-task/SKILL.md

@@ -20,9 +20,10 @@ Read [references/task-authoring.md](references/task-authoring.md). Inspect the
 target checkout's status and preserve unrelated changes. Resolve its root
 explicitly; do not infer it from where this skill was installed.
 
-Before scaffolding, inspect one or two closest **formal** packages under the
-target checkout's `tasks/`. Choose them by engineering objective, evaluation/judge
-shape, resources/APIs, hardware and input/artifact layout. Record their exact paths and why they are relevant. Treat them as
+Before scaffolding, inspect one or two closest reviewed packages already merged
+into the base branch under `tasks/`. Choose them by engineering objective,
+evaluation/judge shape, resources/APIs, hardware and input/artifact layout.
+Record their exact paths and why they are relevant. Treat them as
 read-only structural precedents: the current skill, repository validators,
 schema and shared-image documentation take priority. Do not copy task-specific
 IDs, authors, datasets, thresholds, pins, licenses or access policy without
@@ -40,7 +41,7 @@ Record a short design summary before writing the package:
 | Evaluation | Metric, public gates, baseline if needed, failure/timeout behavior |
 | Inputs | Public/hidden split, actual files, provenance, redistribution rights |
 | Resources | CPU/GPU, memory/storage/time, network, permitted APIs/models |
-| Precedent | Formal task path(s), matching dimensions, structural patterns reused, intentional differences |
+| Precedent | Reviewed task path(s), matching dimensions, structural patterns reused, intentional differences |
 
 CPU is the default; choose GPU when the agent or verifier executes GPU work. Ask for
 missing facts that change the design; do not invent labels, licenses, service
@@ -59,24 +60,19 @@ python "$SKILL_DIR/scripts/scaffold_task.py" example-search \
   --repo-root "$REPO" --author 'Alice Example' --hardware cpu
 ```
 
-Use `--hardware gpu` only for GPU execution. New tasks belong at
-`task-submissions/<task-name>`, with `task.name = "search-swe/<task-name>"`.
-Names start with an ASCII lowercase letter, contain lowercase letters/digits
-and single hyphens, and have at most five words. Use a concise description of
-the task; omit the `task-` prefix. `all` is reserved. Check both package roots
-and active PRs for collisions. Repeat `--author` for actual coauthors.
-The helper refuses overwrites and symlink roots. Its explicit `--formal` option
-is for maintainer tooling, not a bypass for new task contributions. Edit an
-existing task in place instead of deleting it to make the helper succeed.
-
-One PR may add multiple uniquely named tasks. Read the bundled
-[submission and PR workflow](references/submission-and-pr.md). Promotion keeps
-the same name: `task-submissions/<task-name>` → `tasks/<task-name>`. Each task
-gets its own pure rename commit in **the same PR**, followed by a separate
-finalization commit when references, assets or integration need changes. Do not
-reuse a submission path in that PR. Preserve original author and promotion
-commits: **merge commit only**, never squash/rebase. All tasks must be promoted
-before merge; no submission package enters final main.
+Use `--hardware gpu` only for GPU execution. Create new tasks directly at
+`tasks/<task-name>` in the contribution branch, with
+`task.name = "search-swe/<task-name>"`. Names start with an ASCII lowercase letter,
+contain lowercase letters/digits and single hyphens, and have at most five words.
+Choose a concise description; the `task-` prefix and `all` are reserved. Check
+names against `tasks/` on the base branch and active PRs. Repeat `--author` for
+actual coauthors. The helper protects existing files and rejects symlink roots.
+Revise existing packages in place.
+
+One PR may add multiple uniquely named tasks. Follow the
+[branch and PR workflow](references/submission-and-pr.md): review and validate
+each package, publish official inputs and pin their merged SHA, then merge the
+PR with a **merge commit** to preserve original author history.
 
 The scaffold is **not a finished task**: its verifier always fails, its asset
 manifest is empty, data/model mounts are absent, and instructions are writing
@@ -144,7 +140,7 @@ authorizes that scoped run; reuse already-authorized local credentials without
 asking again. Ordinary local checks may proceed.
 
 Report the task path, objective/hardware, commands actually executed and their
-results, formal reference tasks consulted (or that none was close), intentional
+results, reviewed reference tasks consulted (or that none was close), intentional
 reuse/deviations, the source-to-request equivalence review, known-good/negative-case
 evidence, the exact evaluated revision/model/effort, observed scores and judge
 health, feedback-driven task changes (or why none were needed), and every unrun

.agents/skills/create-searchswe-task/agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
   display_name: "Contribute Search-SWE Task"
-  short_description: "Author and validate a temporary task submission"
-  default_prompt: "Use $create-searchswe-task to build and locally validate a task submission with a descriptive name, then prepare an authorized PR handoff."
+  short_description: "Create and validate tasks directly under tasks/"
+  default_prompt: "Use $create-searchswe-task to build and locally validate a task at tasks/<task-name>, then prepare an authorized PR handoff."

.agents/skills/create-searchswe-task/references/assets-and-resources.md

@@ -7,8 +7,7 @@ task. Nothing in this reference grants permission to publish or use paid APIs.
 ## Manifest construction
 
 Keep downloadable fixed files outside the build contexts, under
-`data/` or `models/` in the selected package (initially
-`task-submissions/<task-name>`, later `tasks/<task-name>`).
+`data/` or `models/` in the package at `tasks/<task-name>`.
 Ignore both directories in Git. Hidden
 queries/labels and grading code go in `tests/`, not the public asset bundle.
 For a verifier-only corpus stored in `data/verifier/`, mount only public
@@ -48,16 +47,16 @@ Do not attempt `chmod` on read-only mounted files during verification.
 
 ## Development and incremental publication
 
-For pre-promotion development, use an authorized **personal public temporary HF
+During development, use an authorized **personal public temporary HF
 dataset** with manifest, provenance and license; pin its immutable 40-hex SHA in
-submission `assets.json`. The downloader accepts arbitrary HF repositories:
+the task's `assets.json`. The downloader accepts arbitrary HF repositories:
 
 ```bash
-python scripts/download_assets.py --task-path task-submissions/example-search
-python scripts/download_assets.py --task-path task-submissions/example-search --verify-only
+python scripts/download_assets.py --task example-search
+python scripts/download_assets.py --task example-search --verify-only
 ```
 
-After the maintainer approves promotion in the same PR, prepare new official
+After task and asset review, prepare new official
 files at `tasks/<task-name>/...`. The target checkout's
 `scripts/prepare_hf_upload.py` accepts a current official manifest snapshot,
 the final task package and **only new data**. It verifies hashes, preserves existing

.agents/skills/create-searchswe-task/references/model-evaluation.md

@@ -54,16 +54,17 @@ host Codex settings. The answer-equivalence judge, if present, remains separate.
 
 ## Launch and observe
 
-Use `--task-path` for a contribution and `--task` for a formal package. Preview
+Use `--task <task-name>` to select the task from `tasks/`. Preview
 first, then run in a new output directory once inputs, credentials, hardware
 and scoped API/GPU authorization are available. An explicit model-evaluation
 request supplies authorization for that evaluation; do not ask for it again.
 For example, replacing placeholders with the actual agreed task and effort:
 
 ```bash
-bash scripts/run_task.sh --task-path "$task_path" --agent codex \
+task_name=example-search  # Use the task being evaluated.
+bash scripts/run_task.sh --task "$task_name" --agent codex \
   --openrouter --model "$model_id" --reasoning-effort "$effort" --dry-run
-bash scripts/run_task.sh --task-path "$task_path" --agent codex \
+bash scripts/run_task.sh --task "$task_name" --agent codex \
   --openrouter --model "$model_id" --reasoning-effort "$effort" \
   --output "$fresh_output"
 ```

.agents/skills/create-searchswe-task/references/publication.md

@@ -25,18 +25,18 @@ repo = 'YOUR_ACCOUNT/search-swe-development'
 api.create_repo(repo_id=repo, repo_type='dataset', private=False, exist_ok=True)
 commit = api.upload_folder(repo_id=repo, repo_type='dataset', folder_path='/path/to/dev-data',
                            commit_message='Add temporary task development inputs')
-print(commit.oid)  # Pin this full SHA in submission assets.json.
+print(commit.oid)  # Pin this full SHA in task assets.json.
 PY
 ```
 
 Use this personal repo, its dataset-relative filenames, size/hash, and printed
-immutable SHA in `assets.json`. The explicit submission downloader/launcher then
-support real pre-promotion validation. Keep the temporary repo accessible through
-review and migration; only retire it after official pinned downloads are verified.
+immutable SHA in `assets.json`. Select the task by name with the downloader and
+launcher for development validation. Keep the temporary repo accessible through
+review and publication; retire it after official pinned downloads are verified.
 
-### Task name: additive official publication, then GitHub merge
+### Official publication, then GitHub merge
 
-After task-name approval and promotion, change only the new task's dataset source
+After task and asset review, change only the new task's dataset source
 repo/filename to `search-swe/Search-SWE` and `tasks/<task-name>/...`. Preserve
 original model repo pins and bundled metadata. Prepare **only new data files**
 in `/path/to/new-data/tasks/<task-name>/...`, at the exact asset sizes/hashes.
@@ -64,7 +64,7 @@ python scripts/prepare_hf_upload.py \
   --output /path/to/upload-staging
 ```
 
-Official asset staging requires a promoted package at `tasks/<task-name>`.
+Stage assets from the reviewed package at `tasks/<task-name>`.
 
 The offline helper verifies hashes and safe paths for new files, rejects
 collisions and symlinks, and stages those files with a merged manifest that
@@ -106,6 +106,6 @@ replace a newer manifest with a stale one.
 **Merge the official HF change first.** Only then pin the resulting official
 40-hex commit SHA (not the community PR/head SHA or `main`) in the finalized
 GitHub task's `assets.json`. Verify downloads using a fresh output directory or
-cache and run release checks. Commit finalization and merge the GitHub PR last.
-No new task with unpublished/unpinned assets or an unfinished submission enters
-main. Preserve existing tasks' pinned revisions and published assets.
+cache and run release and merge-ready checks. Commit the verified asset pins
+in the task PR, then merge the GitHub contribution. Preserve existing tasks'
+pinned revisions and published assets.

.agents/skills/create-searchswe-task/references/submission-and-pr.md

@@ -1,4 +1,4 @@
-# Submission, branch and PR handoff
+# Contribution branch and PR handoff
 
 Choose a descriptive task name of at most five lowercase hyphen-separated words,
 starting with a letter and otherwise using letters/digits. Omit `task-`; `all`
@@ -9,11 +9,10 @@ is reserved. Choose GPU only when execution requires it.
 Resolve the target checkout explicitly and inspect status, branch, remotes and
 base. Preserve other authors' work and commits; never reset, stash or switch
 their branch to simplify your task. Agree on branch/commit scope before changing
-history. New packages use `task-submissions/<task-name>` and canonical
-`task.name = "search-swe/<task-name>"`. Check formal tasks, submissions and active
-PRs for collisions. A PR may add multiple unique names, but cannot reuse a
-submission path. Direct new formal additions without submission history fail CI.
-A scaffold is a deliberately failing starting point, not a finished task.
+history. New packages use `tasks/<task-name>` in the contribution branch, with
+`task.name = "search-swe/<task-name>"`. Check names against the current base and
+active PRs. A PR may add multiple uniquely named tasks. Complete the scaffold's
+instructions, assets, environment and grader before runtime validation.
 
 Set actual `task.toml` authors. Preserve original commits and account-linked Git
 name/email; do not change identity configuration on their behalf. Co-authored-by
@@ -42,12 +41,12 @@ all uppercase values with verified values):
 ```bash
 git push FORK_REMOTE CONTRIBUTION_BRANCH
 gh pr create --repo OWNER/REPO --base BASE_BRANCH \
-  --head FORK_OWNER:CONTRIBUTION_BRANCH --title 'Add task submission' \
+  --head FORK_OWNER:CONTRIBUTION_BRANCH --title 'Add example-search task' \
   --body-file /path/to/reviewed-pr-body.md
 ```
 
 Use a trusted body file, not shell interpolation of task/PR text. Report actual
-validation commands/results and unrun layers. For each task, name the formal
+validation commands/results and unrun layers. For each task, name the reviewed
 reference packages consulted (or state that none was close), the structural
 patterns reused, and intentional differences; do not claim precedent as proof
 that a task-specific value is correct. Link any authorized personal HF repo at
@@ -56,44 +55,28 @@ the **PR author** enables **Allow edits from maintainers** on the PR. Verify the
 setting (`maintainerCanModify` in `gh pr view --json maintainerCanModify`), rather
 than assuming PR creation enabled it. Same-repository branches may not need it;
 organization-owned forks/policies may make it unavailable. In that case agree
-that the contributor performs the promotion commits in the same PR. Never
+that the contributor applies review fixes in the same PR. Never
 request broad credentials or silently replace the PR.
 
-## Review and finalization in that same PR
+## Review and finalization in the same PR
 
 The maintainer audits instructions/resources, heldout split, known-good and
-negative cases, grader isolation, networking/credentials, sources and licenses.
-A review-stage CI pass can still contain unfinished submissions. Missing,
-pending or failed checks are not acceptance. Separately authorize code execution,
-API/GPU costs and any credentialed runtime tests.
-
-Near merge, refresh the base and check name collisions with queued PRs. Preserve
-original author history. Use the target checkout's offline promotion helper
-from a clean worktree/index; missing tools are a prerequisite blocker:
-
-```bash
-python scripts/promote_task.py rename task-submissions/example-search example-search --dry-run
-python scripts/promote_task.py rename task-submissions/example-search example-search
-# Review and, only when authorized, commit this pure git mv alone.
-python scripts/promote_task.py finalize task-submissions/example-search example-search --dry-run
-python scripts/promote_task.py finalize task-submissions/example-search example-search
-```
-
-Repeat independently for each task. The name stays unchanged. Finalize requires
-HEAD to be that task's single-parent, whole-package, 100%-identical pure rename
-commit. It rewrites submission paths in tracked text; it never commits or
-publishes. Review replacements, mounts, image/external paths, inventories and
-authors. Follow [publication](publication.md): personal pinned development data
-→ official `tasks/<task-name>/...` paths through a community PR or authorized
-mirror → official merge → pin that official SHA. Preserve original model pins.
-
-Run release and applicable tests plus `python scripts/check_submission.py
---merge-ready`; no submission task.toml may remain. Commit any reference, asset
-or integration finalization separately in this same PR. Do not create an empty
-commit if no finalization changes are needed.
-
-Re-review each changed head, recheck base/name collisions and exact head before
-an authorized **merge commit**. No squash/rebase or unfinished submissions on
-main. Verify the resulting SHA/tree and attribution using
+negative cases, model-trial feedback, grader isolation, networking/credentials,
+sources and licenses. Separately authorize code execution, API/GPU costs and
+credentialed runtime tests. Track each required check for the reviewed head.
+
+Refresh the base and check names against queued PRs. Apply review fixes and
+necessary inventory or documentation changes in the contribution branch,
+preserving original author commits. Follow [publication](publication.md):
+publish approved dataset inputs under official `tasks/<task-name>/...` paths,
+merge the HF change, then pin its official SHA in `assets.json` and verify clean
+downloads. Preserve original model pins.
+
+Run release checks, applicable tests and `python scripts/check_tasks.py
+--merge-ready --base FULL_PR_BASE_SHA`. Commit the reviewed changes in the same
+PR. Re-review each changed head and verify required checks against the current
+base before an authorized **merge commit**.
+
+Verify the resulting SHA/tree and attribution using
 `git log --follow -- tasks/example-search/instruction.md` and `git blame`.
 Report observed outcomes, task names, official asset SHAs and remaining blockers.