Prototype Tiny Bot PiP as an optional dogfood experiment

[shiny-code-bot]

Objective

Evaluate whether a user-initiated, low-frame-rate Tiny Bot status video can make Context Panel delightful while another Apple TV app is foregrounded, without abusing Picture in Picture, harming media playback, leaking private status, or turning a speculative idea into committed release scope.

Finish Line

A bounded physical-device prototype proves or disproves the rendering, lifecycle, energy, audio-session, coexistence, privacy, accessibility, and review-positioning assumptions. The issue ends with an explicit ship, dogfood-only, defer, or decline decision and supporting evidence.

Current Status

State: Blocked. The normal tvOS app foundation and signed provider-runway surface are complete, but PiP remains optional post-release research and still depends on stable Work Pulse summary states from #377.

Next action: Once #377 is unblocked and delivers stable summary states, and product appetite is explicit, define a minimal visual state machine and build a physical-device-only prototype that renders genuine status video rather than using PiP merely to keep background code alive.

Blocked by: #377 through the existing native dependency; #377 remains blocked by the intentionally parked external producer contract cbusillo/codex-lab#298.

Waiting for: Stable Work Pulse summary states and an explicit decision to promote a non-MVP experiment.

Last verified: August 11, 2026. The dependency graph remains correct; no implementation or product-scope decision has superseded this optional blocked experiment.

Scope

• User-initiated PiP prototype using supported AVKit video content paths.
• Tiny Bot visual states for working, waiting, needs-attention, quiet, stale, and recently completed.
• Low-frame-rate rendering and bounded resource use.
• Interaction with Plex, YouTube, Twitch, and ordinary tvOS navigation on physical hardware.
• Presentation-detail behavior and immediate hide/stop controls.
• App Review guideline and product-positioning assessment.

Excluded:

• Automatic PiP start, hidden background execution, background audio tricks, or guaranteed persistence.
• Shipping commitment before the decision gate.
• Detailed session lists or raw text inside the PiP window.

Acceptance Criteria

• PiP starts only from an explicit user action and stops predictably.
• The content is a legitimate rendered status video with accurate, bounded state.
• Resource use is measured and remains acceptable over a representative viewing session.
• Silent/background-audio behavior does not interfere with foreground media.
• Status remains readable without exposing unnecessary detail or requiring text at tiny sizes.
• Stale or disconnected data visibly degrades rather than appearing active.
• The prototype is exercised with representative foreground media apps on a physical Apple TV.
• The final decision documents technical evidence, UX value, privacy behavior, and review risk.

Relationships

• Related core tvOS plan: Build a tvOS Couch Mode companion #373; this optional experiment is no longer a child that blocks the core Couch Mode finish line.
• tvOS foundation prerequisite Build the read-only tvOS runway app and CloudKit cache #375 is complete.
• Blocked by Work Pulse consumer Consume Work Pulse and deliver tvOS milestone notices #377.
• Optional research; it must not block the usage/provider tvOS release unless explicitly promoted into scope.

Decisions

• Keep PiP outside the first shipping commitment.
• Render aggregate state, not one icon or card per session.
• Treat a dogfood-only outcome as a valid success.

Open Questions

• Can the visual remain genuinely useful without text-heavy detail?
• Does PiP coexist acceptably with the user's normal media apps and audio expectations?
• Is the delight worth the implementation and review complexity?