suggestions

Asks the workspace's AI provider for a template — a name and a tree of nodes — from a description in the caller's own words, for the collection the template would belong to. The tree is held to the collection's capability profile: the prompt says which types may sit under which, and a node the profile refuses is dropped from the answer rather than stored. Asynchronous and answered 202, for the reason every AI call in this product is: the provider is somebody else's machine. The answer appears under GET /suggestions as a TEMPLATE suggestion with target_type=CONTAINER and the collection as its target; its payload is a TemplateInput, which is what accepting creates — through CreateTemplate, as the accepting person, with their rights at the collection and its own audit entry. A workspace with no provider, or one that has not consented to AI processing, is answered 503 with the detail code ai.unavailable, and nothing is queued and nothing is sent.

Asks the workspace's AI provider to propose the work packages and activities that would carry one entry. It proposes and changes nothing: the breakdown is read through GET /suggestions and is created only when somebody accepts it, one ordinary create at a time with their own rights at each destination. Asynchronous and answered 202, for the reason every AI call in this product is: the provider is somebody else's machine. A workspace with no provider, or one that has not consented to AI processing, is answered 503 with the detail code ai.unavailable, and nothing is queued and nothing is sent. Accepting a breakdown can be partial. Each piece is its own create with its own permission check, and a refusal at the third leaves the two before it standing — which is the honest outcome for a person who accepted a breakdown and got most of it, rather than losing all of it to one title that was too long.

Asks the workspace's AI provider to propose a title, notes, a due date and labels for one entry - what the automation action AI_SUGGEST_FIELDS does. Asynchronous and answered 202; a workspace with no provider or no consent is answered 503 with ai.unavailable.

Asks the workspace's AI provider to summarise one entry into its notes - what the automation action AI_SUMMARIZE does. Asynchronous, and a proposal unless the caller asks for it to be applied.

Asks the workspace's AI provider for the entry's title and notes in a language the caller reads. Display only, and nothing is stored: user content is never translated in place, no suggestion is recorded, and there is nothing to accept — a person reads the answer and it is gone. Synchronous, the way the search's meaning is, and bounded the same way: the caller is waiting, so the call has a short timeout and every way of not getting an answer — no consent, no provider, a spent budget, an open breaker, a slow model — is 503 with ai.unavailable; a spent budget adds the parameters reason (budget_spent) and renews_at, the moment it has room again. Reading the entry is the permission asked, because reading it is what this does; the workspace's consent to send its content to a provider is asked after it. The audit records that a translation was asked for an entry and into which language, never the text.

Asks the workspace's AI provider to propose labels for one entry - what the automation action AI_CLASSIFY does. Asynchronous, and a proposal unless the caller asks for it to be applied.

Asks the workspace's AI provider to summarise the comments on one entry — the discussion rather than the entry. Oldest first and bounded: a thread of four hundred comments is a token problem rather than a summary problem, and the bound is part of the design rather than a surprise at the provider. Asynchronous and answered 202, like every AI call here; a workspace with no provider or no consent is answered 503 with ai.unavailable, and nothing is queued and nothing is sent. The answer appears under GET /suggestions as a proposal for the entry's notes, which somebody accepts or dismisses. A comment is somebody's writing and travels as content, never as instruction. Nothing about it — no comment, no author, no title — reaches a log, a metric, a trace or an audit entry; what the trail records is that somebody asked, about what, with which prompt.

Asks the workspace's AI provider how one collection stands — what is open, what moved, what is overdue — in the shape a person asks a colleague on a Monday. The entries it reads are the ones directly in the collection, in the collection's own order and bounded. Asynchronous and answered 202, with the same refusal for a workspace that has no provider or has not consented. The answer appears under GET /suggestions with target_type=CONTAINER. Nothing accepts it. A collection has nowhere to put a status summary — a description says what a collection is for, not how its week went — so the suggestion is the answer: read it, and :dismiss closes it.

Answers the entries that sit near this one in the embedding space. No provider is asked and no budget is spent: the vectors are the ones search by meaning already maintains, so this is a query with a threshold rather than a completion. Answered 200 with a suggestion when something is near, and 204 when nothing is — which is also the answer where the installation carries no pgvector, where the workspace has no provider that can embed, and where the entry's own vector has not been produced yet. All four are "nothing to propose" rather than an error, and the first two are visible before anybody asks, under semantic_search in GET /meta/capabilities. The neighbours are narrowed to what the caller may read, and an entry's own parent and its children are never among them: a work package is not a duplicate of the task it sits in. Accepting is not what happens to a duplicate. The suggestion records what was found; what a person does about it — archive one, trash one, move one under the other — is their own decision through the ordinary use cases, so POST /suggestions/{id}:accept refuses a DUPLICATES suggestion and :dismiss is the answer that closes it.

The suggestions standing against one entry, newest first. Nothing here has changed anything: a suggestion is a record with a name on it — the model, the prompt version and the moment — and it becomes a change only when somebody accepts it, as their own write with their own rights. Needs whatever reading the target itself needs. A suggestion about an entry says something about that entry, so it is exactly as readable as the entry is.

Applies what was proposed, as the accepting person's own write: the ordinary use case, with the ordinary permission check, the ordinary validation and the ordinary history entry. A suggestion cannot grant anybody anything — somebody who could not make the change by hand cannot make it by accepting. Two audit entries follow, deliberately: the acceptance and the write. "Who decided this" and "what changed" are two questions, and a year later only the first explains the second. A suggestion made against an entry that has since been rewritten is stale and is refused (409, detail code suggestions.stale): applying it would attach a proposal about one state of the entry to a different one. Ask for a new suggestion instead. The optional body carries what the person changed or added before accepting — an edited title, or the destination collection a jumble suggestion cannot know. It is merged over the proposal, and it is the caller's own input checked by the use case with the caller's own rights, exactly as if they had made the call themselves. The suggestion's target is never taken from either the proposal or the overrides: a proposal about one entry cannot be made to change another.

A state, not a deletion: the record stays readable, so "what was proposed and turned down" has an answer, and the retention engine ages it out by rule rather than by hand. Dismissing an already decided suggestion is refused rather than silently repeated.