Task List Gantt/project schedule automation gaps: sections, dependencies, and view config

[everything-bot-engineer]

Summary

While trying to use lark-cli to generate a Feishu/Lark Task List as an execution-level Gantt chart from a structured YAML schedule, I ran into several API/CLI gaps that make the workflow hard to fully automate.

The desired workflow is:

1. Keep schedule.yaml as the source of truth.
2. Create/update one Feishu Task List per project.
3. Create visible workstream/lane groups or sections from YAML swimlanes.
4. Create tasks with start/due dates.
5. Preserve dependencies so the Task List / Gantt view can show execution ordering.
6. Configure the Gantt/list view enough that the result is usable without manual UI setup.

For reporting-only timelines, Bitable Gantt works reasonably well. For execution-level project management, Task List would be the better fit, but I could not make the above workflow fully scriptable.

Environment

• lark-cli version 1.0.23
• Auth mode: bot / tenant access token
• Product area: lark-cli task / Feishu Task v2 APIs
• Use case: YAML schedule -> Feishu Task List / Gantt-style project execution view

Issues encountered

1. Visible Task List sections/groups are hard to create/configure via CLI

The Feishu UI exposes visible list groupings/sections that would be the natural representation for YAML swimlanes, for example:

• 冻干
• 发酵
• 动物实验
• 可选
• 文档与交付

However, in the observed lark-cli task surface, it was not clear how to create/manage those visible sections/groups and assign tasks to them in a stable way.

I looked at commands such as:

• lark-cli task +tasklist-create
• lark-cli task +create
• lark-cli task +update
• lark-cli task +set-ancestor
• lark-cli task subtasks create

But these mostly map to task/tasklist/task-detail relationships. They do not seem to cover the visible section/group model that users see in the Task List UI.

This means the generated list is structurally correct at the task level, but not presented as a usable workstream/lane board without manual UI configuration.

2. Parent/subtask APIs do not map to the visible expandable list hierarchy expected for project lanes

set-ancestor, parent_task_guid, and subtasks are valid task-detail relationships, but they do not appear to be a reliable substitute for UI-visible sections/groups in the main task list.

For a Gantt/project schedule use case, this distinction matters:

• YAML swimlanes should become visible groups/sections in the list/Gantt view.
• Task-detail subtasks are useful for smaller checklist items, but not for high-level workstream layout.

It would help if the CLI documented the intended mapping between:

• Task List visible sections/groups
• task ancestors / parent tasks
• subtasks
• custom fields / view grouping

3. Task dependency schema exists but did not reliably persist in bot-mode tests

The public schema suggests task.dependencies supports objects like:

[
  {
    "task_guid": "<predecessor-guid>",
    "type": "prev"
  }
]

I tried mapping YAML dependencies to this representation:

• current task depends on predecessor -> dependency object with predecessor task_guid and type: "prev"

But in bot-mode tests, dependency updates were not reliably visible after reading the task back with the API. In particular:

• create-payload dependencies did not appear to persist reliably
• patching dependencies via update fields failed or did not result in visible dependency state

Because of this, the fallback was to preserve dependencies as generated description text such as:

【前置任务】
FS FMT 冻干工艺曲线优化
SS 动物实验评价分析

That preserves information, but it means native dependency/Gantt behavior cannot be relied on.

4. Gantt/view configuration for Task List does not seem fully automatable

For Bitable, lark-cli exposes enough commands/API access to create a table, create fields, create records, create a Gantt view, and set the timebar.

For Task List, I could not find an equivalent stable workflow to configure the list/Gantt presentation from CLI, especially around:

• visible grouping/sections
• Gantt/date view setup
• dependency visualization
• field/view configuration

This creates a gap between:

• Bitable Gantt: good reporting snapshot, but no native dependency arrows/view
• Task List: better execution model, but not fully automatable for generated project schedules

Expected behavior / feature request

It would be very helpful if lark-cli task could support and document a full Task List project schedule automation path, including:

1. Create/list/update/delete visible Task List sections/groups.
2. Assign tasks to those sections/groups.
3. Configure Task List views, especially Gantt/date views if the underlying API supports it.
4. Create/update task dependencies and verify them with a read-back command.
5. Document the difference between visible sections/groups, ancestors, subtasks, and custom fields.
6. Provide a YAML/JSON -> Task List example for project schedules.

A high-level command set could look something like:

lark-cli task section-create --tasklist-guid ... --name "冻干"
lark-cli task section-list --tasklist-guid ...
lark-cli task +create --tasklist-guid ... --section-guid ... --summary ...
lark-cli task dependency-add --task-guid ... --prev-task-guid ...
lark-cli task dependency-list --task-guid ...
lark-cli task view-configure --tasklist-guid ... --view gantt --start-field start --due-field due --group-by section

Exact names aside, the key request is to make the UI-visible Task List/Gantt structure scriptable and verifiable.

Current workaround

For now, the most reliable split is:

• Use DHTMLX Gantt generated from YAML for high-fidelity dependency/hierarchy visualization.
• Use Feishu Bitable Gantt for collaborative reporting/timeline snapshots.
• Use Feishu Task List only for manual execution tracking, while writing dependencies into task descriptions as text.

This works, but it prevents Task List from being the fully automated execution-layer output for AI-generated project schedules.