Files
LlamaCasty/HANDOFF.md
T
gramps 2a15be21bd HANDOFF: vv webcam plan locked; drop the unverified vertical-preview landmine
Planning-only session: no code, no build, no test run. The creator's vv
(9:16) webcam feature is now specified, and HANDOFF carries the locked
rules plus the code facts needed to build it without re-hunting:

- vv Live: small tile, circle OR rect (creator's choice), snapped to one
  of six spots (top/bottom x L/C/R). vv Chat: rect only, plus enlarge to
  fill one 607x540 area (exactly 50% of the frame), top or bottom.
  16:9 and Starting/BRB/Ending unchanged.
- Placement by tap/click-drag with snap, like the socials, plus manual
  entry in properties. vv keeps its own camera layout per scene, so the
  16:9 layout survives switching modes (creator-confirmed).
- Geometry only: preview and compositor both read the element's own
  X/Y/W/H + ClipShape, so the two-tile look falls out of the camera
  covering half the band - no capture, chat-box or blit-path change. The
  existing per-scene clamp already permits 607x540.

Withdraws the HANDOFF landmine "vertical-format regression ... no longer
shrinks the capture border in the preview": never verified, and wrong as
stated - the creator confirms vv dims the two bands astride the centre
band. It cost this session a pointless question.

MyMistakes.md records the session-history search recipe (the creator's
turns live in session_message, NOT part - a hit in part can be my own
text echoing the phrase) and the ask-don't-check lesson plus the
creator's standing reply-format directives.
2026-10-17 09:02:59 -07:00

118 lines
8.4 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# HANDOFF — 2026-10-17 (PLANNING ONLY session; nothing pushed — push at the next milestone)
## At a glance
- **Branch** main, tracking `origin/main`. **origin/main = `931ab46`; HEAD = the tip commit
"HANDOFF: vv webcam plan, and drop the stale vertical-preview landmine"** — **5 ahead, 0 behind**
(nothing pushed; per the commit/push policy, push only when the creator says so). This file cannot
record its own commit's hash, so the tip is named by subject.
- The five local-only commits: `3cb29ea` (previous session's HANDOFF refresh), `a3a4681`
(per-element composite timing + scene dump), `84cbec2` (FramePumpTests thread-safe log sink),
`cdf82f6` (read the first instrumented take), the tip. Always check
`git log origin/main..HEAD` — never trust a handoff's own "0 ahead" claim.
- Working tree clean after the tip commit.
- **This session produced NO code, NO build, NO test run.** It specified the creator's **vv
(vertical 9:16) webcam feature** end to end; implementation has not started. The locked rules are
below — they are the deliverable, and they must land in `TASKS.md` when work is queued.
## vv webcam feature — locked rules (creator, 2026-10-17)
| mode | shape | size | position |
|---|---|---|---|
| 16:9 | as today | as today | as today |
| **vv · Live** | **circle OR rect, creator's choice** | small tile | one of six spots: top/bottom × L/C/R |
| **vv · Chat** | **rect only — no circle option** | normal, or enlarged to fill one area (607×540) | enlarged → top or bottom |
| Starting / BRB / Ending | unchanged | unchanged | unchanged |
- **Placement is set by tap/click-drag with snap, exactly like the socials today**, plus manual entry
in properties. Creator's explicit precedent, not an inferred one.
- **vv keeps its own camera position, size and shape per scene** — creator-confirmed: switching back
to 16:9 restores the desktop layout exactly as it was.
- **No explicit borderless/no-background mode is needed**: round + border/bg options already let the
creator strip both (creator's ruling — this deletes that item from the original request).
- Creator's "square" means the rectangular view (the camera's own aspect), not a literal 1:1 box.
## What the code already gives us (established this session — do not re-hunt)
- **vv = the active tier's centred band crop.** 1080p60-vertical: master band **x 656.25–1263.75
(607.5 wide), full height**, upscaled to 1080×1920 (`MainViewModel.Streaming.cs` `ApplyStreamQuality`
→ `OutputRect*`). The band splits into **two 607×540 areas** (top/bottom) — the creator's "two mini
16:9 views", each exactly 50% of the frame.
- **The Live webcam sits at x≈1425 → entirely outside the band.** That is the whole motivation: in vv
the camera is not misplaced, it is invisible.
- **Geometry only — no render-path change.** Preview (`Controls/PreviewPane.xaml` 144–230) and
compositor (`Services/Compositor/SceneCompositor.cs` 389–397, `DrawBorder`) both read the element's
own `X/Y/W/H` + `ClipShape`, so parking the camera needs no compositor or preview work. The
two-tile look *falls out of* the camera covering half the band — the capture element, chat box and
blit path stay untouched.
- **Round / border / background are independent**: `ClipShape.Round`; `HasBorder` = width > 0 AND a
valid 6-hex colour; `BackgroundEffect` = None/Remove/Blur.
- **Per-scene camera size policy already exists**: `MaxWebcamWidthFor/HeightFor` (Chat 1358×764,
others 960×540) + `ClampWebcamToBounds`. **A 607×540 tile sits inside both → the clamp needs no
change.**
- **Storage**: `WebcamSceneConfig` table; new columns go in `MigrateWebcamConfigTable()` as idempotent
`ALTER TABLE … ADD COLUMN` guarded on `PRAGMA table_info` — the established "additive, no version
bump" idiom (`RectWidth/RectHeight`, TASK 51's `BackgroundEffect` landed this way) — plus
`LayoutStore.Save.cs` INSERT and `LayoutStore.Load.cs` SELECT.
- **Existing per-element precedent for remembered geometry**: `RectWidth/RectHeight` +
`ToggleClipShape` (`Models/SceneElement.cs` 124–152) — the pattern for keeping the 16:9 layout
while vv owns its own.
## Units (each: ONE Good Dog integration test, own commit, memory in the same commit)
1. **vv camera layout** — stored separately per scene, resolved when the tier changes. Live: small
tile (circle or rect) snapped to one of six spots; drag like the socials + properties entry.
*Test:* with the vertical tier active, dragging the Live camera to top-right places it top-right
inside the band; switching back to 16:9 restores the original layout.
2. **vv · Chat** — rect enforced with the circle option unavailable, plus enlarge-to-one-area
(607×540) snapping top or bottom.
*Test:* in Chat under the vertical tier, enlarge sets the full top area and the circle option is
not offered.
## Corrections made this session
- **Withdrawn landmine (creator-confirmed):** the old line "Vertical-format regression (STALE, not
fixed): 1080p60-vertical selection no longer shrinks the capture border in the preview" was **never
verified**, and it cost this session a pointless question. The creator confirms vv *does* dim the two
bands astride the centre band and that this is expected/best practice. If the original symptom was
something else (the capture element's own border?), it is **unexplained, not known-broken** — do not
re-raise it as a dependency.
- The prev-session content (first instrumented take: judder did not reproduce, no element slow; probe
+ recipe; the four local commits) is unchanged and lives in `ai.md` →
"✅ What the first instrumented take said".
## Next step
- **Implement Unit 1 on the creator's go-ahead.** Nothing is queued in `TASKS.md` — the creator queues
work, and this plan lives here until then. Queue it in `TASKS.md` as part of the first Unit 1 commit.
## Open (operational)
- **verify.sh's known-failure whitelist is too loose (confirmed twice on 2026-10-16):** it passes when
ANY known failure appears, so a new failure rides along unnoticed — and when the ONLY failure is a
known flake (`LayerReorderPersistenceTests.RealMouseDrag_OnTheLayerList_PersistsTheReorder`, which
passes in isolation) it reports "NOT the known pre-existing pair". **Follow-up: require EVERY
failure line to be whitelisted**, and add `MasterLimiter_CapsTheLiveMix_OnThePipe` +
`RealMouseDrag_OnTheLayerList_PersistsTheReorder` to the list.
- **A pre-existing stash is still sitting there:** `stash@{0}` = "WIP on main: 0464593 Compositor:
fast-path opaque 1:1 when source fills canvas" (NOT this session's; do not drop it blindly).
- The judder reproduction take in the FAILING geometry (vertical 1080p60 first) is still outstanding —
**no fix until a take names the stage** (see `ai.md`; the `parts` line decides the latch hypothesis).
- ⛔ Sudo password rotation pending (user; then update both `CREDENTIALS.md` password lines).
- TASK 56 secret scan before `gramps/LlamaCasty` goes public.
- TASK 55 disk hygiene (`startup.log` uncapped — 23MB and the new lines add to it every 5s).
## Tests
- Last full run: **428/428 passed, 0 warnings** (2026-10-16, the gate run for `84cbec2`). **No run this
session (planning only).**
- Known flaky-by-environment (all pass in isolation): `AudioPipelineTests.Mix_HonorsProviderGains…`,
`MasterLimiter_CapsTheLiveMix_OnThePipe`, `LayerReorderPersistenceTests.RealMouseDrag…`,
`Round_Clip_Corner…`. **Read verify.sh's output — it can pass with an unlisted failure present, or
fail on a known flake (see above).**
## Secrets / paths (do not re-hunt)
- Layout DB: `%APPDATA%\ytLlive\ytLlive.db` (SQLite, full-rewrite per save). Auth:
`%APPDATA%\ytLlive\ytLlive.auth` (DPAPI). Startup log: `%APPDATA%\ytLlive\startup.log` (23MB).
- Recordings land in `C:\Users\gramp\Downloads\recordings\` (`ty-<date>-<time>-<ms>-<seq>.mp4`; a
duplicate name gets a `-2` suffix — the log's path and the file on disk can differ that way).
- **Conversation history (how to recover what was actually said):**
`~/.local/share/opencode/opencode.db`, table **`session_message`** (`type='user'`, text in
`data.text`). The `part` table holds only assistant-authored text — searching it for a creator
message returns nothing. Recipe + command in `MyMistakes.md`.
- LAN credentials: `CREDENTIALS.md` (gitignored). Google Cloud OAuth project number `198374416003`,
owned by `llamachile.shop@gmail.com` — verify at
`https://console.cloud.google.com/apis/credentials?project=198374416003`.