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

199 lines
5.5 KiB
Markdown

---
seo_title: Adapter UI Parser Contract
seo_description: 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.
```text
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:
```json
{
"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.
```ts
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.
```ts
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:
```ts
{ 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.
```ts
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
- [External Adapters](./external-adapters.md)
- [Creating an Adapter](./creating-an-adapter.md)