Observed on an iPhone 16, 25 August 2026, during a 28-second AppModel run in the #101 harness.
shots / candidates 0 / 31
recordingError libppcp: limit exceeded (observe(own:), DeviceMint.swift:121)
⛔ Thirty-one Candidates, zero Shots.DeviceMint.observe(own:) — ppcp_mint_observe_own — began refusing, and once it does the Mint engine sees no further nominations, so nothing is minted for the rest of the session. Detection carried on; the thing detection exists to feed had stopped.
Why it matters more than the count suggests
⚠ Candidates are unbounded by design and Shots are not.CORE 5.12c and I8 require every onset to be nominated, winners and losers alike, and CandidateAudioRetention's own header spells out the consequence — "the candidate count is not bounded by anything the user does": ball into the screen, club on the mat, a dropped club, an adjacent player, speech. A range session will produce hundreds. This run produced 31 in 28 seconds from injected audio and hit the ceiling.
⛔ So this is not an edge case reachable only under abuse. It is the ordinary shape of a real session, and the failure mode is the worst available: the loud half keeps working while the quiet half stops — exactly the pattern #98 was about, in a different subsystem.
Where the ceiling is
In libppcp, and it wants confirming against the source before it is reported upstream — the candidate retained by the Mint engine is bounded by a fixed array, and ppcp_mint_observe_own returns PPCP_ERR_LIMIT once it is full. DeviceMint exposes retainedCount, pendingCount and mintedCount, so the state at the moment of refusal is readable and should be captured before anything is changed.
⚠ Check our own call site first, as #98 established the habit: a Mint engine that is never pumped, or pumped on a deadline that never expires, would retain forever and hit any ceiling. DetectAndMint.pump(nowRefNs:) runs on AppModel's 100 ms mint ticker; whether the issue-hold deadline (8.2i) is actually expiring on this path is the first thing to establish.
Worth noting
⚠ The error names its call site — observe(own:), DeviceMint.swift:121 — because of the change made for #98. Without it this would have read libppcp: limit exceeded and nothing more.
Exit criterion
⛔ A session that nominates several hundred Candidates still mints a Shot for the last one. Whatever bounds retention is asserted, observable, and does not silently stop minting.
⛔ Thirty-one Candidates, zero Shots.
DeviceMint.observe(own:)—ppcp_mint_observe_own— began refusing, and once it does the Mint engine sees no further nominations, so nothing is minted for the rest of the session. Detection carried on; the thing detection exists to feed had stopped.Why it matters more than the count suggests
⚠ Candidates are unbounded by design and Shots are not.
CORE5.12c and I8 require every onset to be nominated, winners and losers alike, andCandidateAudioRetention's own header spells out the consequence — "the candidate count is not bounded by anything the user does": ball into the screen, club on the mat, a dropped club, an adjacent player, speech. A range session will produce hundreds. This run produced 31 in 28 seconds from injected audio and hit the ceiling.⛔ So this is not an edge case reachable only under abuse. It is the ordinary shape of a real session, and the failure mode is the worst available: the loud half keeps working while the quiet half stops — exactly the pattern #98 was about, in a different subsystem.
Where the ceiling is
In
libppcp, and it wants confirming against the source before it is reported upstream — the candidate retained by the Mint engine is bounded by a fixed array, andppcp_mint_observe_ownreturnsPPCP_ERR_LIMITonce it is full.DeviceMintexposesretainedCount,pendingCountandmintedCount, so the state at the moment of refusal is readable and should be captured before anything is changed.⚠ Check our own call site first, as #98 established the habit: a Mint engine that is never pumped, or pumped on a deadline that never expires, would retain forever and hit any ceiling.
DetectAndMint.pump(nowRefNs:)runs onAppModel's 100 ms mint ticker; whether the issue-hold deadline (8.2i) is actually expiring on this path is the first thing to establish.Worth noting
⚠ The error names its call site —
observe(own:), DeviceMint.swift:121— because of the change made for #98. Without it this would have readlibppcp: limit exceededand nothing more.Exit criterion
⛔ A session that nominates several hundred Candidates still mints a Shot for the last one. Whatever bounds retention is asserted, observable, and does not silently stop minting.