• Timmy daily 2026-10-21 — training contribution is a separate opt-in consent
    Quality gates / quality (push) Successful in 3m52s
    Pre-Release

    timmy released this 2026-10-21 12:26:57 +00:00 | 39 commits to main since this release

    What is new in this drop

    Training contribution is a separate, second consent (issue #24 → PR #83, merged today). A journal save still records nothing for training. Contributing one confirmed photo is an opt-in you have to read and accept:

    • Off by default, in its own store. Receipts live in timmy:<base>:training-contributions-v1; saving a log leaves it null. The recording throws if a save queues anything.
    • The consent version and the receipt are on screen before the control works. The sheet names training-consent-v1, the receipt id, what is included (this one photo's bytes; the confirmed Bristol form, broad color, image quality) and what is never included (note text, symptom answers, urgency/discomfort ratings, anything identifying you or the device). Contribute this photo and label stays disabled until the terms box is ticked — and no receipt exists before that.
    • On this device only. The receipt is queued locally; this build transmits nothing. No photo bytes are copied into the receipt (asserted in the test and re-asserted on camera).
    • Withdrawal keeps a tombstone. Withdrawing flips the receipt to withdrawn and keeps a tombstone naming every derived artifact (raw-image, confirmed-label) by contribution id, so a future corpus pipeline can address each one. Delete-all clears receipts with the ledger and photos.

    One finish fix rode along (baabeb0): the new receipt and tombstone rows rendered as one run-on line — Type 4 · brownReceipt contrib-…, Withdrawn Oct 21, 12:09 PMraw image, … — because nothing styled .contribution-row. Labels, detail lines and the row action are now separated, tombstones muted, long receipt ids wrap inside the card. Verified at a 390px viewport and re-recorded; frames inspected at full resolution.

    Gates (all passed)

    unit/security 207 pass / 0 fail · mobile green path · photo-first acceptance · sleek Hermes chat · manual fallback draft recovery · provisional suggestion state · hard-stool follow-up · vision corpus refusal · worker container receipts · worker post-load readiness · longitudinal pattern summary · grounded chat citations · training contribution consent · dependency audit (0 high) · syntax · secret scan · forbidden-artifact scan · actual browser recording · H.264 720x1280 yuv420p probe · complete MP4 decode · release delta painted on camera.

    First build attempt (11c63a8) failed one gate on a load-related flake (staging-health: a spawned server missed its 800 ms deadline at load 5.9 on 4 cores; the file then passed 3/3 in isolation); the gate was re-run in full, not bypassed. QC on that build's frames found the row-layout defect above, so it was never published.

    Demonstrated on camera (65/65 captions measured as painted, on-top, in-frame bars)

    Training contribution: nothing queued after an ordinary save → consent version + receipt + include/exclude lists with the confirm button visibly disabled → one receipt queued on the device → withdrawal leaving a tombstone naming both derived artifacts by contribution id → delete-all clearing receipts too.

    Plus the standing path: photo-first consent gate and provisional suggestion; Type 2 follow-up asking soreness/hydration/blood/black-or-tarry (dark brown not escalated, true black/tarry escalated in the app's fixed words); vision-offline and model-not-loaded states with manual entry one tap away; corpus refusals and fail-closed out-of-range replies; pattern summary citing its confirmed logs and refusing a trend on two; saved-photo lifecycle (label, reveal, remove photo and keep the log); grounded chat citations; Hermes chat with the safety override intercepted before the provider.

    Artifacts

    • Source archive timmy-talking-turd-2026-10-21-baabeb0f4f91.tar.gz — 254,710 bytes — SHA-256 7358b2aa177582d8c8ed83ed1f6f5328a2abde61e9e13e9043edef79a75a90b9 (129 entries; no model weights, .env, real medical images, raw corpora or provider logs)
    • Demo timmy-talking-turd-2026-10-21-baabeb0f4f91-demo.mp4 — 18,845,637 bytes — 720x1280 H.264/yuv420p, 25 fps, 4m47s — SHA-256 3a4dd74f1d524d2b29fbc17e09982425e9fc425fce3f8c4a7685f9f5e3be14f4

    Model / profile

    Vision profile selfhost (SmolVLM2-2.2B-Instruct banner). The recording drives the real app server in Chromium at phone width with TIMMY_VISION_ENABLED=false; the provider-facing endpoints (/api/vision-status, /api/analyze, /api/agent/status, /api/agent/chat) are fulfilled at the network layer from deterministic synthetic fixtures, so no model inference and no Hermes call happened during recording. Fixtures are synthetic: a synthetic Type-4 photo, a committed non-stool .jpg that is really text, fictional multi-day sample logs, and a synthetic saved photo for the contribution flow.

    Known accuracy limitation

    The vision layer only ever suggests visible Bristol form, broad color and image quality, with bounded confidence and abstention. It cannot judge urgency, pain, symptoms, blood, or a diagnosis, and a photo never rules out bleeding; sensitive visual fields stay low-confidence and non-stool images are refused rather than guessed. User confirmation is mandatory before anything is saved, and training contribution is a separate consent on top of that — nothing is transmitted by this build. Bristol accuracy is not clinically validated. Server-side ingress hardening for hostile uploads (#16, PR #82) is not in this release.

    Downloads