The 41 existing Penpot seeds contain hand-fabricated penpot_api_info and high_level_overview tool results that assert facts the server never said, which is how the model learned an API that does not exist. This adds four schema files that make the seed corpus mechanically verifiable against the real server instead. - penpot_api_docs.md: 34 verbatim captures of high_level_overview and penpot_api_info, each headed by the exact request that produced it. Every penpot_api_info tool result in a seed must be a subset of lines of this file, in original order. Records three places where the served docs contradict the runtime (addFlexLayout/addGridLayout copy-paste in the Grid section, flex.appendChild for grid children, withChildren vs includeChildren), plus the createText() example that is the direct cause of the production failure. - penpot_system_prompt.md: the server's instructions block verbatim. Goes as a system message into ~30% of the new seeds; it is the countermeasure to the "don't pick your own colours" rule that produces the grey boxes. - penpot_errors.md: the real error strings, including a section on silent failures that raise nothing at all and are why the read-back invariant exists. - PENPOT_API_VERIFIED.md: the allow-list. No seed may reference a member absent from it. Documents the four root causes (findShapeById arity 1, no shape.layout, createText() returning null, the #B1B2B5 default fill), the twelve anti-grey-box invariants, and the forbidden-pattern list the linter checks. Live re-verification of the error strings is still pending: the Penpot plugin is not currently connected, so it is deferred to the gate 5 baseline step, which needs the live connection anyway.
4.3 KiB
Penpot MCP — bloque instructions del servidor, verbatim
Este archivo guarda verbatim el bloque instructions que el servidor MCP de Penpot inyecta en el
system prompt de todo cliente que se conecta. Es la causa raíz #4 del diagnóstico de la Fase 6: la
regla de "don't get overly creative / don't pick your own colours" está pensada para el flujo
diseño→código, pero el modelo la aplica al revés y produce cajas grises cuando se le pide crear un
diseño con colores vibrantes.
Procedencia: capturado el 2026-07-30 en la Fase 6, contra el servidor MCP penpot conectado a esta
sesión. El texto es idéntico al que devuelve la herramienta high_level_overview (el servidor sirve el
mismo documento por ambas vías); la copia completa de esa captura vive en penpot_api_docs.md.
Uso obligatorio: este texto va byte a byte como mensaje system en ~30 % de los seeds nuevos de
data/raw/seeds/penpot.jsonl. Ninguna paráfrasis, ningún recorte. Ver PENPOT_API_VERIFIED.md §
"Contramedida al system prompt".
Fragmento crítico (el que produce el gris)
IMPORTANT: When transferring styles from a Penpot design to code, make sure that you strictly adhere to the design. NEVER make assumptions about missing values and don't get overly creative (e.g. don't pick your own colours and stick to non-creative defaults such as white/black if you are lacking information).
Lectura correcta, y la que los seeds deben enseñar explícitamente en reasoning_content: la regla
condiciona sobre "transferring styles from a Penpot design to code". Cuando el usuario pide crear
un diseño nuevo no hay diseño previo del que transferir, así que no hay "missing values" sobre los que
asumir: elegir una paleta deliberada es la tarea, no una invención.
Bloque completo, verbatim
You have access to Penpot tools in order to interact with a Penpot design project directly.
As a precondition, the user must connect the Penpot design project to the MCP server using the Penpot MCP Plugin.
IMPORTANT: When transferring styles from a Penpot design to code, make sure that you strictly adhere to the design.
NEVER make assumptions about missing values and don't get overly creative (e.g. don't pick your own colours and stick to
non-creative defaults such as white/black if you are lacking information).
# Executing Code
One of your key tools is the `execute_code` tool, which allows you to run JavaScript code using the Penpot Plugin API
directly in the connected project.
VERY IMPORTANT: When writing code, NEVER LOG INFORMATION YOU ARE ALSO RETURNING. It would duplicate the information you receive!
To execute code correctly, you need to understand the Penpot Plugin API. You can retrieve API documentation via
the `penpot_api_info` tool.
This is the full list of types/interfaces in the Penpot API: Penpot, ActiveUser, Blur, Board, VariantContainer, Boolean, CloseOverlay, Color, ColorShapeInfo, ColorShapeInfoEntry, Comment, CommentThread, CommonLayout, Context, ContextGeometryUtils, ContextTypesUtils, ContextUtils, Dissolve, Ellipse, EventsMap, Export, File, FileVersion, Fill, FlexLayout, Flow, Font, FontVariant, FontsContext, GridLayout, Group, GuideColumn, GuideColumnParams, GuideRow, GuideSquare, GuideSquareParams, HistoryContext, Image, Interaction, LayoutCellProperties, LayoutChildProperties, Library, LibraryColor, LibraryComponent, LibraryVariantComponent, LibraryElement, LibrarySummary, LibraryTypography, LocalStorage, NavigateTo, OpenOverlay, OpenUrl, OverlayAction, Page, Path, PathCommand, PluginData, PreviousScreen, Push, Rectangle, RulerGuide, Shadow, ShapeBase, Slide, Stroke, SvgRaw, Text, TextRange, ToggleOverlay, Track, User, Variants, Viewport, Action, Animation, BooleanType, Bounds, Gradient, Guide, ImageData, LibraryContext, Point, RulerGuideOrientation, Shape, StrokeCap, Theme, TrackType, Trigger
You use the `storage` object extensively to store data and utility functions you define across tool calls.
This allows you to inspect intermediate results while still being able to build on them in subsequent code executions.
El resto del documento (estructura de diseños, propiedades de shapes, z-order, layouts, texto,
penpotUtils, inspección visual, librerías) está capturado íntegro y verbatim en
penpot_api_docs.md, sección "Captura 1".