{
  "expectations": [
    {"text": "All three models (User, Post, Comment) are extracted into detected-entities.json as separate entries", "passed": true, "evidence": "detected-entities.json entities[] has 3 items: class_name=User, Post, Comment — each as separate entry."},
    {"text": "Each entity's table_name matches the @@map(...) value in the fixture (e.g., User → 'users', Post → 'posts', Comment → 'comments')", "passed": true, "evidence": "table_names match @@map values exactly: User→users, Post→posts, Comment→comments. Entity.table_name overrides class-name default via @@map extraction."},
    {"text": "Every @relation(fields: [...], references: [...]) field produces a relationship in detected-entities.json with a non-empty target_entity that names another extracted model — no blank target_entity strings", "passed": false, "evidence": "All relationships have target_entity='' (empty string). Root cause: prisma.yaml's relationship_detection.patterns matches @relation occurrence but doesn't capture the adjacent model-name token (e.g., from `author User @relation(...)`, no mechanism to extract 'User'). Genuine code gap — needs a capture-group pattern or post-processor. Target for iter-8."},
    {"text": "One-to-many sides (e.g., posts Post[]) produce relationships of type one_to_many; their corresponding many-to-one inverse (e.g., author User @relation(...)) produces type many_to_one, both with the correct target_entity", "passed": false, "evidence": "Partial: Post[]/Comment[] correctly → one_to_many (type OK). But author User @relation(...) and post Post @relation(...) → type='relationship' (generic), not 'many_to_one'. All target_entity values empty. Two defects: type classification doesn't distinguish many_to_one from 'relationship', and target_entity extraction is absent. Target for iter-8."},
    {"text": "Generated database-mapping.md frontmatter has type='entity' and orm_profile='prisma'", "passed": true, "evidence": "database-mapping.md frontmatter contains type: entity and orm_profile: prisma."},
    {"text": "Mermaid erDiagram contains nodes named 'users', 'posts', 'comments' (the table names from @@map, not the model names) and at least one edge of cardinality ||--o{ linking users-posts AND another linking posts-comments", "passed": false, "evidence": "Mermaid has users/posts/comments as left-hand nodes, but right-hand targets are placeholder stubs (users_rel, posts_rel, comments_rel) because target_entity is empty. No real users→posts or posts→comments edge. Downstream symptom of A3/A4 code gap — fixing target_entity resolution will collapse to correct edges."},
    {"text": "mermaid_lint.js reports no issues on the generated page", "passed": true, "evidence": "mermaid_lint.js output = [] (empty array, no issues). Placeholder _rel syntax is still structurally valid erDiagram."}
  ],
  "summary": {"passed": 4, "failed": 3, "total": 7, "pass_rate": 0.571},
  "timing": {"executor_duration_seconds": 0, "total_duration_seconds": 0},
  "execution_metrics": {},
  "eval_feedback": {
    "suggestions": [
      {"assertion": "Every @relation(fields: [...], references: [...]) field produces a relationship in detected-entities.json with a non-empty target_entity", "reason": "Code fix needed (iter-8 candidate P1): extend prisma.yaml's relationship_detection with a capture group that extracts the field type token, OR add a Prisma-specific resolver in extractor.ts that scans for `<fieldname> <TypeName> @relation` and pairs the @relation hit with the TypeName. Same issue hits A4 and A6 (downstream)."},
      {"assertion": "One-to-many sides (e.g., posts Post[]) produce relationships of type one_to_many; their corresponding many-to-one inverse produces type many_to_one", "reason": "Code fix needed (iter-8 candidate P2): add a relationship_type discriminator — '@relation' without '[]' on a non-array field should classify as many_to_one, not generic 'relationship'. Profile-level change, no extractor surgery required."}
    ],
    "overall": "4/7 pass. 3 genuine code gaps in the Prisma profile, all tracing to one root cause: relationship patterns match presence but don't capture target type. Once target_entity is resolved, A4 many_to_one classification + A6 Mermaid edges collapse to correct behavior. This is the most actionable eval in iter-7."
  }
}