[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-78113":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":10,"language":11,"languages":10,"totalLinesOfCode":10,"stars":12,"forks":13,"watchers":14,"openIssues":15,"contributorsCount":16,"subscribersCount":16,"size":16,"stars1d":17,"stars7d":18,"stars30d":19,"stars90d":16,"forks30d":16,"starsTrendScore":20,"compositeScore":21,"rankGlobal":10,"rankLanguage":10,"license":22,"archived":23,"fork":23,"defaultBranch":24,"hasWiki":25,"hasPages":23,"topics":26,"createdAt":10,"pushedAt":10,"updatedAt":27,"readmeContent":28,"aiSummary":29,"trendingCount":16,"starSnapshotCount":16,"syncStatus":14,"lastSyncTime":30,"discoverSource":31},78113,"kata","kenn-io\u002Fkata","kenn-io","Local-first issue tracking for AI-assisted software work, with an agent-friendly CLI and human-facing TUI","",null,"Go",249,16,2,12,0,7,13,36,21,3.69,"MIT License",false,"main",true,[],"2026-06-12 02:03:46","# kata カタ\n\nLocal-first issue tracking for humans and coding agents.\n\nkata gives agents a structured place to record tasks, decisions, links,\ncomments, and state changes without turning GitHub Issues, markdown plans, or\nchat transcripts into the source of truth.\n\nThe CLI is built for agents and automation: stable commands, JSON output, and\npredictable failure modes. The TUI is built for people: browse, triage, edit,\nand supervise agent-written work without reading raw JSON. Both talk to the\nsame local daemon and SQLite database.\n\nStatus: early public preview. The CLI, daemon, and TUI are usable, but command\ncontracts and UI details may still change before a stable release.\n\n## Quick Start\n\n```sh\ngo install go.kenn.io\u002Fkata\u002Fcmd\u002Fkata@latest   # or see Install for other options\n\ncd your-repo\nkata init                                         # bind this workspace to a kata project\nkata create \"fix login race\"                      # returns the issue's short_id, e.g. abc4\nkata list                                         # list open issues\nkata show abc4                                    # inspect by short_id\nkata close abc4 --done --message \"Fixed; tests green.\" --commit \u003Csha>\nkata tui                                          # browse and triage interactively\n```\n\nSee [Install](#install) for `go install`, build-from-source, and Windows\ninstructions; see [Working with kata](#working-with-kata) for a longer\nwalkthrough.\n\n## What kata does today\n\nWhat you can do:\n\n- Track issues separately per project, with short IDs derived from each\n  issue's ULID (`kata#abc4`).\n- Create, list, edit, close, reopen, comment, label, assign, and link issues.\n- Search, idempotent-create, soft-delete, restore, and irreversibly purge.\n- Browse and triage in a TUI (`kata tui`) over the same data.\n- Stream state changes as durable events for polling, live tailing, hooks, and\n  TUI updates.\n\nHow it's built:\n\n- Workspace-to-project binding lives in `.kata.toml`, falling back to a git\n  remote URL when no binding file exists.\n- Data lives locally in SQLite under `KATA_HOME` behind a long-running daemon.\n- Issues have stable ULID `uid` values; `short_id` (the lowercased last 4+\n  chars of the ULID) is the display label, qualified as `kata#abc4` across\n  projects.\n- `kata export` and `kata import` provide a git-friendly JSONL backup and\n  schema cutover path.\n- Successful commands emit JSON for reliable parsing by agents and scripts.\n\n## Goals\n\nThree priorities:\n\n- Agent ergonomics: stable commands, JSON-first workflows, explicit workspace\n  binding, search-before-create, idempotency keys, and predictable exit codes.\n- Human oversight: a TUI that helps people browse, triage, edit, and supervise\n  agent activity without reading raw JSON.\n- Auditability: append-only comments, event history, actor attribution, and\n  explicit destructive operations.\n\nLonger term, kata is intended to support a shared server mode for teams, CI,\nand multiple agents. That mode should be a real authenticated deployment, not\nthe local daemon exposed on a public interface.\n\n## Why kata, and how is it different from Beads or git-bug?\n\nkata is intentionally small. It is not a project-management suite, a git\nworkflow engine, or an agent worker pool. It is a durable task ledger that\nhumans and agents can both understand.\n\n[Beads](https:\u002F\u002Fgithub.com\u002Fgastownhall\u002Fbeads) is a substantial tool in the\nsame space: a Dolt-powered distributed graph issue tracker for AI agents. Its\ndefault shape is project-local: `bd init` creates a `.beads\u002F` Dolt database\nalongside the code, with native Dolt history, branching, merging, push\u002Fpull,\nand optional server mode for concurrent writers. That does not mean Beads\nrequires git; it also supports git-free workflows.\n\nkata makes a different architectural bet: the issue ledger should be a local\nservice adjacent to workspaces, not a database owned by each repository. A\nrepository that uses kata gets only a small, secret-free `.kata.toml` binding;\nthe canonical state lives in `KATA_HOME` behind a daemon API. That keeps task\nstate out of code history while still giving agents a structured coordination\nlayer and giving humans a TUI over the same event stream.\n\nIt also has a different complexity budget. Beads is a large, capable system\nwith distributed database semantics, merge behavior, federation, MCP\nintegration, and agent workflow machinery. kata is deliberately smaller: one\ndaemon, one local store, one HTTP API, one TUI, and a narrow issue model that\nshould stay easy to understand, operate, and teach to agents.\n\n[git-bug](https:\u002F\u002Fgithub.com\u002Fgit-bug\u002Fgit-bug) takes the most git-native\napproach of the three: it stores issues, comments, and identities as git\nobjects under custom refs in the repository itself, and distributes them\nthrough ordinary `git push` \u002F `git pull`. Every clone carries the full issue\nhistory offline, and bridges sync with GitHub, GitLab, and Jira. kata sits at\nthe other end of that spectrum — issue state lives outside git entirely, so\nthe workspace stays clean, non-git workspaces work identically, and issue\nhistory is not interleaved with code history. The trade-off is that kata\ncannot piggyback on git remotes for sharing; that is what the future\nauthenticated server is for.\n\n| Design choice | Beads | kata |\n|---|---|---|\n| Storage boundary | Project-local `.beads\u002F` Dolt database by default | User-local `KATA_HOME` SQLite database behind a daemon |\n| Repository footprint | Owns issue state near the repo by default; can sync via Dolt remotes | Repo stores only `.kata.toml` project binding |\n| Collaboration model | Dolt push\u002Fpull, Dolt server mode, federation, MCP tooling | Local daemon today; future authenticated shared server |\n| IDs | Hash-based IDs by default; counter IDs optional | Short IDs derived from each issue's ULID (`kata#abc4`) |\n| Workflow shape | Rich graph tasks, priorities, claiming, messages, dependencies | Deliberately small issue ledger: status, comments, labels, owner, links, events |\n| Git relationship | Git integration is optional but first-class; commit conventions and doctor checks can connect code history to issues | Git can help identify workspaces; kata does not infer issue state from commits |\n\nAll three approaches are useful. Beads is strongest when you want\ndistributed, database-versioned task memory that can travel with a project and\nmerge across branches or agents. git-bug is strongest when you want issue\nstate to live inside the repository's own git history and ride the same\nremotes the code does. kata is aimed at a smaller, API-first issue system\nthat can span workspaces and eventually teams without forcing every user and\nagent to understand the repository, git remote, or distributed database that\ncarries the issue state.\n\n## Install\n\nkata is a single Go binary with no runtime dependencies and builds on macOS,\nLinux, and Windows. Pre-built release binaries are not published yet; install\nfrom source using one of the options below. All paths require **Go 1.26 or\nlater** (\u003Chttps:\u002F\u002Fgo.dev\u002Fdl\u002F>).\n\n### `go install` (any platform)\n\n```sh\ngo install go.kenn.io\u002Fkata\u002Fcmd\u002Fkata@latest\n```\n\nGo places `kata` in `$(go env GOBIN)`, falling back to `$(go env GOPATH)\u002Fbin`\n(typically `~\u002Fgo\u002Fbin` on Unix, `%USERPROFILE%\\go\\bin` on Windows). Add that\ndirectory to your `PATH`.\n\n### Build from a clone (macOS \u002F Linux)\n\n```sh\nmake install                            # installs to ~\u002F.local\u002Fbin\nmake install GOBIN=\u002Fusr\u002Flocal\u002Fbin       # or set GOBIN to install elsewhere\n```\n\nAdd the install directory to your `PATH` if it isn't already. `GOBIN` from the\nenvironment is also honored (`export GOBIN=\u002Fopt\u002Fbin && make install`).\n\n### Build from a clone (Windows)\n\nPowerShell or cmd.exe:\n\n```powershell\ngo build -o kata.exe .\u002Fcmd\u002Fkata\n# Move kata.exe to a directory on your PATH, e.g. %USERPROFILE%\\.local\\bin\n```\n\nThe `go install` command above also works on Windows and is usually simpler.\n\n### Development\n\n```sh\nmake test          # run the test suite\nmake lint          # run golangci-lint\n```\n\n## Working with kata\n\nInitialize kata in a workspace:\n\n```sh\nkata init\n```\n\n`kata init` creates or resolves the project and writes `.kata.toml` when\nneeded. In a git workspace, the default project name is derived from the\nremote URL. For a non-git workspace or an explicit shared project name:\n\n```sh\nkata init --project product\n```\n\nCreate and inspect issues:\n\n```sh\nkata create \"fix login race\" --body \"Safari can double-submit the callback.\"\nkata list\n# Each issue prints its short_id (e.g. abc4); use it for follow-up commands.\nkata show abc4\nkata comment abc4 --body \"Reproduced on macOS.\"\nkata close abc4 --done --message \"Fixed; verified tests pass.\" --commit \u003Csha>\n```\n\nOpen the TUI for human triage:\n\n```sh\nkata tui\n```\n\nPress `?` inside the TUI for keybindings.\n\nUse `--workspace \u003Cpath>` when running from outside the project directory:\n\n```sh\nkata --workspace ~\u002Fcode\u002Fproduct list --status all\n```\n\nSet the actor for a session:\n\n```sh\nexport KATA_AUTHOR=codex-wesm-laptop\nkata whoami\n```\n\nActor precedence is `--as` > `KATA_AUTHOR` > `git config user.name` >\n`anonymous`.\n\n## Core Commands\n\nCommon issue commands:\n\n```sh\nkata create \u003Ctitle> [--body TEXT | --body-file PATH | --body-stdin]\n                  [--label LABEL] [--owner NAME] [--priority 0..4]\n                  [--parent \u003Cref>] [--blocks \u003Cref>] [--blocked-by \u003Cref>]\n                  [--related \u003Cref>] [--idempotency-key KEY] [--force-new]\nkata list [--status open|closed|all] [--limit N]\nkata show \u003Cissue-ref>\nkata edit \u003Cissue-ref> [--title TEXT] [--body TEXT] [--owner NAME]\n                  [--priority 0..4 | --priority -]\n                  [--parent \u003Cref>] [--blocks \u003Cref>] [--blocked-by \u003Cref>] [--related \u003Cref>]\n                  [--remove-parent \u003Cref>] [--remove-blocks \u003Cref>]\n                  [--remove-blocked-by \u003Cref>] [--remove-related \u003Cref>]\n                  [--comment TEXT]\nkata comment \u003Cref> [--body TEXT | --body-file PATH | --body-stdin]\nkata close \u003Cref> --done --message \u003Ctext> [--commit|--pr|--test|--reviewed|--evidence] [--comment TEXT]\nkata close \u003Cref> [--wontfix|--duplicate-of \u003Cref>|--superseded-by \u003Cref>|--audit-no-change] [--comment TEXT]\nkata reopen \u003Cref> [--comment TEXT]\n```\n\n`--comment TEXT` is available on `close`, `reopen`, `edit`, `assign`,\n`unassign`, and `label add`\u002F`rm`. The mutation lands first; the comment is\nappended in a follow-up call. If the comment call fails, the error names\nthe issue so you can retry with `kata comment \u003Cref> --body ...`.\n\nRefs accept a bare short_id (`abc4`), a qualified short_id (`kata#abc4`), or\na full 26-char ULID. The relationship flags on `create`\u002F`edit` are\ndocumented in detail in \"Relationships ride on `kata create` and `kata edit`\"\nbelow.\n\nClosing issues:\n\n```sh\nkata close abc4 --done --message \"\u003Cwhat changed and how it was verified>\" \\\n                --commit \u003Csha>\nkata close abc4 --duplicate-of d4ex  --message \"\u003Cshort pointer>\"\nkata close abc4 --superseded-by d4ex --message \"\u003Cshort pointer>\"\nkata close abc4 --wontfix --message \"\u003C>=60 chars of rationale>\"\nkata close abc4 --audit-no-change \\\n                --message \"\u003Cscope + verification of no-change conclusion>\" \\\n                --evidence \"no-change-audit:\u003Cshort rationale>\" \\\n                --reviewed \u003Cpath\u002Fto\u002Ffile>\n```\n\nClosing an issue asserts that the work is complete. Close each issue\nas soon as its work is verified — not at the end of a batch. Use the\n`needs-review` label and a comment when the work is incomplete instead.\nThe daemon refuses these structurally dangerous patterns:\n\n- closing a parent while its children remain open\n- closing >3 siblings under the same parent within 5 minutes\n- closing two siblings of the same parent with the same close message\n  (within 30 minutes, for `done`\u002F`audit-no-change`)\n\nThe sibling-burst and repeated-message throttles can be disabled\ndaemon-wide via `[close.throttle] enabled = false` in\n`\u003CKATA_HOME>\u002Fconfig.toml`; the parent-completeness refusal and the\nsubstance\u002Fevidence checks on `--message`\u002F`--evidence` always run.\n\nThe TUI close path (`x` in `kata tui`) bypasses the substance and\nevidence checks — interactive humans close with a single keystroke.\nStructural guards still apply.\n\n`kata audit closes` lists close events with filters; specific lazy\ncloses can be undone individually with `kata reopen \u003Cref>`.\n\nLabels, ownership, and relationships:\n\n```sh\nkata label add \u003Cref> \u003Clabel> [--comment TEXT]\nkata label rm \u003Cref> \u003Clabel> [--comment TEXT]\nkata labels\nkata assign \u003Cref> \u003Cowner> [--comment TEXT]\nkata unassign \u003Cref> [--comment TEXT]\n```\n\nRelationships ride on `kata create` and `kata edit` as repeatable flags,\nall framed from the operating issue's POV:\n\n```sh\n# Add (work on create + edit)\nkata create \"...\" --parent \u003Cref> --blocks \u003Cref> --blocked-by \u003Cref> --related \u003Cref>\nkata edit   \u003Cref> --parent \u003Cref> --blocks \u003Cref> --blocked-by \u003Cref> --related \u003Cref>\n\n# Remove (edit only)\nkata edit \u003Cref> --remove-parent \u003Cref>        # strict: must equal current parent\nkata edit \u003Cref> --remove-blocks \u003Cref>        # idempotent\nkata edit \u003Cref> --remove-blocked-by \u003Cref>    # idempotent\nkata edit \u003Cref> --remove-related \u003Cref>       # idempotent\n```\n\n`--parent` is at-most-one and replaces any existing parent on `edit`.\nThe other flags are repeatable. `--remove-parent \u003Cref>` is strict: it fails\nloudly if the current parent is unset or different from `\u003Cref>` (an\noptimistic-concurrency check against agents acting on stale state). All\nmutations in a single `edit` call apply atomically.\n\nEvery `\u003Cref>` above accepts a bare short_id (`abc4`), a qualified\nshort_id (`kata#abc4`), or a 26-char ULID. Legacy numeric `#N` refs\nno longer resolve.\n\nSearch, readiness, events, and project inspection:\n\n```sh\nkata search \u003Cquery> [--limit N] [--include-deleted]\nkata ready [--limit N]\nkata events [--after N] [--limit N]\nkata events --tail [--last-event-id N]\nkata digest --since 24h [--until ...] [--project-id N | --all-projects]\n            [--actor NAME ...]\nkata projects list\nkata projects show \u003Cproject>\nkata projects rename \u003Cproject> \u003Cname>\nkata projects merge \u003Csource> \u003Ctarget> [--rename-target NAME]\nkata export [--project NAME] [--output PATH]\nkata import --input PATH --target PATH [--force]\n```\n\n`kata digest` summarizes activity over a time window. It groups events by\nactor and lists per-issue actions (created, commented:N, closed:done,\nlabeled:bug, unblocks:abc4, ...) so you can see at a glance what each agent\nor person did overnight. `--since` accepts a duration (`24h`, `7d`) or an\nRFC3339 timestamp; `--until` defaults to now. The default scope is the\ncurrent workspace's project; pass `--all-projects` for a cross-project\ndigest, or `--project-id N` for an explicit one. `--actor` is repeatable to\nlimit the report to one or more actors.\n\nDestructive operations are explicit:\n\n```sh\nkata delete \u003Cref> --force --confirm \"DELETE \u003Cqualified-id>\"\nkata restore \u003Cref>\nkata purge \u003Cref> --force --confirm \"PURGE \u003Cqualified-id>\"\n```\n\nThe confirmation string is the issue's qualified short_id, e.g.\n`DELETE kata#abc4`. `delete` is reversible. `purge` is not.\n\nDaemon, diagnostics, and agent instructions:\n\n```sh\nkata daemon status\nkata daemon stop\nkata daemon reload\nkata daemon logs --hooks [--tail]\nkata health\nkata whoami\nkata quickstart\nkata tui\n```\n\n## Agent Quickstart\n\nThis is the short version to give any coding agent, regardless of whether that\nagent supports skills, memories, or custom instructions. It is also shipped\nwith the CLI:\n\n```sh\nkata quickstart\nkata agent-instructions   # alias\n```\n\nSession setup:\n\n- Run from the project workspace, or pass `--workspace \u003Cpath>`.\n- Set `KATA_AUTHOR` once at session start.\n- Prefer `--json` for reads and writes when you need to parse output.\n\nPer-task guidelines:\n\n- Never create a project implicitly. If the workspace is not initialized,\n  report that `kata init` is needed.\n- Search before creating; pass an idempotency key when you do create.\n- Prefer updating existing issues over opening duplicates.\n- Close only when the work is actually complete.\n- Do not run `delete` or `purge` unless the user explicitly asks for that\n  exact destructive action and issue ref.\n\nUse relationships deliberately. The link types mean:\n\n| Type | Meaning |\n|---|---|\n| `parent` | This issue is part of a larger issue. |\n| `blocks` | The first issue must be resolved before the second can proceed. |\n| `related` | Useful context, but not ordering. |\n\nExample session (using `abc4` as a placeholder for the issue's actual\nshort_id, which `kata create --json` and `kata search --json` both\nreturn):\n\n```sh\n# Search before creating\nkata search \"login race\" --json\n\n# If no existing issue fits, create with an idempotency key\nkata create \"fix login race\" \\\n  --body \"Observed double-submit in Safari callback.\" \\\n  --idempotency-key \"login-race-2026-05-02\" \\\n  --json\n\n# Update an existing issue rather than open a duplicate\nkata show abc4 --json\nkata comment abc4 --body \"Found another reproduction path.\" --json\nkata label add abc4 safari --json\nkata edit abc4 --blocks d4ex --json\n\n# Close when done\nkata close abc4 --done --message \"Fixed; verified tests pass.\" --commit \u003Csha> --json\n```\n\nFor long-running agents, poll events and remember the returned cursor; resume\nfrom it on the next call. If a response says `reset_required`, discard cached\nkata state and resume from the reset cursor.\n\n```sh\nkata events --after 0 --limit 100 --json\n```\n\nFor live streams, `--tail` emits newline-delimited JSON:\n\n```sh\nkata events --tail\n```\n\n## Sharing and multi-user workflows\n\nToday kata is local-first:\n\n- one local daemon;\n- one local SQLite database;\n- no authentication;\n- trusted same-user CLI and TUI clients.\n\nMultiple checkouts or repositories can share one kata project when they use\nthe same `.kata.toml` project name and run `kata init` in each checkout.\nThat shares the issue ledger — short_ids, labels, links, and events —\nacross those workspaces in the same local database.\n\nIf a repository rename accidentally creates a second project, merge the old\nsource into the surviving target, for example:\n\n```sh\nkata projects merge old-repo new-repo --rename-target new-repo\n```\n\nFuture shared mode should be a distinct deployment:\n\n- a shared kata server reachable over HTTPS, SSH tunnel, or a private network;\n- authenticated users and service tokens;\n- server-derived actor identity;\n- server-side hooks and backups;\n- the same project, issue, event, and relationship model.\n\nThe local daemon should not be exposed directly to a LAN or public network.\n\n### Remote daemon (opt-in, no auth)\n\nA kata daemon can serve clients on other hosts over a private network\n(loopback, RFC1918, CGNAT, link-local, ULA — public addresses are rejected):\n\n```sh\nkata daemon start --listen 100.64.0.5:7777\n```\n\nOr set the address persistently in `\u003CKATA_HOME>\u002Fconfig.toml`:\n\n```toml\nlisten = \"100.64.0.5:7777\"\n```\n\nThe CLI flag wins over the config file when both are present. Auto-started\ndaemons (the on-demand path triggered by `kata create`, `kata list`, etc.)\nalso pick up the config-file value, so on a host where you want every kata\ninvocation to use the same TCP address you only have to set it once.\n\nRun the daemon under launchd \u002F systemd \u002F nohup on the host that holds the\nSQLite database. Clients on other hosts target it by setting `KATA_SERVER`:\n\n```sh\nexport KATA_SERVER=http:\u002F\u002F100.64.0.5:7777\nkata list\n```\n\nOr by writing a per-developer, gitignored `.kata.local.toml` next to\n`.kata.toml`:\n\n```toml\nversion = 1\n\n[server]\nurl = \"http:\u002F\u002F100.64.0.5:7777\"\n```\n\n`kata init` adds `.kata.local.toml` to `.gitignore` automatically.\n`KATA_SERVER` wins over the file when both are set.\n\nThere is no authentication in this mode — network ACLs (firewall, VPN,\ntailnet) are the access boundary. Default behavior (no flag, no env, no local\nfile) is unchanged: a local Unix-socket daemon is auto-started on demand.\n\n## Backup and restore\n\n`kata export` writes the local database as JSONL; `kata import` rebuilds\na database from that file. Together they cover backups, machine moves,\nand migrations between schema versions.\n\nBack up the local database:\n\n```sh\nkata daemon stop\nkata export --output backups\u002Fkata-$(date -u +%Y%m%d).jsonl\nkata daemon start\n```\n\nWithout `--output`, `kata export` writes a timestamped file\n(`kata-export-YYYYMMDDTHHMMSSZ.jsonl`) in the current directory. Export\nrefuses to run while a daemon holds the database open; pass\n`--allow-running-daemon` to take a best-effort snapshot on a host where\nyou cannot stop the daemon.\n\nRestore into a fresh database file:\n\n```sh\nkata import --input backups\u002Fkata-20260512.jsonl --target ~\u002F.kata\u002Frestored.db\n```\n\n`kata import` always creates a brand-new database. The target must not\nexist; `--force` deletes it first. There is no merge mode today — see\n\"Exporting a single project\" below for what that means in practice. To\nactivate a restored database, point `KATA_DB` at it (or move it into\n`KATA_HOME` as `kata.db`) and restart the daemon.\n\nJSONL is plain text and diffs cleanly, so a simple versioned-backup\nsetup is to keep snapshots in a git repository:\n\n```sh\nmkdir -p ~\u002Fkata-backups && cd ~\u002Fkata-backups\ngit init -q\nkata daemon stop\nkata export --output snapshot.jsonl\nkata daemon start\ngit add snapshot.jsonl\ngit commit -q -m \"snapshot $(date -u +%FT%TZ)\"\n```\n\nRun that on a schedule (cron, launchd, systemd timer) and you have\npoint-in-time recovery without operating a backup service. Push the repo\nto a private remote if you want off-host storage.\n\n### Exporting a single project\n\nUse the global `--project NAME` flag to scope an export to one project:\n\n```sh\nkata daemon stop\nkata --project myproj export --output backups\u002Fmyproj.jsonl\nkata daemon start\n```\n\n`--project-id N` works too if you prefer the numeric id from\n`kata projects list --json`.\n\nA single-project export round-trips into a **fresh** database that\ncontains only that project:\n\n```sh\nkata import --input backups\u002Fmyproj.jsonl --target \u002Ftmp\u002Fmyproj-only.db\n```\n\nThis is useful for archiving one project before deleting it, handing a\nproject's full history to a collaborator who'll set up a fresh kata\ninstall, or moving a project to a different host.\n\nWhat does **not** work today:\n\n- Importing a per-project snapshot **into an existing populated\n  database**. `kata import` always wipes the target first; there is no\n  merge or \"add this project\" mode. So you cannot use per-project files\n  as building blocks to stitch a multi-project database together.\n- Re-importing a snapshot on top of itself to refresh it incrementally.\n\nFor multi-project backups, take the full-database snapshot shown above\ninstead of one file per project. A per-project merge import (apply one\nproject's snapshot to an existing database without disturbing other\nprojects) is planned — tracked in\n[kenn-io\u002Fkata#42](https:\u002F\u002Fgithub.com\u002Fkenn-io\u002Fkata\u002Fissues\u002F42).\n\n## Configuration\n\nUseful environment variables:\n\n- `KATA_HOME`: data directory. Defaults to `~\u002F.kata`.\n- `KATA_DB`: explicit SQLite database path.\n- `KATA_AUTHOR`: default actor for mutations.\n- `KATA_HTTP_TIMEOUT`: per-request CLI timeout for non-streaming daemon calls\n  (any `time.ParseDuration` string, e.g. `30s`, `2m`). Defaults to `5s`. Bump\n  this for bulk imports where create requests can exceed the default.\n- `KATA_SERVER`: opt-in remote daemon URL (e.g. `http:\u002F\u002F100.64.0.5:7777`). When\n  set, the client skips local discovery and auto-start entirely. See \"Remote\n  daemon\" below.\n- `XDG_RUNTIME_DIR`: runtime socket parent on Unix.\n\nThe workspace binding file is intentionally secret-free:\n\n```toml\nversion = 1\n\n[project]\nname = \"product\"\n```\n\nCommit `.kata.toml` when multiple agents, clones, or worktrees should resolve\nto the same kata project.\n","kata 是一个面向本地优先的问题跟踪工具，旨在为人类和编码代理提供服务。它通过命令行界面（CLI）和文本用户界面（TUI）来记录任务、决策、链接、评论和状态变更，而无需依赖 GitHub Issues 或聊天记录作为事实来源。项目使用 Go 语言开发，数据存储在 SQLite 数据库中，并通过一个长期运行的守护进程进行管理。CLI 专为自动化设计，支持 JSON 输出和稳定的命令；TUI 则为用户提供了一个交互式的环境，以便浏览、分类和编辑问题。适用于需要对软件开发过程中的问题进行精细管理和跟踪的场景，特别是当团队希望将部分工作自动化或与 AI 代理协作时。","2026-06-11 03:56:28","CREATED_QUERY"]