Bug: slot validation warnings (Levenshtein typo suggestions) silently dropped

[qantrepreneur]

Bug

When a page provides an unknown slot name (typo), the validation computes Levenshtein-based suggestions (e.g., headr → "Did you mean header?") but these warnings are never surfaced to the developer.

Root cause

render-page.tsx:117-121 runs validateSlots() and checks validation.errors (missing required slots), but ignores validation.warnings entirely:

const validation = validateSlots({ providedSlots, extractedSlots });
if (validation.errors.length > 0) {
    throw new Error(validation.errors.map((e) => e.message).join("; "));
}
// validation.warnings is never read

Expected

In dev mode, warnings should be logged to console. The Levenshtein suggestion is computed but never shown — wasted work.

Reproduction

Create a route with slot name headr (typo for header). Get a generic 500 with "Required slot 'header' is missing" — no mention of the typo or suggestion.

Related

Test issue #156, item 18.

🤖 Generated with Claude Code

[qantrepreneur]

This was generated by AI during triage.

Agent Brief

Goal: Surface slot validation warnings to the developer console.

Why: validateSlots() computes Levenshtein-based typo suggestions but render-page.tsx ignores the warnings array. Developer sees generic "Required slot missing" error with no hint about the typo.

Fix:
In packages/framework/src/render-page.tsx after line 121, log each warning:

for (const warning of validation.warnings) {
    console.warn(`[sundayceo] ${warning.message}`);
}

Acceptance criteria:

1. When a page provides an unknown slot name that's close to a valid one, console shows Unknown slot "headr" provided. Did you mean "header"?
2. When a page provides an unknown slot with no close match, console shows available slots
3. Existing validate-slots.test.ts still passes
4. Playground route /typo-slot triggers the warning before the error

Files to touch:

• packages/framework/src/render-page.tsx (primary change)

Out of scope: Gating behind dev/prod mode (always warn is fine for now — this is a dev-time mistake).