Visual Brief

Visual Brief

Start with a Visible Acknowledgment

Before a long setup or implementation block, send the human a short visible acknowledgment in the current conversation. Say what you are starting and where you will publish the result. Do this before creating files or running lengthy commands.

The same rule applies to a substantial request sent through the page. Answer the thread first with one short confirmation. Publish the completed work later. If the request takes only a moment, answer it directly without a separate acknowledgment.

Use the Page as the Report

The human reads the page. The chat only points to it. Put the complete report on the page, including conclusions, limits, reasoning, and evidence. Do not repeat the report in the terminal response.

A visual brief is useful for substantial implementation results, design reports, investigations, reviews, and decision sets. Trivial progress and small fixes belong in ordinary conversation. An explicit request for a visual brief overrides this threshold.

The page supports layers:

• glance states one plain claim.
• explanation gives the reasoning in full.
• forensics holds raw evidence, file paths, output, errors, and numbers.
• tables hold repeated or comparable values.

Keep each prose field as a flowing thought. Several distinct facts should be separate items, table rows, or forensic notes. Do not cram numbered lists into glance, explanation, or a conversation turn.

Publish One Complete Briefing

Every normal publish accepts one JSON object with exactly these fields:

• id
• timestamp
• headline
• summary
• lanes

visual-brief publish appends that object to updates. The last entry, updates[-1], is the latest briefing. The page gives it the prominent card treatment. When another briefing arrives, the prior latest keeps its stable id and moves into the quieter earlier-briefing ledger. Its folds, drafts, conversations, and pending state remain attached to the same record.

There is no separate current-state object and no separate changes object. Do not send the retired current_state plus changes envelope.

Choose one to six lanes for the report. Lane names should fit the actual work. There is no required template. A lane may explain new work, current behavior, limits, decisions, evidence, or next actions. Include a section about recent changes only when that content helps the reader.

Use plain prose in the headline and summary. Avoid internal codenames, unexplained abbreviations, bare file names, arrows, status chains, or process metrics. Test counts and review rounds are evidence for a claim, so place them under the relevant item.

Never author questions in a publish payload. The queue, fold, and answer commands own conversations. The latest briefing root, every lane, and every item can receive chat.

Create and Serve a Run

visual-brief new --label "what this session is about"
visual-brief serve --port 8765
visual-brief list

new prints both local URLs. One loopback-only daemon serves all active runs. --run RUN is optional when exactly one run exists.

Publish through the CLI:

visual-brief publish --file report.json

The payload is direct:

{
  "id": "parser-verification",
  "timestamp": "2026-08-04T12:00:00Z",
  "headline": "The parser now rejects truncated policies",
  "summary": "Focused comparisons pass, while one wider limit remains.",
  "lanes": [
    {
      "id": "verified-behavior",
      "name": "Verified behavior",
      "items": [
        {
          "id": "truncated-policy",
          "glance": "Truncated policies now return a syntax failure.",
          "explanation": "The local result agrees with the reference parser.",
          "trust": "verified-by-me",
          "forensics": [
            "focused comparison: 12 cases, 0 disagreements"
          ]
        }
      ]
    }
  ]
}

Each lane has id, name, and items. Each item has id, glance, explanation, and trust. Optional item fields are forensics, tables, and suggestions.

trust is one of:

• verified-by-me
• reported-by-agent
• unverified
• known-limitation

Use zero to three suggestions only when a few specific replies would help the human act on that item. Each suggestion has a short label and the full message it sends. A selected suggestion becomes a human conversation turn; fold and answer it like any other message.

A forensic entry may be a raw string or a note with title, body, optional id, and optional children. Markdown works in visible prose fields and conversation turns. Links are active only for https, http, and mailto.

Payload commands accept --file F or a bare - for standard input. add-update remains only for compatibility imports. Normal reports use publish.