Pages
Project and workspace pages, folders, what each page status does, labels and pinning, and what happens when a page is deleted.
A page is a Markdown document: a design note, a runbook, a spec, a record of a decision. Pages sit beside the issues they describe, so an agent can read the design before it starts work and write down what it learned when it finishes.
Project pages and workspace pages
Most pages belong to a project. A workspace page belongs to no project and is meant for material that spans projects, such as team conventions.
| Project page | Workspace page | |
|---|---|---|
| Identifier | APP-DOC-3, numbered within the project | DOC-3, numbered across the workspace |
| Folders | Yes | No |
| Labels | Yes, from its project | No |
| Who can read it | Anyone who can read the project | While membership is enforced, administrators only. Otherwise everyone. |
| Who can change it | maintainer on the project | The same as reading it |
A page stays where it was created. It cannot move to another project or between a project and the workspace. To move one, create it in the new place and delete the old one.
Over MCP, create_page makes a workspace page when you leave out project.
Fields
| Field | What it holds |
|---|---|
title | Required. |
content | Markdown. In the web UI, identifiers such as APP-12, APP-DOC-3 and APP-PLAN-2 in the text become links. |
status | Where the document stands. New pages start as draft. See Status. |
folder_id | The folder the page sits in, or none for the project root. |
labels | Any of the project's labels. |
pinned | Whether the page is pinned. See Pinning. |
created_at, updated_at | Set by Lific. |
For a small change to a long page, edit_page replaces one exact string and leaves the rest untouched. Like issues, a page update accepts the expected_seq you last read and is refused if someone changed the page since. See Concurrent edits.
Status
A page's status describes the document, not the work it is about. Lific uses it to filter; changing it moves nothing and notifies no one.
| Status | Meaning | In the web UI |
|---|---|---|
draft | Being written. Not yet something to rely on. | Listed under Drafts as well as in the tree. |
active | Current and in use. | Shown normally. |
complete | Finished and still accurate, such as a spec for shipped work. | Shown normally. |
archived | Kept for the record, no longer current. | Hidden from the page tree and recent pages until you choose Archived or the All filter. |
An archived page is still readable by identifier, still found by search, and still served by a public project. Archiving hides it from browsing and nothing else. Delete the page if it should go.
list_resources over MCP and GET /api/pages both take a status filter.
Folders
Folders organize a project's pages into a tree. A folder belongs to one project, has a name, and can sit inside another folder in the same project. A page can sit in a folder or at the project root, and it must be in the same project as its folder.
Folder names are not unique. Tools that take a folder by name, such as folder on create_page, match it without case, so keep names distinct.
Deleting a folder deletes every folder beneath it too. The pages inside are not deleted: they move to the project root. Folders have no trash.
Creating, renaming and deleting folders takes maintainer while membership is enforced, and lead while it is off, the same as modules and labels.
Labels
A project page can carry any number of its project's labels, the same ones its issues use. Sending labels on an update replaces the complete set; leave it out to keep the current labels. Modules and labels covers the matching rules.
Pinning
A pinned page is shown in its own section above the folder tree in the page list. Pinning is shared: pinning a page pins it for everyone in the project. It does not change the page's folder or status. Pinning is a page edit, so it takes maintainer.
Comments
Every page has its own comment thread, including workspace pages. Anyone who can read the page can comment. See Comments and activity.
Long pages
Agent harnesses cut tool output off at roughly 50 KB without saying so. To keep a read from being silently truncated, get_page returns a page of up to 30,000 characters whole, and a longer page as its outline (each heading with the size of its section) plus the start of its content. The agent then reads the part it needs, such as get_page(identifier="APP-DOC-3", section="Current state"). A section can be long too, for example a log of dated entries with no subheadings, so every cut response ends with the exact call that continues it, with an offset. The web UI always shows the whole page.
Creating or editing a page past that size through MCP adds a line to the response suggesting a split, or moving old history to an archive page.
To catch up on a page read earlier, an agent passes the seq from that read as since_seq and gets back only the changed lines. Lific keeps up to 50 recent versions of each page's content for this, dropping the oldest once they total 2,000,000 characters. The history is removed when the page is purged from the trash, and project archives do not carry it. get_page documents every option.
Deleting and restoring
Deleting a page moves it to the trash, along with its comments. It disappears from lists, search and public projects at once. For the next 30 days, a maintainer (an administrator, for a workspace page) can restore it with POST /api/pages/{id}/restore, and the comments come back with it. After that the retention sweep removes it permanently. trash_days in the [retention] section sets the window.
The page's identifier is not handed out again while it is in the trash, so a restore never collides with a newer page.
Modules and labels
How modules divide a project into areas and labels tag issues and pages, what each status and field does, and what deleting or merging them changes.
Plans
Nested step trees for multi-session work, how step ids differ from positions, and exactly when a step and its mirrored issue update each other.