How it works

You don't need any of this to use the plugin — it's here for when you're curious or debugging.

How it works

• Plugin discovery is marker-based. Each @pro-laico/* plugin stashes its resolved slugs and options on config.custom (payloadSeed, payloadImages, payloadIcons, payloadFonts, payloadMux, payloadRevalidate). The snapshot builder reads those markers off payload.config. No plugin imports, so nothing else is a dependency; third-party setups just show fewer panels.
• The dev page file passes Payload in. createDevPage({ payload }) takes an app-supplied Payload handle (e.g. getPayload({ config })) — the plugin registers no onInit and stashes no config on globalThis.
• Seeding goes through the seed plugin's own endpoint. The seed card and toolbar POST to /api/seed: same gate (ENABLE_SEED=true + a logged-in user), same { error, issues } responses, surfaced inline.
• Draft mode flips server-side. The panel header's draft switch calls GET /api/dev/draft?enable=1|0, which drives Next's draftMode() — the real __prerender_bypass cookie, exactly as a preview route would set it — then refreshes the page you're on so drafts render in or out. It's URL-addressable too (?to=/path redirects after flipping), like /api/dev/stage.
• The toolbar persists because it lives in the layout. Its rows are client-side <Link>s, so navigating between dev pages never remounts it. It injects one <style> tag (all .pdt-/.pdtp- prefixed, no host theme dependency; --pdt-accent is the override seam), and it only ever receives test labels, never render functions.
• Gating is layered. Endpoints check per request, pages and toolbar per render. A production build ships neither markup nor data.
• It sits beside Next's own dev indicator, on purpose. The launcher borrows its idiom and defaults to the opposite corner (Next's is bottom-left).

Next

• The /dev pages — the routes and the snapshot these mechanics power.
• The test harness — the defineTest model.
• Troubleshooting — when the gating or draft-mode wiring surprises you.