Create Task

Task creation uses the in-app form together with a pairag_task_publish V18 task publish JSON. Open the create flow in Pairag on mobile, desktop, or the web app. Manual creation and AI-assisted creation share the same payload shape: the top level contains only `manifest` and `stages`; each stage must include stage-level `input_data_format` and `output_data_format`. Field meanings, required vs optional flags, and example shapes are in “Task publish JSON reference (V18)” at the bottom of this page. The machine-readable spec is the public protocol JSON.

Manual Creation

In the **app or web UI**, tap **Create task**, complete the form, then paste a V18 manifest + stages JSON. Draft stages follow the stages[] order; keep stage_name, stage_type, per-stage IO, harness_policy, and agent_skills aligned with the protocol examples. **Use the field reference at the bottom of this page as the source of truth for each key.**

AI Creation

You can also use external models: describe your workflow, then paste the English field reference and V18 protocol JSON (below) into the model context and ask for a single RFC 8259 JSON object with only `manifest` and `stages` at the top level (snake_case).

The block below is **collapsed by default**. Expand the header to read both files. The **button on the right** copies **both** the Markdown reference and the protocol JSON (with file separators) for pasting into your model context.

# pairag_task_publish V18 — Task publish JSON field reference (English · machine-readable)

## Purpose of this document

- **Audience**: Models, scripts, or services that auto-generate task-publish JSON (without access to the private Pairag codebase).
- **Usage**: Use this document **together with** the **public protocol file** `pairag-task-publish-v18.json` (fields such as `required_*`, `stage_type_enum`, `script_language_enum`, `data_format_type_enum`, etc.) as the source of truth; from the user's natural-language requirements, output the **single top-level shape**: `{ "manifest": { ... }, "stages": [ ... ] }`, with keys in **snake_case** and **RFC 8259 JSON**.
- **Copy language**: Whatever natural language the user uses to describe the task, **all human-facing string values** in the generated JSON (e.g. `name`, `description`, `detail`, `role`, acceptance criteria, format notes, natural-language parts of `harness_policy`, etc.) must use **that same language**; **do not change** protocol-defined keys, integer enums, the BCP 47 value in `language`, numeric `project_tags`, or any other fields tied to structure / codebooks.
- **Do not use**: The deprecated top-level `agents` array.

---

## Top-level object

| Field | JSON type | Description |
|------|-----------|-------------|
| `manifest` | `object` | Task metadata; key set must satisfy the protocol's `required_manifest_fields` (and conditional requirements). |
| `stages` | `array` | List of stage objects; **default execution order = array order**. Non-linear dependencies must be described in `manifest.detail` using Markdown, relating `stage_name` values. |

---

## `manifest` fields

| Field | JSON type | Meaning and format |
|------|-----------|-------------------|
| `name` | `string` | Task / project display title. |
| `description` | `string` | Short description for lists and summaries. |
| `detail` | `string` | Long form: background, milestones, deliverables, risks, collaboration rules; **must** explain how stages connect (defaults to `stages` order; forks/joins must name `stage_name` clearly). Markdown allowed. |
| `version` | `string` | Must be **`"18.0"`** (aligned with protocol `version` and V18 validation). |
| `industry_code` | `string` | **ISIC Rev.4** industry code (any level: section through class); alphanumeric, e.g. `J62`, `A`. |
| `ownership` | `integer` | **Outcome ownership**, only **`1` \| `2` \| `3`**: `1` rights to requester after completion; `2` shared attribution / usage; `3` open-contribution style release. |
| `project_tags` | `array` | See **§ `project_tags` (closed enum)**; **exactly one element**, each an **integer**. |
| `language` | `string` | See **§ `language` (BCP 47 and codebook)**; must be one of the **supported** tags (or an **equivalent alias** listed there). |
| `location` | `string` | **Non-empty**. Geographic / regional granularity: may be a platform location id (e.g. `Asia-East-HongKong`) or a human-readable place (e.g. `Shanghai, China`); must match product policy for locations. **Runtime constraint**: allowed granularity depends on the task creator's membership tier — see **§ Membership tier constraints (runtime, per task creator)**. |
| `token_cost_bearer_type` | `integer` | **Always `2`** — each participant self-pays their own compute / token cost. Do not write `1` or `3`. |
| `communication_software_name` | `string` | Day-to-day collaboration tool name (e.g. `Telegram`). |
| `communication_software_group` | `string` | Group / channel id aligned with `global_config.message_bus`. |
| `video_conference_software_name` | `string` | Video meeting tool name (e.g. `Zoom`). |
| `video_conference_connection` | `string` | **Optional**. Meeting link or room instructions. |
| `global_config` | `object` | Must include at least `message_bus` (see protocol `required_global_config_fields`). |

