inkreach-teable-cli

71 Commits 1 Branch 0 Tags

3 Commits

Include renames

Author	SHA1	Message	Date
yeuimu	2a186c9acc	chore: standalone repo bootstrap after split from inkreach-teable monorepo - untrack dist/, add .gitignore, add pnpm-lock.yaml - inline tsconfig.base.json options (no monorepo extends) - install.sh: CLI now at repo root; install skill to ~/.zcode/skills (user scope) - fix stale paths in skill docs; 7 actions in help text; README	2026-09-23 04:01:22 +00:00
yeuimu	035384131c	feat(view-preset): shared view presets with fork-on-edit semantics Lands the view-preset / server-persisted personal-layer feature that has been running in production, plus the hotfix for "the same preset shows different filter configs to different users" (物流问题-已出轨迹 on tblgsJTXhqwiDpsjeL5 / viwyszJmLQNOLhA9sh5). Root cause of the divergence: - usePersonalViewSync implicitly flushed any overlay edit by a view\|update user INTO the shared preset row (last-writer-wins). Overlays are stale snapshots seeded at apply time, so one user's seed silently erased colleagues' filter changes (2026-09-17 02:55 the preset lost the 流转角色=售后 condition), and active overlays never converged because preset updates do not propagate. Fix (semantics: presets are shared definitions, edits are personal): - fork-on-edit: the first user edit strips the seed markers from the overlay (toolbar switches to the personal config); edits only ever write the user's personal row - shared presets change ONLY through the new explicit, confirmed "Update to current config" row action (canManage users) - un-edited preset overlays auto-follow redefinitions: applyPreset stamps a presetVersion (preset.lastModifiedTime); when the preset list refetches with a newer row the overlay re-seeds. Edited overlays carry no markers and are never clobbered. Legacy rows without a version re-seed exactly once - exits strip both seed markers from the persisted personal row Also lands the pending WIP shipped with the deployed build: select-choice visibility constraint, personal-view server sync + proxy, grid async records scope/request tracking, CLI resource display, preset i18n (10 locales), view_preset migrations, docs/skill updates, .zcode gitignore. Verified end-to-end on the live instance (headless chromium, real session): apply -> edit flips toolbar to Personal with ZERO shared-row PUTs; explicit update PUTs the shared row; API-side redefinition auto-reseeds an un-edited overlay on the next list refetch.	2026-09-17 04:07:30 +00:00
yeuimu	5fa843df05	feat: add inkreach CLI + inkreach-teable-ops skill A self-built CLI and companion agent skill for operating a deployed inkreach-teable instance — configuring tables, fields, records, views, and the project's OWN automation engine. Why not the official 'teable' CLI: inkreach-teable's automation is self-built with a different contract: - conditions (not filter), fieldIds (not watchFieldIds) - recordCondition (not recordMatchesConditions) - webhook route /api/webhook/{baseId}/{wfId} (not the /base//workflow/ form) - scheduledTime backend honors only timing.type + timing.interval The official CLI targets the upstream contract and 404s/misconfigures here. Table/field/record/view APIs ARE upstream-compatible, but automation is not. inkreach CLI (packages/inkreach-cli/): - Node.js + commander, zero extra runtime deps - Uses node:http (NOT fetch — Node 24 fetch drops Authorization header) - Commands: auth (login/status/token), base/table/field/record/view, workflow (list/get/create/update/delete/activate/deactivate/test), trigger set (8 types, builds correct config keys), action add/update/delete (6 types), secret, runs (list/get/rerun), fire (button-click/webhook), sql - --json mode for agent parsing; GET->modify->PUT whole-graph for node edits - Verified end-to-end: create workflow -> set webhook trigger -> add script action -> activate -> fire webhook -> runs list (succeeded) inkreach-teable-ops skill (.agents/skills/inkreach-teable-ops/): - SKILL.md entry: module map, routing rules, 11 key constraints (the real contract keys), execution rules, error recovery - guides/: cli-reference, automation-guide, tables-fields, instance-access, development (build/restart, known gotchas) - api-reference/: trigger-types (8 triggers, exact config), action-types (6 actions, sandbox globals), field-types (21 types incl. Button) - metadata.json + install.sh	2026-08-05 02:04:39 +08:00

Author

SHA1

Message

Date

yeuimu

2a186c9acc

chore: standalone repo bootstrap after split from inkreach-teable monorepo

- untrack dist/, add .gitignore, add pnpm-lock.yaml
- inline tsconfig.base.json options (no monorepo extends)
- install.sh: CLI now at repo root; install skill to ~/.zcode/skills (user scope)
- fix stale paths in skill docs; 7 actions in help text; README

2026-09-23 04:01:22 +00:00

yeuimu

035384131c

feat(view-preset): shared view presets with fork-on-edit semantics

Lands the view-preset / server-persisted personal-layer feature that has
been running in production, plus the hotfix for "the same preset shows
different filter configs to different users" (物流问题-已出轨迹 on
tblgsJTXhqwiDpsjeL5 / viwyszJmLQNOLhA9sh5).

