Jotting a note
The fastest way to capture something is a one-liner from the CLI. No anchors, no ceremony:--project <id> files it on a project, and --project <id> --card <id> attaches it to a specific card mid-loop, where it rides the card’s next context bundle and gets synthesized into a draft topic when the project closes.
Sideways: sharing with a teammate
Share a note directly with one or more workspace members. It lands in their inbox (“shared with me”) without becoming team-wide Knowledge. This is the right move for “you specifically should see this.”| Action | Surface |
|---|---|
| Share a note with members | POST /workspaces/:slug/topics/:topicSlug/share-with with { "recipients": ["user_…"] } |
| Your inbox (shared with me) | GET /workspaces/:slug/shared (?unread=true for the unattended feed) |
| Mark one read / all read | POST /workspaces/:slug/shared/:id/read · POST /workspaces/:slug/shared/read-all |
Up: merging into Knowledge
When a note is durable enough for the whole team, it climbs the trust axis: Note → Up for review → Knowledge. Merging is an owner/admin act. An owner or admin merges it, or explicitly asks an agent to run the merge on their behalf. What comes out is the team’s source of truth, the thing agents pull before they edit. See Governance for the full lifecycle and the merge commands.A public read-only link (different thing)
Sharing with a teammate (above) is internal and member-gated. To hand a topic to someone outside the workspace, mint a public read-only link instead:| Share with a teammate | Public link (context share) | |
|---|---|---|
| Audience | a workspace member’s inbox | anyone with the URL |
| Auth | member-gated | unauthenticated, read-only |
| Use when | ”you should see this note" | "show this to someone outside the team” |
