Capability Apps
A capability app is a self-contained piece of UI + client-side logic that implements one specific product capability well enough to be reused as-is by more than one host application — rather than each app re-implementing its own version of the same form/flow against the same backend domain.
This is a documentation grouping, not a package boundary today — every
capability app currently lives inside PlayoutAdmin's source tree, built
for PlayoutAdmin's own screens first. The point of calling them out
separately here is that their scope, API contract, and known gaps are
meant to be understood independent of PlayoutAdmin, since the next
consumer (Tellyboard's own admin, most immediately) is expected to embed
or port the same component rather than reinvent the flow against the raw
domain/media API.
Why this distinction matters for a consuming team: the rest of
docs/domain/media/ documents the backend — routes, schemas, pipeline
behavior. These pages document the frontend contract on top of it —
which fields a form actually sends, what it detects/decides client-side
before it ever calls the API, and which parts are still placeholder
(hardcoded values, unbuilt pickers) that a second consumer needs to know
about before depending on the current behavior.
Capability apps documented here
| App | Backend domain | Host app today | Status |
|---|---|---|---|
| Media Upload | media | PlayoutAdmin (AddContentSheet.jsx) |
Working, several hardcoded assumptions — see its To-do list |
| Media Transcoding Presets | media — TranscodingProfile/TranscodingProfileVersion |
PlayoutAdmin (TranscodingProfileList.jsx + ProfileEditSheet.jsx) |
Full CRUD, all 3 categories (video/image/document) |
Both apps sit on top of the same domain/media backend documented in
docs/domain/media — read that first for the
pipeline/API side; these pages pick up where that leaves off, at the
form and its decisions.
Adding a new capability app to this list
A page belongs here if it's a UI flow another team is expected to reuse or port, not just any React component. When adding one:
- Create
docs/capability-apps/<kebab-case-name>/index.md. - Trace the actual functions called, in call order — not just a feature list. A second team porting this needs to know which client-side decision (file-extension sniffing, category mapping, passthrough detection, etc.) happens before which API call, since that's exactly the logic they'd otherwise have to reverse-engineer from the component source.
- Call out every hardcoded/placeholder value explicitly, with a To-do — a capability app being reused elsewhere is exactly the moment a "temporary" hardcoded tenant or folder stops being safe to copy silently.
- Add a row to the table above.