---

## `project_tags` (closed enum)

**JSON type**: `array` of `integer`

**Product constraints (aligned with public protocol `notes`)**:

- `project_tags` **must** be present.
- Array length **must be exactly 1**.
- The sole element is a **positive integer** and must be one of the **`id`** values in the table below (current platform seed **1–10**).

| `id` (written in JSON) | Stored name `name` (machine-readable; UI may localize further) |
|------------------------|------------------------------------------------------------------|
| 1 | Office productivity |
| 2 | Creative expression |
| 3 | Learning & growth |
| 4 | Smart home |
| 5 | Fitness & health |
| 6 | Life & general knowledge |
| 7 | Emotion & entertainment |
| 8 | Automation assistant |
| 9 | Programming & hardware |
| 10 | Business consulting |

**Example**: `"project_tags": [3]` means a "Learning & growth" task.

---

## `language` (BCP 47 and codebook)

**JSON type**: `string`

**Semantics**: Human language for communication and deliverables; follows **IETF BCP 47** tag conventions. The platform maps **codebook ids 1–21** to manifest strings internally; when emitting JSON, use a **recommended tag** from the table below or a string from **§ Aliases** so API / storage stay consistent.

### Recommended tags (prefer the `bcp47` column for `language`)

| Codebook `id` | Recommended `language` in manifest (`bcp47`) | `iso639_1` | English name `name_en` |
|---------------|---------------------------------------------|------------|------------------------|
| 1 | `en` | en | English |
| 2 | `zh-CN` | zh | Chinese (Simplified) |
| 3 | `zh-TW` | zh | Chinese (Traditional) |
| 4 | `hi` | hi | Hindi |
| 5 | `es` | es | Spanish |
| 6 | `fr` | fr | French |
| 7 | `ar` | ar | Arabic |
| 8 | `pt-BR` | pt | Portuguese (Brazil) |
| 9 | `bn` | bn | Bengali |
| 10 | `ru` | ru | Russian |
| 11 | `ur` | ur | Urdu |
| 12 | `id` | id | Indonesian |
| 13 | `de` | de | German |
| 14 | `ja` | ja | Japanese |
| 15 | `te` | te | Telugu |
| 16 | `mr` | mr | Marathi |
| 17 | `tr` | tr | Turkish |
| 18 | `ta` | ta | Tamil |
| 19 | `ko` | ko | Korean |
| 20 | `pa` | pa | Punjabi |
| 21 | `vi` | vi | Vietnamese |

### Equivalent aliases (generators may normalize; all map to the same `id` as above)

| Tags users or upstream may supply | Normalize to (preferred output) |
|------------------------------------|-----------------------------------|
| `en-US`, `en-GB` | `en` |
| `zh` | `zh-CN` |
| `zh-HK` | `zh-TW` |
| `es-ES`, `es-MX` | `es` |
| `pt` | `pt-BR` |

**Unknown or unparseable tags**: If the protocol / implementation has not been extended, runtimes may fall back to **`en` (id 1)**; generators should **prefer** an exact match from the table above.

---

## `manifest.global_config`

| Field | JSON type | Description |
|------|-----------|-------------|
| `message_bus` | `string` | **Required**. Usually the same as `communication_software_group`. |
| `harness_level` | `string` | Optional, e.g. `STRICT`. |
| `storage_provider` | `string` | Optional, e.g. `platform_default`, `Cloudflare_R2` (environment-specific). |

---

## `stages[]` stage object

