[Meerav29]

Part of #4 (autopilot log).

What this slice does

Adds skill/design.md, the design for turning discourse-lens into a Claude.ai chat skill, and skill/contract.schema.json, the JSON contract between the research step and the artifact. It also logs 5 decisions in docs/autopilot/decisions.md and sets slice-1 to in-review in the queue.

The open problem (how the map gets drawn) is settled as approach A. Claude judges which topic each source belongs to, how well it fits, and which propositions it takes a stance on. The artifact computes a seeded force layout in plain JS, with no CDN dependency: topics that share more propositions sit closer together. Embeddings and UMAP are rejected because the sandbox has no bundled model and Hugging Face isn't on the default egress list. Claude writing x/y directly is rejected as fake precision.

Review pack

About 25 minutes:

1. Read skill/design.md (176 lines, ~15 min). §0 is the whole design in one paragraph. §4 is the map decision. §6 is the source budget and what it costs in map quality.
2. Read §1's capability table (~3 min). Rows V1–V6 are verified against docs and linked. Rows A1–A6 are assumptions. §10 lists the three things worth checking in a real Claude.ai chat before slice-3: whether sandbox files persist across turns (A4), whether a sandbox HTML file can be the artifact (A5), and whether cdnjs loads in chat artifacts (A1).
3. Skim the decisions at the bottom of docs/autopilot/decisions.md (~5 min).
4. Optional: skim skill/contract.schema.json. It's the fixture's shape plus optional fields.

The thing to be skeptical about: whether ~35–45 sources (25–30 read in full) is enough to show real camps. §6 predicts the fixture's two small AI topics would merge at that size.

Acceptance criteria

Section numbers refer to skill/design.md.

• Which views survive, with reasons. §3 has a table covering all six (map, claims, key terms, timeline, ask, reader) plus source review, outliers/table, and export. Map and Claims are kept; Key terms and Timeline are merged; Ask moves to chat; Reader is dropped and replaced by a source card.
• How the map gets drawn: ≥3 approaches, feasibility, verified vs assumed, a pick. §4.1 compares four approaches (A force layout from Claude's judgments, B embeddings+UMAP, C Claude places points, D TF-IDF+SVD). §1 marks each capability verified (with a doc link) or assumed. §4.2 picks A and says why. Supporting evidence, computed on the fixture:

  topic  umap-nearest  most-shared-propositions
  0      1             [1, 5] (tie, hit)
  1      0             [0]    hit
  2      3             [3]    hit
  3      2             [2]    hit
  4      5             [5]    hit
  5      4             [0]    miss
  

• Data contract / JSON schema. §5 and skill/contract.schema.json. It's a strict superset of the fixture. Validated with jsonschema 4.26.0:

  fixture errors: 0
  bad-date errors: 2   (same fixture with one date set to "May 2024": rejected)
  

  The first validation run did fail: fixture article 18 has title: null. The schema now allows a null title, and the renderer falls back to the domain.
• Source budget, and quality compared with the app. §6 gives a table (8–12 searches, 15 full reads per turn, up to 3 turns, ~35–45 sources on the map) and five concrete effects on quality, measured against the fixture's numbers. The token figures behind the budget are estimates (A6), and the doc says so.
• Copyright. §7: paraphrase-only fields with length caps the schema enforces, at most one quote of ≤15 words per source, no page text in any file, link-out source cards, no paywall circumvention.
• What the prototype must prove. §8 has nine checkable statements (P1–P9) with thresholds.
• Non-goals and anti-goals. §9.

Checks run: the schema validation above, and the fixture analysis script (inline Python, not committed). The repo's own CI also runs on this PR and passed on head 5f7bffe: Backend (lint, tests), Frontend (types, lint, unit tests, build), and End-to-end. Those checks cover the app, which this PR doesn't touch, so they only confirm nothing broke; they don't check the design.

Couldn't verify:

• That claude.ai chat artifacts use the same CSP as Claude Code artifacts (A1).
• What the claude.ai sandbox has preinstalled (A2). The documented list is for the API tool.
• Sandbox persistence across turns (A4).
• Sandbox file → artifact (A5).
• Chat context size (A6).
• A pinned d3-force version. The CDNs weren't reachable from this sandbox, so slice-2 has to check one.

The design is built so that none of these breaks it outright; §1 gives the fallbacks.

Decisions made without you

All five are also in docs/autopilot/decisions.md.

1. Map layout: approach A. Rejected: B (no model or egress), C (fake precision), D (unverified scikit-learn, weak signal; kept as a later option).
2. Views. Claims runs by default instead of opt-in, because Claude has already read the pages. Ask moves to chat and Reader becomes a source card. Rejected: an in-artifact Ask (it would need article text inside the page).
3. Source budget: ~35–45 sources over up to 3 turns, with 1–2 labelled "dissent" queries. Rejected: matching the app's 50–100 (doesn't fit in context); a single turn only (too few camps).
4. Contract is a strict superset of the fixture. Rejected: a fresh schema.
5. No runtime JS dependency in the template, with d3 as the fallback. Rejected: d3 by default, because of the unverified chat CSP.

Deliberately not included

• No prototype or skill code. Those are slices 2 and 3.
• The contract checker (build_map.py) is only specified (§5, P8), not written.
• No change to backend/, frontend/, tests/, AUTOPILOT.md or CLAUDE.md. No article text.
• No check of the assumptions in a real Claude.ai chat; this sandbox can't do that.

How to revert

Close this PR unmerged. If it was merged: git revert <merge-commit> on auto/queue. That removes skill/design.md and skill/contract.schema.json and the decisions entries, and you'd also need to set slice-1 back to todo in docs/autopilot/queue.md.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Syq9WDBc9qa8wP5T1LvVmG