Measured across three consecutive runs: the Penpot plugin reliably handles
5 or 6 heavy prompts and then degrades to 30-second timeouts on createPage,
always with the same shape - the first few work, the rest fail in setup
without exception. That is not random flakiness.
Prompts now run in batches of 4 with a clean handshake between batches,
giving the server a recovery point before the deterioration sets in. A
setup failure no longer burns the prompt as measured-with-score-None: it
goes on a pending list, the batch stops, and the run exits 3 with the exact
GATE5_ONLY line to resume. Insisting past the first timeout only spends
pages and dirties the JSON, since once the plugin starts timing out the
rest fail identically.
On the 30-second timeout the user asked to raise: it is the MCP server's
own limit on a plugin task, not a client timeout, so it cannot be raised
from here. What can be done is not to approach it. generateStyle with
includeChildren plus generateMarkup serialise the whole subtree and are by
far the most expensive part of the audit, so above 400 nodes they are
skipped and rendersOk becomes not-applicable rather than risking the entire
audit - and with it the prompt's measurement - timing out. That required
fixing the scoring too: a metric whose VALUE is None is now not-applicable,
like one whose threshold is None. Counting "could not measure" as a failure
would have penalised exactly the large designs the gate is meant to reward.
aleleba
387b237ee5