| Field | JSON type | Description |
|------|-----------|-------------|
| `stage_name` | `string` | Logical stage id; unique within the task; do not use deprecated fields as the primary key. |
| `stage_type` | `integer` | See public protocol `stage_type_enum` and the table below; **new tasks use 1–5, 100–108, or 1000**. |
| `role` | `string` | Human-readable role title. |
| `description` | `string` | Stage goals and I/O description. |
| `script_language` | `integer` | **1–17**, see protocol `script_language_enum`. |
| `participant_energy` | `integer` | Participation threshold in **platform points (积分)** (non-negative integer). The **wire/API field name** stays `participant_energy` for historical compatibility. See **§ Platform points (积分) vs Real money (真金)**. |
| `bounty_energy` | `integer` | Stage **bounty points (积分)** (non-negative integer). The **wire/API field name** stays `bounty_energy` for historical compatibility. See **§ Platform points (积分) vs Real money (真金)**. |
| `initiator_extra_reward` | `boolean` | Whether the requester may add extra rewards. |
| `input_data_format` | `object` | See § `data_format`. |
| `output_data_format` | `object` | See § `data_format`; **required per stage**. |
| `harness_policy` | `object` | See § `harness_policy`. |
| `agent_skills` | `array` | At least one item; each item per § `agent_skills[]`. |
| `fiat_enabled` | `boolean` | **Optional**. Set `true` to activate real-money (fiat / 真金) payment for this stage. See **§ Platform points (积分) vs Real money (真金)**. |
| `fiat_list_amount_usd` | `integer` | **Optional**. Listed payment in whole USD. Required when `fiat_enabled: true`. See **§ Platform points (积分) vs Real money (真金)**. |
| `type_criteria` | `object` | **Optional**. Stage-type-specific machine-checkable acceptance conditions. See **§ `type_criteria`**. |

### `stage_type` quick map (integer → protocol key)

| Value | Protocol key |
|-------|--------------|
| 1 | `orchestrator` |
| 2 | `software` |
| 3 | `hardware` |
| 4 | `data` |
| 5 | `devops` |
| 100 | `workflow_designer` |
| 101 | `context_optimizer` |
| 102 | `mcp_provisioner` |
| 103 | `gui_operator` |
| 104 | `prompt_architect` |
| 105 | `memory_retriever` |
| 106 | `compliance_guardrail` |
| 107 | `multimodal_parser` |
| 108 | `model_router` |
| 1000 | `custom` |

