Files
v10/internal/design
Christian PillsburyandClaude Opus 4.8 2820b844b8 docs(spf): record live-window-guard fix and live/DVR seekable + anchor-coupling follow-ups
- live-stream-support.md: correct the window-exit guard description and
  test matrix to match the shipped fix (guard no longer bails on
  `seeking`); add the resolved out-of-window-seek-stall note; add Open
  questions for the seekable-range "lip", clamp-to-seekable as the
  general mechanism, and back-of-window yank-to-edge on discrete window
  slides. Remove stray EOF tags.
- live-presentation-modeling.md: add Open question flagging the
  model <-> anchor <-> resolve-track coupling for a holistic revisit.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-25 11:52:15 -07:00
..
2026-04-13 22:25:35 -07:00

Design Docs

Decisions you own — documented for posterity.

What Belongs Here

Design Docs are decisions you own. Write one when:

  • Making architectural decisions in your area
  • Choosing between implementation approaches
  • Introducing design patterns others will follow
  • Documenting internal APIs or component specs

When to Use RFC Instead

Use an RFC (rfc/) when:

  • Changes public API surface
  • Affects product direction
  • Affects user-facing developer experience
  • Significant changes to core architecture
  • Hard to reverse once shipped

Rule of thumb: If you need someone else's approval, it's an RFC. If you're documenting your own decision, it's a Design Doc.

Format

---
status: decided
date: 2025-01-27
---

# Title

## Decision

What you decided. Be direct.

## Context

Why this came up. What problem triggered the decision.

## Alternatives Considered

- **Option A** — Why not chosen
- **Option B** — Why not chosen

## Rationale

Why this choice wins. Keep concise.

Status Values

Status Meaning
draft Thinking through it, not final
decided Decision made, documented
implemented Built and shipped — kept for rationale
superseded Replaced by another design doc

Archive

archive/ contains design docs for fully implemented features where the "what" is now captured by the code itself. These docs are preserved for reference but are no longer actively maintained. Docs with high "why" value (decisions, rationale, alternatives) stay in the main directory with status: implemented.

File Naming

Use lowercase with hyphens:

queue-design.md
hook-naming.md
skin-theming.md

See Also

  • Decisions — ADR-style single-decision records
  • RFCs — Proposals needing buy-in
  • Plans — Implementation details
  • CLAUDE.md — How these relate