row

kylon workspace row — kylon workspace help detail

row — rows in a non-upgraded legacy Table (default 20 rows per page)
  Runtime scope: add --scope-room <room_id> when this table is in
    another room you can access.
  kylon workspace row list --table <table_id_or_title> [--view <view_id>] [--filters <json>] [--sorts <json>] [--query <keyword>] [--limit <n>] [--offset <n>]
    --query: case-insensitive substring match across title, content, and cells (SQL-side via trigram).
      Combine with --filters for precise narrowing (query runs AND with filters).
      Prefer --filters when you know a specific field (e.g. status=open); use
      --query for quick "find the row about X" searches.
  kylon workspace row get --row <row_id> --table <table_id_or_title>
  kylon workspace row create --table <table_id_or_title> --title <title> [--content <text>] [--cell <key>=<value>] [--cells <json>] [--no-thread] [--thread current|<root_message_id>]
    --cell sets one scalar string cell per flag and may be repeated:
      --cell status=opt_open --cell priority=opt_high
    --cells is the JSON form for multi-cell, null, or array values:
      --cells '{"status":"opt_open","priority":"opt_high"}'
    The --cell and --cells forms are mutually exclusive on one invocation.
      There is NO --field
      flag — passing --field is a usage error.
    select/multi_select fields take existing option IDs, not labels. Run
      field list --table <table_id_or_title> to see option IDs. Do not
      invent IDs; use field add-option first when a new option is needed.
    user/multi_user fields take workspace member user IDs (humans: "user_xxx";
      agents: the agent_def ID, e.g. "d889bb49c5db"). Arrays need --cells:
      --cells '{"assignees":["user_abc","d889bb49c5db"]}'
    attachment fields take file IDs from "file list". Arrays need --cells:
      --cells '{"screenshots":["file_abc","file_def"]}'
    Thread linkage: top-level-trigger turns (agent replying to a top-
      level room message) AUTOMATICALLY link the new row to that
      message as its discussion root. Thread-reply turns (you are
      inside an existing thread) do NOT auto-link; you must judge —
      see below.
    PREFER linking in thread-reply turns whenever a thread is
      specifically about the single concrete item this row represents
      (e.g. the issue thread becoming an issues-table row, the bug
      thread becoming a bugs-table row). Pass --thread current to link
      to the thread you are currently inside, or --thread <id> for a
      different top-level message. Skip --thread only when the thread
      covers multiple unrelated topics or is only loosely related.
    --no-thread: opt out of auto-link on top-level-trigger turns (bulk
      create, unrelated row, etc.).
    Any link attempt soft-fails: if the anchor already serves another
    row, is not top-level, or is cross-room, the row is STILL
    created and the tool returns a warning naming the conflict so you
    can update the existing row or pick a different thread next turn.
  kylon workspace row update --row <row_id> --table <table_id_or_title> [--title <title>] [--content <text>] [--cell <key>=<value>] [--cells <json>]
    Same --cell / --cells contract as row create. At least one of --title,
      --content, --cell, --cells is required; an empty update is rejected.
    Single-cell update example:  --cell status=opt_no_reply
    Multi-cell / null / array:   --cells '{"status":"opt_done","notes":null}'
    Thread linkage: no --thread flag. If the row has no anchor and the
      current thread is about this row, run thread attach --target
      table_row:<id> --root current (the response also reminds you).
      Anchors are 1:1 and unmovable — attach now or accept it stays
      unlinked.
  kylon workspace row delete --row <row_id> --table <table_id_or_title>

--- Filter/Sort JSON reference (used by row list, view create, view update) ---
  --filters '[{"fieldId":"<field_key>","operator":"<op>","value":"<val>"}]'
  --sorts   '[{"fieldId":"<field_key>","direction":"asc|desc"}]'
  Operators: eq, neq, contains, gt, gte, lt, lte, isEmpty, isNotEmpty
  Use field key (e.g. "status", "created_date") as fieldId.

  Dynamic values — prefer these over hardcoded literals when the intent is
  relative (e.g. "my tasks", "overdue", "recent"). They resolve at query time,
  so saved views stay correct as time passes and across different users.
    "$current_member" → viewing user's ID (use with user/multi_user fields)
    "$start_of_today"      → 00:00 UTC today
    "$start_of_tomorrow"   → 00:00 UTC tomorrow
    "$start_of_yesterday"  → 00:00 UTC yesterday
    "$start_of_7_days_ago" → 00:00 UTC 7 days ago
    "$start_of_30_days_ago"→ 00:00 UTC 30 days ago
  Common patterns:
    Due today:        gte $start_of_today + lt $start_of_tomorrow
    Overdue:          lt  $start_of_today
    Last 7 days:      gte $start_of_7_days_ago
    Last 30 days:     gte $start_of_30_days_ago
    Assigned to me:   eq  $current_member  (user field)
    Involves me:      contains $current_member  (multi_user field)

Note: quote flag values that contain spaces; follow each command's JSON syntax.