Skip to content

feat(output)!: spell the to-do type value task, not todo - #223

Merged
ryanlewis merged 1 commit into
mainfrom
fix/issue-218-type-task
Sep 10, 2026
Merged

ryanlewis merged 1 commit into
mainfrom
fix/issue-218-type-task

Conversation

@ryanlewis

Copy link
Copy Markdown
Owner

Closes #218

What changed

type on a to-do row in JSON output is now "task" instead of "todo". model.typeNames is the single source of truth (internal/model/model.go), so every JSON surface picks this up without its own change.

Mechanical rename, nothing else touched:

  • internal/model/model.go, internal/model/model_test.go — codec map and its round-trip/marshal/unmarshal/string tests
  • cmd/things/run_test.go — raw-JSON assertions from feat(output)!: render type as a string in JSON #214
  • internal/skill/SKILL.md, docs/content/commands.md, docs/content/agents.md — every "todo" value in prose and jq examples

The legacy integer 0 still decodes on input; no compatibility shim for the string todo is needed since #214 is unreleased. Plain text output, model.Status, and the codec's structure are unchanged.

Why

#214 introduced the string values todo/project/heading. Review on that PR flagged todo as a fourth spelling of one concept — the codebase already says task/to-do elsewhere — and the issue calls for task as the word the CLI should use generally, before 0.8.0 ships the contract.

How tested

  • make test and make lint pass
  • /code-review --fix run against the diff; its two suggested fixes (a db.go/tasks.go cleanup) were out of scope for this issue and were not applied

BREAKING CHANGE: type on a to-do row in JSON output is now "task"
instead of "todo". Supersedes the unreleased "todo" spelling from
@ryanlewis
ryanlewis force-pushed the fix/issue-218-type-task branch from 524b634 to 312504f Compare September 10, 2026 11:15
@ryanlewis
ryanlewis merged commit 6656c7c into main Sep 10, 2026
10 checks passed
@ryanlewis
ryanlewis deleted the fix/issue-218-type-task branch September 10, 2026 11:17
ryanlewis added a commit that referenced this pull request Sep 10, 2026
Closes #219

The `--json` error payload spelled one concept two ways. `kind` was
`"task"` everywhere except the `not a project` failure, where it was
`"to-do"`, while `type` on a task row has said `"task"` since #214. One
word wins, and that word is `task`.

## What changed

`ProjectEditCmd.Run` now builds its `wrongKindError` with `Kind:
"task"`. That field feeds both the JSON `kind` and the rendered message,
so the message moves with it: `"Post letter" is a task; use things
edit`. Every other producer already said `task`, `project`, `area` or
`tag`.

The docs that print or explain the payload follow: the error-payload
example in the bundled skill, the token paragraph on the agents page,
and the README paragraph explaining what `kind` carries. The skill gains
a one-line note in its `--json` section saying a to-do is a `task` in
every JSON value the CLI emits, naming `import` payloads as the one
exception.

`commands.md` and `configuration.md` are untouched. Neither documents
the error payload, and no command or flag changed.

## Not a breaking change

`kind: "to-do"` was introduced in #193, which is not an ancestor of
`v0.7.0`. The value has never appeared in a release, so no published
contract moves and there is nothing for the 0.8.0 notes to warn about.
That is the same reasoning #223 applied to the `type` rename. The
`error` token is untouched either way: it stays `not a project`.

## Out of scope, deliberately

`import` payloads still spell a to-do `"to-do"`. That is Things' own
JSON URL scheme format and it stays documented as the exception.

Three other `kind` variables hold `"to-do"` and were left alone, because
none of them reaches JSON. They only compose English prose: the
repeating-item refusal in `verify.go`, the per-item refusal line in
`importcheck.go`, and the agent brief's opening sentence in
`internal/output/agent.go`. The issue scopes itself to JSON values, and
renaming these would rewrite prose and its tests well outside that. The
new comment on the `Kind` field says so explicitly, so the next reader
does not take the rule as wider than it is.

## How tested

`make test` and `make lint` both green.
`TestRunProjectEditRefusesTodoReference` asserts the new `kind` and
message and carries a comment saying why. The built binary was run
against the live Things database to confirm the payload it prints.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

feat(output)!: spell the to-do type value task, not todo

1 participant