タスク作成

タスク作成はアプリ内フォームと pairag_task_publish V18 の公開 JSON を組み合わせます。Pairag モバイル／デスクトップ／Web で作成フローを開いてください。手動作成と AI 支援作成は同じペイロード形：トップレベルは `manifest` と `stages` のみ。各ステージにステージ単位の `input_data_format` / `output_data_format` が必須です。各キーの意味・必須／任意・例の形は本ページ末尾の「タスク公開 JSON リファレンス（V18）」に従います。機械可読な仕様は公開プロトコル JSON を参照してください。

手動作成

**アプリまたは Web** で「タスク作成」を開き、フォームに沿って入力したうえで、V18 準拠の `manifest` + `stages` JSON を貼り付けます。ドラフトは `stages[]` の順に並びます。`stage_name`、`stage_type`、ステージ IO、`harness_policy`、`agent_skills` はプロトコル例と整合させてください。**各項目の説明と入力の要点は本ページ末尾のフィールドリファレンスを正とします。**

AI 作成

外部モデルでも可：ワークフローを説明し、下の 英語フィールドリファレンス と V18 プロトコル JSON をコンテキストに渡し、トップレベルが `manifest` と `stages` のみの単一 RFC 8259 JSON（snake_case）を出力させてください。

下のブロックは**既定で折りたたみ**です。見出しを開くと両方の参照全文を読めます。見出し**右のボタン**で「英語説明 + プロトコル JSON」（ファイル区切り付き）を**まとめてコピー**し、モデルコンテキストに貼れます。

# 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"
            }
          }
        }
      ]
    }]
    }
  

モデル出力の JSON を作成フローの「タスクプロトコル JSON」検証欄に貼り付けて検証します。通過後、アプリはその JSON からパイプライン全体（ステージとフォーム項目がプロトコルと一致）を構成します。

タスク作成

1. モバイル／デスクトップ／Web アプリで「タスク作成」を開きます。
2. 作成画面でアプリと同じグループ分けで入力：タイトル、説明（タスク表用の短い要約）、詳細（プロトコル JSON に保存する全文）。設定で成果の帰属、プロジェクトタグ（現状ちょうど 1 つ）、業種（ISIC）、言語、所在地 などを設定。これが V18 公開マニフェストとなり、作成 API と一致します。

   

3. ステージ設定 → 実行ステージ でパイプラインを順に追加します。1 行が公開の 1 ステップ。上から：ステージ名、ステージ種別、スクリプト言語、責務（一文）、説明（達成内容と入出力の想定）、参加者エネルギー閾値、バウンティエネルギー、発起者追加報酬 のオンオフ、禁止アクション（複数はカンマ区切りでプレースホルダと同様）、行動境界、入力／出力データ形式、任意で 入出力スキーマ、スキル名、受け入れ基準（測定可能な複数行）。詳細では背景・マイルストーン・成果物・主要リスクを長文で書き、ステージのつながりを説明：既定はここで並べた順。分岐・合流は Markdown でステージ名同士の依存を明示。

   

4. 基本情報と実行ステージを保存すると、クライアントが編集可能なステージドラフトを生成します。内容がよければ発起者が 審査に提出 でプラットフォーム審査に送ります（ボタンラベルはアプリ作成画面と同じ）。

タスク公開 JSON リファレンス（V18）

以下は公開 pairag_task_publish v18 レイアウトと一致します。**括弧内の日本語ラベル・プレースホルダ・選択肢は Flutter 作成フロー（ja ロケール想定の UI 文言）に合わせた説明**です。`stage_type` の番号は本サイト「ステージ種別」を参照。`script_language` はアプリの「id — 言語名」ドロップダウンと一致します。

V18 プロトコルと形式 · V18 プロトコルテンプレート（JSON） · 定義と受け入れメモ全文