# 12 — Technical Documentation Corpus

**Rank 27 of 28** · Tier C · `docs/`
**Format:** Markdown with mermaid diagrams, typeset to PDF/DOCX

> **Why this ranks here.** On its own it does not get you hired. Attached to the
> systems above, it is what converts "I worked on that" into "I can defend
> that." Google's promotion process and every bank's change-control process run
> on documents like these. Do not lead with it — but bring it.

---

## Three book-length manuals

### `docs/webrtc-chat/` — 20 chapters
Executive summary → architecture → protocol spec → Go backend → call lifecycle
→ media plane → ICE/STUN/TURN → iOS → web → edge → Cassandra → Kafka/Redis →
security → observability → deployment/runbook → **gap register** →
**remediation roadmap** → onboarding → appendices → task list.
Also typeset: `TheOne-WebRTC-Chat-Engineering-Manual.pdf` / `.docx`, plus a
diagram bundle.

### `docs/billboard/` — 17 chapters
The same spine applied to the music mode, and it contains the artifact worth
showing: **`14-SPOTIFY-PARITY.md`**, a feature-by-feature comparison scoring the
system at **14 of 52** against Spotify. A candidate applying to Spotify who has
already written an honest parity gap analysis of their own product against
Spotify's is having a different conversation than everyone else in the pipeline.

Plus `10-API-CONTRACT-DIFF.md` (client expectation vs server reality, line by
line), `13-GAP-REGISTER.md`, and a session-record directory tracking decisions,
blockers, inferences, and a deploy queue.

### `docs/dating/` — audit + remediation
Technical report, WebRTC report, remediation plan, performance analysis, and
integration plans. Headline findings: **dual match backends**, a **three-way
identity split**, **three chat table families**, dead iOS swipe paths, and
credentials committed to a repository — each named rather than smoothed over.

## The recurring structure

Every manual follows the same discipline:

1. **State the scope and the date.** ("as of 2026-08-25")
2. **One diagram of the whole system**, with dead components marked dead.
3. **Component inventory** — path, runtime, status.
4. **Every hostname the client dials**, traced to the line that dials it.
5. **Gap register** — numbered, severity-ranked.
6. **Remediation roadmap** — what to fix, in what order.
7. **Task list** — the roadmap made executable.

## Why this matters for the target role

The rarest thing in a systems interview is a candidate who says *"here is what
is broken in the thing I built, ranked, with the cost of each fix."* These
documents are that, three times over, written before anyone asked for them.

Files like `docs/billboard/session/BLOCKED.md` and `INFERRED.md` — separating
what was *verified* from what was *assumed* — are the same instinct that makes
a good incident report.