Skip to main content

​
crewship consolidate

Trigger the Consolidate worker — the background process that compacts recent agent/crew journal activity into semantic rules appended to .memory/topics/learned-*.md. Normally runs on a 6h schedule; this command forces an immediate pass.

​
Subcommands

Every subcommand honours the global --format flag (json/yaml/ndjson) — see Output Formats.

​
crewship consolidate run

The command takes no positional args — scope is passed via flags. A bare crewship consolidate run backend-team fails (unknown command). Sample outputs:
accepted=true on a triggered run confirms the request was genuinely accepted (not just that a 202 came back). Accepted, but skipped (202) with a note means the consolidator is wired but lacks a summarizer client — set OLLAMA_HOST and install a chat model.

​
crewship consolidate proposed

The human-in-the-loop half. When the consolidator runs with CREWSHIP_CONSOLIDATE_HITL=1 it does not write extracted rules straight into a crew’s canonical learned-*.md. It stages them in .proposed/, records a pending row, and raises an inbox item — and these four verbs are the decision side of that.
CREWSHIP_CONSOLIDATE_HITL is unset by default, and with it unset nothing is ever staged: the consolidator writes directly and these commands can only ever return 404. That is a configuration answer, not a fault. See Environment.

​
Finding a proposal id

There is no list endpoint — proposals are addressed by id and nothing enumerates them. The id travels on the inbox item the proposal raises:
The id is on the item’s payload.proposal_id, and looks like mp_20260826T101500-abcdef0123456789.

​
Reviewing one

explain reports the crew, the rule count, how many journal entries were scanned, the evidence the rules rest on and the scores the consolidator assigned. Under --format json the evidence and scores blobs stay JSON rather than being flattened to strings. diff prints the unified diff between the crew’s canonical file and what it would become. The server builds this preview through the same code path approve writes through, so it is byte-for-byte what lands.

​
Approving and rejecting

Approving merges the staged rules into the canonical file and records a new memory version, so it prompts first. With --diff the preview is fetched before the prompt — a preview shown after the decision would not be one. Under --format json/yaml/ndjson the preview is not printed alongside the result — it travels inside it, on a preview key, so stdout stays a single parseable document.
--reason is sent and echoed back, but the server does not persist it: memory_proposals has no reason column yet. The command says so rather than implying an audit trail that is not there. Put anything you need to keep in the crew’s journal instead.

​
Requirements and errors

​
Requirements

  • Auth: OWNER or ADMIN role (403 otherwise).
  • Ollama: The consolidator needs a summarizer LLM. In local dev, start Ollama with the external-SSD model path:

​
Errors

​
Journal entries emitted

Even when skipped, the run emits both system.consolidation_triggered and system.consolidation_completed so the audit trail captures the no-op. See the Consolidate guide for payload shapes.