Root cause of the divergence:
- usePersonalViewSync implicitly flushed any overlay edit by a
  view|update user INTO the shared preset row (last-writer-wins). Overlays
  are stale snapshots seeded at apply time, so one user's seed silently
  erased colleagues' filter changes (2026-09-17 02:55 the preset lost the
  流转角色=售后 condition), and active overlays never converged because
  preset updates do not propagate.

Fix (semantics: presets are shared definitions, edits are personal):
- fork-on-edit: the first user edit strips the seed markers from the
  overlay (toolbar switches to the personal config); edits only ever
  write the user's personal row
- shared presets change ONLY through the new explicit, confirmed
  "Update to current config" row action (canManage users)
- un-edited preset overlays auto-follow redefinitions: applyPreset stamps
  a presetVersion (preset.lastModifiedTime); when the preset list
  refetches with a newer row the overlay re-seeds. Edited overlays carry
  no markers and are never clobbered. Legacy rows without a version
  re-seed exactly once
- exits strip both seed markers from the persisted personal row

Also lands the pending WIP shipped with the deployed build: select-choice
visibility constraint, personal-view server sync + proxy, grid async
records scope/request tracking, CLI resource display, preset i18n (10
locales), view_preset migrations, docs/skill updates, .zcode gitignore.

Verified end-to-end on the live instance (headless chromium, real
session): apply -> edit flips toolbar to Personal with ZERO shared-row
PUTs; explicit update PUTs the shared row; API-side redefinition
auto-reseeds an un-edited overlay on the next list refetch.

2026-09-17 04:07:30 +00:00

yeuimu

5fa843df05

feat: add inkreach CLI + inkreach-teable-ops skill

A self-built CLI and companion agent skill for operating a deployed
inkreach-teable instance — configuring tables, fields, records, views, and
the project's OWN automation engine.

Why not the official 'teable' CLI:
  inkreach-teable's automation is self-built with a different contract:
  - conditions (not filter), fieldIds (not watchFieldIds)
  - recordCondition (not recordMatchesConditions)
  - webhook route /api/webhook/{baseId}/{wfId} (not the /base//workflow/ form)
  - scheduledTime backend honors only timing.type + timing.interval
  The official CLI targets the upstream contract and 404s/misconfigures here.
  Table/field/record/view APIs ARE upstream-compatible, but automation is not.

inkreach CLI (packages/inkreach-cli/):
  - Node.js + commander, zero extra runtime deps
  - Uses node:http (NOT fetch — Node 24 fetch drops Authorization header)
  - Commands: auth (login/status/token), base/table/field/record/view,
    workflow (list/get/create/update/delete/activate/deactivate/test),
    trigger set (8 types, builds correct config keys), action add/update/delete
    (6 types), secret, runs (list/get/rerun), fire (button-click/webhook), sql
  - --json mode for agent parsing; GET->modify->PUT whole-graph for node edits
  - Verified end-to-end: create workflow -> set webhook trigger -> add script
    action -> activate -> fire webhook -> runs list (succeeded)

inkreach-teable-ops skill (.agents/skills/inkreach-teable-ops/):
  - SKILL.md entry: module map, routing rules, 11 key constraints (the real
    contract keys), execution rules, error recovery
  - guides/: cli-reference, automation-guide, tables-fields, instance-access,
    development (build/restart, known gotchas)
  - api-reference/: trigger-types (8 triggers, exact config), action-types
    (6 actions, sandbox globals), field-types (21 types incl. Button)
  - metadata.json + install.sh

2026-08-05 02:04:39 +08:00