Files
paperclip-docs/docs/reference/adapters/adapter-ui-parser.md
Aron PrinsandClaude Opus 5 325c9eb819 seo: hand-write titles and descriptions for all 192 pages (#115)
## Why

The build derived `<title>` from the **sidebar label** and the
description from the **first paragraph clipped to 220 characters**. Both
are the wrong source. A sidebar label is written for a 240px-wide nav
that supplies its own context; a search result has none.

On production that produced:

- **7 pages titled "Overview"**, and 32 pages sharing a title with
another page
- **109 of 193 descriptions cut off mid-word**, and 174 over 160
characters (where Google truncates)

```
/guides/welcome/key-concepts/
  BEFORE (220):  ...and if you misunderstand them early, the product wi
```

Near-identical titles are the weak-differentiation signal behind
"crawled — currently not indexed", which is the exact symptom on this
property.

## What changed

`seo_title` and `seo_description` frontmatter on **every one of the 192
pages**, written by hand against each page's real content and optimised
for the click — lead with what the reader can do, name the concrete
things covered, no keyword stuffing, no repeating the title.

| | Before | After |
|---|---|---|
| Duplicate titles | 32 pages | **0** |
| Duplicate descriptions | — | **0** |
| Descriptions cut mid-word | 109 | **0** |
| Descriptions over 160 chars | 174 | **0** |
| Title length (incl. suffix) | up to "Overview" | **26–60** |
| Description length | 31–240 | **122–158** |

**No prose was rewritten.** I measured content overlap between the
colliding pairs first — only 17–23%, so these were always distinct pages
wearing the same label, not duplicate content. The `docs/` diff is **564
insertions, zero deletions**.

### Examples

```
BEFORE — all seven identical:  "Overview | Paperclip Docs"
AFTER:  "Adapters Overview"      "API Overview"        "CLI Overview"
        "Deployment Overview"    "Bundled Skills"      "Optional Skills"
        "Experimental Features"

BEFORE — both identical:  "Issues | Paperclip Docs"
AFTER:  "Issues: Creating and Tracking Work"   /guides/day-to-day/issues/
        "Issues API"                           /reference/api/issues/
```

```
/guides/getting-started/five-minute-path/
BEFORE (220):  The shortest route from a running Paperclip instance to an agent that has
               just completed work for you. After Paperclip is installed, the path takes
               about 5 minutes: create a company, hire a CEO agent, approve its first s
AFTER  (131):  Install Paperclip, create a company, hire a CEO agent, and approve its
               first strategy — a working AI company in about five minutes.
```

## Plumbing

- **`site/build-release.mjs`** prefers the authored fields; the derived
path stays only as a fallback the CI gate prevents ever reaching.
`<title>`, `<meta name="description">`, and the `TechArticle` JSON-LD
all read from the same source.
- **`site/app.js`** uses the same fields, so a client-side transition
cannot leave a different title on screen than the crawler was served.
Verified in-browser: navigating `/guides/day-to-day/issues/` →
`/reference/api/issues/` swaps to exactly the server-rendered values, no
JS errors.
- **`scripts/verify-seo-metadata.mjs`** (new) enforces presence,
uniqueness, length, complete-sentence endings, and the
frontmatter-safety rules. Wired into `docs:test` and CI as its own step.

I negative-tested the gate rather than assuming it works — it correctly
fails on a duplicate title, a mid-word description, and a missing field,
and passes again once restored.

## Automating it going forward

`skills/sync-docs/SKILL.md` now:

- gains an **"Authored SEO metadata"** section: why the fields exist,
the enforced rules as a table, and how to actually write them (title
names the subject not the nav position; description writes for the
click; never generate mechanically from the first paragraph — *that is
the fallback the gate exists to prevent*).
- requires both fields in the **page-authoring instruction** given to
every subagent, with guidance on when to update an existing description
versus leave it.
- runs `docs:test:seo-metadata` and `docs:test:crawlable-links` as
**fail-loud gates in Phase 7** before commit.
- documents all six build gates in the files/gates section.

So once this lands, a new page cannot ship without hand-written
metadata, and a title collision cannot reach production.

## Verified

All six verifiers pass:

```
Static route verification passed
Asset fingerprint verification passed
Hierarchical Skills nav verification passed
Skill source block verification passed (11 skill pages, 1 control page)
Crawlable-link contract passed: 40886 internal links across 194 pages resolve in one hop
Authored-SEO contract passed: 192 pages carry a unique, hand-written seo_title and seo_description
```

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------

Co-authored-by: Claude Opus 5 (1M context) <[email protected]>
2026-08-25 22:51:42 +02:00

5.5 KiB

seo_title, seo_description
seo_title seo_description
Adapter UI Parser Contract Paperclip streams adapter stdout to the run viewer live. Ship a UI parser so structured lines render as tool calls and results instead of raw text.

Adapter UI Parser Contract

Paperclip streams adapter stdout to the run viewer in real time. If your adapter emits structured lines, ship a UI parser so the viewer can render tool calls, tool results, thinking blocks, and system messages instead of treating everything as plain assistant text.

Use this page when:

  • you are building an external adapter
  • your runtime emits structured stdout
  • you want the run viewer to show more than a shell transcript

What It Solves

Without a custom parser, the UI falls back to the generic shell parser. That means:

  • tool invocations appear as plain text
  • tool durations and results are lost
  • stderr and system markers are harder to distinguish

With a parser, the run viewer can render a richer transcript and keep the execution story readable.

Tip: If your runtime only prints plain text, you can skip the parser entirely and let the generic shell parser handle it.


How It Loads

  1. The adapter package exposes ./ui-parser in package.json.
  2. The server reads that module and serves it at GET /api/adapters/:type/ui-parser.js.
  3. The browser fetches the module when the user opens a run.
  4. The UI evaluates the parser in a browser sandbox and registers it for that adapter type.
package.json -> dist/ui-parser.js -> GET /api/adapters/:type/ui-parser.js -> browser eval -> transcript rendering

Note: The parser module must be self-contained. No runtime imports, no DOM access, and no Node APIs.


Package Contract

Your package should declare the parser contract version:

{
  "paperclip": {
    "adapterUiParser": "1.0.0"
  }
}

The host checks this value before loading the parser.

Host expects Adapter declares Result
1.x 1.0.0 Parser loads
1.x 2.0.0 Host logs a warning and falls back to the generic parser
1.x missing Parser loads for now, but future versions may require the field

Export Shapes

Your dist/ui-parser.js must export at least one of these shapes:

parseStdoutLine(line: string, ts: string): TranscriptEntry[]

Use this when each line can be parsed independently.

export function parseStdoutLine(line: string, ts: string): TranscriptEntry[] {
  if (line.startsWith("[my-agent]")) {
    return [{ kind: "system", ts, text: line }];
  }

  return [{ kind: "assistant", ts, text: line }];
}

createStdoutParser(): { parseLine(line, ts): TranscriptEntry[]; reset(): void }

Use this when you need state across lines, such as multi-line tool output or continuation handling.

let counter = 0;

export function createStdoutParser() {
  let awaitingResult = false;

  function parseLine(line: string, ts: string): TranscriptEntry[] {
    const trimmed = line.trim();
    if (!trimmed) return [];

    if (trimmed.startsWith("[tool]")) {
      const toolUseId = `tool-${++counter}`;
      awaitingResult = true;
      return [{ kind: "tool_call", ts, name: "shell", input: {}, toolUseId }];
    }

    if (awaitingResult) {
      awaitingResult = false;
      return [{ kind: "tool_result", ts, toolUseId: `tool-${counter}`, content: trimmed, isError: false }];
    }

    return [{ kind: "assistant", ts, text: trimmed }];
  }

  function reset() {
    awaitingResult = false;
  }

  return { parseLine, reset };
}

If both exports are present, the stateful parser takes priority.


Transcript Entries

These are the entry kinds the viewer understands:

{ kind: "assistant"; ts: string; text: string; delta?: boolean }
{ kind: "thinking"; ts: string; text: string; delta?: boolean }
{ kind: "user"; ts: string; text: string }
{ kind: "tool_call"; ts: string; name: string; input: unknown; toolUseId?: string }
{ kind: "tool_result"; ts: string; toolUseId: string; content: string; isError: boolean }
{ kind: "system"; ts: string; text: string }
{ kind: "stderr"; ts: string; text: string }
{ kind: "stdout"; ts: string; text: string }

Use toolUseId to link a call to its result. The UI renders those pairs as collapsible cards.

Warning: Never throw from the parser. If you cannot parse a line, return a plain stdout entry instead.


Constraints

  1. No runtime imports.
  2. No top-level side effects.
  3. No DOM or Node APIs.
  4. Deterministic output for the same (line, ts) input.
  5. Error tolerant behavior on every line.
  6. Keep the bundle small. The parser is served and evaluated per run.

Testing

Test your parser against a sample transcript before publishing the package.

import { createStdoutParser } from "./dist/ui-parser.js";

const parser = createStdoutParser();

for (const line of [
  "[my-agent] Starting session abc123",
  "Thinking about the task...",
  "[tool] read /src/main.ts",
  "const main = () => {}",
]) {
  const entries = parser.parseLine(line, new Date().toISOString());
  console.log(entries);
}

If the parser is browser-safe and exports the right shape, Paperclip can load it dynamically at runtime.


When To Skip It

You can omit the parser entirely when:

  • the runtime prints plain text only
  • tool boundaries do not matter to the user
  • the generic shell transcript is already readable enough

That is a valid choice for simple adapters and command wrappers.


Next Steps