inkreachhub/inkreach-teable-cli
4
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

skill(iter-1): fix CLI getRecords flag + docs from eval feedback

Browse Source 
Ran 4 end-to-end evals (skill-creator flow): all 23 assertions passed (100%).
The evals exposed 3 issues, now fixed:

1. CLI bug: getRecords/createRecord/updateRecord --target-table flag was
   read as opts['target-table'] but commander stores it camelCase
   (opts.targetTable). Added a pick() helper accepting both forms.
2. trigger-types.md: buttonClick output said record.fields.* implying all
   fields; actually record.fields only contains the button field's count.
   Documented the back-channel API fetch pattern for other fields.
3. automation-guide.md: documented that 'workflow test' uses mock input
   with empty fields, so upstream outputs are absent in test mode — use
   real fire for data-dependent validation.

Also: corrected button field options (workflow.id object, not workflowId).
This commit is contained in:
yeuimu
2026-08-05 10:48:33 +08:00
parent d3790ab856
commit 3e06a10fe0
6 changed files with 92 additions and 16 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.agents/skills/inkreach-teable/api-reference/trigger-types.md
+12 -3
View File
@@ -176,12 +176,21 @@ inkreach-teable trigger set <wfId> --type buttonClick --table-id tblXXX --field-
```json
{ "tableId": "tblXXX", "fieldIds": ["fldGo"] }
```
- The field **must be a Button-type field** whose `options.workflowId` points to this workflow.
- Create it: `inkreach-teable field create --table-id tblXXX --name "Go" --type button --options '{"workflowId":"wflXXX","label":"Go"}'`
- The field **must be a Button-type field** whose `options.workflow.id` points to this workflow.
- Create it: `inkreach-teable field create --table-id tblXXX --name "Go" --type button --options '{"workflow":{"id":"wflXXX"},"label":"Go"}'`
**Triggering:** the click comes from `POST /api/table/{tableId}/record/{recordId}/{fieldId}/button-click` (the web UI calls this; CLI tests via `fire button-click`).
**Output:** `record.id`, `record.fields.*`, `fieldId`, `user`, `runId`, `name`, `tableId`, `workflowId`.
**Output:** `record.id`, `record.name` (primary field), `record.fields.<buttonFieldId>` (**only the clicked button field's count, NOT all fields**), `fieldId`, `user`, `runId`, `name`, `tableId`, `workflowId`.
⚠️ **`record.fields` contains ONLY the button field itself** (e.g. `{fldXxx:{count:1}}`), not the record's other fields. To read other fields (e.g. an "订单号" text field), use the back-channel API inside a script:
```js
const rec = await fetch(`${triggerInput._apiBaseUrl}/api/record/${triggerInput.record.id}`, {
headers: { Authorization: 'Bearer ' + triggerInput._accessToken }
}).then(r => r.json());
return { orderId: rec.fields.fldXxx };
```
`record.name` (primary field) and `record.id` ARE directly available.
⚠️ The Button field's `options` captures a stale `isActive` snapshot at creation. After deactivating, the API validates the DB `isActive` instead — so a deactivated workflow returns 400 "not active" on click. Re-`activate` to fix.