Repair corrupted tailwind.config in generated dashboards

[suiyangqiu]

📝 Summary of Changes

Corresponding issue: #98

• Generated dashboards with a corrupted tailwind.config block (which made the dashboard render mostly black-and-white with invisible text) are now auto-detected and auto-repaired before deployment instead of shipping broken.

🤷‍♂️ Why

The dashboard's inline tailwind.config script defines the ssw-red, ssw-charcoal, and ssw-gray palettes. In rare regenerations the model emits a JS syntax error in this block (e.g. dropping the leading quote on 'sans-serif'), the entire script throws on parse, and every utility built on those palettes silently produces no CSS - so brand colours and most text become invisible. The failure rate is low but the user-facing impact when it happens is severe (whole dashboard unreadable).

The fix is a post-processor validation step that runs after Claude writes the dashboard but before deployment:

1. Parse every inline <script> block via new Function(body) (parse-only, no execution).
2. If any block fails, locate the dashboard's tailwind.config block, confirm it is the corrupted one, and replace it with the canonical block from templates/dashboard.html.
3. Re-validate after repair; only write the file if all scripts now parse.
4. If validation itself throws, deployment continues with the original file (non-fatal).

🧪 Test plan

• Unit tests cover clean dashboard, corrupted-tailwind-block repair, and corruption outside the tailwind block (53 tests pass)
• End-to-end smoke test: validator detects and repairs the actual broken dashboard reported in 🐛 Bug - Tiger dashboard looks broken with white text #98 (zero remaining syntax errors after repair)
• Reviewer: process a fresh transcript end-to-end and confirm the new validation step logs and that a clean dashboard is unchanged
• Reviewer: optionally hand-corrupt a generated index.html (e.g. break a quote in the tailwind block) and confirm the processor repairs it before deploy

🤖 Generated with Claude Code

[suiyangqiu]

🤖 Agent Review

🚨 Must Fix / Address

• ✌️ None - Self-contained, defensive, well-tested, non-fatal on failure. Nothing blocks merge.

⚠️ Notable Changes

• ⚠️ Corrupted dashboards still ship if the failure is outside the tailwind.config block - validator returns reason: "corruption-outside-tailwind-block" and processor/index.js:74-81 deploys anyway. Consider escalating non-tailwind syntax errors beyond a warn log.
• Repair pulls from the current templates/dashboard.html - if the template's tailwind block changes later, older deploys retroactively get the new block on repair. Probably what you want, just be aware.
• new Function(body) parses as a function body, not a classic script - a few constructs differ (top-level return, await). Edge-case-only for the corruptions you're seeing; current choice is fine.

📞 Callouts

• Commit 2 revert was the right call - one safety net (validator) beats two overlapping mechanisms. findTailwindConfigScript is generic enough to add sibling repair-targets later if needed.
• 👀 Failure-mode visibility is warn-log only - given this exists because a silent failure shipped a broken dashboard, consider a Teams notification on repaired: true so you can track frequency in production.
• log("debug", ...) always prints - lib/logger.js doesn't filter by level. The "scripts parse cleanly" debug line runs on every successful processing. Low volume, just flagging.

🤏 Small Feedback

• reason strings are typed-by-convention - lift to exported constants if callers ever branch on them.
• 🎯 findSyntaxError returns any caught Error, not just SyntaxError - Tighten to err.name === "SyntaxError" ? err : null to match the name.
• No test for the repair-incomplete branch (tailwind broken AND another block broken). Worth adding for coverage.
• Doc comment on dashboardValidator.js:22 mentions templates/dashboard.html as if hardcoded, but the path is a parameter.

Made by @suiyangqiu

[suiyangqiu]

In response to the Agent Review, I won't be actioning changes to address the additonal validation just yet, primarily because that is beyond the scope of the PR and the issue here. It definitely is a valid point and something that I have noted down however.