docs(projects): document project workflow API

docs/usage/projects/project-workflows.md

@@ -86,6 +86,20 @@ Permissions are checked when workflows are managed, not when they run.
 - Changes made by a workflow show in the timeline as done by "Project workflow" and are attributed to the user who triggered the event, like review requests made by CODEOWNERS. They don't trigger other workflows.
 - Only users who can read an item can add it to a project or move its card, so a workflow never acts for someone on an item they can't see.
 
+## API
+
+Workflows can also be managed through the REST API under the project routes of a repository (`/repos/{owner}/{repo}/projects/{id}`), an organization (`/orgs/{org}/projects/{id}`) or the authenticated user (`/user/projects/{id}`):
+
+| Method | Path | Purpose |
+| --- | --- | --- |
+| `GET` | `.../workflows` | List the project's workflows |
+| `GET` | `.../workflows/{workflow_id}` | Get a workflow |
+| `POST` | `.../workflows` | Create a workflow |
+| `PATCH` | `.../workflows/{workflow_id}` | Edit a workflow, omitted fields are left unchanged |
+| `DELETE` | `.../workflows/{workflow_id}` | Delete a workflow |
+
+A workflow has an `event` (`item_added_to_project`, `item_removed_from_project`, `item_reopened`, `item_closed`, `item_column_changed`, `code_changes_requested`, `code_review_approved` or `pull_request_merged`), an `enabled` flag, `filters` (`issue_type`, `source_column_id`, `target_column_id`, `label_ids`) and `actions` (`column_id`, `add_label_ids`, `remove_label_ids`, `issue_state`). The same [permissions](#permissions) apply as in the UI.
+
 ## Example: triage incoming bug reports
 
 The following workflow keeps bug reports organized automatically:

i18n/zh-cn/docusaurus-plugin-content-docs/current/usage/projects/project-workflows.md

@@ -84,6 +84,20 @@ description: "在仓库项目上使用事件、过滤器和动作组合来自动
 - 工作流所做的更改在时间线中显示为由“项目工作流”完成，并归属于触发该事件的用户，与 CODEOWNERS 发起的审查请求相同。这些更改不会触发其他工作流。
 - 只有能读取条目的用户才能将其加入项目或移动其卡片，因此工作流不会替用户操作其无法查看的条目。
 
+## API
+
+也可以通过 REST API 管理工作流，路径位于仓库（`/repos/{owner}/{repo}/projects/{id}`）、组织（`/orgs/{org}/projects/{id}`）或当前用户（`/user/projects/{id}`）的项目路由下：
+
+| 方法 | 路径 | 用途 |
+| --- | --- | --- |
+| `GET` | `.../workflows` | 列出项目的工作流 |
+| `GET` | `.../workflows/{workflow_id}` | 获取工作流 |
+| `POST` | `.../workflows` | 创建工作流 |
+| `PATCH` | `.../workflows/{workflow_id}` | 编辑工作流，未提供的字段保持不变 |
+| `DELETE` | `.../workflows/{workflow_id}` | 删除工作流 |
+
+工作流包含 `event`（`item_added_to_project`、`item_removed_from_project`、`item_reopened`、`item_closed`、`item_column_changed`、`code_changes_requested`、`code_review_approved` 或 `pull_request_merged`）、`enabled` 开关、`filters`（`issue_type`、`source_column_id`、`target_column_id`、`label_ids`）以及 `actions`（`column_id`、`add_label_ids`、`remove_label_ids`、`issue_state`）。权限规则与界面操作相同，参见[权限](#权限)。
+
 ## 示例：自动分流新的缺陷报告
 
 以下工作流可以让缺陷报告自动进入待处理区：

i18n/zh-tw/docusaurus-plugin-content-docs/current/usage/projects/project-workflows.md

@@ -84,6 +84,20 @@ description: "以事件、篩選條件與動作組合，替儲存庫專案自動
 - 工作流程所做的變更在時間軸中顯示為由「專案工作流程」完成，並歸屬於觸發該事件的使用者，與 CODEOWNERS 發起的審查請求相同。這些變更不會觸發其他工作流程。
 - 只有能讀取項目的使用者才能將其加入專案或移動其卡片，因此工作流程不會替使用者操作其無法查看的項目。
 
+## API
+
+也可以透過 REST API 管理工作流程，路徑位於儲存庫（`/repos/{owner}/{repo}/projects/{id}`）、組織（`/orgs/{org}/projects/{id}`）或目前使用者（`/user/projects/{id}`）的專案路由下：
+
+| 方法 | 路徑 | 用途 |
+| --- | --- | --- |
+| `GET` | `.../workflows` | 列出專案的工作流程 |
+| `GET` | `.../workflows/{workflow_id}` | 取得工作流程 |
+| `POST` | `.../workflows` | 建立工作流程 |
+| `PATCH` | `.../workflows/{workflow_id}` | 編輯工作流程，未提供的欄位保持不變 |
+| `DELETE` | `.../workflows/{workflow_id}` | 刪除工作流程 |
+
+工作流程包含 `event`（`item_added_to_project`、`item_removed_from_project`、`item_reopened`、`item_closed`、`item_column_changed`、`code_changes_requested`、`code_review_approved` 或 `pull_request_merged`）、`enabled` 開關、`filters`（`issue_type`、`source_column_id`、`target_column_id`、`label_ids`）以及 `actions`（`column_id`、`add_label_ids`、`remove_label_ids`、`issue_state`）。權限規則與介面操作相同，詳見[權限](#權限)。
+
 ## 範例：自動分流新的錯誤回報
 
 以下設定能讓錯誤議題自動落在待處理區：