Comments and activity

Comments belong to exactly one issue or one page. A comment stores its author, Markdown content, creation time, and update time.

Comments on issues and pages have separate threads. Deleting an issue or page also deletes its comments.

An author can edit and delete their own comments. Over REST, an administrator can also edit or delete any comment. An edited comment keeps its identity and records a new update time, which is what marks it as edited.

Each comment has a stable anchor derived from its numeric id, so a single comment in a thread can be linked to directly.

A comment body is limited to 262144 bytes (256 KiB) after Lific normalizes escaped newlines and tabs. A create or edit over that limit is rejected with a 400 and leaves any existing comment unchanged. Comments already stored above the limit stay readable and editable down to a body within it.

Reading a thread

No surface returns an unbounded thread. Every comment list is a page of at most 500 comments, and each surface has its own default:

The REST default is asc for compatibility, so the default REST page of a long thread is its oldest 50 comments and says nothing about the newest one. Ask for order=desc to read the current end of a conversation. The MCP tool, the CLI, and the web UI all default to newest first for exactly that reason.

Page with offset. The MCP tool and the CLI print the offset of the next page when one exists; the web UI offers a "Load older comments" control.

REST comment lists additionally accept a keyset cursor (before_created_at plus before_id) that pages backwards from a comment already seen. It exists because an offset drifts under a live thread: one comment posted above a reader shifts every offset by one, so the next page repeats a comment or skips one. The web UI uses the cursor for exactly that reason.

get_issue carries a comment trail too, and it is bounded the same way: recent (the default) shows the last three, all shows the most recent 500, and none reports only the count, including when that count is zero. A thread longer than the all window says so and points at list_comments.

Mentions

Comment text can include @username mentions. A mention token begins with @ and can contain ASCII letters, digits, underscores, and hyphens.

Lific resolves mention tokens when a comment is created or edited. Matching is case-insensitive. Repeated mentions of the same user resolve once.

Unmatched mention tokens remain in the comment text. They do not create a resolved mention record.

When project-scoped authorization is enforced, resolved mentions are limited to the project's non-bot members. When it is not enforced, any non-bot user can be a mention candidate.

Activity log

The activity log is an append-only record of mutations. It covers changes made through the web UI, MCP server, REST API, CLI, and system operations.

An activity entry records a timestamp, actor information when available, transport, resource type, action, and changed values. Update operations record one entry for each changed field.

The actor is the identity that made the change, and the transport is the door it came through: web, mcp, api, cli, or system. A connected agent has its own identity, so its writes are attributed to that agent rather than to the person who connected it, and entries mark it as a bot.

Issue activity includes issue changes, comments, label attachments and removals, and issue relationship changes. Page activity includes page changes, comments, and label attachments and removals. Plan activity includes plan and plan-step changes.

Activity can be read for an issue, page, project, or plan. Entries are returned newest first.

If an actor account is later deleted, existing activity entries remain. The actor identity fields can be unavailable on those entries.