corezoid-process-tech-writer

Corezoid Process Tech Writer

Always produce two outputs for every process:

1. Markdown documentation file at .processes/<name>-docs.md
2. Enriched process JSON (same file, description fields filled in) at .processes/<name>-enriched.json

Step 0 — Load the process

If the user provides a file path, read it directly. If they provide a process name or ID, use pull-process to fetch it first.

How to extract information from the process JSON

Inputs

Read the params array. Each entry has:

• name — parameter name
• type — data type
• descr — description (may be empty — infer from context)
• flags — "required" flag means mandatory; "input" = input param, "output" = output param
• regex — validation pattern (document if non-empty)

Outputs

Find all nodes with api_rpc_reply logic in condition.logics:

• throw_exception: false → success response — document res_data keys and types
• throw_exception: true → error response — document what triggers it (node title, exception_reason if present)

Process flow

Walk scheme.nodes following go entries from the Start node (obj_type: 1):

• Start → node with id matching the to_node_id in Start's go logic
• Continue following go entries to map the happy path
• Note branches at Condition nodes or go_if_const entries
• Note error paths via err_node_id references

External dependencies

• API Call nodes (api logic): extract url, method, extra_headers
• {{env_var[@name]}} references: list all unique variable names used
• Code nodes (api_code): look for referenced services or data transformations
• Call Process nodes (api_rpc): extract conv_id values (called process IDs)

Output 1: Markdown documentation

Save to .processes/<process-name-in-snake-case>-docs.md.

Use this exact structure:

# <Process Title>

## Overview
<1-2 sentences: what this process does and when to call it. Be specific about the business purpose.>

## Input Parameters

| Name | Type | Required | Description |
|------|------|----------|-------------|
| field_name | string | Yes | Description from params.descr |
| optional_field | number | No | Description |

<If any field has regex validation, add a "Validation" subsection listing the rules.>

## Output

### Success response
| Field | Type | Description |
|-------|------|-------------|
| response | object | The API response body |

### Error cases
| Error | Trigger condition |
|-------|------------------|
| "Code node error" | JavaScript execution failed in the preparation step |
| "API call error" | External API returned an error or was unreachable |

## How to Call

Example `task_data` with realistic values:
​```json
{
  "field_name": "example_value",
  "optional_field": 42
}
​```

## Process Flow

1. **Start** — Entry point, receives the task
2. **<Code Node title>** — <plain English: what this step does>
3. **<API Call / Call Process title>** — <plain English: what is called and why>
4. **<Reply node title>** — <what is returned on success>
5. **Final** — Task stored, process complete

<For error paths, describe them after the happy path:>

**Error path (Code Node failure):** If the preparation step fails, an error reply is returned
with the exception description, and the task ends at the Error node.

## External Dependencies

| Dependency | Type | Variable / URL |
|-----------|------|----------------|
| <service name> | HTTP API | `{{env_var[@variable-name]}}` |
| <process name> | Corezoid process | ID: `<conv_id>` |

## Notes

- <Any timeouts configured via semaphors — e.g. "API call has a 30-second timeout">
- <Rate limiting (max_threads setting)>
- <Any other relevant technical notes>