Evaluate Web application

Prompt

I am giving you run.py, app.py and prof6.html. You are a **Principal Engineering Review Board + Security Lab + AI Safety System + Architecture Governance Engine**. You do NOT give a single-pass response. You execute a **multi-phase correctness pipeline**. --- # SYSTEM UNDER REVIEW * Single-file HTML application (~1400+ lines) * HTML + CSS + JavaScript * Family-tree / genealogy data-entry system * Supports: * persons * parent-child relationships * siblings * spouses * Includes local LLM for text correction (e.g., “coimbatoure → Coimbatore”) --- # CORE PRINCIPLE You must treat this system as: > a live production system that can fail in hidden, cascading, or adversarial ways Your job is to: * discover issues * formalize correctness rules * break the system * fix the system * prevent regression * evolve specifications --- # EXECUTION PIPELINE (RUN IN ORDER) --- # PHASE 1 — SPECIFICATION MAPPING Input: (optionally) external spec list (e.g., 145 topics) Task: * Filter relevant topics for THIS system * Group into meaningful audit categories: * Data Integrity * Security * AI Safety * UX * Performance * Maintainability Output: * “What actually matters for this system” --- # PHASE 2 — DEEP SYSTEM AUDIT Analyze system: * architecture * DOM structure * CSS structure * JS logic * form workflows * data flow Identify: * bugs * design flaws * hidden assumptions * maintainability risks --- # PHASE 3 — DOMAIN INVARIANT COMPILER Extract and formalize: * identity invariants * relationship invariants (parent/child/sibling/spouse) * temporal invariants (age, birth, death) * AI safety invariants * data integrity invariants For each: * logical rule * violation cases * detection strategy * enforcement strategy --- # PHASE 4 — ADVERSARIAL ATTACK GENERATION Act as a hostile engineer. Generate: * data attacks * relationship graph attacks * AI manipulation attacks * UI/state corruption attacks * stress/performance attacks Include: * multi-step attack chains * AI-assisted corruption scenarios * silent failure modes --- # PHASE 5 — AUTO-REPAIR DESIGN For all issues: * classify severity * identify root cause * design fix (local vs structural vs redesign) * ensure invariant preservation * harden AI boundaries --- # PHASE 6 — REGRESSION MEMORY BUILD Create failure memory: * past bugs * attack patterns * invariant violations * structural weaknesses Generalize into: * reusable failure patterns * regression triggers --- # PHASE 7 — SELF-EVOLVING SPEC UPDATE Update system specification: * add new invariants * refine existing rules * remove obsolete rules * evolve attack models Ensure: > correctness definition improves over time --- # PHASE 8 — FINAL SCORECARD Provide strict evaluation: Score 0–10: * Architecture * Security * Data Integrity * Reliability * Performance * AI Safety * UX Compute weighted final score: Weights: * Data Integrity: 25% * Security: 20% * Reliability: 15% * Architecture: 15% * AI Safety: 10% * UX: 10% * Performance: 5% --- # PHASE 9 — FINAL VERDICT Choose ONE: * Production Ready * Needs Improvements * Not Safe for Production --- # PHASE 10 — TOP INSIGHTS Return: * Top 10 critical issues * Top 10 fixes * Top 5 architectural changes * Top 5 AI safety improvements * Top 5 regression risks --- # GLOBAL RULES * Be strict, not polite * Prefer correctness over completeness * Detect hidden assumptions * Think like a hostile reviewer * Prioritize data integrity above UI elegance * Treat AI behavior as untrusted unless proven safe --- # FINAL OUTPUT FORMAT Return results in this order: 1. Spec Mapping Summary 2. System Audit Findings 3. Invariants 4. Attack Scenarios 5. Fix Plan 6. Regression Memory 7. Evolved Spec 8. Scorecard 9. Final Verdict 10. Top Insights --- # FINAL INSTRUCTION You are not reviewing code. You are operating a **full correctness lifecycle system for software under adversarial conditions**. And in the last, give me final patched file.

A system prompt was added to support web rendering