pyworklog 0.8.0__tar.gz → 0.9.0__tar.gz

pyworklog-0.9.0/.dockerignore

@@ -0,0 +1,11 @@
+.venv
+.git
+__pycache__
+*.pyc
+.pytest_cache
+.coverage
+htmlcov
+*.egg-info
+build
+dist
+*.bak

{pyworklog-0.8.0 → pyworklog-0.9.0}/.github/workflows/test.yml

@@ -44,7 +44,7 @@ jobs:
           export WORKLOG_DB=$(mktemp -d)/worklog.db
           uv run wl init
           uv run wl --version
-          uv run wl add "ci smoke task" -k task -p A --sched today
+          uv run wl add "ci smoke task" -p A --sched today
           uv run wl log 1 "hello from CI"
           uv run wl recap "ci smoke recap"   # creates today's day skeleton so the overview renders
           uv run wl show 1

{pyworklog-0.8.0 → pyworklog-0.9.0}/AGENTS.md

@@ -41,7 +41,7 @@ wl --db /tmp/scratch.db add "..."
 
 **Single-package CLI.** `src/worklog/` holds everything: `cli.py` (~5000 lines) is the implementation, `migrations/NNNN_*.sql` is the schema (one initial file at v0.3.0, more added per schema change), `__init__.py` re-exports `__version__`. No further submodule split inside `cli.py` — kept this way intentionally; reconsider only when a feature truly cannot be co-located.
 
-**One polymorphic `node` table.** The `kind` column distinguishes `lifetime / decade / year / quarter / month / week / day / area / project / task / meetlog / habit / signal`; `parent_id` self-reference builds the tree. Two parallel sub-trees hang under `lifetime`: a **responsibility line** (`area → project → task`, PARA-style) and a **time line** (`year → quarter → month → week → day`, time skeleton + each level's `goal` / the day's `summary` reserved-tag logs). Day/week/month views are **log-driven** (`logged_at` + ancestor chain + tags), not via fixed parent-of-task — moving projects between areas does not break per-day views. Tables: `node / tag / log / prop / link / sched / date_meta` + recursive CTE view `v_node_path`.
+**One polymorphic `node` table.** Classification is the orthogonal `type.*` prop namespace (`type.para` area/project/task · `type.date` lifetime…day · `type.habit` · `type.meetlog`); `parent_id` self-reference builds the tree. Two parallel sub-trees hang under `lifetime`: a **responsibility line** (`area → project → task`, PARA-style) and a **time line** (`year → quarter → month → week → day`, time skeleton + each level's `goal` / the day's `summary` reserved-tag logs). Day/week/month views are **log-driven** (`logged_at` + ancestor chain + tags), not via fixed parent-of-task — moving projects between areas does not break per-day views. Tables: `node / tag / log / prop / link / sched / date_meta` + recursive CTE view `v_node_path`.
 
 **Path resolution.** Priority: `wl --db PATH` flag → `$WORKLOG_DB` env → `$XDG_DATA_HOME/worklog/worklog.db` (default `~/.local/share/worklog/worklog.db`). Config is `$XDG_CONFIG_HOME/worklog/aliases.ini`. `_resolve_db_path(args)` is the only resolver; `cmd_config` displays which branch fired.
 

{pyworklog-0.8.0 → pyworklog-0.9.0}/CHANGELOG.md

@@ -6,6 +6,38 @@ The autogenerated `Commits since vX.Y.Z` block on each GitHub Release captures e
 
 ## [Unreleased]
 
+## [0.9.0] - 2026-06-18
+
+### Breaking
+- **`kind` retired — classification is now the orthogonal `type.*` prop namespace** (`type.para` area/project/task · `type.date` level · `type.habit` · `type.meetlog`); a node can hold several at once. Migration **0011** backfills + verifies a lossless round-trip + drops the `node.kind` column, auto-run on first use.
+- **`-k/--kind` gone from `wl add` / `wl node edit`** — set the role with `--para area|project` (bare = task), other types with `--prop type.<x>` (e.g. `type.habit`, `type.date=day`); reclassify later via `wl set type.<x>`.
+- **`--kind` filter gone** from `ls`/`tree`/`day`/`logs`/`agenda`/`find` — filter by `--para area|project|task` or `--prop type.<x>`; `wl find` gains `--para`, and `wl checkin --all-types` (renamed from `--all-kinds`) still covers habit + task + meetlog.
+- **JSON drops the collapsed `kind` for an orthogonal `type` object** — every `-o json` (`show`/`ls`/`tree`/`day`/`projects`/`summary`) carries `type` (the `type.*` facets, prefix stripped, e.g. `{"para":"project","habit":true}`; bare task → `{}`).
+- **`wl kinds` → `wl types`** — lists the raw `type.*`/`date.*` props grouped by key (no collapse); a node shows under every facet it carries.
+- **`wl import` / `wl apply` drop the `kind` field/token** — classify via the real props: JSON `{"props": {"type.para": "project"}}` (or `type.date`/`type.habit`/`type.meetlog`; bare = task), or an `@prop type.para=project` sub-line (no `[project]` token on the node line).
+
+### Added
+- **`wl add --para {area,project,task}`** — name a responsibility role at creation (writes the `type.para` prop, same flag as `wl ls --para`); `wl add --prop K=V` sets props at creation. Every new node now also populates the `type.*` namespace (the successor to `kind`).
+- **`wl find --para {area,project,task}`** — filter full-text search results by responsibility role.
+- **`wl log show #L282`** — print one log's full, untruncated body (lists truncate to one line).
+- **`wl retag #L282 <tag>`** — change a log's tag (`note`/`-`/empty clears to a plain note).
+- **`wl ls --root <id>`** — flat list of a whole subtree (all descendants), vs `--parent` (one level).
+- **`wl metric ls --tag X`** with no node — find a metric tag across every node.
+- **`wl help body`** — node.body (long description) vs log.body (per-entry text).
+- **`wl recap --diff`** — list the notes logged after the recap (excludes checkin/metric noise).
+- **`wl reindex --incremental`** — embed only nodes new/changed since the last index + drop deleted ones (cheap day-to-day top-up vs a full rebuild).
+- **Background auto-reindex** — after any write, the index is incrementally updated so `wl query` stays fresh without a manual reindex. On by default; disable with `[index] auto_reindex = false` (config.ini) or `WORKLOG_AUTO_REINDEX=0`.
+
+### Changed
+- **`wl relation <id> <ids…>` defaults to `related`** (omit the type word); split-from/into still explicit.
+
+### Fixed
+- **`wl show` multi-line `body`** — continuation lines now indent under the value, not column 0.
+- **`wl query` Chinese recall** — a node matching every query term now leads; vector list capped before RRF so its tail can't bury exact hits.
+- **`wl query` highlight** — highlights each segmented term, so a non-contiguous match (微信…导出) still lights up.
+- **`wl query` stale-index hint** — warns on stderr `⚠ N node(s) not indexed — run wl reindex`.
+- **Silence jieba's `SyntaxWarning`** (invalid escape sequences, flagged by Python 3.12+) at import — jieba's bug, was noise on stderr.
+
 ## [0.8.0] - 2026-06-14
 
 ### Breaking
@@ -21,6 +53,7 @@ The autogenerated `Commits since vX.Y.Z` block on each GitHub Release captures e
 
 ### Added
 - **`wl query` / `wl reindex` — hybrid (semantic + keyword) search.** `wl reindex` embeds each node's chunks (head + per-log) via an OpenAI-compatible server (default local Ollama) into a sidecar LanceDB; `wl query` RRF-fuses best-chunk cosine with a jieba-segmented, `[synonyms]`-expanded keyword match — paraphrases *and* exact names both surface — showing the matched passage, term-highlighted (`--limit`/`--threshold`/`-o json`). Configurable backend + `query_prompt` template (`wl config`). Pluggable, graceful degradation: the `semantic` extra (LanceDB + jieba) is the fast path, but absent it `wl query`/`reindex` auto-fall-back to a pure-Python SQLite vector store + `\w+` segmentation — so semantic search works on every Python 3.9–3.14 / platform with no required extras (slower where there's no LanceDB wheel: Intel macOS, musl, …).
+- **`wl config init`** — writes a commented `config.ini` template (embedding backend / `query_prompt` / `api_key`); never overwrites an existing file.
 - **`wl help` is a short overview; `wl help --all` lists every topic.**
 - **Structured goal targets — `wl goal "..." <ids>`** records the task nodes a goal targets (order = priority) as queryable `goal` metrics; shown as `[done/total]` in `wl day`/`wl goal`.
 - **`wl show` timeline marks a log's tag** — `✎ goal`/`✎ summary`/`✎ <custom>` vs plain `✎ log`.
@@ -205,7 +238,9 @@ Initial open-source release of `worklog-cli` (`wl`).
 - **Vault integration** — `wl link` ↔ Obsidian docs (`[[doc]]`).
 - Bilingual docs (EN + 中文); MIT License.
 
