Comments and activity
Comments, mentions, and the audit activity log.
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.
New comment bodies are capped at 256 KiB after escaped-newline and tab normalization. Larger existing bodies may be edited without growing. HTTP requests remain capped at 2 MiB; direct database and stdio operations are not subject to that transport limit. Bodies allow at most 256 distinct mention tokens and 256 distinct attachment IDs. Excess references cause an explicit refusal, including on older comments: reduce them before saving.
Reading a thread
Interactive reads return at most 500 comments within a 2 MiB budget. Byte limits can shorten any page, so follow continuation instructions rather than assuming a short page ends the thread. Exports use a separate exhaustive query with their own limits. Each surface has its own default:
| Surface | Default page | Default order |
|---|---|---|
GET /api/issues/{id}/comments, GET /api/pages/{id}/comments | 50 | asc (oldest first) |
list_comments MCP tool | 50 | desc (newest first) |
lific comment list | 50 | desc (newest first) |
| Web UI issue and page detail | 50 | newest page, shown oldest first |
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.
MCP includes rendered links, escaped text, and the get_issue preamble in its encoded response budget. If a comment cannot fit by itself, the read fails explicitly with instructions for continuing; it does not silently skip the comment.
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.