Pod

Yes, this is on purpose. Pod is built for agents, so the default page is plain HTML.
Human? View the normal website.
Agent? You probably prefer /mcp/roastpilot/issues.md or /mcp/roastpilot/issues.json, or Pod over MCP.

Reported issues for RoastPilot

Pod holds 23 of 96 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded entirely — a maintainer's release checklist is not a warning to a prospective user.

Back to RoastPilot.

Most discussed

E7-S4: Run Warp manual Hottop MCP control validation

Goal

Validate operator-controlled Hottop hardware use through Warp and the RoastPilot MCP tools. This is a manual device-control story: the operator remains in control of every hardware-affecting action.

Safety boundary

Read the thread · 2026-05-03 · closed · 16 comments

E7-S3: Test Warp MCP client connection

Goal

Validate coffee-roaster-mcp from Warp as a real local MCP client using the mock-safe path. This story proves Warp can configure, start, discover, and call the RoastPilot stdio MCP server before any hardware-control validation.

Scope

Read the thread · 2026-05-03 · closed · 6 comments

E7-S5a: Test MCP first-crack detection with labelled WAV replay

Goal

Validate the RoastPilot MCP first-crack runtime with a mock roaster and prerecorded labelled audio from the coffee-first-crack-detection evaluation data. This closes the current test gap between mock roaster MCP validation and full real-roast/audio validation.

Scope

Read the thread · 2026-05-25 · closed · 4 comments

E7-S6: Run end-to-end agent roast validation with HF ONNX audio path

Goal

Prove the current RoastPilot release candidate can be handed to Warp as the MCP client for a supervised manual roast using configured Hottop hardware, automatic T0 detection, released Hugging Face ONNX first-crack inference, sliding-window detector confirmation, and a real laptop USB microphone.

This is the first real microphone validation story. Treat microphone setup, detector status, detector confirmation metadata, and Hottop operator approvals as first-class evidence, not incidental

Read the thread · 2026-05-18 · closed · 4 comments

E7-S6a: Align MCP first-crack detector with sliding-window validation

Goal

Align RoastPilot's MCP first-crack runtime with the detector behavior used by the coffee-first-crack-detection training/inference repo before the full E7-S6 manual Warp roast.

E7-S5a proved the released ONNX model can fire through public MCP tools, but the current MCP runtime uses non-overlapping detector windows and records first crack at the inferred window end. With the labelled replay fixture, this detects around 20.017s after T0 for a label interval that starts at 3.827s and

Read the thread · 2026-05-25 · closed · 3 comments

T0 should anchor to the charge / decline ONSET (bean departs ~179 °C), not the turning-point minimum (~150 °C) — ~15 s late

Refines #167 / agent-plan D49. On a real Hottop roast (roastpilot-agent roast 4, 27 Jun 2026), auto-T0 landed ~15 s too late — at the turning-point region, not the charge instant.

Evidence (roast 4)

Read the thread · 2026-06-27 · closed · 2 comments

Make the server console log useful during a roast: quiet the 1 Hz CallToolRequest spam + surface valuable events