-[Unreleased]: https://github.com/xyb/worklog/compare/v0.7.0...HEAD
+[Unreleased]: https://github.com/xyb/worklog/compare/v0.9.0...HEAD
+[0.9.0]: https://github.com/xyb/worklog/compare/v0.8.0...v0.9.0
+[0.8.0]: https://github.com/xyb/worklog/compare/v0.7.0...v0.8.0
 [0.7.0]: https://github.com/xyb/worklog/compare/v0.6.0...v0.7.0
 [0.6.0]: https://github.com/xyb/worklog/compare/v0.5.0...v0.6.0
 [0.5.0]: https://github.com/xyb/worklog/compare/v0.4.0...v0.5.0

{pyworklog-0.8.0 → pyworklog-0.9.0}/DESIGN.md

@@ -20,7 +20,7 @@ worklog's whole job is to **structure** the work log so information can be preci
 
 The tool must be simple enough to **use without reading the manual**, for both humans and AI. AI faces a plain-text interface; complexity makes it err.
 
-- Keep the **kinds of records hung under a node** restrained (fewer is better): each extra kind is one more concept to remember and one more block to render — heavier, harder to grasp.
+- Keep the **types of records hung under a node** restrained (fewer is better): each extra type is one more concept to remember and one more block to render — heavier, harder to grasp.
 - Self-check any new design with three questions: (1) how many new concepts does it add? (2) does using it force AI/humans to make a choice ("A or B?")? (3) can you guess it right without docs? If any answer is poor, simplify further.
 - When G1 and G2 conflict, find the "structured AND fewest-concepts" answer — don't pile on new tables / fields / commands just to be structured.
 
@@ -38,7 +38,7 @@ worklog deliberately stays **dependency-light and low-abstraction**: runtime is
 - Verb first: `wl <verb> [args] [--flags]`
 - Subcommand names: lowercase single words — `add` / `done` / `tree` / `projects` / `changes` / `summary` / `focus` …
 - Commands operating on a single node take `id` (int) as the first positional arg: `wl show 42` / `wl done 42` / `wl log 42 "..."`
-- Long flags `--xxx`; short flags only for the highest-frequency ones (`-k` kind / `-p` priority / `-t` tag)
+- Long flags `--xxx`; short flags only for the highest-frequency ones (`-p` priority / `-t` tag)
 - Missing node: always `sys.exit(f"✗ ... #{id} not found")` with non-zero exit code
 
 ### 1.1 Command taxonomy (primitive CRUD / composite helper / view)
@@ -134,7 +134,7 @@ metric + done), and the compound `add --log/--done/--at/--link/--sched/--metric`
 **C. View** — read-only cross-entity rendering, no single-row CRUD: `ls` / `tree` /
 `day` / `agenda` / `projects` / `changes` / `summary` / `focus` / `ancestors` /
 `descendants` / `find` / `logs` / `show`. These share the unified filter (§ shared
-`--tag/--kind/--status/--priority/--prop`), time-window (§8) and `--by` (§9) conventions. `--prop`
+`--tag/--para/--status/--priority/--prop`), time-window (§8) and `--by` (§9) conventions. `--prop`
 is repeatable (AND) and honors the namespace convention — exact `K=V` (matches a member of a
 comma-joined value), key existence `K`, and `GROUP.` / `GROUP.*` prefix (see §2 / `wl help prop`).
 
@@ -161,14 +161,14 @@ two ways to invoke the same operation never drift in discoverability, only in ke
 
 ## 2. Data model (`src/worklog/migrations/`)
 
