mirror of https://github.com/zoriya/v10.git synced 2026-08-16 02:45:09 +00:00

Files

T

Christian PillsburyandClaude Opus 4.8 05a0a6452d wip(spf): non-zero-PTS relocation as establishStartMediaTime reactor + relocation steps

Rebuild relocation from the config-bundle (createRelocation + self-discriminating
origin-discoverer) into a DOM-free per-source reactor plus DOM config-pipeline
steps, per the presentation-timeline design + review.

- behaviors/establish-start-media-time.ts (new, DOM-free): the reactor — 3 states
  (inactive clears the transient slot per source / monitoring runs the injected
  deriveStartMediaTime seam -> writes Track.startMediaTime / established disables it).
  Owns mediaContainerData on state; selection optional/defensive; never touches pipelines.
- behaviors/dom/relocation-steps.ts (new): relocationMessagePipelines — a plain
  config step array. discover writes state.mediaContainerData; stamp reads the
  track's own discovered origin (Tier 1) -> timestampOffset. Steps read composition
  state from call-time deps; coordinate with the reactor only through the slot.
- segment-loader: StepDeps widened with the composition {state,context,config}
  (opaque conduit; the loader never reads them).
- primitives/head-peek.ts (new): generic eager head-peek (replaces origin-discoverer).
- media/types: Track.startMediaTime + MediaContainerData.
- setup-buffer-actors: relocation pipelines from config; threads composition deps.
- engine: composes the reactor + bakes relocationMessagePipelines + mediaContainerData
  + deriveStartMediaTime config, comment-marked for easy removal.
- Deleted relocation.ts, origin-discoverer.ts. Doc + backlog updated.

Deferred (backlog): per-type keying; non-0th-segment origin (#4 — non-zero starts
currently mis-relocate); tier-agnostic apply; text-cue relocation; Tier 2 min;
audio-only wiring.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

2026-07-09 14:05:36 -07:00

README.md

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

File Naming

Use lowercase with hyphens:

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