Found operating the first hardware roast (roastpilot-agent #134). The console is flooded with one line per second:

[06/14/26 14:27:48] INFO  Processing request of type CallToolRequest   server.py:727
[06/14/26 14:27:49] INFO  Processing request of type CallToolRequest   server.py:727
... (every ~1s, indefinitely)

Cause

server.py:727 is the MCP SDK lowlevel server logging every request at INFO. The agent controller polls get_roast_state at 1 Hz, so it emits one INFO l

Read the thread · 2026-06-14 · closed · 2 comments

E5-S9: Add log schema tests

Done when

Required tests

Parent epic: #5 Epic 5: Roast Metrics And Log Export

Read the thread · 2026-05-03 · closed · 2 comments

Most recent

docs: publish current live-roast status and complete README surface

Goal

Bring the README and published package description up to date after the August 2026 RoastPilot hardware runs.

Scope

Read the thread · 2026-08-23 · closed · 0 comments

Fix PyPI Core Metadata 2.5 publishing for v0.1.15

Problem

The v0.1.14 tag workflow built and smoke-tested the package successfully, but Publish PyPI failed before upload:

InvalidDistribution: Invalid distribution metadata: '2.5' is not a valid metadata version

Hatchling emitted Core Metadata 2.5. The workflow pins pypa/gh-action-pypi-publish at cef221092ed1bacb1cc03d23a2d87d1d172e277b from February 2026. Upstream v1.14.2 explicitly adds Metadata 2.5 upload support through Twine 7.

Scope

Read the thread · 2026-08-23 · closed · 0 comments

Publish corrected component-scope metadata to PyPI and MCP Registry

Problem

PR #198 corrected the source package description and keywords, but production PyPI 0.1.13 is immutable and still describes autonomous coffee roasting. The MCP Registry also remains pinned to the published package version.

Scope

Prepare and publish a metadata-only 0.1.14 release from the corrected origin/main source. Align the package version, server.json version, package entry version, version test, and release changelog. Do not change runtime or hardware-control behaviour.

Read the thread · 2026-08-23 · closed · 0 comments

Yocto-Meteo sentinel check uses ==, so a NaN reading passes through as a real measurement

Found while closing out the agent-side ambient guards (roastpilot-agent#752 / #758). Verified against installed 0.1.13.

The defect

YoctoMeteoAmbientReader._current_value (coffee_roaster_mcp/ambient.py:177-182):

def _current_value(self, sensor: Any, *, label: str) -> float:
    value = sensor.get_currentValue()
    invalid = getattr(sensor, "CURRENTVALUE_INVALID", None)
    if invalid is not None and value == invalid:
        raise AmbientReaderError(f"Yocto-Meteo {label} 

[Read the thread](https://github.com/syamaner/coffee-roaster-mcp/issues/199) · 2026-08-11 · open · 0 comments

### Replace autonomous-roasting package description with precise MCP scope

## Problem

The package metadata describes coffee-roaster-mcp as supporting "autonomous coffee roasting". That wording is broader than the component's actual responsibility and conflicts with RoastPilot's public accuracy boundary: the MCP server exposes telemetry and controlled actuation, while the controller owns the loop and the language model is advisory-only.

## Single-PR plan

Update the package description in `pyproject.toml` to describe coffee-roaster telemetry and controlled actuation w

[Read the thread](https://github.com/syamaner/coffee-roaster-mcp/issues/197) · 2026-08-10 · closed · 0 comments

### Expose a short-window RoR field in RoastSessionState (enabler for corrected affordability-class control laws)

## Motivation (from roastpilot-agent D95 — the falsified D94 affordability law)

The agent's post-FC control experiments need a less-lagged rate-of-rise reading than the current `bean_ror_c_per_min` (a 60 s-window delta — verified identical to `bean_temp_delta_60s_c`). During the D94 falsification analysis, a corrected control law was found to be UNCONSTRUCTIBLE purely because no shorter-window RoR exists at the decision instant: the 60 s window lags the true rate by enough that engagement-time 

[Read the thread](https://github.com/syamaner/coffee-roaster-mcp/issues/196) · 2026-07-15 · open · 0 comments

### audio: sustained input-overflow streaks during live roasts on an M-series Mac — Pi 5 headroom risk (E11 gate)

## Observed (12 Jul, roast 14 live, dual-mic recording + int8 FC inference)

Sustained overflow streaks for minutes at a time, repeatedly climbing to 15
consecutive before brief resets (log excerpt below). This is on an M-series Mac
— the E11 target is a Raspberry Pi 5, with a fraction of the CPU headroom, and
the fatal threshold (`_DEFAULT_MAX_CONSECUTIVE_OVERFLOWS = 30`, audio.py:418)
is only 2× the streaks we already hit. On the Pi this plausibly crosses 30 and
raises `AudioCaptureError` mid-

[Read the thread](https://github.com/syamaner/coffee-roaster-mcp/issues/190) · 2026-07-12 · closed · 0 comments

### Stale heat_level_percent persists a few ticks into cooling after drop

Found in the roastpilot-agent roast-9/10 trace analysis (9 Jul, run `a4299aea`): after the drop → COOLING transition, `heat_level_percent` in the reported state kept the last commanded value (91) for a few ticks before refreshing, even though heat had been cut. Cosmetic/telemetry-only (the actual cut went through), but it misleads trace analysis — the post-drop chart shows heat high into cooling.

Likely the device-state cache refresh cadence around the phase transition. Fix belongs MCP-side (th

[Read the thread](https://github.com/syamaner/coffee-roaster-mcp/issues/189) · 2026-07-10 · closed · 1 comment

### Ambient sensor: read Yoctopuce Yocto-Meteo-V2-C (temp/humidity/pressure) and expose in session state (mirrors the FC mic)

Add a USB **ambient environmental sensor** (Yoctopuce Yocto-Meteo-V2-C: temperature / relative humidity / barometric pressure) as an MCP-owned device, following the **exact pattern the FC microphone already uses** (config → device reader → session-state field → tests). Corpus-metadata for the agent's roast record; **read-only, no control-loop or roaster-write involvement**.

## Why here (not the agent)
The MCP already owns every device on the roaster rig — the Hottop serial and the FC mic (a USB

[Read the thread](https://github.com/syamaner/coffee-roaster-mcp/issues/185) · 2026-07-07 · closed · 0 comments

### Multi-device recording (#176) starves the FC detector read loop → mic overflow fault (roast 5)

**Severity: high — broke a live roast.** On roast 5 (27 Jun, real Hottop), with `recording.enabled` + the two-device capture on, the FC detector's mic input overflowed **30 consecutive reads** (`audio.py:387`) → audio capture faulted → `first_crack: faulted`, `Processed: 0`. No FC detection for the entire roast; the roast had to be stopped pre-FC. Roast 4 (no recording) ran fine, so recording is the differentiator.

**Root cause (hypothesis):** the multi-device recorder **tees the detector's mic

[Read the thread](https://github.com/syamaner/coffee-roaster-mcp/issues/180) · 2026-06-27 · closed · 0 comments

### Pin pyright so local == CI (unpinned >=1.1 caused 2 reportPrivateUsage CI failures on #177)

**Operator hygiene (27 Jun).** `pyproject.toml` has `pyright>=1.1` (unpinned), so CI resolves a newer pyright than a local `.venv` installed earlier. On PR #177 this bit twice: the local gate showed `pyright` 0 errors, but CI's newer pyright failed the **Checks** job on `reportPrivateUsage` (`_WavStreamWriter`, `_normalize_origin_slug` in test imports) — green-locally, red-in-CI, a wasted CI round each time.

**Fix:** pin pyright to an exact version in `pyproject.toml` (e.g. `pyright==1.1.x`), m

[Read the thread](https://github.com/syamaner/coffee-roaster-mcp/issues/179) · 2026-06-27 · closed · 0 comments

### Mic/record check at roaster START (live levels) — in-roast peak/RMS differs from a quiet pre-roast check

**Operator note (27 Jun, post-0.1.9).** The `record-check` smoke test (#176) and the existing pre-roast mic-check both run with the **roaster off / quiet**. But the real acoustic environment during a roast — drum spinning, fan, heating element — has materially different levels, so a peak/RMS baseline (and any "has_signal" / dead-mic threshold) taken quiet does **not** reflect live conditions. **Peak detection will be different once the roaster is running.**

**Ask:** run a brief mic/record check

[Read the thread](https://github.com/syamaner/coffee-roaster-mcp/issues/178) · 2026-06-27 · closed · 0 comments

### Multi-mic roast audio capture (MCP-owned, config-driven) — record per roast for FC training data (v1: capture-only)

Turn every roast into FC training data + model-validation material. Surfaced by roast 4 (the audio detector missed; #175). **v1 is capture-only** — no in-system annotation (Label Studio stays the labeler), no fine-tune.

## Scope (v1)
- **The MCP captures roast audio**, config-driven (it already owns the audio device for detection, so it owns capture). Read the device **once** and tee: feed the FC inference + write the WAV(s) from the same stream (no double-open, no extra device contention).
- *

[Read the thread](https://github.com/syamaner/coffee-roaster-mcp/issues/176) · 2026-06-27 · closed · 1 comment

### Console flood regression: quiet_sdk_per_request_log() no-ops (its level guard runs before logging is configured) — #162 fix ineffective in 0.1.8

**Regression of #162.** The 1 Hz `Processing request of type CallToolRequest` (`mcp.server.lowlevel.server`, INFO) flood is **back** during a live roast on **0.1.8** — observed on a real Hottop roast, 27 Jun 2026 (spawned as the roastpilot-agent stdio child).

## Root cause
`quiet_sdk_per_request_log()` (`src/coffee_roaster_mcp/mcp_server.py`) guards on the logger's *current* effective level:
```python
sdk_logger = logging.getLogger("mcp.server.lowlevel.server")
if sdk_logger.getEffectiveLevel()

[Read the thread](https://github.com/syamaner/coffee-roaster-mcp/issues/173) · 2026-06-27 · closed · 1 comment

### FC should be backdated to crack onset, not stamped at audio-confirmation time (sibling of #167)

## Problem

First-crack is stamped at the moment the audio detector **confirms** the crack, which lags the true crack onset. This is the same confirmation-lag pattern as #167 (T0 backdating), applied to FC: the detector needs a window of cracks before it fires, so the stamped FC time is systematically late versus the first audible crack.

## Why it matters

Development time and DTR are measured from FC. A late FC stamp **compresses** measured development time and skews DTR, which the agent's pos

[Read the thread](https://github.com/syamaner/coffee-roaster-mcp/issues/168) · 2026-06-21 · closed · 0 comments

The remaining reports are on [the project's issue tracker](https://github.com/syamaner/coffee-roaster-mcp/issues).