-A single `node` table carries everything; the `kind` field discriminates type; `parent_id` self-reference builds the tree. The schema is delivered as numbered SQL migrations under `src/worklog/migrations/NNNN_*.sql`; `PRAGMA user_version` tracks the highest applied migration. `ensure_db()` auto-applies pending migrations on every command; `wl migrate` is the explicit form. Before applying, `run_migrations` snapshots an **existing** DB (`user_version` > 0) to a same-dir `<db>.pre-v<N>.bak` so a bad migration is recoverable (a fresh init at v0 has no data to protect, so it's skipped); a backup that can't be written aborts the migration rather than risking unrecoverable loss. See `src/worklog/migrations/0001_initial_schema.sql` for the initial layout and `README.md` for the high-level picture.
+A single `node` table carries everything; classification is the orthogonal `type.*` prop namespace (no dedicated column); `parent_id` self-reference builds the tree. The schema is delivered as numbered SQL migrations under `src/worklog/migrations/NNNN_*.sql`; `PRAGMA user_version` tracks the highest applied migration. `ensure_db()` auto-applies pending migrations on every command; `wl migrate` is the explicit form. Before applying, `run_migrations` snapshots an **existing** DB (`user_version` > 0) to a same-dir `<db>.pre-v<N>.bak` so a bad migration is recoverable (a fresh init at v0 has no data to protect, so it's skipped); a backup that can't be written aborts the migration rather than risking unrecoverable loss. See `src/worklog/migrations/0001_initial_schema.sql` for the initial layout and `README.md` for the high-level picture.
 
 > **Migration-authoring rule**: the runner wraps each file in one `BEGIN/COMMIT` (so a mid-script failure rolls the whole file back). Migration files must therefore **not** contain their own `BEGIN`/`COMMIT`.
 
-- **kind values**: `lifetime / decade / year / quarter / month / week / day / area / project / task / meetlog / habit / signal` (extensible, but new kinds should have a clear place in tree / projects / summary classification)
-- **status only applies to task / habit / meetlog**; time-hierarchy kinds (year/month/...) and project kind leave status NULL
+- **classification values** (orthogonal `type.*` props, no single column): `type.para` = PARA role `area / project / task`; `type.date` = time level `lifetime / decade / year / quarter / month / week / day`; `type.habit`; `type.meetlog`; custom `type.<x>` (extensible, but a new type should have a clear place in tree / projects / summary classification). A node may hold several at once; a single representative token is derived by `node_type` / `node_type_from_props` (precedence para > date > habit > meetlog > custom > task)
+- **status only applies to task / habit / meetlog**; time-hierarchy / area / project nodes leave status NULL
 - Tables: `node / tag / log / metric / clock / prop / link / sched / date_meta` + derived view `v_node_path`
-- **`node → log → metric` spine** (the log-centric core): a `node` has many `log`s; a `log` (carrying a `tag` — `note`/`goal`/`summary`/`metric`(carrier)/… , NULL = plain note) has 0..N `metric`s. A `metric` is a structured datapoint (`tag` = what it is e.g. `glucose`/`pullups`/`checkin`, or `goal` = a goal log's priority-ordered target node ids; `value_num`/`value_text`/`unit`/`note`/`at`). **`tag` is the uniform classification field across all three** — node (a multi-value label set), log (its role, single-value), metric (its kind, single-value); same word, different scopes, SQL-unambiguous. A metric **must hang off a log** (`metric.log_id` NOT NULL) — so every datapoint has a log carrier; a `CHECK` requires a value (pure markers store `value_num=1`). `metric.node_id` is denormalized for join-free per-node queries (no FK; triggers keep it equal to the carrier log's node). CRUD surface: `wl metric add/ls/edit/rm` (`add` without `--on-log` creates a carrier log; a value-less marker is stored as `value_num=1`); `--metric` on `wl log`/`wl add` and `metrics` in `wl import` attach datapoints inline. Habit "done today" = a `tag=checkin` metric that day (written by `wl tick`/`wl checkin`), not "any log exists".
+- **`node → log → metric` spine** (the log-centric core): a `node` has many `log`s; a `log` (carrying a `tag` — `note`/`goal`/`summary`/`metric`(carrier)/… , NULL = plain note) has 0..N `metric`s. A `metric` is a structured datapoint (`tag` = what it is e.g. `glucose`/`pullups`/`checkin`, or `goal` = a goal log's priority-ordered target node ids; `value_num`/`value_text`/`unit`/`note`/`at`). **`tag` is the uniform classification field across all three** — node (a multi-value label set), log (its role, single-value), metric (its type, single-value); same word, different scopes, SQL-unambiguous. A metric **must hang off a log** (`metric.log_id` NOT NULL) — so every datapoint has a log carrier; a `CHECK` requires a value (pure markers store `value_num=1`). `metric.node_id` is denormalized for join-free per-node queries (no FK; triggers keep it equal to the carrier log's node). CRUD surface: `wl metric add/ls/edit/rm` (`add` without `--on-log` creates a carrier log; a value-less marker is stored as `value_num=1`); `--metric` on `wl log`/`wl add` and `metrics` in `wl import` attach datapoints inline. Habit "done today" = a `tag=checkin` metric that day (written by `wl tick`/`wl checkin`), not "any log exists".
 - **Design rule — keep `log` thin; new per-log data goes on a `metric`, not a new log column.** The `log` table stays a small fixed shape (`node_id`/`logged_at`/`body`/`tag`). When some feature wants to attach structured data to a log event (a measurement, an id, a category, a flag), the answer is a `metric` hanging off that log — never a widened `log` row. A metric is already typed (`tag` + `value_num`/`value_text`/`unit`/`note`/`at`), queryable (`wl metric ls --tag …`), and append-only, so it carries arbitrary per-event fields without bloating every log. Example: `wl agent --record` records a bind as **two metrics on one carrier log** — `agent_session` (`value_text` = full sid) and `agent` (`value_text` = the runtime name — claude / cursor / codex, from `$WL_AGENT` / `--agent`) — not as `log.session_id` / `log.agent` columns. Each value is its own queryable datapoint (`wl metric ls <id> --tag agent_session` / `--tag agent`). This keeps the log body human-readable and the schema stable (G3). The live pointer is the `agent_session.<agent>` prop (the key suffix carries the agent too); session lookups match `key LIKE 'agent_session.%'` since the sid alone is unique. (The metric tag string `agent_session` mirrors the prop namespace; the Python constant is `_SESSION_METRIC_TAG`.)
 - **Decision rule — where does a fact go: `prop` vs `metric` vs `log`?** Sort by *"will I filter / group / aggregate over it across nodes?"* and by *cardinality*:
   - **`prop`** — a **single-value query dimension** (`PRIMARY KEY (node_id, key)` → one value per key, overwrite-in-place). Use it for the few attributes you slice the whole tree by: `owner`, `project`, `linear-id`, or **the one identifying ref a task maps to** (the release it shipped in → `release=v0.7.0`, so "which tasks shipped in v0.7.0" is one `prop` query; the single PR a one-shot task *is*). Props are scarce and high-value — don't flood the key-space with process noise.
@@ -177,15 +177,15 @@ A single `node` table carries everything; the `kind` field discriminates type; `
   - Worked example (commit / PR / release ↔ task): the **many** intermediate commits of a dev task → `log` (add a `commit` **metric** if you want them structured); a task that maps to **one** identifying PR/commit, or its **release** → `prop` (so it's filterable/countable). The dividing question is value-to-query, not "can it physically fit".
   - **Namespaced prop keys (`group.member`)** — a prop key may use a dot to group related single-value props under a shared prefix (`agent_session.claude` / `agent_session.cursor`; external ids per system `ext.linear` / `ext.github`). Each full key is still one single-value prop (`PRIMARY KEY (node_id, key)`); the namespace groups *sibling* keys — it does **not** make a key multi-valued. The convention's payoff is **prefix lookup**: one `key LIKE 'group.%'` finds every member across nodes, so prop-based features (filter / summary / stats) operate on a whole namespace, not just an exact key. **All prop query surfaces must honor it**: exact key (`k=v`), key existence (`k`), and namespace prefix (`group.` / `group.*`). Reserve it for a logical dimension with several named slots; keep flat keys (`owner`, `release`) flat. First user: `wl agent` (the live binding is the `agent_session.<agent>` prop; sid lookups match `key LIKE 'agent_session.%'`).
   - **Task↔task relations are `relation.*` props (`wl relation`)** — derivation / association *across* the tree (this task was split out of / into / relates to that one), distinct from **ancestors** (the parent/child hierarchy). Stored as namespaced props `relation.split_from` / `relation.split_into` / `relation.related`, each a **comma-separated id list** (a relation is naturally many-per-node, so the value is multi-valued — the one place a prop value holds a list rather than a single scalar). `split-from` ↔ `split-into` are inverses; `related` is symmetric. `wl relation` writes **both sides** (so either node's `wl show` displays it) and the resolved view *also* derives the reverse from other nodes' props, so a hand-set one-sided value still reads bidirectionally. `wl show` renders a dedicated `relations:` block (and `-o json` a resolved `relations` object); the raw `relation.*` props are hidden from the generic props block to avoid double display. Why a prop and not a `link`-style table: it rides the existing namespace + `wl ls --prop relation.` query machinery for free (G3) — no new table or join.
-  - **A goal's structured targets are `goal` metrics on the goal log** — a `goal` log (goal/summary are `log` rows with a reserved `tag`) can carry, supplied **explicitly at write time** (`wl goal "ship X" 12 34` / `wl goal set <node> "..." 7 9 3`), the task/project node ids it aims to deliver — stored as one `goal` metric per id on the log (`metric.tag='goal'`, `value_num=node id`, **insertion order = priority**, any count). wl **never parses them from the prose** (text extraction is too fragile); omit them and the goal is plain free text. The metric tag is the bare word `goal` (same as the carrier log's tag) — no per-level suffix, because the carrier log's `node.kind` (day/week/month/year) already says the level. So the plan↔node link is **queryable** off the metric table (`tag='goal'`, `value_num=<id>` = which goals target a node; narrow by `node.kind` for the level) rather than buried in prose, and history-preserving (each goal edit appends a log with its own target snapshot; `_log_goals` reads the latest). Reuses the existing `metric` entity — no new table.
+  - **A goal's structured targets are `goal` metrics on the goal log** — a `goal` log (goal/summary are `log` rows with a reserved `tag`) can carry, supplied **explicitly at write time** (`wl goal "ship X" 12 34` / `wl goal set <node> "..." 7 9 3`), the task/project node ids it aims to deliver — stored as one `goal` metric per id on the log (`metric.tag='goal'`, `value_num=node id`, **insertion order = priority**, any count). wl **never parses them from the prose** (text extraction is too fragile); omit them and the goal is plain free text. The metric tag is the bare word `goal` (same as the carrier log's tag) — no per-level suffix, because the carrier log's node type (day/week/month/year) already says the level. So the plan↔node link is **queryable** off the metric table (`tag='goal'`, `value_num=<id>` = which goals target a node; narrow by node type for the level) rather than buried in prose, and history-preserving (each goal edit appends a log with its own target snapshot; `_log_goals` reads the latest). Reuses the existing `metric` entity — no new table.
 - **Deliberate design — `wl add` / `wl log` stamp the current local time in their success line** (`✓ #1 task '…'  @2026-06-09 20:09`). Intentional, primarily an **AI affordance**: an assistant's sense of "today" drifts to the date its session started and goes stale over a long session, so it mis-dates backfills and reasoning. Echoing the real wall-clock on every content-creating command re-anchors the caller's clock to *now*. (`local_now()`, minute precision.)
-- **Reserved-tag logs are history-preserving**: `goal` (forward, any time level) and `summary` (backward recap) are `log.tag` logs (latest = current; each edit appends), with their own `wl goal set/ls/rm` CRUD group (`--summary` flag targets the summary); also written by bare `wl goal`/`wl recap` (today-auto) and the key-routed `wl set <node> <key>` shortcut. A goal is the **same `goal` tag at every level** — the node's kind (day/week/month/year) is the level; the former week `overview` and month `top5` collapsed into it (migration 0010). (`prop` is back to truly-static single-value attributes — a separate store.) In the `wl day` header the day's goal + recap plus the ancestor week's & month's goal each render with a distinct marker (`_DAY_MARKERS`: 🎯 goal · 📝 recap · 📅 this week · ⭐ this month) through `_header_blockquote`, which prefixes only the FIRST line with `> ` and aligns every continuation (soft-wrap / embedded newline) with plain spaces under the `> ` content column (cleaner than repeating `> `), wrapping by display width like `_node_line`. Each shown goal then lists its structured target nodes below it — numbered, status-marked (`_emit_goal_targets`, shared by `wl day` / `wl goal` / `wl goal ls` so they render identically) — and a ` [done/total]` achievement tag (`_goal_progress`/`_goal_counts`: counts the structured targets' DONE/CANCELED, falling back to prose `#id`/`WL#id` refs when a goal has no structured targets; ✅/🟡/⬜).
+- **Reserved-tag logs are history-preserving**: `goal` (forward, any time level) and `summary` (backward recap) are `log.tag` logs (latest = current; each edit appends), with their own `wl goal set/ls/rm` CRUD group (`--summary` flag targets the summary); also written by bare `wl goal`/`wl recap` (today-auto) and the key-routed `wl set <node> <key>` shortcut. A goal is the **same `goal` tag at every level** — the node's type (day/week/month/year) is the level; the former week `overview` and month `top5` collapsed into it (migration 0010). (`prop` is back to truly-static single-value attributes — a separate store.) In the `wl day` header the day's goal + recap plus the ancestor week's & month's goal each render with a distinct marker (`_DAY_MARKERS`: 🎯 goal · 📝 recap · 📅 this week · ⭐ this month) through `_header_blockquote`, which prefixes only the FIRST line with `> ` and aligns every continuation (soft-wrap / embedded newline) with plain spaces under the `> ` content column (cleaner than repeating `> `), wrapping by display width like `_node_line`. Each shown goal then lists its structured target nodes below it — numbered, status-marked (`_emit_goal_targets`, shared by `wl day` / `wl goal` / `wl goal ls` so they render identically) — and a ` [done/total]` achievement tag (`_goal_progress`/`_goal_counts`: counts the structured targets' DONE/CANCELED, falling back to prose `#id`/`WL#id` refs when a goal has no structured targets; ✅/🟡/⬜).
 - **`clock` is structured time tracking**: `clock(node_id, start_at, end_at, elapsed_sec)`, written by `wl start`/`stop`/`spent`/`wait` — replaces the old `CLOCK_IN`/`CLOCK_OUT` log-body convention. Durations are summed from `elapsed_sec`, not parsed from text.
 - **Two parallel trees, both hung under lifetime**:
   - **Responsibility line**: `lifetime → area → project → task` (PARA model: area is a cross-time responsibility domain, projects belong to areas, tasks belong to projects)
   - **Time line**: `lifetime → year → quarter → month → week → day` (carries the time skeleton + reserved-tag logs: each level's `goal`, the day's `summary` recap)
     - The recap (`summary` log) carries its own `logged_at` = write time. `wl day` shows "(written ...)" and, if there are later plain-note logs that day (`tag IS NULL`), warns "⚠ N changes after recap, consider rewriting". (Replaces the old `summary_at` prop.)
-  - **Projects no longer hang under months** (legacy design did; migrated to areas). Day/month/week views derive from **log's `logged_at`** (time dimension) and **kind/tag/ancestor chain** (domain dimension) — so moving projects under areas does not affect any per-day or per-project view.
+  - **Projects no longer hang under months** (legacy design did; migrated to areas). Day/month/week views derive from **log's `logged_at`** (time dimension) and **type/tag/ancestor chain** (domain dimension) — so moving projects under areas does not affect any per-day or per-project view.
 
 ## 3. State machine (#+TODO style)
 
@@ -275,7 +275,7 @@ Both `tree` and `summary` support `--by`; future aggregation commands follow the
 
 ### 9.1 `wl tree` default behavior (anti-blast)
 
-Fully expanding both trees would print thousands of lines. **Bare `wl tree` (no --root/--kind/--depth/--by) is a dedicated overview view `_print_default_tree`**:
+Fully expanding both trees would print thousands of lines. **Bare `wl tree` (no --root/--para/--depth/--by) is a dedicated overview view `_print_default_tree`**:
 
 - **Time line expanded to today**: year → quarter → month → week → today (only the path to today, no other months/weeks/days), and today's day node lists **only tasks with a log today** (task/habit/meetlog, no log body). You see the current month yet stay focused on today.
 - **Areas are one level only**: 7 areas show only area names, no project expansion.
@@ -284,7 +284,7 @@ Fully expanding both trees would print thousands of lines. **Bare `wl tree` (no
 
 `_print_tree` rules:
 - **Depth cap**: with `--root`, default 3; without root (`--depth` explicit), as given; `_print_tree(max_depth)` truncates beyond
-- **Time nodes sort by date** (`_tree_children`): kind ∈ time-types sort by `title` (date) ascending; others by priority → id (otherwise W22 sorts before W18)
+- **Time nodes sort by date** (`_tree_children`): type ∈ time-levels sort by `title` (date) ascending; others by priority → id (otherwise W22 sorts before W18)
 - **Day node expansion = day's activity** (`_print_day_activity`): after areas changeover, day has no real children — instead expand "tasks with logs that day + only that day's logs" (log-driven, same source as `wl day`). **Tasks should not hang under day** (hang under project); day content is derived from log dates.
 
 ## 10. Project ↔ task association (`_project_members`)
@@ -357,10 +357,10 @@ Reuse these when a new command needs the functionality; do not write another cop
 ```json
 {
   "add": [
-    { "ref": "p1", "title": "...", "kind": "project", "priority": "A",
-      "tags": [...], "props": {...}, "links": [...], "logs": [...],
+    { "ref": "p1", "title": "...", "priority": "A",
+      "tags": [...], "props": {"type.para": "project"}, "links": [...], "logs": [...],
       "children": [ {... nested child nodes ...} ] },
-    { "title": "...", "kind": "task", "parent_ref": "p1" }
+    { "title": "...", "parent_ref": "p1" }
   ],
   "update": [
     { "id": 45, "status": "DONE", "parent": 6, "add_tags": [...], "remove_tags": [...], "add_logs": [...], "add_links": [...] }
@@ -370,6 +370,7 @@ Reuse these when a new command needs the functionality; do not write another cop
 
 Conventions:
 
+- **Classification = `props` with `type.*` keys**: `{"type.para":"project"}` (or `area`/`task`), `{"type.date":"day"}` (week/month/…), `{"type.habit":"true"}`, `{"type.meetlog":"true"}`; a bare node (no `type.*`) is a plain task. A `type.date` prop auto-completes its `date.period`/span from the title.
 - **Two parent-child notations coexist**: `children` nesting (parent id auto-propagates to children — natural for time-hierarchy loads) + `ref`/`parent_ref` (in-batch temporary references — flat cross-section loads). `ref` must be defined before use.
 - **`status=DONE` auto-writes `closed_at`** (in both add and update)
 - **Update-able fields**: `status` / `priority` / `title` / `scheduled_at` / `deadline_at` / `body` / `parent` (move, validates existence) + `add_tags` / `remove_tags` / `add_logs` / `add_links`. ⚠️ Keys not in the whitelist are silently ignored — `parent` was once missing from the whitelist and caused moves to silently fail (later fixed); when adding fields, sync the whitelist.
@@ -388,8 +389,8 @@ When adding import fields (new node attribute / update operation), keep `_import
 
 ### 18.1 Add `+` / delete `-` / anchor ` `: the node line
 
-`<prefix><indent>[marker] [#pri] #id [kind] title :tags:` (marker required; `+` has no `#id`; `-` / anchor must have `#id`).
-Rich-field sub-lines: `@log <text>` / `@link <doc>` / `@prop k=v` (attached to the preceding `+` / anchor node).
+`<prefix><indent>[marker] [#pri] #id title :tags:` (marker required; `+` has no `#id`; `-` / anchor must have `#id`).
+Rich-field sub-lines: `@log <text>` / `@link <doc>` / `@prop k=v` (attached to the preceding `+` / anchor node). Classification is set via `@prop type.*` (e.g. `@prop type.para=project`), not a token on the node line.
 marker → status: `[ ]`=TODO, `[x]`=DONE, `[/]`=DOING, `[>]`=LATER, `[?]`=WAIT, `[-]`=CANCELED.
 
 ```
@@ -459,7 +460,7 @@ Terminal highlighting goes through `rich`; can be turned off, can switch themes,
 ### 19.1 Switches and detection
 
 - Global flags (before any subcommand): `--color {auto,always,never}` + `--theme {auto,dark,light,mono}` (theme choices = `["auto"] + list(THEMES)`; new palettes are auto-added to choices) + `--width {full,help,N}` / `$WORKLOG_WIDTH` (output width cap: `full` = fill terminal [default], `help` = the `--help` cap `HELP_MAX_WIDTH`, `N` = N columns). Resolved by `_resolve_width_cap` → `_set_width_cap`; `_term_width()` returns `min(terminal, cap)`, so all width-sensitive rendering (`_truncate_log_body`, title fits) respects it from one lever.
-- `--title {wrap,clip}` / `$WORKLOG_TITLE` — how a node title too wide for the line renders in `_node_line`: `wrap` (default) folds onto multiple lines, continuation lines **hang-indented** to the title column (`prefix_cols` = display width of the plain `indent+marker+pri+id+kind` prefix), so a long title never breaks the tree/list indentation; `clip` keeps one line, truncating with `…` (same budget as `_truncate_log_body`). Resolved by `_resolve_title_mode` → `_set_title_mode`; the wrap itself is `_wrap_display(text, cols)` — display-width-aware (East-Asian), breaks at spaces and hard-breaks a token (e.g. a spaceless CJK run) wider than the line. Anything but `clip` resolves to `wrap`, so the safe default always wins.
+- `--title {wrap,clip}` / `$WORKLOG_TITLE` — how a node title too wide for the line renders in `_node_line`: `wrap` (default) folds onto multiple lines, continuation lines **hang-indented** to the title column (`prefix_cols` = display width of the plain `indent+marker+pri+id+type` prefix), so a long title never breaks the tree/list indentation; `clip` keeps one line, truncating with `…` (same budget as `_truncate_log_body`). Resolved by `_resolve_title_mode` → `_set_title_mode`; the wrap itself is `_wrap_display(text, cols)` — display-width-aware (East-Asian), breaks at spaces and hard-breaks a token (e.g. a spaceless CJK run) wider than the line. Anything but `clip` resolves to `wrap`, so the safe default always wins.
 - `-o/--output {text,json}` — the **structured-output** surface, a shared `output_parent` parser on the commands that serialize: `show` / `ls` / `logs` / `projects` / `day` / `tree` / `summary` (a command without it rejects `-o` rather than silently printing text). `text` (default) is the rich rendering; `json` prints via `json.dumps(ensure_ascii=False, indent=2)` (plain `print`, never `out()` — machine output isn't styled/wrapped). `show` → `_node_to_dict` (full node + relations: tags / ancestors / props / links / schedule / children / logs / metrics / clock, no elision; single id → object, several → array). `ls` → array of `_node_summary_dict` (compact: identity + filter/sort fields + tags; filters apply, the display 20-cap is skipped, explicit `--limit`/`--top` honored). `logs` → array of log rows. `projects` → array of project summaries + `counts` (done/doing/pending/total) + `latest_activity`. `day` → `{date, weekday, nature, node_id, goal, goal_targets ([{id,title,status}], the goal's structured target nodes in priority order), goal_progress, summary, summary_at, week_goal, month_goal (the day node's reserved-tag logs, flattened in — only present keys), tasks[{…, logs, planned, clock_min}], clock_min_total}`. `tree` → the nested structural subtree (`--root` or top-level forest, each node + `children[]`, depth-bounded; ignores the text `--by`/filter sugar). `summary` → `{since, until, totals, by_direction, done[], pending[]}`. Empty result → `[]`. Field names mirror the DB columns (stable as an API contract); `*_at` are UTC instants verbatim, `*_date` local calendar days. Models the k8s `-o json` / `gh --json` pattern: let an AI/script pull an exact field instead of parsing the text view (G3).
 - Env fallback: `$WORKLOG_COLOR` (same values as `--color`), `$WORKLOG_THEME`, `$NO_COLOR` (standard, any value disables color)
 - `--color auto` (default) decides: `rich available AND stdout.isatty() AND no $NO_COLOR` → enabled. So pipes / redirects / test StringIO auto-downgrade to plain text, **tests need no special handling.**
@@ -470,7 +471,7 @@ Terminal highlighting goes through `rich`; can be turned off, can switch themes,
 **There is no palette named `default`** — `default` was once a fourth standalone palette and had confused semantics (neither dark nor light). Now there are three real palettes + one `auto` selector.
 
 `THEMES` dict: each palette maps semantic names to rich styles. Semantic names (not color names), full set in `_THEME_KEYS`:
-`done/doing/later/wait/todo/canceled` (status), `pri_a/pri_b/pri_c` (priority), `id/kind/tag/hit/header/meta/planned/clock`.
+`done/doing/later/wait/todo/canceled` (status), `pri_a/pri_b/pri_c` (priority), `id/type/tag/hit/header/meta/planned/clock`.
 
 - `dark`: dark background, `bright_*` for contrast
 - `light`: light background, deep saturated colors (`green4` / `red3` / `dark_orange3` / `dark_cyan` / `purple` / `grey42` …), avoiding bright colors that wash out on white
@@ -491,7 +492,7 @@ out(_c("✓", "done") + " " + _c(f"#{id}", "id") + " " + _c(title))
 
 - `_CONSOLE is None` (plain text): `_c` returns `str(text)` as-is, zero overhead
 - Styled: `_c` **first escapes content via `rich.markup.escape`** (so titles containing `[x]` / `[[doc]]` aren't eaten as markup), then wraps with `[style]…[/style]`; `style=None` only escapes, no color wrap
-- **Iron rule: any fragment going into `out()` that may contain `[` `]` (marker `[x]` / priority `[#A]` / kind `[day]` / wikilink `[[doc]]` / timestamp `[ts]`) must pass through `_c`.** Throwing a raw bracket-containing string into `out()` triggers `rich.MarkupError` or silent eating.
+- **Iron rule: any fragment going into `out()` that may contain `[` `]` (marker `[x]` / priority `[#A]` / type `[day]` / wikilink `[[doc]]` / timestamp `[ts]`) must pass through `_c`.** Throwing a raw bracket-containing string into `out()` triggers `rich.MarkupError` or silent eating.
 
 ### 19.4 `out()` replaces `print()`
 
@@ -515,10 +516,10 @@ When adding output / changing colors, keep `_init_console` / `_detect_bg_is_dark
   - Canonical formats are validated directly (illegal date/month/week raises `ValueError`, caught at dry-run, no bad data lands)
   - Relative words normalize: `today` → date, `tomorrow` → date, `next-week` → `YYYY-Www`, `next-month` → `YYYY-MM`, `next-quarter` → `YYYY-Qn`, `someday` → `someday`
   - Unrecognized → `ValueError` with valid-format hint (no silent swallow)
-- **Granularity `_sched_kind(s)`** / **sort `_sched_sort_key(s)`**: sort key = `(anchor start date, granularity rank)`; fuzzy values anchor to start of their time slot (`2026-06` → `2026-06-01`, `2026-Q3` → `2026-07-01`); `someday` anchors far future (sorts last); same anchor → finer granularity first
+- **Granularity `_sched_level(s)`** / **sort `_sched_sort_key(s)`**: sort key = `(anchor start date, granularity rank)`; fuzzy values anchor to start of their time slot (`2026-06` → `2026-06-01`, `2026-Q3` → `2026-07-01`); `someday` anchors far future (sorts last); same anchor → finer granularity first
 - **Display `_sched_display(s)`**: precise date this year shows `MM-DD`; fuzzy shows as-is (`2026-06` / `2026-Q3` / `someday`); `_node_line(sched=True)` renders `@<display>` (planned style highlight; prefix `@` not emoji — 📅 is loud, `@` is light and separates well in plain-text mode); ls / day / summary turn `sched=True` on by default
 
-When changing scheduled-time logic, keep `_norm_sched` / `_sched_kind` / `_sched_anchor` / `_sched_sort_key` / `_sched_display` / `cmd_add` / `cmd_defer` / `_import_node` / `_validate_fieldop` / `_exec_update` / `_node_line` in sync.
+When changing scheduled-time logic, keep `_norm_sched` / `_sched_level` / `_sched_anchor` / `_sched_sort_key` / `_sched_display` / `cmd_add` / `cmd_defer` / `_import_node` / `_validate_fieldop` / `_exec_update` / `_node_line` in sync.
 
 ## 21. Log historical dates (for migration)
 
@@ -537,7 +538,7 @@ Goal: reproduce the day-dimension view of "all projects + progress on a given da
 - **Bucket = `work`/`personal` tag** → `Work` / `Personal` / `Other` (`_node_bucket`), order in `_BUCKET_ORDER`
 - **Secondary group `--by`** (`_sec_group` / `_sec_sort_key`):
   - `plan` (**`wl day` default** — closest to markdown day structure): scheduled that day (or migration-era `planned` tag) → `Planned`; everything else → `Unplanned`. (The old separate `Unplanned (untagged)` bucket was merged into `Unplanned` — now that planned/unplanned derives from sched, the tag distinction has no value and the label misled.)
-  - `project`: project ancestor (`_node_project` picks the `kind=project` ancestor). `wl logs --group day` still defaults to `project`
+  - `project`: project ancestor (`_node_project` picks the project ancestor, `type.para=project`). `wl logs --group day` still defaults to `project`
   - `priority`: `A/B/C → P0/P1/P2`, no priority → `—` (defaults to unplanned but flagged unconfirmed). ⚠️ **Planned/unplanned is fundamentally per-day (per-log)** (a task may be planned today, unplanned tomorrow); hanging the mark on the task itself is an approximation after merging migration. Precise modeling would push the mark down to log rows (schema not yet done, decision pending).
 - **`wl logs --group day [--by ...]`** reuses `_render_day_group`: groups by date header, each day has the same structure as `wl day`
 - **`wl logs` default time window**: when no `--id` / `--date` / `--since`, only the last `--days` (default 7) — prevents flooding (works even when data grows); `--since` / `--until` / `--date` explicitly override

{pyworklog-0.8.0 → pyworklog-0.9.0}/DESIGN.zh.md

@@ -38,26 +38,26 @@ worklog 刻意保持**少依赖、低抽象**：运行时只有 **stdlib + `rich
 - 动词在前：`wl <verb> [args] [--flags]`
 - 子命令名用全小写单词：`add` / `done` / `tree` / `projects` / `changes` / `summary` / `focus` …
 - 操作单个节点的命令第一个位置参数是 `id`（int）：`wl show 42` / `wl done 42` / `wl log 42 "..."`
-- 长 flag 用 `--xxx`，短 flag 仅给最高频的（`-k` kind / `-p` priority / `-t` tag）
+- 长 flag 用 `--xxx`，短 flag 仅给最高频的（`-p` priority / `-t` tag）
 - 节点不存在一律 `sys.exit(f"✗ ... #{id} not found")`，退出码非 0
 
 ## 2. 数据模型（`src/worklog/migrations/`）
 
-单 `node` 表承载一切，`kind` 字段区分类型，`parent_id` 自引用建树。schema 以编号 SQL migrations 的形式发布,放在 `src/worklog/migrations/NNNN_*.sql`,`PRAGMA user_version` 记录最高已应用版本。`ensure_db()` 每条命令都自动 apply pending migrations,显式形式是 `wl migrate`。初始版本见 `src/worklog/migrations/0001_initial_schema.sql`,整体概览见 `README.md`。
+单 `node` 表承载一切，分类由正交的 `type.*` prop 命名空间承担（没有专门的列），`parent_id` 自引用建树。schema 以编号 SQL migrations 的形式发布,放在 `src/worklog/migrations/NNNN_*.sql`,`PRAGMA user_version` 记录最高已应用版本。`ensure_db()` 每条命令都自动 apply pending migrations,显式形式是 `wl migrate`。初始版本见 `src/worklog/migrations/0001_initial_schema.sql`,整体概览见 `README.md`。
 
 > **migration 编写规则**：runner 把每个文件包进一个 `BEGIN/COMMIT`(中途失败整文件回滚),所以 migration 文件本身**不要**写 `BEGIN`/`COMMIT`。
 
-- **kind 取值**：`lifetime / decade / year / quarter / month / week / day / area / project / task / meetlog / habit / signal`（可扩展，但加新 kind 要想清楚它在 tree / projects / summary 里怎么归类）
+- **分类取值**（正交的 `type.*` props，没有单列）：`type.para` = PARA 角色 `area / project / task`；`type.date` = 时间层级 `lifetime / decade / year / quarter / month / week / day`；`type.habit`；`type.meetlog`；自定义 `type.<x>`（可扩展，但加新 type 要想清楚它在 tree / projects / summary 里怎么归类）。一个 node 可同时持有多个；需要单个代表 token 时由 `node_type` / `node_type_from_props` 派生（优先级 para > date > habit > meetlog > custom > task）
 - **status 只在 task / habit / meetlog 类用**；时间层级类（year/month/...）跟 project 类 status 留 NULL
 - 表：`node / tag / log / metric / clock / prop / link / sched / date_meta` + 派生 view `v_node_path`
 - **`node → log → metric` 主干**（log 为中心的核心）：一个 `node` 挂多条 `log`；一条 `log`(带 `tag`——`note`/`goal`/`summary`/`metric`(载体)/…，NULL = 普通笔记)下挂 0..N 条 `metric`。`metric` 是结构化数据点(`tag` = 它是什么，如 `glucose`/`pullups`/`checkin`，或 `goal` = 一条 goal log 按优先级排序的目标 node id；外加 `value_num`/`value_text`/`unit`/`note`/`at`)。**`tag` 是三处统一的分类字段**——node(多值标签集)、log(角色,单值)、metric(种类,单值);同一个词、不同范围、SQL 不混。metric **必须挂在一条 log 上**(`metric.log_id` NOT NULL)——所以每个数据点都有 log 载体；`CHECK` 要求有值(纯标记如打卡存 `value_num=1`)。`metric.node_id` 是反范式冗余(免 join 查某 node 的数据点，无 FK；trigger 保证它始终等于载体 log 的 node)。CRUD 入口：`wl metric add/ls/edit/rm`(`add` 不带 `--on-log` 时建载体 log；无值标记存 `value_num=1`);`wl log`/`wl add` 的 `--metric` 和 `wl import` 的 `metrics` 可内联挂数据点。habit「今天做没做」= 当天有没有 `tag=checkin` 的 metric(`wl tick`/`wl checkin` 写),不再是「那天有没有 log」。
-- **保留 tag 的 log = 历史保留**：`goal`(前瞻,任意时间层级)和 `summary`(后顾日终)都是 `log.tag` 化的 log(最新一条=当前值,每次改追加一条),有自己的 `wl goal set/ls/rm <node>` 组(`--summary` 改写 summary),也由 bare `wl goal`/`wl recap`(今日自动)和 key-route 的 `wl set <node> goal|summary` 写。goal **每个层级同一个 `goal` tag**——node 的 kind(day/week/month/year)就是层级;旧的 week `overview`、month `top5` 已并入 goal(迁移 0010)。一条 goal 可带结构化目标(写时显式给的 node id,顺序=优先级,存成 `goal` metric);`wl day`/`wl goal` 展示 goal + 编号带状态的目标列表 + `[done/total]`。(`prop` 回归只放真正静态的单值属性。)
+- **保留 tag 的 log = 历史保留**：`goal`(前瞻,任意时间层级)和 `summary`(后顾日终)都是 `log.tag` 化的 log(最新一条=当前值,每次改追加一条),有自己的 `wl goal set/ls/rm <node>` 组(`--summary` 改写 summary),也由 bare `wl goal`/`wl recap`(今日自动)和 key-route 的 `wl set <node> goal|summary` 写。goal **每个层级同一个 `goal` tag**——node 的 type(day/week/month/year)就是层级;旧的 week `overview`、month `top5` 已并入 goal(迁移 0010)。一条 goal 可带结构化目标(写时显式给的 node id,顺序=优先级,存成 `goal` metric);`wl day`/`wl goal` 展示 goal + 编号带状态的目标列表 + `[done/total]`。(`prop` 回归只放真正静态的单值属性。)
 - **`clock` = 结构化计时**:`clock(node_id, start_at, end_at, elapsed_sec)`,由 `wl start`/`stop`/`spent`/`wait` 读写——替代旧的 `CLOCK_IN`/`CLOCK_OUT` log-body 约定;时长从 `elapsed_sec` 求和,不再从文本解析。
 - **两条并列树（都挂 lifetime 下）**（2026-05-29 起）：
   - **责任领域线**：`lifetime → area → project → task`（PARA：area 是跨时间的责任领域，project 归 area，task 归 project）
   - **时间线**：`lifetime → year → quarter → month → week → day`（承载时间骨架 + 保留 tag 的 log：每个层级的 `goal`、day 的 `summary` 日终）
     - 小结(`summary` log)自带 `logged_at` = 写入时间。`wl day` 显示「(写于 …)」,若当天小结后还有普通笔记 log(`tag IS NULL`)就提示「⚠ 小结后又有 N 条变更, 建议重写 recap」。(替代旧的 `summary_at` prop。)
-  - **project 不再挂 month**（旧设计曾挂月，已迁到 area）。日/月/周视图靠 **log 的 logged_at**（时间维度）跟 **kind/tag/祖先链**（领域维度）解耦：`wl day` 按 log 日期驱动、project 经祖先链解析、bucket 经 work/personal tag——所以 project 移到 area 下不影响任何按天/按项目视图
+  - **project 不再挂 month**（旧设计曾挂月，已迁到 area）。日/月/周视图靠 **log 的 logged_at**（时间维度）跟 **type/tag/祖先链**（领域维度）解耦：`wl day` 按 log 日期驱动、project 经祖先链解析、bucket 经 work/personal tag——所以 project 移到 area 下不影响任何按天/按项目视图
 
 ## 3. 状态机（#+TODO 风格）
 
@@ -146,7 +146,7 @@ DONE / DEFERRED / CANCELED   (已了结)
 
 ### 9.1 `wl tree` 默认行为（2026-05-29 调整，防刷屏）
 
-两条并列树全展开会上千行。**纯 `wl tree`（无 --root/--kind/--depth/--by）= 专用概览视图 `_print_default_tree`**：
+两条并列树全展开会上千行。**纯 `wl tree`（无 --root/--para/--depth/--by）= 专用概览视图 `_print_default_tree`**：
 
 - **时间线展开到今天**：年→季→月→周→今天（只走到今天的那条路径，不列别的月/周/日），今天的 day 节点下**只列当天有 log 的任务**（task/habit/meetlog，不展开 log）。这样既看到当月、又只聚焦今天。
 - **area 只列一层**：7 个 area 只出领域名，不展开项目。
@@ -155,7 +155,7 @@ DONE / DEFERRED / CANCELED   (已了结)
 
 底层 `_print_tree`（--root/--depth 路径）规则：
 - **限深**：有 `--root` 默认 3，无 root（`--depth` 显式）按给的值；`_print_tree(max_depth)` 截断。
-- **时间节点按日期排序**（`_tree_children`）：kind ∈ 时间类按 `title`(日期)升序，其他按 优先级→id（否则按 id 会 W22 排 W18 前）。
+- **时间节点按日期排序**（`_tree_children`）：type ∈ 时间层级按 `title`(日期)升序，其他按 优先级→id（否则按 id 会 W22 排 W18 前）。
 - **day 节点展开 = 当天活动**（`_print_day_activity`）：area 化后 day 无真子节点，改展开"当天有 log 的任务 + 只含当天的 log"（log 驱动，跟 `wl day` 同源）。**task 不要挂 day（挂 project）**，day 内容靠 log 日期推。
 
 ## 10. 项目↔任务关联（`_project_members`）
@@ -229,10 +229,10 @@ dev ai sync strategy reflection reading family health morning_check slack_scan
 ```json
 {
   "add": [
-    { "ref": "p1", "title": "...", "kind": "project", "priority": "A",
-      "tags": [...], "props": {...}, "links": [...], "logs": [...],
+    { "ref": "p1", "title": "...", "priority": "A",
+      "tags": [...], "props": {"type.para": "project"}, "links": [...], "logs": [...],
       "children": [ {...嵌套子节点...} ] },
-    { "title": "...", "kind": "task", "parent_ref": "p1" }
+    { "title": "...", "parent_ref": "p1" }
   ],
   "update": [
     { "id": 45, "status": "DONE", "parent": 6, "add_tags": [...], "remove_tags": [...], "add_logs": [...], "add_links": [...] }
@@ -242,6 +242,7 @@ dev ai sync strategy reflection reading family health morning_check slack_scan
 
 约定：
 
+- **分类 = `props` 里的 `type.*` 键**：`{"type.para":"project"}`（或 `area`/`task`）、`{"type.date":"day"}`（week/month/…）、`{"type.habit":"true"}`、`{"type.meetlog":"true"}`；无 `type.*` 的裸节点就是普通 task。`type.date` 会按 title 自动补全 `date.period`/区间
 - **父子两种表达并存**：`children` 嵌套（父 id 自动传子，灌时间分层天然用）+ `ref`/`parent_ref`（同批次临时引用，扁平交叉用）。`ref` 必须先定义后引用
 - **status=DONE 自动写 closed_at**（add 跟 update 都是）
 - **update 可改字段**：`status`/`priority`/`title`/`scheduled_at`/`deadline_at`/`body`/`parent`(move, 校验存在) + `add_tags`/`remove_tags`/`add_logs`/`add_links`。⚠️ 没列在白名单的 key 被静默忽略——`parent` 曾漏在白名单导致 move 静默失败（2026-05-29 修），加字段务必同步白名单
@@ -260,8 +261,8 @@ dev ai sync strategy reflection reading family health morning_check slack_scan
 
 ### 18.1 新增 `+` / 删除 `-` / 锚 ` `：节点行
 
-`<前缀><缩进>[marker] [#pri] #id [kind] title :tags:`（marker 必有；`+` 无 #id，`-`/锚 必有 #id）。
-富字段子行 `@log <文本>` / `@link <doc>` / `@prop k=v`（附到上一个 `+`/锚 节点）。
+`<前缀><缩进>[marker] [#pri] #id title :tags:`（marker 必有；`+` 无 #id，`-`/锚 必有 #id）。
+富字段子行 `@log <文本>` / `@link <doc>` / `@prop k=v`（附到上一个 `+`/锚 节点）。分类用 `@prop type.*` 设置（如 `@prop type.para=project`），节点行上不再有分类 token。
 marker → status：`[ ]`TODO `[x]`DONE `[/]`DOING `[>]`LATER `[?]`WAIT `[-]`CANCELED。
 
 ```
@@ -340,7 +341,7 @@ marker → status：`[ ]`TODO `[x]`DONE `[/]`DOING `[>]`LATER `[?]`WAIT `[-]`CAN
 **没有名叫 `default` 的调色板**——`default` 曾是第 4 个独立配色，语义混乱（既不是 dark 也不是 light）。现在只有三个真实调色板 + 一个 `auto` 选择器：
 
 `THEMES` 字典：每个调色板把语义名映射到 rich style。语义名（不是颜色名），全集见 `_THEME_KEYS`：
-`done/doing/later/wait/todo/canceled`（状态）、`pri_a/pri_b/pri_c`（优先级）、`id/kind/tag/hit/header/meta/planned/clock`。
+`done/doing/later/wait/todo/canceled`（状态）、`pri_a/pri_b/pri_c`（优先级）、`id/type/tag/hit/header/meta/planned/clock`。
 - `dark`：深色背景，`bright_*` 提对比度
 - `light`：浅色背景，深色饱和色（`green4`/`red3`/`dark_orange3`/`dark_cyan`/`purple`/`grey42`…），避免亮色/白色在白底糊掉
 - `mono`：全 `default`（rich 的 default 风格=终端默认前景，无色），给"想要 rich 布局但不要颜色"的场景
@@ -360,7 +361,7 @@ out(_c("✓", "done") + " " + _c(f"#{id}", "id") + " " + _c(title))
 
 - `_CONSOLE is None`（纯文本）：`_c` 原样返回 `str(text)`，零开销
 - styled：`_c` **先 `rich.markup.escape` 内容**（防 title 里的 `[x]`/`[[doc]]` 被当 markup 吃掉），再包 `[style]…[/style]`；`style=None` 只 escape 不包色
-- **铁律：任何要进 `out()` 的片段，凡可能含 `[` `]`（marker `[x]` / 优先级 `[#A]` / kind `[day]` / wikilink `[[doc]]` / 时间戳 `[ts]`），必须经 `_c` 包一层**。直接把含方括号的裸串塞进 `out()` 会触发 rich MarkupError 或被静默吞掉
+- **铁律：任何要进 `out()` 的片段，凡可能含 `[` `]`（marker `[x]` / 优先级 `[#A]` / type `[day]` / wikilink `[[doc]]` / 时间戳 `[ts]`），必须经 `_c` 包一层**。直接把含方括号的裸串塞进 `out()` 会触发 rich MarkupError 或被静默吞掉
 
 ### 19.4 `out()` 取代 `print()`
 
@@ -393,10 +394,10 @@ out(_c("✓", "done") + " " + _c(f"#{id}", "id") + " " + _c(title))
   - 规范格式直接校验（非法日期/月份/周号抛 `ValueError`，在 dry-run 即报，不写脏数据）
   - 相对词归一化：`今天/today`→日期、`明天/tomorrow`→日期、`下周/next-week`→`YYYY-Www`、`下月/next-month`→`YYYY-MM`、`下季/next-quarter`→`YYYY-Qn`、`以后/someday`→`someday`
   - 无法识别 → `ValueError` + 提示合法格式（不静默吞）
-- **粒度 `_sched_kind(s)`** / **排序 `_sched_sort_key(s)`**：排序键 = `(起始日 anchor, 粒度 rank)`；模糊值 anchor 到其时间段起点（`2026-06`→`2026-06-01`、`2026-Q3`→`2026-07-01`），`someday` anchor 远未来排最后；同 anchor 时粒度细的排前
+- **粒度 `_sched_level(s)`** / **排序 `_sched_sort_key(s)`**：排序键 = `(起始日 anchor, 粒度 rank)`；模糊值 anchor 到其时间段起点（`2026-06`→`2026-06-01`、`2026-Q3`→`2026-07-01`），`someday` anchor 远未来排最后；同 anchor 时粒度细的排前
 - **显示 `_sched_display(s)`**：精确日去年只显 `MM-DD`，模糊值显原样（`2026-06`/`2026-Q3`/`someday`）；`_node_line(sched=True)` 用 `@<display>`（planned 风格高亮；前缀 `@` 而非 emoji——📅 太扎眼，`@` 轻量且在 plain 无色模式下跟前文分隔），ls / day / summary 默认开 `sched=True`
 
-加 / 改计划时间相关时，`_norm_sched` / `_sched_kind` / `_sched_anchor` / `_sched_sort_key` / `_sched_display` / `cmd_add` / `cmd_defer` / `_import_node` / `_validate_fieldop` / `_exec_update` / `_node_line` 跟本节同步。
+加 / 改计划时间相关时，`_norm_sched` / `_sched_level` / `_sched_anchor` / `_sched_sort_key` / `_sched_display` / `cmd_add` / `cmd_defer` / `_import_node` / `_validate_fieldop` / `_exec_update` / `_node_line` 跟本节同步。
 
 ## 22. 当天复现视图 `wl day` + `wl logs --group`（markdown 日结构）
 
@@ -406,7 +407,7 @@ out(_c("✓", "done") + " " + _c(f"#{id}", "id") + " " + _c(title))
 - **桶（bucket）= `work`/`personal` tag** → `工作`/`个人`/`其他`（`_node_bucket`），顺序 `_BUCKET_ORDER`
 - **次级分组 `--by`**（`_sec_group` / `_sec_sort_key`）：
   - `plan`（**`wl day` 默认**，设计决策 2026-05-29——最贴近 markdown 日结构）：当天有排期（或迁移期 `planned` tag）→ `计划内`；其余 → `计划外`。（原来单独的 `计划外（未标）` 一档已并入 `计划外`——现在计划内外靠 sched 推导，那个 tag 区分没价值且 `（未标）` 文案误导，会被当成"没打 work/personal tag"。）
-  - `project`：项目祖先（`_node_project` 取 kind=project 的 ancestor）。`wl logs --group day` 仍默认 `project`
+  - `project`：项目祖先（`_node_project` 取项目祖先，`type.para=project`）。`wl logs --group day` 仍默认 `project`
   - `priority`：`A/B/C → P0/P1/P2`，无优先级 `—`（默认当计划外，但标注未显式确认，设计决策 2026-05-29）。⚠️ **计划内/计划外本质是 per-day（per-log）属性**（同一任务今天计划内、明天可能计划外），归并迁移后挂在任务上只是近似；要精确需把标记下沉到 log 行（schema 未做，留待决策）
 - **`wl logs --group day [--by ...]`** 复用 `_render_day_group`：先按日期 header 分组，每天内同 `wl day` 结构
 - **`wl logs` 默认时间窗**：无 `--id`/`--date`/`--since` 时只列**最近 `--days`（默认 7）天**，防全量刷屏（数据涨上来还能用）；`--since`/`--until`/`--date` 显式覆盖
@@ -435,7 +436,7 @@ out(_c("✓", "done") + " " + _c(f"#{id}", "id") + " " + _c(title))
 
 2026-05-29 拍板（vault §八 4/5）：
 
-- **wl day 顶部的 goal / summary**（2026-05-29 起为 prop，后演进，**以下为现状**）：`goal`（前瞻，任意层级）和 `summary`（日终）是节点上保留 tag 的 **log**（历史保留，非 prop）——day 写 goal/summary，week/month 写 goal（同一个 `goal` tag，靠 node kind 区分层级；旧的 `overview`/`top5` 已并入 goal）。`wl goal`/`wl recap`/`wl goal set <node>` 写，goal 可带结构化目标 node id（`goal` metric，顺序=优先级）。`wl day` 顶部按 `> 🎯 / > 📝 Recap / > 📅 This week / > ⭐ This month` blockquote 渲染 + 编号带状态的目标列表 + `[done/total]`。
+- **wl day 顶部的 goal / summary**（2026-05-29 起为 prop，后演进，**以下为现状**）：`goal`（前瞻，任意层级）和 `summary`（日终）是节点上保留 tag 的 **log**（历史保留，非 prop）——day 写 goal/summary，week/month 写 goal（同一个 `goal` tag，靠 node type 区分层级；旧的 `overview`/`top5` 已并入 goal）。`wl goal`/`wl recap`/`wl goal set <node>` 写，goal 可带结构化目标 node id（`goal` metric，顺序=优先级）。`wl day` 顶部按 `> 🎯 / > 📝 Recap / > 📅 This week / > ⭐ This month` blockquote 渲染 + 编号带状态的目标列表 + `[done/total]`。
 - **日期上下文 → 专门 `date_meta` 表**：`(date PRIMARY KEY, label)`。`label` = 节日/休假/调休/节气（劳动节假期 / 调休上班 / 小满 / 年假 …）。**不依赖 day 节点**，可全年预导入假期表 + 自定义。
   - **周X 自动算**（`_cn_weekday`，不存储），`date_meta` 只存非自动信息。
   - `wl day` 头部 = `<date> <周X>[ · <label>]`（`_date_label` 查表）。day 节点标题统一存**纯日期** `YYYY-MM-DD`（周X/节日不进标题，避免与自动算/查表重复）。
@@ -519,7 +520,7 @@ total = max(clock_total, log_span)
 | 类别 | 参数(顶层全局 OR 子命令本地) | 描述 |
 |---|---|---|
 | **状态过滤** | `--show-canceled`(顶层全局, 默认隐) / `--all`(本地, ls/projects: 包括 DONE+CANCELED) / `--status STATUS`(本地, ls 已有) | 默认隐 DONE 和/或 CANCELED |
-| **类型过滤** | `--kind KIND`(本地, ls/tree/find 已有) | 限 task/project/area/... |
+| **类型过滤** | `--para {area,project,task}`(本地, ls/tree/find/day) 走 type.para 精确匹配; 其它分类用 `--prop type.<x>`(如 type.meetlog / type.date=day) | 分类由 type.* 派生 |
 | **优先级过滤** | `--priority A/B/C`(待加, ls/find/day) | 限 P0/P1/P2 |
 | **标签过滤** | `--tag TAG`(本地, ls 已有, AND filter) | 多 tag 逗号分隔 AND |
 | **时间范围** | `--since/--until/--week/--month/--date`(parent parser, changes/summary/logs/projects 已用) | 时间窗口 |
@@ -545,7 +546,7 @@ total = max(clock_total, log_span)
 | `--show-canceled` | 顶层全局 | 跨所有 list/tree/find 命令的状态过滤 |
 | `--color/--theme/--version` | 顶层全局 | 渲染配置 |
 | `--since/--until/--week/--month` | 子命令本地(经 window parent parser) | 只 changes/summary/logs/projects 用 |
-| `--limit/--top/--by/--kind/--tag/--parent/--all` | 子命令本地 | 不一定每个命令都适用 |
+| `--limit/--top/--by/--para/--tag/--parent/--all` | 子命令本地 | 不一定每个命令都适用 |
 
 **冲突处理规则**:
 
@@ -650,7 +651,7 @@ log 写错有两条出路:
 核心反模式: AI 用 `wl ls` / `wl logs --id N` 列全量找 1-2 内容; 浪费 token + 反复试.
 
 落地动作:
-- `wl ls` 无任何过滤参数时顶部加一行 hint 引导用 `wl find` / `--parent` / `--kind` / `wl day` 等精准入口 (仍列出, 不阻断)
+- `wl ls` 无任何过滤参数时顶部加一行 hint 引导用 `wl find` / `--parent` / `--para` / `wl day` 等精准入口 (仍列出, 不阻断)
 - `wl logs --id N --tail K` 单 task 模式 tail 也生效 (之前仅 `--by-task` 配合)
 - vault 文档维护"已识别浪费场景" Audit 清单, 撞到一个反模式就修一个, 持续迭代
 
@@ -724,7 +725,7 @@ epilog   = 使用场景 (3 条) + 跟 wl day 的区别 + 紧凑模式 / full mod
 
 ```
 help     = "list nodes (默认限 20 条, 参考 shell ls -t / -S / -r 各种维度)"
-epilog   = 10 条常用示例 (--parent / --kind / --tag / --unscheduled / --sort / --recent / --ids / --status / --all)
+epilog   = 10 条常用示例 (--parent / --para / --tag / --unscheduled / --sort / --recent / --ids / --status / --all)
 ```
 
 ### 信息密度 vs 简洁的权衡

pyworklog-0.9.0/Dockerfile.dev

@@ -0,0 +1,33 @@
+# Local dev/test image — run the full test suite (and a dev wl) inside a Linux container,
+# physically isolated from the real database.
+#
+# Why: a dev build of wl can connect to the real DB by default (no --db) and mutate it. CLI-flag
+# isolation and "don't touch the real DB" conventions are easy to bypass by accident. The robust
+# fix is physical isolation: run dev work and tests only inside this container.
+#
+# Isolation guarantees:
+#   - the container has its own HOME (/root) and filesystem; the host data dir does not exist in
+#     it and is never mounted in
+#   - even running `wl ...` (without --db) inside the container only creates a DB at a
+#     container-internal path, never touching host data
+#   - tests use pytest's temporary fixture DB (isolated by construction)
+#   - only the project code is bind-mounted to /app at run time; data dirs are never mounted
+#
+# Lighter than the production image: plain python + deps, fast to build.
+FROM python:3.11-slim
+
+RUN pip install --no-cache-dir uv
+
+# Keep the venv outside /app (at /opt/venv) so bind-mounting the project root to /app at run time
+# does not shadow it.
+ENV UV_PROJECT_ENVIRONMENT=/opt/venv
+
+# Build stage installs deps only (incl. semantic + test extras), not the project itself — the code
+# is bind-mounted at run time and referenced via PYTHONPATH=/app/src, so edits take effect without
+# rebuilding the image.
+WORKDIR /build
+COPY pyproject.toml uv.lock ./
+RUN uv sync --all-extras --no-install-project
+
+WORKDIR /app
+CMD ["sh", "-c", "PYTHONPATH=/app/src /opt/venv/bin/python -m pytest"]

{pyworklog-0.8.0 → pyworklog-0.9.0}/Makefile

@@ -15,7 +15,7 @@ WORKLOG_DB_PATH  := $(shell \
   if [ -n "$$WORKLOG_DB" ]; then echo "$$WORKLOG_DB"; \
   else echo "$${XDG_DATA_HOME:-$$HOME/.local/share}/worklog/worklog.db"; fi)
 
-.PHONY: help sync test test-v test-fast cov install uninstall reinstall push pull status commit demo clean reset setup
+.PHONY: help sync test test-v test-fast cov docker-test docker-test-image install uninstall reinstall push pull status commit demo clean reset setup
 
 help:                ## show this help
 	@awk 'BEGIN {FS = ":.*?## "} /^[a-zA-Z_-]+:.*?## / {printf "  \033[36m%-15s\033[0m %s\n", $$1, $$2}' $(MAKEFILE_LIST)
@@ -38,6 +38,16 @@ test-fast:           ## run pytest only (no cov, no gate; quick dev feedback)
 cov:                 ## detailed coverage report (term-missing, includes 95% gate)
 	@$(PYTEST)
 
+# ── docker dev/test (physically isolated from the real DB — see Dockerfile.dev) ──
+
+DEVTEST_IMG := worklog-devtest:latest
+
+docker-test-image:   ## build the isolated dev/test image
+	docker build -f Dockerfile.dev -t $(DEVTEST_IMG) .
+
+docker-test: docker-test-image  ## run the FULL suite inside the container (never mounts the real data dir)
+	docker run --rm -v "$(CURDIR)":/app -w /app $(DEVTEST_IMG)
+
 # ── install / uninstall ──
 
 install: sync        ## install ~/bin/wl wrapper pointing into the project .venv
@@ -74,14 +84,14 @@ demo:                ## populate a fresh demo DB with a sample tree (REFUSES to
 	  exit 1; \
 	fi
 	@wl init
-	@wl add "Lifetime" -k lifetime
-	@wl add "2026" -k year --parent 1
-	@wl add "2026-Q2" -k quarter --parent 2
-	@wl add "2026-05" -k month --parent 3
-	@wl add "2026-W21" -k week --parent 4
-	@wl add "2026-05-18 Mon" -k day --parent 5
-	@wl add "Dev tooling" -k project -p A -t work --parent 4
-	@wl add "Dev tooling — strategy pivot" -k task -p A -t work,unplanned,P0,dev_tooling --parent 6
+	@wl add "Lifetime" --prop type.date=lifetime
+	@wl add "2026" --prop type.date=year --parent 1
+	@wl add "2026-Q2" --prop type.date=quarter --parent 2
+	@wl add "2026-05" --prop type.date=month --parent 3
+	@wl add "2026-W21" --prop type.date=week --parent 4
+	@wl add "2026-05-18" --prop type.date=day --parent 5
+	@wl add "Dev tooling" --para project -p A -t work --parent 4
+	@wl add "Dev tooling — strategy pivot" -p A -t work,unplanned,P0,dev_tooling --parent 6
 	@wl log 8 "2026-05-18 17:18 strategy pivot decided"
 	@wl log 8 "2026-05-19 09:42 break down requirements: export_for_ai"
 	@wl log 8 "2026-05-20 14:55 path B working end-to-end, owners 6/6 -> 7/7"