Skip to main content
The canonical path is /topics. /watchers still works as a deprecated alias for old CLIs and is removed in a later release.

Core CRUD

The read response is the canonical context. It includes a flat trust verdict (reviewed | proposed | draft) plus classification.status and a governance block: the trust signal an agent consumes. Key on trust directly:

Search & Matching

GET /workspaces/:slug/topics also accepts ?tags=a,b (comma-separated, OR semantics). Tag names are normalized server-side (lowercase, whitespace→dashes).

Tags

The workspace tag registry: tags as first-class objects so they can be pre-created with a description before any topic uses them. Attaching an unregistered tag via a topic write auto-registers it.

Health & Graph

Governance

A topic becomes Knowledge only once an owner/admin merges it in. See Governance. approve / reject and Suggested-edit merge / reject require owner/admin authority. They succeed for an owner/admin principal on any surface (dashboard, owned CLI key, or an OAuth/MCP token the owner/admin authorized), and the merge is stamped approved_via (human or agent). A faceless or non-owner principal is rejected.

Relations

POST /topics and PATCH /topics/:topic responses may include anchor_validation: per-pattern match counts against the repo’s default branch (ok / overbroad / zero, with samples and warnings). Advisory only: it never blocks the write. It is omitted when the write carries no pattern, or when no repo is linked. When a repo IS linked but the deployment holds no file index for it, the field is present as { "skipped": "…" } naming the reason — so an absent field never has to be read as “your globs were checked and are fine”. POST …/relations is reachable by OAuth (MCP) principals with topics:write; deleting relations stays human-only.

Share