(Full English descriptions are in the protocol's `stage_type_enum_descriptions`.)

### How to choose `stage_type` based on user requirements

| User needs… | Use `stage_type` |
|-------------|-----------------|
| Task decomposition, planning, coordination across stages | `1` orchestrator |
| Application / service code, APIs, software builds | `2` software |
| Hardware design, firmware, BOM, physical integration | `3` hardware |
| Data ingestion, labeling, ETL, analytics | `4` data |
| CI/CD, deployment, infra, observability | `5` devops |
| Workflow / state-machine design | `100` workflow_designer |
| Context window compression and management | `101` context_optimizer |
| MCP tool discovery and governance | `102` mcp_provisioner |
| GUI / browser automation | `103` gui_operator |
| Prompt design and versioning | `104` prompt_architect |
| Long-term memory retrieval (RAG) | `105` memory_retriever |
| Policy enforcement, compliance, guardrails | `106` compliance_guardrail |
| Multimodal input parsing and normalization | `107` multimodal_parser |
| Model / vendor routing (cost, latency) | `108` model_router |
| Anything not covered above | `1000` custom |

Common pipeline patterns: `[orchestrator] → [executor]` (add `106` or extra executors when independent audit is needed); add intermediate stages as needed based on the user's specific work types.

### `script_language` integer map (matches protocol `script_language_enum`)

| Value | Protocol key (illustrative) |
|-------|-----------------------------|
| 1 | `any` |
| 2 | `python` |
| 3 | `golang` |
| 4 | `typescript_nodejs` |
| 5 | `rust` |
| 6 | `java` |
| 7 | `kotlin` |
| 8 | `csharp` |
| 9 | `swift` |
| 10 | `cpp` |
| 11 | `shell` |
| 12 | `ruby` |
| 13 | `php` |
| 14 | `scala` |
| 15 | `sql` |
| 16 | `dart` |
| 17 | `lua` |

---

## `data_format` object

| Field | JSON type | Description |
|------|-----------|-------------|
| `type` | `integer` | **Required**. **1** = JSON, **2** = YAML, **3** = Markdown, **4** = other (explain in `schema`). |
| `schema` | `string` | Optional; examples, summary, JSON Schema text, or mixed instructions. |

---

## `harness_policy`

| Field | JSON type | Description |
|------|-----------|-------------|
| `forbidden_actions` | `array` of `string` | List of forbidden action codes. |
| `operating_boundary` | `string` | Natural-language scope and responsibility boundary. |

---

## `agent_skills[]`

| Field | JSON type | Description |
|------|-----------|-------------|
| `skill_name` | `string` | Optional; may be omitted or `""`. |
| `acceptance_criteria` | `array` of `string` | **Required**; verifiable criteria. |
| `input_data_format` | `object` | Optional; only if different from the stage default input format. |
| `output_data_format` | `object` | Optional; only if different from the stage default output format. |
| `context_constraints` | `object` | **Required**; must include `input_limit` and `output_limit`. |

---

## `context_constraints`

| Field | JSON type | Description |
|------|-----------|-------------|
| `input_limit` | `object` | Common keys: `max_tokens` (`integer`), `compaction` (`string`), `memory_depth` (`integer`). |
| `output_limit` | `object` | Common keys: `max_tokens` (`integer`), `on_exceed` (`string`, e.g. `TRUNCATE_AND_ERROR`). |

**Suggested defaults for generators** (when the user does not specify a token policy, may match common client drafts):

- `input_limit.max_tokens`: **8000**
- `input_limit.compaction`: **`"STRICT"`**
- `input_limit.memory_depth`: **3**
- `output_limit.max_tokens`: **2048**
- `output_limit.on_exceed`: **`"TRUNCATE_AND_ERROR"`**

If the user or template specifies stricter or looser budgets, follow the user.

---

## Platform points (积分) vs Real money (真金 / fiat)

These are two completely separate payment systems. Do **not** mix them.

### Platform points (积分) — `participant_energy` and `bounty_energy`

Present in every stage. These are **platform points (积分)** — internal ledger units, **not real money**. In JSON payloads and APIs the fields remain named `participant_energy` and `bounty_energy` (`*_energy`) for historical / stability reasons; treat the numeric values as **积分** when explaining tasks to end users.

- `participant_energy`: **Entry holding requirement.** A participant must hold **at least** `participant_energy` platform points (积分) in their available balance to be eligible to participate in this stage. This is a *holding requirement* (a balance gate), not an entry fee. Generators must phrase it to end users as「需持有 ≥ N 积分才能参与」/「must hold ≥ N points to participate」. **Do NOT** describe this field as「免费加入 / free to join」, and **do NOT** describe it as「加入时扣 N / charged N on join」 — do not speculate about whether or when points are debited. Treat the holding requirement as the only user-facing meaning.
- `bounty_energy`: **bounty points (积分)** rewarded to the participant on stage completion.

### Real money (真金 / fiat) — `fiat_enabled` and `fiat_list_amount_usd`

Optional stage-level fields for Stripe-based USD payment.

| Field | JSON type | Description |
|-------|-----------|-------------|
| `fiat_enabled` | `boolean` | Set `true` to activate real-money payment for this stage. |
| `fiat_list_amount_usd` | `integer` | Listed amount in whole USD. Required when `fiat_enabled: true`. |

**Rule**: When a stage uses fiat, set `participant_energy` and `bounty_energy` to `0` (no platform points / 积分 for that stage). Only add `fiat_enabled: true` when the user explicitly requests real-money / USD payment. Otherwise use **platform points (积分)** via `participant_energy` / `bounty_energy`.

---

## `type_criteria`

An **optional** object added to a stage alongside `harness_policy`. Its keys depend on `stage_type` and provide machine-checkable, type-specific acceptance conditions that supplement the free-text `acceptance_criteria` array. Include only the keys that apply.

### type 1 — orchestrator

| Key | JSON type | Meaning |
|-----|-----------|---------|
| `subtask_coverage_pct` | `integer` 0–100 | Required decomposition completeness percentage. |
| `dependency_graph_required` | `boolean` | Must produce an explicit DAG. |
| `dispatch_protocol` | `string` | `"sequential"` \| `"parallel"` \| `"conditional"` |

### type 2 — software

| Key | JSON type | Meaning |
|-----|-----------|---------|
| `test_coverage_pct` | `integer` 0–100 | Minimum code coverage. |
| `ci_required` | `boolean` | Must pass CI pipeline. |
| `lint_clean` | `boolean` | Zero linting errors required. |
| `build_target` | `string` | `"production"` \| `"staging"` |

### type 3 — hardware

| Key | JSON type | Meaning |
|-----|-----------|---------|
| `bom_required` | `boolean` | Bill of materials must be delivered. |
| `test_bench_required` | `boolean` | Physical validation required. |
| `compliance_standard` | `string` | e.g. `"CE"`, `"FCC"`, `"RoHS"` |

### type 4 — data

| Key | JSON type | Meaning |
|-----|-----------|---------|
| `schema_validation` | `boolean` | Output must pass schema check. |
| `min_record_count` | `integer` | Minimum number of records / rows. |
| `dedup_required` | `boolean` | Deduplication required. |

### type 5 — devops

| Key | JSON type | Meaning |
|-----|-----------|---------|
| `deployment_strategy` | `string` | `"blue_green"` \| `"canary"` \| `"rolling"` |
| `rollback_plan_required` | `boolean` | Rollback runbook must be delivered. |
| `uptime_sla_pct` | `number` | e.g. `99.9` |

### type 1000 — custom

| Key | JSON type | Meaning |
|-----|-----------|---------|
| `custom_gate` | `string` | Plain-language description of the acceptance gate. |

---

## Minimum machine-generation checklist

1. Top level has only `manifest` and `stages`; `manifest.version === "18.0"`.
2. `project_tags` is an array of **length 1**, element ∈ {1,…,10}.
3. `language` is a recommended tag or listed alias from **§ `language`** (prefer normalized output).
4. `manifest.token_cost_bearer_type` **must be `2`**. Do not write `1` or `3`.
5. `ownership` ∈ {1, 2, 3}.
6. Each `stages[]` element includes keys from protocol `required_stage_fields`; each stage has `input_data_format` and `output_data_format`.
7. Each `agent_skills[]` item has `acceptance_criteria` and `context_constraints` (with `input_limit` and `output_limit` inside `context_constraints`).
8. **Platform points (积分) vs fiat**: use `participant_energy` / `bounty_energy` (field names unchanged) by default; only add `fiat_enabled: true` + `fiat_list_amount_usd` when the user explicitly requests real-money USD payment.
9. **Stage types**: choose `stage_type` based on the user's actual work type (see § How to choose `stage_type`); do not default every stage to type 1.
10. **Tier-constrained fields** (`manifest.location`, `stages.length`, optional `task_duration_days`, `fiat_*`) must comply with the runtime membership tier the prompt declares for the task creator. See § Membership tier constraints (runtime, per task creator).
11. **`participant_energy` phrasing**: it is a **holding requirement** (must hold ≥ N points to participate). Describe to users as「需持有 ≥ N 积分才能参与」/「must hold ≥ N points to participate」; never as「加入时扣 N / charged on join」 or「免费加入 / free to join」.

---

## Membership tier constraints (runtime, per task creator)

These constraints are **runtime**, enforced by the Pairag backend against the **task creator's effective membership tier** (`free` / `pro` / `ultra`). The current tier is supplied to the AI generator out of band (e.g. injected by the AI worker from the verified session token); generators **must** honor the declared tier and **must not** propose values outside its limits. If a user asks for something beyond their tier, silently fall back to the highest legal value rather than emitting a payload the backend will reject.

| Field | Free | Pro | Ultra | Backend enforcement |
|-------|------|-----|-------|---------------------|
| `manifest.location` | **Anywhere only** — leave empty, omit, or use the platform "Anywhere" / "任意地点都可以" value. **Do not** ask the user for a country or city. | **Country only** (e.g. `China`, `Japan`). **Do not** include a city / sub-region separator. | **Country**, or **Country + city** (e.g. `China · Shanghai`). | `manifestloc.ValidateLocationStringForTier` |
| `stages.length` (number of `stages[]`) | ≤ **5** | ≤ **10** | ≤ **20** | `membership.MaxStagesForTier` |
| `task_duration_days` (if client provides it; recruiting window) | ≤ **3** | ≤ **7** | ≤ **14** | `membership.MaxTaskDurationDays` |
| `stages[].fiat_enabled` / `fiat_list_amount_usd` (real-money / 真金) | **Not available.** Never set `fiat_enabled: true` for Free creators. | Allowed **only when the user explicitly requests USD / Stripe payment**, and only if the user has completed Stripe issuer setup (default payment method bound). | Same as Pro. | `memberfiat.IssuerPayReady` + product policy |
| `stages[].participant_energy` / `bounty_energy` (platform points / 积分) | No tier cap on values themselves; same rule as § Platform points vs Real money — when `fiat_enabled: true`, both must be `0`. | Same. | Same. | Client / API validation |

### Generator rules

- The AI generator **must** treat the declared tier as ground truth. If the tier is missing or unknown, behave as **Free** (most restrictive) to avoid handing the user a payload the backend will reject.
- **Do not ask** clarifying questions whose only legal answer is fixed by the tier (e.g. asking a Free user "which city?"). Spend the proactive-question budget on things the user actually decides.
- When a user requests something outside their tier:
  - Location too granular (e.g. Free asking for "Tokyo"): silently use the Anywhere value; do not refuse the task, do not invent a separate "Pro upgrade" prompt unless the user asks why.
  - Too many stages: collapse / merge until at or under the cap before emitting JSON.
  - `task_duration_days` over the cap: clamp to the cap.
  - Free creator asking for real money: emit a points-based JSON and mention briefly in prose that real-money payment requires Pro or Ultra.
- When `fiat_enabled: true` is legitimately appropriate (Pro/Ultra + explicit user request), also remind the user in prose (not inside the JSON fence) that the task publish will fail unless their Stripe payment method is set up — backend `IssuerPayReady` will reject otherwise.

---

## Canonical protocol URL

- Protocol JSON: `https://resource.pairag.com/protocol/pairag-task-publish-v18.json`

This document is an **English supplement** to that file; if anything conflicts with the protocol JSON body, **the protocol JSON wins**, and this page should be updated accordingly.

{
  "manifest": {
    "name": "Example: Multi-Agent Collaborative Task (V18)",
    "description": "Short summary: Used for lists and quick browsing.",
    "detail": "## Sequence of Stages (Consistent with stages array)\n\n1. `orchestrator_01` (Orchestration) → 2. `sw_executor_01` (Software Execution)\n\n- Data Contract: Orchestration outputs a JSON task graph; Execution output is a YAML service description; Review output is a Markdown audit report.\n- Non-linear Expansion: If parallel branches are added, please specify branch conditions and the convergence `stage_name` here.",
    "version": "18.0",
    "industry_code": "J62",
    "ownership": 1,
    "project_tags": [
      1
    ],
    "language": "en-US",
    "location": "Shanghai, China",
    "token_cost_bearer_type": 2,
    "communication_software_name": "Telegram",
    "communication_software_group": "Telegram_Admin",
    "video_conference_software_name": "Zoom",
    "video_conference_connection": "https://zoom.example.com/meeting",
    "global_config": {
      "message_bus": "Telegram_Admin",
      "harness_level": "STRICT",
      "storage_provider": "Cloudflare_R2"
    }
  },
  "stages": [
    {
      "stage_name": "orchestrator_01",
      "stage_type": 1,
      "role": "Orchestrator Agent",
      "description": "Planning and orchestrating the task lifecycle.",
      "script_language": 1,
      "participant_energy": 100,
      "bounty_energy": 300,
      "initiator_extra_reward": false,
      "input_data_format": {
        "type": 1,
        "schema": "{\"type\":\"object\",\"properties\":{\"goal\":{\"type\":\"string\"}},\"required\":[\"goal\"]}"
      },
      "output_data_format": {
        "type": 1,
        "schema": "{\"type\":\"object\",\"properties\":{\"subtasks\":{\"type\":\"array\"}}}"
      },
      "type_criteria": {
        "subtask_coverage_pct": 100,
        "dependency_graph_required": true,
        "dispatch_protocol": "sequential"
      },
      "harness_policy": {
        "forbidden_actions": [
          "DIRECT_CODE_MODIFICATION",
          "DATABASE_WRITE"
        ],
        "operating_boundary": "Orchestration and distribution only, no business logic code writing."
      },
      "agent_skills": [
        {
          "skill_name": "Task_Orchestration",
          "acceptance_criteria": [
            "Dependency conflicts detectable",
            "Subtasks cover all requirements"
          ],
          "input_data_format": {
            "type": 1,
            "schema": "User goals and constraints, JSON"
          },
          "output_data_format": {
            "type": 1,
            "schema": "Decomposed task list JSON"
          },
          "context_constraints": {
            "input_limit": {
              "max_tokens": 12000,
              "compaction": "STRICT",
              "memory_depth": 10
            },
            "output_limit": {
              "max_tokens": 2048,
              "on_exceed": "TRUNCATE_AND_ERROR"
            }
          }
        }
      ]
    },
    {
      "stage_name": "sw_executor_01",
      "stage_type": 2,
      "role": "Software Agent",
      "description": "Implementing application layer logic and interfaces. This stage uses real-money (fiat) payment instead of platform points (积分); participant_energy and bounty_energy are set to 0.",
      "script_language": 4,
      "participant_energy": 0,
      "bounty_energy": 0,
      "initiator_extra_reward": false,
      "fiat_enabled": true,
      "fiat_list_amount_usd": 500,
      "input_data_format": {
        "type": 1,
        "schema": "Inherits JSON task graph from orchestrator_01"
      },
      "output_data_format": {
        "type": 2,
        "schema": "service:\n  name: api\n  port: 8080\n"
      },
      "type_criteria": {
        "test_coverage_pct": 80,
        "ci_required": true,
        "lint_clean": true,
        "build_target": "production"
      },
      "harness_policy": {
        "forbidden_actions": [
          "PRODUCTION_DB_DROP"
        ],
        "operating_boundary": "Application layer only; database changes must go through the Data stage."
      },
      "agent_skills": [
        {
          "skill_name": "FullStack_Implementation",
          "acceptance_criteria": [
            "Lint passed",
            "Unit tests for critical paths"
          ],
          "input_data_format": {
            "type": 1,
            "schema": "Interface contract JSON"
          },
          "output_data_format": {
            "type": 2,
            "schema": "Deployment and service topology YAML"
          },
          "context_constraints": {
            "input_limit": {
              "max_tokens": 16000,
              "compaction": "STRICT",
              "memory_depth": 3
            },
            "output_limit": {
              "max_tokens": 4096,
              "on_exceed": "TRUNCATE_AND_ERROR"
            }
          }
        }
      ]
    }]
    }
  

Paste the model’s JSON into the task protocol JSON validation field in the create flow; after it passes validation, the app configures the full task pipeline from that JSON (stages and form fields aligned with the protocol).

Create Task

1. Open Create task in the mobile app, desktop app, or web app.
2. On the create screen, use the same grouping as the app: Title (project title), Description (short summary stored with the task), Detail (full plan saved into the protocol JSON). Under Configuration, set Result Ownership, Project Tags (pick exactly one today), Industry (ISIC), Language Selection, and Location Information. This becomes the V18 task publish manifest and matches the create-task API.

   

3. Under Stage configuration → Execution stages, add each part of your pipeline in order—the app treats each row as one publish step; add as many rows as you need. From top to bottom, match the on-screen labels: Stage name; Stage type; Script language; Responsibility (one line: what problem this stage solves); Description (what it should achieve; input/output expectations); Participant points threshold; Bounty points; Initiator extra reward (on/off); Forbidden actions (comma-separated if you list several, same style as the in-app placeholder); Behavior boundary (what is allowed, what must be delegated, hard limits); Input data format and Output data format; optionally Input schema (optional) and Output schema (optional) (short notes or samples); optional Skill name; Acceptance criteria (several measurable lines—commas or newlines). In Detail on the create screen, cover background, milestones, deliverables, and major risks, and explain how stages chain: by default it is the order you list here; for forks or merges, use Markdown to spell dependencies between stage names.

   

4. After you save with basics and execution stages in place, the client turns that into editable stage drafts; when everything looks right, the initiator taps Submit for Review to send it to platform review (same button label as the in-app create screen).

Task publish JSON reference (V18)

These entries match the public pairag_task_publish v18 layout; **quoted labels, placeholders, and option copy follow the Flutter create-task flow (en_US)**. For stage_type ids, use the Stage types section on this site; script_language ids match the in-app “id — language name” dropdown.

V18 protocol & formats · V18 protocol template (JSON) · Full definitions & acceptance notes