@autobe/agent 0.30.2 → 0.30.4-dev.20260324

package/lib/orchestrate/analyze/histories/transformAnalyzeExtractDecisionsHistory.d.ts

@@ -0,0 +1,18 @@
+import { AutoBeAnalyze, AutoBeAnalyzeWriteSectionEvent } from "@autobe/interface";
+import { AutoBeContext } from "../../../context/AutoBeContext";
+import { IAutoBeOrchestrateHistory } from "../../../structures/IAutoBeOrchestrateHistory";
+/**
+ * Transform histories for key decision extraction from a single file.
+ *
+ * Provides the extractor with:
+ *
+ * 1. The system prompt for decision extraction
+ * 2. The full section content of ONE file
+ *
+ * Each file is processed independently in parallel, so only one file's content
+ * is included per call.
+ */
+export declare const transformAnalyzeExtractDecisionsHistory: (_ctx: AutoBeContext, props: {
+    file: AutoBeAnalyze.IFileScenario;
+    sectionEvents: AutoBeAnalyzeWriteSectionEvent[][];
+}) => IAutoBeOrchestrateHistory;

package/lib/orchestrate/analyze/histories/transformAnalyzeExtractDecisionsHistory.js

@@ -0,0 +1,51 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.transformAnalyzeExtractDecisionsHistory = void 0;
+const utils_1 = require("@autobe/utils");
+const uuid_1 = require("uuid");
+/**
+ * Transform histories for key decision extraction from a single file.
+ *
+ * Provides the extractor with:
+ *
+ * 1. The system prompt for decision extraction
+ * 2. The full section content of ONE file
+ *
+ * Each file is processed independently in parallel, so only one file's content
+ * is included per call.
+ */
+const transformAnalyzeExtractDecisionsHistory = (_ctx, props) => {
+    // Build full section content for this file
+    const fileContent = props.sectionEvents
+        .map((sectionsForModule, moduleIndex) => sectionsForModule
+        .map((sectionEvent, unitIndex) => sectionEvent.sectionSections
+        .map((section) => `### [M${moduleIndex + 1}.U${unitIndex + 1}] ${section.title}\n\n${section.content}`)
+        .join("\n\n"))
+        .join("\n\n"))
+        .join("\n\n---\n\n");
+    return {
+        histories: [
+            {
+                id: (0, uuid_1.v7)(),
+                created_at: new Date().toISOString(),
+                type: "systemMessage",
+                text: "<!--\nfilename: ANALYZE_EXTRACT_DECISIONS.md\n-->\n# Key Decision Extractor\n\nYou are the **Key Decision Extractor** for hierarchical requirements documentation.\nYour role is to extract **binary and discrete decisions** from a single file's section content as structured data, enabling programmatic cross-file contradiction detection.\n\nThis agent achieves its goal through function calling. **Function calling is MANDATORY**.\n\n---\n\n## 1. What to Extract\n\nExtract every **binary or discrete decision** embedded in the prose. A \"decision\" is a specific behavioral choice the document makes about how the system works.\n\n### 1.1. Binary Decisions (yes/no)\n\nStatements that assert or deny a capability, requirement, or behavior.\n\n**Examples:**\n- \"Users must provide their current password to change it\" \u2192 `topic: \"password_change\", decision: \"requires_current_password\", value: \"yes\"`\n- \"The system does not require the old password\" \u2192 `topic: \"password_change\", decision: \"requires_current_password\", value: \"no\"`\n- \"Deleted emails can be reused for new accounts\" \u2192 `topic: \"deleted_email\", decision: \"can_be_reused\", value: \"yes\"`\n- \"An email from a deleted account is permanently blocked\" \u2192 `topic: \"deleted_email\", decision: \"can_be_reused\", value: \"no\"`\n\n### 1.2. Discrete Decisions (multiple options)\n\nStatements that choose one option among several possibilities.\n\n**Examples:**\n- \"Deleted todos are removed via soft delete\" \u2192 `topic: \"todo_deletion\", decision: \"deletion_method\", value: \"soft_delete\"`\n- \"Deleted todos are immediately and permanently removed\" \u2192 `topic: \"todo_deletion\", decision: \"deletion_method\", value: \"hard_delete\"`\n- \"Edit history records the new values of changed fields\" \u2192 `topic: \"edit_history\", decision: \"recorded_values\", value: \"new_values\"`\n- \"Edit history records the previous values of changed fields\" \u2192 `topic: \"edit_history\", decision: \"recorded_values\", value: \"previous_values\"`\n\n### 1.3. Behavioral Decisions\n\nStatements about system behavior in specific scenarios.\n\n**Examples:**\n- \"Users are automatically logged in after registration\" \u2192 `topic: \"registration\", decision: \"auto_login_after_signup\", value: \"yes\"`\n- \"Users must log in separately after registration\" \u2192 `topic: \"registration\", decision: \"auto_login_after_signup\", value: \"no\"`\n- \"Display name is required during account creation\" \u2192 `topic: \"display_name\", decision: \"required_at_signup\", value: \"yes\"`\n- \"Display name can be set later after account creation\" \u2192 `topic: \"display_name\", decision: \"required_at_signup\", value: \"no\"`\n\n---\n\n## 2. How to Extract\n\n### 2.1. Topic Normalization\n\nUse consistent, lowercase, underscore-separated topic names:\n- `password_change`, NOT `PasswordChange` or `changing password`\n- `todo_deletion`, NOT `TodoDeletion` or `deleting todos`\n- `edit_history`, NOT `EditHistory` or `history of edits`\n\n### 2.2. Decision Normalization\n\nUse consistent, descriptive decision names:\n- `requires_current_password`, NOT `needsOldPassword` or `old password needed`\n- `deletion_method`, NOT `howToDelete` or `delete approach`\n\n### 2.3. Value Normalization\n\nUse short, consistent values:\n- Binary: `\"yes\"` or `\"no\"`\n- Discrete: short descriptive strings like `\"soft_delete\"`, `\"hard_delete\"`, `\"new_values\"`, `\"previous_values\"`\n\n### 2.4. Evidence\n\nInclude a short quote (1-2 sentences) from the source text that supports the extracted decision. This helps identify contradictions later.\n\n---\n\n## 3. What NOT to Extract\n\n- **Obvious facts**: \"Users can create todos\" \u2014 this is a feature, not a decision\n- **Vague statements**: \"The system should be secure\" \u2014 not specific enough\n- **Quantities or numbers**: \"Maximum 300 characters\" \u2014 handled by other validators\n- **Lists of features**: \"Users can filter by status\" \u2014 not a binary/discrete choice\n- **Implementation details**: \"Uses JWT tokens\" \u2014 technical, not behavioral\n\nFocus ONLY on decisions where **two files could reasonably disagree** about the correct answer.\n\n---\n\n## 4. Output Format\n\nCall `process()` with ALL extracted decisions:\n\n```typescript\nprocess({\n  thinking: \"This file defines password change as requiring current password, soft delete for todos, and edit history recording previous values.\",\n  request: {\n    type: \"complete\",\n    decisions: [\n      {\n        topic: \"password_change\",\n        decision: \"requires_current_password\",\n        value: \"yes\",\n        evidence: \"A user may change their password only by providing their current password.\"\n      },\n      {\n        topic: \"todo_deletion\",\n        decision: \"deletion_method\",\n        value: \"soft_delete\",\n        evidence: \"When a user deletes a todo, it is removed from their main todo list but remains accessible in their trash.\"\n      },\n      {\n        topic: \"edit_history\",\n        decision: \"recorded_values\",\n        value: \"previous_values\",\n        evidence: \"Each history entry must record the previous value of each field that was modified.\"\n      }\n    ]\n  }\n});\n```\n\nIf the file contains no extractable decisions (e.g., 00-toc.md):\n\n```typescript\nprocess({\n  thinking: \"This file is a table of contents with no behavioral decisions.\",\n  request: {\n    type: \"complete\",\n    decisions: []\n  }\n});\n```\n\n---\n\n## 5. Common Decision Topics\n\nThese are common topics where contradictions frequently occur between files. Extract these whenever you see them:\n\n- **Authentication**: `requires_current_password`, `auto_login_after_signup`, `session_mechanism`\n- **Account lifecycle**: `deleted_email_reusable`, `account_deletion_method`, `data_retention_after_deletion`\n- **Data deletion**: `deletion_method` (soft/hard), `retention_period`, `cascade_behavior`\n- **Edit history**: `recorded_values` (new/previous/both), `immutable`, `survives_soft_delete`\n- **Profile**: `display_name_required_at_signup`, `email_immutable`\n- **Authorization**: `owner_only_access`, `cross_user_visibility`\n- **Dates**: `date_validation_rules`, `null_date_sort_position`\n\n---\n\n## 6. Quality Rules\n\n- **Be exhaustive**: Extract ALL decisions, not just obvious ones\n- **Be consistent**: Same topic name for the same concept across calls\n- **Be precise**: Values should be unambiguous and distinct\n- **Be faithful**: Only extract what the text actually says, do not infer or assume\n- **One decision per statement**: If a sentence contains two decisions, extract both separately" /* AutoBeSystemPromptConstant.ANALYZE_EXTRACT_DECISIONS */,
+            },
+            {
+                id: (0, uuid_1.v7)(),
+                created_at: new Date().toISOString(),
+                type: "assistantMessage",
+                text: utils_1.StringUtil.trim `
+          ## File: ${props.file.filename}
+
+          ## Full Section Content
+
+          ${fileContent}
+        `,
+            },
+        ],
+        userMessage: `Extract all binary and discrete decisions from the file "${props.file.filename}". Return structured decisions for cross-file contradiction detection.`,
+    };
+};
+exports.transformAnalyzeExtractDecisionsHistory = transformAnalyzeExtractDecisionsHistory;
+//# sourceMappingURL=transformAnalyzeExtractDecisionsHistory.js.map

package/lib/orchestrate/analyze/histories/transformAnalyzeExtractDecisionsHistory.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"transformAnalyzeExtractDecisionsHistory.js","sourceRoot":"","sources":["../../../../src/orchestrate/analyze/histories/transformAnalyzeExtractDecisionsHistory.ts"],"names":[],"mappings":";;;AAIA,yCAA2C;AAC3C,+BAA0B;AAM1B;;;;;;;;;;GAUG;AACI,MAAM,uCAAuC,GAAG,CACrD,IAAmB,EACnB,KAGC,EAC0B,EAAE;IAC7B,2CAA2C;IAC3C,MAAM,WAAW,GAAG,KAAK,CAAC,aAAa;SACpC,GAAG,CAAC,CAAC,iBAAiB,EAAE,WAAW,EAAE,EAAE,CACtC,iBAAiB;SACd,GAAG,CAAC,CAAC,YAAY,EAAE,SAAS,EAAE,EAAE,CAC/B,YAAY,CAAC,eAAe;SACzB,GAAG,CACF,CAAC,OAAO,EAAE,EAAE,CACV,SAAS,WAAW,GAAG,CAAC,KAAK,SAAS,GAAG,CAAC,KAAK,OAAO,CAAC,KAAK,OAAO,OAAO,CAAC,OAAO,EAAE,CACvF;SACA,IAAI,CAAC,MAAM,CAAC,CAChB;SACA,IAAI,CAAC,MAAM,CAAC,CAChB;SACA,IAAI,CAAC,aAAa,CAAC,CAAC;IAEvB,OAAO;QACL,SAAS,EAAE;YACT;gBACE,EAAE,EAAE,IAAA,SAAE,GAAE;gBACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;gBACpC,IAAI,EAAE,eAAe;gBACrB,IAAI,qnNAAsD;aAC3D;YACD;gBACE,EAAE,EAAE,IAAA,SAAE,GAAE;gBACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;gBACpC,IAAI,EAAE,kBAAkB;gBACxB,IAAI,EAAE,kBAAU,CAAC,IAAI,CAAA;qBACR,KAAK,CAAC,IAAI,CAAC,QAAQ;;;;YAI5B,WAAW;SACd;aACF;SACF;QACD,WAAW,EAAE,4DAA4D,KAAK,CAAC,IAAI,CAAC,QAAQ,wEAAwE;KACrK,CAAC;AACJ,CAAC,CAAC;AA9CW,QAAA,uCAAuC,2CA8ClD"}

package/lib/orchestrate/analyze/histories/transformAnalyzeScenarioHistory.js

@@ -8,7 +8,7 @@ const transformAnalyzeScenarioHistory = (ctx, preliminary, feedback) => ({
         {
             id: (0, uuid_1.v7)(),
             type: "systemMessage",
-            text: "<!--\nfilename: ANALYZE_SCENARIO.md\n-->\n# Scenario Analyst\n\nYou are the **Scenario Analyst** \u2014 the agent that extracts business concepts from user conversations.\n\n**Your Job**: Identify `prefix`, `actors`, `concepts`, `features`, and `language` from user requirements.\n\n**Your Mindset**: Think like a business analyst. Capture WHAT the business needs, not HOW to implement it.\n\n**Boundary**: Do not define database schemas or API endpoints. Those belong to later phases.\n\n---\n\n## 1. Workflow\n\n1. **Clarify** \u2014 Ask questions if business type, actors, scope, or core policies are unclear\n2. **Close** \u2014 Stop asking when: user says proceed, all key questions resolved, or 8 questions reached\n3. **Output** \u2014 Call `process({ request: { type: \"complete\", ... } })` with extracted scenario\n\n---\n\n## 2. 6-File SRS Structure\n\n| File | Focus | Downstream |\n|------|-------|-----------|\n| 00-toc.md | Summary, scope, glossary | Project setup |\n| 01-actors-and-auth.md | Who can do what | Auth middleware |\n| 02-domain-model.md | Business concepts and relationships | Database design |\n| 03-functional-requirements.md | What operations users can perform | Interface design |\n| 04-business-rules.md | Validation rules, error conditions | Service logic |\n| 05-non-functional.md | Performance, security | Infrastructure |\n\n---\n\n## 3. Output Format\n\n```typescript\nprocess({\n  thinking: \"Identified 3 actors and 5 domain concepts from user requirements.\",\n  request: {\n    type: \"complete\",\n    reason: \"User described a todo app with user authentication\",\n    prefix: \"todoApp\",\n    language: \"en\",\n    actors: [\n      { name: \"guest\", kind: \"guest\", description: \"Unauthenticated visitors\" },\n      { name: \"member\", kind: \"member\", description: \"Registered users managing todos\" }\n    ],\n    concepts: [\n      { name: \"User\", description: \"Registered user of the system\", relationships: [] },\n      { name: \"Todo\", description: \"Task item that users create and track\", relationships: [\"owned by User\"] }\n    ],\n    features: []\n  }\n});\n```\n\n---\n\n## 4. Actors\n\n**Default to minimal set**: `guest`, `member`\n\nOnly add actors when the user explicitly describes a distinct identity type (e.g., \"sellers\" vs \"buyers\" in a marketplace). If someone can be represented as a role attribute on an existing actor, don't create a new actor.\n\n**Test**: \"Does this require a separate login and account lifecycle?\" YES \u2192 actor. NO \u2192 attribute.\n\n---\n\n## 5. Concepts\n\nDescribe **business concepts** \u2014 the nouns users talk about when describing their business.\n\n**Good**: `{ name: \"Todo\", description: \"A task item users create and manage\", relationships: [\"owned by User\"] }`\n\n**Bad**: `{ name: \"Todo\", attributes: [\"title: text(1-500)\", \"completed: boolean\"] }` \u2014 attributes belong in Database phase.\n\n---\n\n## 6. Features (Optional)\n\nOnly include if user mentions specific capabilities:\n\n| Feature | Trigger Keywords |\n|---------|-----------------|\n| `real-time` | live updates, WebSocket, chat |\n| `external-integration` | payment, OAuth, email service |\n| `file-storage` | file upload, attachments, S3 |\n\n---\n\n## 7. User Input Preservation\n\nThe user's stated requirements are authoritative:\n- \"multi-user\" \u2192 design as multi-user\n- \"email/password login\" \u2192 use email/password auth\n- \"soft delete\" \u2192 implement soft delete\n- 8 features mentioned \u2192 include all 8\n\n---\n\n## 8. Document Sections (Post-Closure)\n\nAfter closing clarification, the requirements document must include:\n\n### 8.1. Interpretation & Assumptions\n- Original user input (verbatim)\n- Your interpretation\n- At least 8 assumptions (business type, users, scope, policies, etc.)\n\n### 8.2. Scope Definition\n- In-scope (v1 features)\n- Out-of-scope (deferred to v2)\n\n### 8.3. Domain Concepts\n- Business description of each concept\n- How concepts relate to each other\n\n### 8.4. Core Workflows\n- User journeys in natural language\n- Exception scenarios\n\n---\n\n## 9. Diagrams\n\nUse business language in flowcharts:\n\n```mermaid\ngraph LR\n    A[\"Browse Products\"] --> B[\"Add to Cart\"]\n    B --> C{\"Checkout?\"}\n    C -->|Yes| D[\"Complete Order\"]\n    C -->|No| E[\"Continue Shopping\"]\n```\n\n---\n\n## 10. Final Checklist\n\n**Scenario Extraction:**\n- [ ] `prefix` is a valid camelCase identifier\n- [ ] All actors have `name`, `kind`, and `description`\n- [ ] All concepts have `name`, `description`, and `relationships`\n- [ ] Features only from fixed catalog: `real-time`, `external-integration`, `file-storage`\n\n**Prohibited Content (REJECT if present):**\n- [ ] NO database schemas or table definitions\n- [ ] NO API endpoints or HTTP methods\n- [ ] NO field types or column definitions\n- [ ] NO technical implementation details\n\n**Business Language Only:**\n- [ ] Concepts describe WHAT exists, not HOW it's stored\n- [ ] Relationships describe business connections, not foreign keys\n- [ ] All descriptions use user-facing language" /* AutoBeSystemPromptConstant.ANALYZE_SCENARIO */,
+            text: "<!--\nfilename: ANALYZE_SCENARIO.md\n-->\n# Scenario Analyst\n\nYou are the **Scenario Analyst** \u2014 the agent that extracts business concepts from user conversations.\n\n**Your Job**: Identify `prefix`, `actors`, `concepts`, `features`, and `language` from user requirements.\n\n**Your Mindset**: Think like a business analyst. Capture WHAT the business needs, not HOW to implement it.\n\n**Boundary**: Do not define database schemas or API endpoints. Those belong to later phases.\n\n---\n\n## 1. Workflow\n\n1. **Clarify** \u2014 Ask questions if business type, actors, scope, or core policies are unclear\n2. **Close** \u2014 Stop asking when: user says proceed, all key questions resolved, or 8 questions reached\n3. **Output** \u2014 Call `process({ request: { type: \"complete\", ... } })` with extracted scenario\n\n---\n\n## 2. 6-File SRS Structure\n\n| File | Focus | Downstream |\n|------|-------|-----------|\n| 00-toc.md | Summary, scope, glossary | Project setup |\n| 01-actors-and-auth.md | Who can do what | Auth middleware |\n| 02-domain-model.md | Business concepts and relationships | Database design |\n| 03-functional-requirements.md | What operations users can perform | Interface design |\n| 04-business-rules.md | Validation rules, error conditions | Service logic |\n| 05-non-functional.md | Performance, security | Infrastructure |\n\n---\n\n## 3. Output Format\n\n```typescript\nprocess({\n  thinking: \"Identified 3 actors and 5 domain concepts from user requirements.\",\n  request: {\n    type: \"complete\",\n    reason: \"User described a todo app with user authentication\",\n    prefix: \"todoApp\",\n    language: \"en\",\n    actors: [\n      { name: \"guest\", kind: \"guest\", description: \"Unauthenticated visitors\" },\n      { name: \"member\", kind: \"member\", description: \"Registered users managing todos\" }\n    ],\n    concepts: [\n      { name: \"User\", description: \"Registered user of the system\", relationships: [] },\n      { name: \"Todo\", description: \"Task item that users create and track\", relationships: [\"owned by User\"] }\n    ],\n    features: []\n  }\n});\n```\n\n---\n\n## 4. Actors\n\n**Default to minimal set**: `guest`, `member`\n\nOnly add actors when the user explicitly describes a distinct identity type (e.g., \"sellers\" vs \"buyers\" in a marketplace). If someone can be represented as a role attribute on an existing actor, don't create a new actor.\n\n**Test**: \"Does this require a separate login and account lifecycle?\" YES \u2192 actor. NO \u2192 attribute.\n\n---\n\n## 5. Concepts\n\nDescribe **business concepts** \u2014 the nouns users talk about when describing their business.\n\n**Good**: `{ name: \"Todo\", description: \"A task item users create and manage\", relationships: [\"owned by User\"] }`\n\n**Bad**: `{ name: \"Todo\", attributes: [\"title: text(1-500)\", \"completed: boolean\"] }` \u2014 attributes belong in Database phase.\n\n---\n\n## 6. Features (STRICT \u2014 Default is EMPTY)\n\nFeatures activate conditional modules across ALL 6 SRS files. Wrong activation causes massive hallucination downstream. **Default: empty array `[]`**.\n\n**Activation Rule**: Include a feature ONLY if the user used one of its exact trigger keywords. Do NOT infer features from general context.\n\n| Feature | Activate ONLY if user said | Do NOT activate if |\n|---------|---------------------------|-------------------|\n| `real-time` | \"live updates\", \"WebSocket\", \"real-time\", \"chat\", \"push notifications\" | User just described a standard CRUD app |\n| `external-integration` | \"payment\", \"Stripe\", \"OAuth\", \"email service\", \"SMS\", \"third-party API\" | User just mentioned login/signup (that's built-in auth, not external integration) |\n| `file-storage` | \"file upload\", \"image upload\", \"attachments\", \"S3\", \"media\" | User described text-only data (title, description, dates) |\n\n**Examples**:\n- \"Todo app with user auth, CRUD, soft delete\" \u2192 `features: []` (no trigger keywords)\n- \"Shopping mall with Stripe payment\" \u2192 `features: [{ id: \"external-integration\", providers: [\"stripe\"] }]`\n- \"Chat app with real-time messaging and file sharing\" \u2192 `features: [{ id: \"real-time\" }, { id: \"file-storage\" }]`\n\n**Self-check**: For each feature you want to activate, quote the exact user words that triggered it. No quote \u2192 remove feature.\n\n---\n\n## 7. User Input Preservation\n\nThe user's stated requirements are authoritative:\n- \"multi-user\" \u2192 design as multi-user\n- \"email/password login\" \u2192 use email/password auth\n- \"soft delete\" \u2192 implement soft delete\n- 8 features mentioned \u2192 include all 8\n\n---\n\n## 8. Document Sections (Post-Closure)\n\nAfter closing clarification, the requirements document must include:\n\n### 8.1. Interpretation & Assumptions\n- Original user input (verbatim)\n- Your interpretation\n- At least 8 assumptions (business type, users, scope, policies, etc.)\n\n### 8.2. Scope Definition\n- In-scope (v1 features)\n- Out-of-scope (deferred to v2)\n\n### 8.3. Domain Concepts\n- Business description of each concept\n- How concepts relate to each other\n\n### 8.4. Core Workflows\n- User journeys in natural language\n- Exception scenarios\n\n---\n\n## 9. Diagrams\n\nUse business language in flowcharts:\n\n```mermaid\ngraph LR\n    A[\"Browse Products\"] --> B[\"Add to Cart\"]\n    B --> C{\"Checkout?\"}\n    C -->|Yes| D[\"Complete Order\"]\n    C -->|No| E[\"Continue Shopping\"]\n```\n\n---\n\n## 10. Final Checklist\n\n**Scenario Extraction:**\n- [ ] `prefix` is a valid camelCase identifier\n- [ ] All actors have `name`, `kind`, and `description`\n- [ ] All concepts have `name`, `description`, and `relationships`\n- [ ] Features default to empty array \u2014 only activated by EXACT trigger keywords from user\n- [ ] For each activated feature, you can quote the user's exact words that triggered it\n- [ ] A standard CRUD app with auth has NO features \u2014 features: []\n\n**Prohibited Content (REJECT if present):**\n- [ ] NO database schemas or table definitions\n- [ ] NO API endpoints or HTTP methods\n- [ ] NO field types or column definitions\n- [ ] NO technical implementation details\n\n**Business Language Only:**\n- [ ] Concepts describe WHAT exists, not HOW it's stored\n- [ ] Relationships describe business connections, not foreign keys\n- [ ] All descriptions use user-facing language" /* AutoBeSystemPromptConstant.ANALYZE_SCENARIO */,
             created_at: new Date().toISOString(),
         },
         ...ctx

package/lib/orchestrate/analyze/histories/transformAnalyzeScenarioHistory.js.map

@@ -1 +1 @@
-{"version":3,"file":"transformAnalyzeScenarioHistory.js","sourceRoot":"","sources":["../../../../src/orchestrate/analyze/histories/transformAnalyzeScenarioHistory.ts"],"names":[],"mappings":";;;AAAA,yCAA2C;AAC3C,+BAA0B;AAOnB,MAAM,+BAA+B,GAAG,CAC7C,GAAkB,EAClB,WAAoE,EACpE,QAAiB,EACU,EAAE,CAAC,CAAC;IAC/B,SAAS,EAAE;QACT;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,IAAI,EAAE,eAAe;YACrB,IAAI,2jKAA6C;YACjD,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;SACrC;QACD,GAAG,GAAG;aACH,SAAS,EAAE;aACX,MAAM,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,IAAI,KAAK,aAAa,IAAI,CAAC,CAAC,IAAI,KAAK,kBAAkB,CAAC;QAC3E,GAAG,WAAW,CAAC,YAAY,EAAE;QAC7B,GAAG,CAAC,QAAQ;YACV,CAAC,CAAC;gBACE;oBACE,EAAE,EAAE,IAAA,SAAE,GAAE;oBACR,IAAI,EAAE,kBAA2B;oBACjC,IAAI,EAAE,kBAAU,CAAC,IAAI,CAAA;;;;;gBAKjB,QAAQ;;;aAGX;oBACD,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;iBACrC;aACF;YACH,CAAC,CAAC,EAAE,CAAC;KACR;IACD,WAAW,EAAE,kBAAU,CAAC,IAAI,CAAA;;;;;;;;;wCASU,GAAG,CAAC,MAAM;GAC/C;CACF,CAAC,CAAC;AA9CU,QAAA,+BAA+B,mCA8CzC"}
+{"version":3,"file":"transformAnalyzeScenarioHistory.js","sourceRoot":"","sources":["../../../../src/orchestrate/analyze/histories/transformAnalyzeScenarioHistory.ts"],"names":[],"mappings":";;;AAAA,yCAA2C;AAC3C,+BAA0B;AAOnB,MAAM,+BAA+B,GAAG,CAC7C,GAAkB,EAClB,WAAoE,EACpE,QAAiB,EACU,EAAE,CAAC,CAAC;IAC/B,SAAS,EAAE;QACT;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,IAAI,EAAE,eAAe;YACrB,IAAI,g2MAA6C;YACjD,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;SACrC;QACD,GAAG,GAAG;aACH,SAAS,EAAE;aACX,MAAM,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,IAAI,KAAK,aAAa,IAAI,CAAC,CAAC,IAAI,KAAK,kBAAkB,CAAC;QAC3E,GAAG,WAAW,CAAC,YAAY,EAAE;QAC7B,GAAG,CAAC,QAAQ;YACV,CAAC,CAAC;gBACE;oBACE,EAAE,EAAE,IAAA,SAAE,GAAE;oBACR,IAAI,EAAE,kBAA2B;oBACjC,IAAI,EAAE,kBAAU,CAAC,IAAI,CAAA;;;;;gBAKjB,QAAQ;;;aAGX;oBACD,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;iBACrC;aACF;YACH,CAAC,CAAC,EAAE,CAAC;KACR;IACD,WAAW,EAAE,kBAAU,CAAC,IAAI,CAAA;;;;;;;;;wCASU,GAAG,CAAC,MAAM;GAC/C;CACF,CAAC,CAAC;AA9CU,QAAA,+BAA+B,mCA8CzC"}

package/lib/orchestrate/analyze/histories/transformAnalyzeScenarioReviewHistory.js

@@ -19,7 +19,7 @@ const transformAnalyzeScenarioReviewHistory = (ctx, props) => {
                 id: (0, uuid_1.v7)(),
                 created_at: new Date().toISOString(),
                 type: "systemMessage",
-                text: "<!--\nfilename: ANALYZE_SCENARIO_REVIEW.md\n-->\n# Scenario Reviewer\n\nYou are a requirements analyst reviewing whether a scenario correctly captures the user's original requirements. You receive the user's conversation history and the scenario output, then validate accuracy.\n\n---\n\n## 1. Your Role\n\nThe scenario stage extracts `prefix`, `actors`, `concepts`, and `features` from user requirements. Your job is to verify this extraction is **complete and accurate** \u2014 no missing concepts, no hallucinated additions.\n\n---\n\n## 2. Review Criteria\n\n### 2.1. Concept Coverage (CRITICAL)\n\nEvery domain concept the user mentioned or clearly implied MUST have a corresponding concept.\n\n**Check**: For each noun/concept in the user's requirements, verify a concept exists.\n- User said \"comment\" \u2192 `Comment` concept must exist\n- User said \"like\" \u2192 `Like` concept must exist\n- User said \"category\" \u2192 `Category` concept must exist\n\n**Exception**: `User` concept is always acceptable even if not explicitly mentioned (it's implied by authentication).\n\n**If missing**: Report as `missing_concept` with the concept name and suggested concept.\n\n### 2.2. No Hallucinated Concepts (CRITICAL)\n\nNo concepts should exist that the user never mentioned, implied, or that aren't logically necessary.\n\n**Check**: For each concept in the scenario, verify it traces back to user requirements.\n- User said \"todo app\" \u2192 `Todo`, `User` are valid; `AuditLog`, `Notification`, `Tag` are hallucinations unless user mentioned them\n- Concepts for standard auth flows (`RefreshToken`, `Session`) are acceptable IF the auth model requires them\n\n**If hallucinated**: Report as `hallucinated_concept` with explanation of why it's not justified.\n\n### 2.3. Actor Classification\n\nActors must follow the identity boundary test and match user requirements.\n\n**Default**: `guest` / `member` only. Add `admin` ONLY if the user explicitly requested admin functionality.\n\n**Check**:\n- Are there actors the user didn't request? Do NOT add `admin` unless the user explicitly mentioned admin features.\n- Are actor `kind` values correct? (guest=unauthenticated, member=authenticated, admin=system management)\n- Could any actor be represented as a role attribute instead of a separate actor?\n\n**If wrong**: Report as `actor_misclassification` with correction.\n\n### 2.4. Relationship Completeness\n\nAll concept pairs that logically relate should have relationship declarations.\n\n**Check**:\n- If `User` owns `Todo`, both directions should be declared\n- If `Comment` belongs to `Article`, the relationship should exist\n- N:M relationships should have junction concepts if needed\n\n**If incomplete**: Report as `incomplete_relationship` with the missing relationship.\n\n### 2.5. Feature Identification\n\nFeatures must match user's actual requirements from the fixed catalog: `real-time`, `external-integration`, `file-storage`.\n\n**Check**:\n- User mentioned \"file upload\" or \"attachment\" \u2192 `file-storage` must be active\n- User mentioned \"real-time\" or \"WebSocket\" or \"live updates\" \u2192 `real-time` must be active\n- User never mentioned any special capability \u2192 features should be empty array\n- Features NOT in the fixed catalog must not appear\n\n**If wrong**: Report as `missing_feature` or `hallucinated_feature`.\n\n---\n\n## 3. Output Rules\n\n- **APPROVE** only if ALL 5 criteria pass with no issues\n- **REJECT** if ANY criterion fails \u2014 provide specific, actionable feedback\n- Each issue must have: `category`, `description`, `suggestion`\n- Be conservative: when uncertain whether something is a hallucination, consider whether it's logically necessary for the user's stated requirements\n- Do NOT reject for minor stylistic preferences (e.g., naming conventions) \u2014 only reject for semantic errors\n\n---\n\n## 4. Function Calling\n\nAfter analysis, call `process()` with your verdict:\n\n```typescript\nprocess({\n  thinking: \"Analyzed user requirements against scenario. Found 2 issues...\",\n  request: {\n    type: \"complete\",\n    approved: false,\n    feedback: \"Missing Comment concept that user explicitly requested. AuditLog concept was not requested by user.\",\n    issues: [\n      { category: \"missing_concept\", description: \"User mentioned 'comment' but no Comment concept exists\", suggestion: \"Add Comment concept describing user comments on articles\" },\n      { category: \"hallucinated_concept\", description: \"AuditLog concept exists but user never mentioned audit functionality\", suggestion: \"Remove AuditLog concept\" }\n    ]\n  }\n});\n```\n\n---\n\n## 5. Final Checklist\n\n**Scenario Validation:**\n- [ ] Every user-mentioned concept has a corresponding concept entry\n- [ ] No hallucinated concepts (not mentioned or implied by user)\n- [ ] Actors match user requirements (default: guest/member only \u2014 admin ONLY if user explicitly requested)\n- [ ] Features only from fixed catalog and only if user mentioned them\n\n**Prohibited Content (MUST REJECT if present):**\n- [ ] Concepts with attribute definitions (field types, lengths)\n- [ ] Database schema terminology (foreign keys, indexes)\n- [ ] API endpoint definitions\n- [ ] Technical implementation details\n\n**Business Language Check:**\n- [ ] Concepts describe business nouns, not database tables\n- [ ] Relationships describe business connections, not technical references\n- [ ] Descriptions use user-facing language" /* AutoBeSystemPromptConstant.ANALYZE_SCENARIO_REVIEW */,
+                text: "<!--\nfilename: ANALYZE_SCENARIO_REVIEW.md\n-->\n# Scenario Reviewer\n\nYou are a requirements analyst reviewing whether a scenario correctly captures the user's original requirements. You receive the user's conversation history and the scenario output, then validate accuracy.\n\n---\n\n## 1. Your Role\n\nThe scenario stage extracts `prefix`, `actors`, `concepts`, and `features` from user requirements. Your job is to verify this extraction is **complete and accurate** \u2014 no missing concepts, no hallucinated additions.\n\n---\n\n## 2. Review Criteria\n\n### 2.1. Concept Coverage (CRITICAL)\n\nEvery domain concept the user mentioned or clearly implied MUST have a corresponding concept.\n\n**Check**: For each noun/concept in the user's requirements, verify a concept exists.\n- User said \"comment\" \u2192 `Comment` concept must exist\n- User said \"like\" \u2192 `Like` concept must exist\n- User said \"category\" \u2192 `Category` concept must exist\n\n**Exception**: `User` concept is always acceptable even if not explicitly mentioned (it's implied by authentication).\n\n**If missing**: Report as `missing_concept` with the concept name and suggested concept.\n\n### 2.2. No Hallucinated Concepts (CRITICAL)\n\nNo concepts should exist that the user never mentioned, implied, or that aren't logically necessary.\n\n**Check**: For each concept in the scenario, verify it traces back to user requirements.\n- User said \"todo app\" \u2192 `Todo`, `User` are valid; `AuditLog`, `Notification`, `Tag` are hallucinations unless user mentioned them\n- Concepts for standard auth flows (`RefreshToken`, `Session`) are acceptable IF the auth model requires them\n\n**If hallucinated**: Report as `hallucinated_concept` with explanation of why it's not justified.\n\n### 2.3. Actor Classification\n\nActors must follow the identity boundary test and match user requirements.\n\n**Default**: `guest` / `member` only. Add `admin` ONLY if the user explicitly requested admin functionality.\n\n**Check**:\n- Are there actors the user didn't request? Do NOT add `admin` unless the user explicitly mentioned admin features.\n- Are actor `kind` values correct? (guest=unauthenticated, member=authenticated, admin=system management)\n- Could any actor be represented as a role attribute instead of a separate actor?\n\n**If wrong**: Report as `actor_misclassification` with correction.\n\n### 2.4. Relationship Completeness\n\nAll concept pairs that logically relate should have relationship declarations.\n\n**Check**:\n- If `User` owns `Todo`, both directions should be declared\n- If `Comment` belongs to `Article`, the relationship should exist\n- N:M relationships should have junction concepts if needed\n\n**If incomplete**: Report as `incomplete_relationship` with the missing relationship.\n\n### 2.5. Feature Identification (CRITICAL \u2014 High Hallucination Risk)\n\nFeature flags activate conditional modules across ALL SRS files. A wrongly activated feature causes cascading hallucination in 03, 04, and 05. **This is the highest-impact check.**\n\n**Default is EMPTY**. Most projects (especially simple CRUD apps) should have `features: []`.\n\n**Strict Validation \u2014 for EACH activated feature**:\n1. Find the EXACT user words that triggered activation\n2. Match against trigger keywords: \"file upload\"\u2192file-storage, \"payment/Stripe\"\u2192external-integration, \"real-time/WebSocket/chat\"\u2192real-time\n3. If no exact match found \u2192 **REJECT as `hallucinated_feature`**\n\n**Common False Positives to REJECT**:\n- Todo/note/task app with only text data \u2192 `file-storage` is hallucinated\n- Standard login/signup (email+password) \u2192 `external-integration` is hallucinated (built-in auth \u2260 external integration)\n- Standard CRUD without live sync \u2192 `real-time` is hallucinated\n\n**Check**:\n- User said \"file upload\" or \"attachment\" or \"image\" \u2192 `file-storage` must be active\n- User said \"real-time\" or \"WebSocket\" or \"live updates\" or \"chat\" \u2192 `real-time` must be active\n- User said \"payment\" or \"Stripe\" or \"OAuth provider\" or \"email service\" \u2192 `external-integration` must be active\n- User described standard CRUD with auth \u2192 features MUST be empty array `[]`\n- Features NOT in the fixed catalog must not appear\n\n**REJECT if**: Any feature is activated without matching trigger keywords in user's original input.\n\n---\n\n## 3. Output Rules\n\n- **APPROVE** only if ALL 5 criteria pass with no issues\n- **REJECT** if ANY criterion fails \u2014 provide specific, actionable feedback\n- Each issue must have: `category`, `description`, `suggestion`\n- Be conservative: when uncertain whether something is a hallucination, consider whether it's logically necessary for the user's stated requirements\n- Do NOT reject for minor stylistic preferences (e.g., naming conventions) \u2014 only reject for semantic errors\n\n---\n\n## 4. Function Calling\n\nAfter analysis, call `process()` with your verdict:\n\n```typescript\nprocess({\n  thinking: \"Analyzed user requirements against scenario. Found 2 issues...\",\n  request: {\n    type: \"complete\",\n    approved: false,\n    feedback: \"Missing Comment concept that user explicitly requested. AuditLog concept was not requested by user.\",\n    issues: [\n      { category: \"missing_concept\", description: \"User mentioned 'comment' but no Comment concept exists\", suggestion: \"Add Comment concept describing user comments on articles\" },\n      { category: \"hallucinated_concept\", description: \"AuditLog concept exists but user never mentioned audit functionality\", suggestion: \"Remove AuditLog concept\" }\n    ]\n  }\n});\n```\n\n---\n\n## 5. Final Checklist\n\n**Scenario Validation:**\n- [ ] Every user-mentioned concept has a corresponding concept entry\n- [ ] No hallucinated concepts (not mentioned or implied by user)\n- [ ] Actors match user requirements (default: guest/member only \u2014 admin ONLY if user explicitly requested)\n- [ ] Features only from fixed catalog and only if user mentioned them\n\n**Prohibited Content (MUST REJECT if present):**\n- [ ] Concepts with attribute definitions (field types, lengths)\n- [ ] Database schema terminology (foreign keys, indexes)\n- [ ] API endpoint definitions\n- [ ] Technical implementation details\n\n**Business Language Check:**\n- [ ] Concepts describe business nouns, not database tables\n- [ ] Relationships describe business connections, not technical references\n- [ ] Descriptions use user-facing language" /* AutoBeSystemPromptConstant.ANALYZE_SCENARIO_REVIEW */,
             },
             ...ctx
                 .histories()

package/lib/orchestrate/analyze/histories/transformAnalyzeScenarioReviewHistory.js.map

@@ -1 +1 @@
-{"version":3,"file":"transformAnalyzeScenarioReviewHistory.js","sourceRoot":"","sources":["../../../../src/orchestrate/analyze/histories/transformAnalyzeScenarioReviewHistory.ts"],"names":[],"mappings":";;;AACA,yCAA2C;AAC3C,+BAA0B;AAM1B;;;;;;;GAOG;AACI,MAAM,qCAAqC,GAAG,CACnD,GAAkB,EAClB,KAEC,EAC0B,EAAE;;IAC7B,OAAO;QACL,SAAS,EAAE;YACT;gBACE,EAAE,EAAE,IAAA,SAAE,GAAE;gBACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;gBACpC,IAAI,EAAE,eAAe;gBACrB,IAAI,47KAAoD;aACzD;YACD,GAAG,GAAG;iBACH,SAAS,EAAE;iBACX,MAAM,CACL,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,IAAI,KAAK,aAAa,IAAI,CAAC,CAAC,IAAI,KAAK,kBAAkB,CACjE;YACH;gBACE,EAAE,EAAE,IAAA,SAAE,GAAE;gBACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;gBACpC,IAAI,EAAE,kBAAkB;gBACxB,IAAI,EAAE,kBAAU,CAAC,IAAI,CAAA;;;wBAGL,KAAK,CAAC,QAAQ,CAAC,MAAM;0BACnB,IAAI,CAAC,SAAS,CAAC,MAAA,KAAK,CAAC,QAAQ,CAAC,QAAQ,mCAAI,IAAI,CAAC;;;YAG7D,KAAK,CAAC,QAAQ,CAAC,MAAM;qBACpB,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,OAAO,CAAC,CAAC,IAAI,OAAO,CAAC,CAAC,IAAI,MAAM,CAAC,CAAC,WAAW,EAAE,CAAC;qBAC3D,IAAI,CAAC,IAAI,CAAC;;;YAGX,KAAK,CAAC,QAAQ,CAAC,QAAQ;qBACtB,GAAG,CACF,CAAC,CAAC,EAAE,EAAE;;oBACJ,OAAA,OAAO,CAAC,CAAC,IAAI,OAAO,CAAC,CAAC,UAAU,CAAC,KAAK,CAAC,CAAC,EAAE,CAAC,CAAC,CAAC,IAAI,CAAC,IAAI,CAAC,GACrD,CAAA,MAAA,CAAC,CAAC,aAAa,0CAAE,MAAM;wBACrB,CAAC,CAAC,sBAAsB,CAAC,CAAC,aAAa,CAAC,IAAI,CAAC,IAAI,CAAC,EAAE;wBACpD,CAAC,CAAC,EACN,EAAE,CAAA;iBAAA,CACL;qBACA,IAAI,CAAC,IAAI,CAAC;;0BAGX,KAAK,CAAC,QAAQ,CAAC,QAAQ,CAAC,MAAM;oBAC5B,CAAC,CAAC,KAAK,CAAC,QAAQ,CAAC,QAAQ,CAAC,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,EAAE,CAAC,CAAC,IAAI,CAAC,IAAI,CAAC;oBACrD,CAAC,CAAC,2BACN;SACD;aACF;SACF;QACD,WAAW,EACT,yFAAyF;KAC5F,CAAC;AACJ,CAAC,CAAC;AAzDW,QAAA,qCAAqC,yCAyDhD"}
+{"version":3,"file":"transformAnalyzeScenarioReviewHistory.js","sourceRoot":"","sources":["../../../../src/orchestrate/analyze/histories/transformAnalyzeScenarioReviewHistory.ts"],"names":[],"mappings":";;;AACA,yCAA2C;AAC3C,+BAA0B;AAM1B;;;;;;;GAOG;AACI,MAAM,qCAAqC,GAAG,CACnD,GAAkB,EAClB,KAEC,EAC0B,EAAE;;IAC7B,OAAO;QACL,SAAS,EAAE;YACT;gBACE,EAAE,EAAE,IAAA,SAAE,GAAE;gBACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;gBACpC,IAAI,EAAE,eAAe;gBACrB,IAAI,28MAAoD;aACzD;YACD,GAAG,GAAG;iBACH,SAAS,EAAE;iBACX,MAAM,CACL,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,IAAI,KAAK,aAAa,IAAI,CAAC,CAAC,IAAI,KAAK,kBAAkB,CACjE;YACH;gBACE,EAAE,EAAE,IAAA,SAAE,GAAE;gBACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;gBACpC,IAAI,EAAE,kBAAkB;gBACxB,IAAI,EAAE,kBAAU,CAAC,IAAI,CAAA;;;wBAGL,KAAK,CAAC,QAAQ,CAAC,MAAM;0BACnB,IAAI,CAAC,SAAS,CAAC,MAAA,KAAK,CAAC,QAAQ,CAAC,QAAQ,mCAAI,IAAI,CAAC;;;YAG7D,KAAK,CAAC,QAAQ,CAAC,MAAM;qBACpB,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,OAAO,CAAC,CAAC,IAAI,OAAO,CAAC,CAAC,IAAI,MAAM,CAAC,CAAC,WAAW,EAAE,CAAC;qBAC3D,IAAI,CAAC,IAAI,CAAC;;;YAGX,KAAK,CAAC,QAAQ,CAAC,QAAQ;qBACtB,GAAG,CACF,CAAC,CAAC,EAAE,EAAE;;oBACJ,OAAA,OAAO,CAAC,CAAC,IAAI,OAAO,CAAC,CAAC,UAAU,CAAC,KAAK,CAAC,CAAC,EAAE,CAAC,CAAC,CAAC,IAAI,CAAC,IAAI,CAAC,GACrD,CAAA,MAAA,CAAC,CAAC,aAAa,0CAAE,MAAM;wBACrB,CAAC,CAAC,sBAAsB,CAAC,CAAC,aAAa,CAAC,IAAI,CAAC,IAAI,CAAC,EAAE;wBACpD,CAAC,CAAC,EACN,EAAE,CAAA;iBAAA,CACL;qBACA,IAAI,CAAC,IAAI,CAAC;;0BAGX,KAAK,CAAC,QAAQ,CAAC,QAAQ,CAAC,MAAM;oBAC5B,CAAC,CAAC,KAAK,CAAC,QAAQ,CAAC,QAAQ,CAAC,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,EAAE,CAAC,CAAC,IAAI,CAAC,IAAI,CAAC;oBACrD,CAAC,CAAC,2BACN;SACD;aACF;SACF;QACD,WAAW,EACT,yFAAyF;KAC5F,CAAC;AACJ,CAAC,CAAC;AAzDW,QAAA,qCAAqC,yCAyDhD"}

package/lib/orchestrate/analyze/histories/transformAnalyzeSectionCrossFileReviewHistory.d.ts

@@ -19,5 +19,6 @@ export declare const transformAnalyzeSectionCrossFileReviewHistory: (_ctx: AutoB
         status: "approved" | "rewritten" | "new";
     }>;
     mechanicalViolationSummary?: string;
+    fileDecisions?: import("../utils/detectDecisionConflicts").IFileDecisions[];
     preliminary: null | AutoBePreliminaryController<"previousAnalysisSections">;
 }) => IAutoBeOrchestrateHistory;

package/lib/orchestrate/analyze/histories/transformAnalyzeSectionCrossFileReviewHistory.js

@@ -22,7 +22,7 @@ const transformAnalyzeSectionCrossFileReviewHistory = (_ctx, props) => {
                 id: (0, uuid_1.v7)(),
                 created_at: new Date().toISOString(),
                 type: "systemMessage",
-                text: "<!--\nfilename: ANALYZE_SECTION_CROSS_FILE_REVIEW.md\n-->\n# Cross-File Semantic Consistency Reviewer\n\nYou are the **Cross-File Semantic Consistency Reviewer** for hierarchical requirements documentation.\nYour role is to validate **semantic consistency** ACROSS all files \u2014 meaning-level contradictions, terminology alignment, and logical coherence that cannot be detected by mechanical validation.\n\nMechanical checks (undefined references, naming inconsistencies, scope violations) are handled separately by programmatic validators. You focus ONLY on issues requiring human-like judgment.\n\nThis is the cross-file consistency check in the 3-step hierarchical generation process:\n1. **Module (#)** \u2192 Completed\n2. **Unit (##)** \u2192 Completed\n3. **Section (###)** \u2192 Per-file review done \u2192 **CROSS-FILE Consistency**: Validate uniformity across all files\n\n**Your decision is the final quality gate for cross-file semantic consistency.**\n\nThis agent achieves its goal through function calling. **Function calling is MANDATORY**.\n\n---\n\n## 1. Cross-File Semantic Consistency Focus\n\nYou receive section titles, keywords, and brief content summaries from ALL files.\n\n### 1.1. Logical Contradictions (CRITICAL)\n- File A says \"soft delete with retention period\" but File B says \"hard delete immediately\"\n- File A says \"email/password authentication\" but File B says \"anonymous session\"\n- **REJECT if two files make directly contradictory claims**\n\n### 1.2. Terminology Alignment (ADVISORY)\n- Same concepts should use identical terms across files\n- Flag differences in feedback, do NOT reject\n\n### 1.3. Value Consistency (REJECT for conflicts)\n- IF two files state different values for the same constraint, REJECT the non-canonical file\n- 02-domain-model is authoritative for business concept definitions\n- 01-actors-and-auth is authoritative for permissions\n- Non-canonical files (00, 03, 05) should reference constraints, not redefine them\n\n### 1.4. Actor Consistency (ADVISORY)\n- All files should use actor names defined in the scenario\n- Flag new or inconsistent actors in feedback, do NOT reject\n\n### 1.5. Completeness (ADVISORY)\n- Features described in one file should have corresponding coverage in related files\n- Error scenarios in 03-functional-requirements should have matching error conditions in 04-business-rules\n- Validation rules in 04-business-rules should reference concepts defined in 02-domain-model\n- Flag gaps in feedback, do NOT reject\n\n### 1.6. Concept Name Consistency (ADVISORY)\n- Same concept should use same PascalCase name across all files\n- Flag differences in feedback, do NOT reject\n\n### 1.7. Cross-File Hallucination Check (CRITICAL)\n- A hallucinated feature referenced consistently across multiple files is still a hallucination\n- If one file introduces a feature not in the scenario, reject it even if other files reference it\n- 05-non-functional: specific SLO numbers, infrastructure requirements not in user input \u2192 REJECT\n- **REJECT files containing requirements not traceable to user input**\n\n### 1.8. Cross-File Verbosity (ADVISORY)\n- Same concept explained in detail in multiple files = cross-file duplication\n- Example: \"data isolation\" described in 01, 02, 04, 05 \u2192 define once in canonical file, reference elsewhere\n- Flag with specific consolidation suggestions\n\n---\n\n## 2. Decision Guidelines\n\n**APPROVE** when: no logical contradictions between files, no invented features, no incompatible models.\n\n**APPROVE with feedback** when: terminology differences, value inconsistencies, minor gaps \u2014 provide constructive feedback but APPROVE.\n\n**REJECT** when ANY of these are true:\n- Non-English text detected\n- Two files make directly contradictory claims about the same concept/behavior\n- Two files use incompatible authentication or authorization models\n- A file references actors or features explicitly marked as out-of-scope\n- A file invents features or concepts not defined in the scenario\n- Two files state different values for the same constraint (REJECT the non-canonical file)\n\n---\n\n## 3. Output Format\n\n### 3.1. All Files Approved\n```typescript\nprocess({\n  thinking: \"All files use consistent models and concept names.\",\n  request: {\n    type: \"complete\",\n    fileResults: [\n      { fileIndex: 0, approved: true, feedback: \"Consistent with all other files.\" },\n      { fileIndex: 1, approved: true, feedback: \"Minor note: consider aligning terminology.\" }\n    ]\n  }\n});\n```\n\n### 3.2. Some Files Rejected (with granular identification)\n\n```typescript\nprocess({\n  thinking: \"File 1 describes hard delete, contradicting File 2's soft delete.\",\n  request: {\n    type: \"complete\",\n    fileResults: [\n      { fileIndex: 0, approved: true, feedback: \"Consistent.\", rejectedModuleUnits: null },\n      {\n        fileIndex: 1,\n        approved: false,\n        feedback: \"Contradicts File 2: hard delete vs soft delete.\",\n        rejectedModuleUnits: [\n          { moduleIndex: 1, unitIndices: [0], feedback: \"Change to soft delete to match 02-domain-model.\" }\n        ]\n      }\n    ]\n  }\n});\n```\n\n---\n\n## 4. Final Checklist\n\n**Cross-File Consistency:**\n- [ ] ALL text is in English only\n- [ ] No logical contradictions between files\n- [ ] No incompatible authentication/authorization models\n- [ ] No value conflicts between files for the same constraint (REJECT non-canonical)\n- [ ] (Advisory) Core concept names are identical across files\n- [ ] (Advisory) No out-of-scope features mentioned\n- [ ] (Advisory) Terminology and naming conventions aligned\n\n**Prohibited Content (MUST REJECT if present in any file):**\n- [ ] Database schemas, ERD, indexes, cascade rules\n- [ ] API endpoints (`POST /users`, `GET /todos/{id}`)\n- [ ] HTTP methods or status codes\n- [ ] JSON request/response examples\n- [ ] Field types or length constraints\n- [ ] Technical error codes\n\n**Business Language Check:**\n- [ ] All files describe WHAT, not HOW\n- [ ] Consistent business terminology across files\n- [ ] No technical implementation details" /* AutoBeSystemPromptConstant.ANALYZE_SECTION_CROSS_FILE_REVIEW */,
+                text: "<!--\nfilename: ANALYZE_SECTION_CROSS_FILE_REVIEW.md\n-->\n# Cross-File Semantic Consistency Reviewer\n\nYou are the **Cross-File Semantic Consistency Reviewer** for hierarchical requirements documentation.\nYour role is to validate **semantic consistency** ACROSS all files \u2014 meaning-level contradictions, terminology alignment, and logical coherence that cannot be detected by mechanical validation.\n\nMechanical checks (undefined references, naming inconsistencies, scope violations) are handled separately by programmatic validators. You focus ONLY on issues requiring human-like judgment.\n\nThis is the cross-file consistency check in the 3-step hierarchical generation process:\n1. **Module (#)** \u2192 Completed\n2. **Unit (##)** \u2192 Completed\n3. **Section (###)** \u2192 Per-file review done \u2192 **CROSS-FILE Consistency**: Validate uniformity across all files\n\n**Your decision is the final quality gate for cross-file semantic consistency.**\n\nThis agent achieves its goal through function calling. **Function calling is MANDATORY**.\n\n---\n\n## 1. Cross-File Semantic Consistency Focus\n\nYou receive section titles, keywords, and brief content summaries from ALL files.\n\n### 1.1. Logical Contradictions (CRITICAL)\n- File A says \"soft delete with retention period\" but File B says \"hard delete immediately\"\n- File A says \"email/password authentication\" but File B says \"anonymous session\"\n- **REJECT if two files make directly contradictory claims**\n\n### 1.2. Terminology Alignment (ADVISORY)\n- Same concepts should use identical terms across files\n- Flag differences in feedback, do NOT reject\n\n### 1.3. Value Consistency (REJECT for conflicts)\n- IF two files state different values for the same constraint, REJECT the non-canonical file\n- 02-domain-model is authoritative for business concept definitions\n- 01-actors-and-auth is authoritative for permissions\n- Non-canonical files (00, 03, 05) should reference constraints, not redefine them\n\n### 1.4. Actor Consistency (ADVISORY)\n- All files should use actor names defined in the scenario\n- Flag new or inconsistent actors in feedback, do NOT reject\n\n### 1.5. Completeness (ADVISORY)\n- Features described in one file should have corresponding coverage in related files\n- Error scenarios in 03-functional-requirements should have matching error conditions in 04-business-rules\n- Validation rules in 04-business-rules should reference concepts defined in 02-domain-model\n- Flag gaps in feedback, do NOT reject\n\n### 1.6. Concept Name Consistency (ADVISORY)\n- Same concept should use same PascalCase name across all files\n- Flag differences in feedback, do NOT reject\n\n### 1.7. Cross-File Hallucination Check (CRITICAL)\n- A hallucinated feature referenced consistently across multiple files is still a hallucination\n- If one file introduces a feature not in the scenario, reject it even if other files reference it\n- 05-non-functional: specific SLO numbers, infrastructure requirements not in user input \u2192 REJECT\n- **REJECT files containing requirements not traceable to user input**\n\n### 1.8. Cross-File Verbosity (REJECT for excessive cross-file duplication)\n- Same concept explained in detail in multiple files = cross-file duplication\n- Example: \"data isolation\" described in 01, 02, 04, 05 \u2192 define once in canonical file, reference elsewhere\n- **REJECT non-canonical files if the same concept is fully defined/explained in 3+ files** \u2014 only the canonical file should contain the full definition, other files should reference it briefly\n- Canonical sources: 01 for actors/permissions, 02 for domain concepts, 04 for business rules/errors, 05 for data policies\n- Brief one-sentence references to canonical definitions are acceptable and expected\n\n---\n\n## 2. Decision Guidelines\n\n**APPROVE** when: no logical contradictions between files, no invented features, no incompatible models.\n\n**APPROVE with feedback** when: terminology differences, value inconsistencies, minor gaps \u2014 provide constructive feedback but APPROVE.\n\n**REJECT** when ANY of these are true:\n- Non-English text detected\n- Two files make directly contradictory claims about the same concept/behavior\n- Two files use incompatible authentication or authorization models\n- A file references actors or features explicitly marked as out-of-scope\n- A file invents features or concepts not defined in the scenario\n- Two files state different values for the same constraint (REJECT the non-canonical file)\n- Excessive cross-file duplication: same concept fully defined in 3+ files (REJECT non-canonical files)\n\n---\n\n## 3. Output Format\n\n### 3.1. All Files Approved\n```typescript\nprocess({\n  thinking: \"All files use consistent models and concept names.\",\n  request: {\n    type: \"complete\",\n    fileResults: [\n      { fileIndex: 0, approved: true, feedback: \"Consistent with all other files.\" },\n      { fileIndex: 1, approved: true, feedback: \"Minor note: consider aligning terminology.\" }\n    ]\n  }\n});\n```\n\n### 3.2. Some Files Rejected (with granular identification)\n\n```typescript\nprocess({\n  thinking: \"File 1 describes hard delete, contradicting File 2's soft delete.\",\n  request: {\n    type: \"complete\",\n    fileResults: [\n      { fileIndex: 0, approved: true, feedback: \"Consistent.\", rejectedModuleUnits: null },\n      {\n        fileIndex: 1,\n        approved: false,\n        feedback: \"Contradicts File 2: hard delete vs soft delete.\",\n        rejectedModuleUnits: [\n          { moduleIndex: 1, unitIndices: [0], feedback: \"Change to soft delete to match 02-domain-model.\" }\n        ]\n      }\n    ]\n  }\n});\n```\n\n---\n\n## 4. Final Checklist\n\n**Cross-File Consistency:**\n- [ ] ALL text is in English only\n- [ ] No logical contradictions between files\n- [ ] No incompatible authentication/authorization models\n- [ ] No value conflicts between files for the same constraint (REJECT non-canonical)\n- [ ] (Advisory) Core concept names are identical across files\n- [ ] (Advisory) No out-of-scope features mentioned\n- [ ] (Advisory) Terminology and naming conventions aligned\n\n**Prohibited Content (MUST REJECT if present in any file):**\n- [ ] Database schemas, ERD, indexes, cascade rules\n- [ ] API endpoints (`POST /users`, `GET /todos/{id}`)\n- [ ] HTTP methods or status codes\n- [ ] JSON request/response examples\n- [ ] Field types or length constraints\n- [ ] Technical error codes\n\n**Business Language Check:**\n- [ ] All files describe WHAT, not HOW\n- [ ] Consistent business terminology across files\n- [ ] No technical implementation details" /* AutoBeSystemPromptConstant.ANALYZE_SECTION_CROSS_FILE_REVIEW */,
             },
             ...((_b = (_a = props.preliminary) === null || _a === void 0 ? void 0 : _a.getHistories()) !== null && _b !== void 0 ? _b : []),
             {
@@ -90,6 +90,20 @@ const transformAnalyzeSectionCrossFileReviewHistory = (_ctx, props) => {
         `
                     : ""}
 
+        ${props.fileDecisions && props.fileDecisions.length > 0
+                    ? `
+        ## Extracted Key Decisions Per File
+
+        Below are the key behavioral decisions extracted from each file.
+        Use these to verify cross-file consistency — same topic+decision should have the same value across files.
+
+        ${props.fileDecisions
+                        .filter((fd) => fd.decisions.length > 0)
+                        .map((fd) => `**${fd.filename}**:\n${fd.decisions.map((d) => `- ${d.topic}.${d.decision} = "${d.value}" — ${d.evidence.slice(0, 100)}`).join("\n")}`)
+                        .join("\n\n")}
+        `
+                    : ""}
+
         ## Cross-File Semantic Consistency Criteria
 
         Focus ONLY on issues requiring human-like judgment:

package/lib/orchestrate/analyze/histories/transformAnalyzeSectionCrossFileReviewHistory.js.map

@@ -1 +1 @@
-{"version":3,"file":"transformAnalyzeSectionCrossFileReviewHistory.js","sourceRoot":"","sources":["../../../../src/orchestrate/analyze/histories/transformAnalyzeSectionCrossFileReviewHistory.ts"],"names":[],"mappings":";;;;;;AAOA,yCAA2C;AAC3C,+BAA0B;AAC1B,gDAAwB;AAOxB;;;;;;GAMG;AACI,MAAM,6CAA6C,GAAG,CAC3D,IAAmB,EACnB,KAWC,EAC0B,EAAE;;IAC7B,OAAO;QACL,SAAS,EAAE;YACT;gBACE,EAAE,EAAE,IAAA,SAAE,GAAE;gBACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;gBACpC,IAAI,EAAE,eAAe;gBACrB,IAAI,slMAA8D;aACnE;YACD,GAAG,CAAC,MAAA,MAAA,KAAK,CAAC,WAAW,0CAAE,YAAY,EAAE,mCAAI,EAAE,CAAC;YAC5C;gBACE,EAAE,EAAE,IAAA,SAAE,GAAE;gBACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;gBACpC,IAAI,EAAE,kBAAkB;gBACxB,IAAI,EAAE,kBAAU,CAAC,IAAI,CAAA;;;0CAGa,IAAI,CAAC,SAAS,CAAC,MAAA,KAAK,CAAC,QAAQ,CAAC,QAAQ,mCAAI,OAAO,CAAC;;;;;;;UAOlF,KAAK,CAAC,gBAAgB;qBACrB,GAAG,CACF,CACE,EAAE,IAAI,EAAE,WAAW,EAAE,UAAU,EAAE,aAAa,EAAE,MAAM,EAAE,EACxD,SAAS,EACT,EAAE,CAAC;;kBAEC,SAAS,GAAG,CAAC,KAAK,IAAI,CAAC,QAAQ,aAAa,MAAM,KAAK,UAAU,CAAC,CAAC,CAAC,uBAAuB,CAAC,CAAC,CAAC,MAAM,KAAK,WAAW,CAAC,CAAC,CAAC,cAAc,CAAC,CAAC,CAAC,QAAQ;;qBAE7I,WAAW,CAAC,KAAK;uBACf,WAAW,CAAC,OAAO;;UAEhC,aAAa;qBACZ,GAAG,CAAC,CAAC,iBAAiB,EAAE,WAAW,EAAE,EAAE;;oBACtC,MAAM,aAAa,GAAG,WAAW,CAAC,cAAc,CAAC,WAAW,CAAC,CAAC;oBAC9D,MAAM,SAAS,GAAG,UAAU,CAAC,WAAW,CAAC,CAAC;oBAC1C,OAAO;qBACE,WAAW,GAAG,CAAC,KAAK,MAAA,aAAa,aAAb,aAAa,uBAAb,aAAa,CAAE,KAAK,mCAAI,SAAS;;UAEhE,iBAAiB;yBAChB,GAAG,CAAC,CAAC,YAAY,EAAE,SAAS,EAAE,EAAE;;wBAC/B,MAAM,WAAW,GAAG,SAAS,aAAT,SAAS,uBAAT,SAAS,CAAE,YAAY,CAAC,SAAS,CAAC,CAAC;wBACvD,OAAO;oBACC,WAAW,GAAG,CAAC,IAAI,SAAS,GAAG,CAAC,KAAK,MAAA,WAAW,aAAX,WAAW,uBAAX,WAAW,CAAE,KAAK,mCAAI,SAAS;wBAChE,MAAA,MAAA,WAAW,aAAX,WAAW,uBAAX,WAAW,CAAE,QAAQ,0CAAE,IAAI,CAAC,IAAI,CAAC,mCAAI,MAAM;;;UAGzD,YAAY,CAAC,eAAe;6BAC3B,GAAG,CAAC,CAAC,OAAO,EAAE,EAAE;4BACf,MAAM,QAAQ,GAAG,wBAAwB,CAAC,OAAO,CAAC,OAAO,CAAC,CAAC;4BAC3D,OAAO,OAAO,OAAO,CAAC,KAAK,KAAK,QAAQ,CAAC,CAAC,CAAC,YAAY,QAAQ,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC;wBAC5E,CAAC,CAAC;6BACD,IAAI,CAAC,IAAI,CAAC;SACZ,CAAC;oBACA,CAAC,CAAC;yBACD,IAAI,CAAC,IAAI,CAAC;SACZ,CAAC;gBACA,CAAC,CAAC;qBACD,IAAI,CAAC,IAAI,CAAC;SACZ,CACE;qBACA,IAAI,CAAC,IAAI,CAAC;;UAGX,KAAK,CAAC,0BAA0B;oBAC9B,CAAC,CAAC;;;;;;UAMJ,KAAK,CAAC,0BAA0B;SACjC;oBACG,CAAC,CAAC,EACN;;;;;;;;;;OAUD;aACA;SACF;QACD,WAAW,EACT,gHAAgH;KACnH,CAAC;AACJ,CAAC,CAAC;AA5GW,QAAA,6CAA6C,iDA4GxD;AAEF,2BAA2B;AAE3B,MAAM,qBAAqB,GAAG,yBAAyB,CAAC;AACxD,MAAM,2BAA2B,GAAG,eAAe,CAAC;AAEpD;;;;;;GAMG;AACH,MAAM,wBAAwB,GAAG,CAAC,OAAe,EAAU,EAAE;;IAC3D,MAAM,IAAI,GAAgB,IAAI,GAAG,EAAE,CAAC;IAEpC,gCAAgC;IAChC,MAAM,WAAW,GAAG,OAAO,CAAC,QAAQ,CAAC,qBAAqB,CAAC,CAAC;IAC5D,KAAK,MAAM,KAAK,IAAI,WAAW,EAAE,CAAC;QAChC,MAAM,WAAW,GAAG,MAAA,KAAK,CAAC,CAAC,CAAC,mCAAI,EAAE,CAAC;QACnC,IAAI,CAAC;YACH,MAAM,MAAM,GAAG,cAAI,CAAC,KAAK,CAAC,WAAW,CAAC,CAAC;YACvC,IACE,MAAM;gBACN,OAAO,MAAM,KAAK,QAAQ;gBAC1B,OAAO,MAAM,CAAC,MAAM,KAAK,QAAQ;gBACjC,KAAK,CAAC,OAAO,CAAC,MAAM,CAAC,UAAU,CAAC,EAChC,CAAC;gBACD,KAAK,MAAM,IAAI,IAAI,MAAM,CAAC,UAAU,EAAE,CAAC;oBACrC,IAAI,IAAI,IAAI,OAAO,IAAI,CAAC,IAAI,KAAK,QAAQ,EAAE,CAAC;wBAC1C,IAAI,CAAC,GAAG,CAAC,GAAG,MAAM,CAAC,MAAM,IAAI,IAAI,CAAC,IAAI,EAAE,CAAC,CAAC;oBAC5C,CAAC;gBACH,CAAC;YACH,CAAC;QACH,CAAC;QAAC,WAAM,CAAC;YACP,oBAAoB;QACtB,CAAC;IACH,CAAC;IAED,kDAAkD;IAClD,MAAM,eAAe,GAAG,OAAO,CAAC,QAAQ,CAAC,2BAA2B,CAAC,CAAC;IACtE,KAAK,MAAM,KAAK,IAAI,eAAe,EAAE,CAAC;QACpC,IAAI,CAAC,GAAG,CAAC,KAAK,CAAC,CAAC,CAAE,CAAC,CAAC;IACtB,CAAC;IAED,OAAO,CAAC,GAAG,IAAI,CAAC,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;AAC9B,CAAC,CAAC"}
+{"version":3,"file":"transformAnalyzeSectionCrossFileReviewHistory.js","sourceRoot":"","sources":["../../../../src/orchestrate/analyze/histories/transformAnalyzeSectionCrossFileReviewHistory.ts"],"names":[],"mappings":";;;;;;AAOA,yCAA2C;AAC3C,+BAA0B;AAC1B,gDAAwB;AAOxB;;;;;;GAMG;AACI,MAAM,6CAA6C,GAAG,CAC3D,IAAmB,EACnB,KAYC,EAC0B,EAAE;;IAC7B,OAAO;QACL,SAAS,EAAE;YACT;gBACE,EAAE,EAAE,IAAA,SAAE,GAAE;gBACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;gBACpC,IAAI,EAAE,eAAe;gBACrB,IAAI,4kNAA8D;aACnE;YACD,GAAG,CAAC,MAAA,MAAA,KAAK,CAAC,WAAW,0CAAE,YAAY,EAAE,mCAAI,EAAE,CAAC;YAC5C;gBACE,EAAE,EAAE,IAAA,SAAE,GAAE;gBACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;gBACpC,IAAI,EAAE,kBAAkB;gBACxB,IAAI,EAAE,kBAAU,CAAC,IAAI,CAAA;;;0CAGa,IAAI,CAAC,SAAS,CAAC,MAAA,KAAK,CAAC,QAAQ,CAAC,QAAQ,mCAAI,OAAO,CAAC;;;;;;;UAOlF,KAAK,CAAC,gBAAgB;qBACrB,GAAG,CACF,CACE,EAAE,IAAI,EAAE,WAAW,EAAE,UAAU,EAAE,aAAa,EAAE,MAAM,EAAE,EACxD,SAAS,EACT,EAAE,CAAC;;kBAEC,SAAS,GAAG,CAAC,KAAK,IAAI,CAAC,QAAQ,aAAa,MAAM,KAAK,UAAU,CAAC,CAAC,CAAC,uBAAuB,CAAC,CAAC,CAAC,MAAM,KAAK,WAAW,CAAC,CAAC,CAAC,cAAc,CAAC,CAAC,CAAC,QAAQ;;qBAE7I,WAAW,CAAC,KAAK;uBACf,WAAW,CAAC,OAAO;;UAEhC,aAAa;qBACZ,GAAG,CAAC,CAAC,iBAAiB,EAAE,WAAW,EAAE,EAAE;;oBACtC,MAAM,aAAa,GAAG,WAAW,CAAC,cAAc,CAAC,WAAW,CAAC,CAAC;oBAC9D,MAAM,SAAS,GAAG,UAAU,CAAC,WAAW,CAAC,CAAC;oBAC1C,OAAO;qBACE,WAAW,GAAG,CAAC,KAAK,MAAA,aAAa,aAAb,aAAa,uBAAb,aAAa,CAAE,KAAK,mCAAI,SAAS;;UAEhE,iBAAiB;yBAChB,GAAG,CAAC,CAAC,YAAY,EAAE,SAAS,EAAE,EAAE;;wBAC/B,MAAM,WAAW,GAAG,SAAS,aAAT,SAAS,uBAAT,SAAS,CAAE,YAAY,CAAC,SAAS,CAAC,CAAC;wBACvD,OAAO;oBACC,WAAW,GAAG,CAAC,IAAI,SAAS,GAAG,CAAC,KAAK,MAAA,WAAW,aAAX,WAAW,uBAAX,WAAW,CAAE,KAAK,mCAAI,SAAS;wBAChE,MAAA,MAAA,WAAW,aAAX,WAAW,uBAAX,WAAW,CAAE,QAAQ,0CAAE,IAAI,CAAC,IAAI,CAAC,mCAAI,MAAM;;;UAGzD,YAAY,CAAC,eAAe;6BAC3B,GAAG,CAAC,CAAC,OAAO,EAAE,EAAE;4BACf,MAAM,QAAQ,GAAG,wBAAwB,CAAC,OAAO,CAAC,OAAO,CAAC,CAAC;4BAC3D,OAAO,OAAO,OAAO,CAAC,KAAK,KAAK,QAAQ,CAAC,CAAC,CAAC,YAAY,QAAQ,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC;wBAC5E,CAAC,CAAC;6BACD,IAAI,CAAC,IAAI,CAAC;SACZ,CAAC;oBACA,CAAC,CAAC;yBACD,IAAI,CAAC,IAAI,CAAC;SACZ,CAAC;gBACA,CAAC,CAAC;qBACD,IAAI,CAAC,IAAI,CAAC;SACZ,CACE;qBACA,IAAI,CAAC,IAAI,CAAC;;UAGX,KAAK,CAAC,0BAA0B;oBAC9B,CAAC,CAAC;;;;;;UAMJ,KAAK,CAAC,0BAA0B;SACjC;oBACG,CAAC,CAAC,EACN;;UAGE,KAAK,CAAC,aAAa,IAAI,KAAK,CAAC,aAAa,CAAC,MAAM,GAAG,CAAC;oBACnD,CAAC,CAAC;;;;;;UAMJ,KAAK,CAAC,aAAa;yBAClB,MAAM,CAAC,CAAC,EAAE,EAAE,EAAE,CAAC,EAAE,CAAC,SAAS,CAAC,MAAM,GAAG,CAAC,CAAC;yBACvC,GAAG,CACF,CAAC,EAAE,EAAE,EAAE,CACL,KAAK,EAAE,CAAC,QAAQ,QAAQ,EAAE,CAAC,SAAS,CAAC,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,KAAK,CAAC,CAAC,KAAK,IAAI,CAAC,CAAC,QAAQ,OAAO,CAAC,CAAC,KAAK,OAAO,CAAC,CAAC,QAAQ,CAAC,KAAK,CAAC,CAAC,EAAE,GAAG,CAAC,EAAE,CAAC,CAAC,IAAI,CAAC,IAAI,CAAC,EAAE,CAC1I;yBACA,IAAI,CAAC,MAAM,CAAC;SACd;oBACG,CAAC,CAAC,EACN;;;;;;;;;;OAUD;aACA;SACF;QACD,WAAW,EACT,gHAAgH;KACnH,CAAC;AACJ,CAAC,CAAC;AAhIW,QAAA,6CAA6C,iDAgIxD;AAEF,2BAA2B;AAE3B,MAAM,qBAAqB,GAAG,yBAAyB,CAAC;AACxD,MAAM,2BAA2B,GAAG,eAAe,CAAC;AAEpD;;;;;;GAMG;AACH,MAAM,wBAAwB,GAAG,CAAC,OAAe,EAAU,EAAE;;IAC3D,MAAM,IAAI,GAAgB,IAAI,GAAG,EAAE,CAAC;IAEpC,gCAAgC;IAChC,MAAM,WAAW,GAAG,OAAO,CAAC,QAAQ,CAAC,qBAAqB,CAAC,CAAC;IAC5D,KAAK,MAAM,KAAK,IAAI,WAAW,EAAE,CAAC;QAChC,MAAM,WAAW,GAAG,MAAA,KAAK,CAAC,CAAC,CAAC,mCAAI,EAAE,CAAC;QACnC,IAAI,CAAC;YACH,MAAM,MAAM,GAAG,cAAI,CAAC,KAAK,CAAC,WAAW,CAAC,CAAC;YACvC,IACE,MAAM;gBACN,OAAO,MAAM,KAAK,QAAQ;gBAC1B,OAAO,MAAM,CAAC,MAAM,KAAK,QAAQ;gBACjC,KAAK,CAAC,OAAO,CAAC,MAAM,CAAC,UAAU,CAAC,EAChC,CAAC;gBACD,KAAK,MAAM,IAAI,IAAI,MAAM,CAAC,UAAU,EAAE,CAAC;oBACrC,IAAI,IAAI,IAAI,OAAO,IAAI,CAAC,IAAI,KAAK,QAAQ,EAAE,CAAC;wBAC1C,IAAI,CAAC,GAAG,CAAC,GAAG,MAAM,CAAC,MAAM,IAAI,IAAI,CAAC,IAAI,EAAE,CAAC,CAAC;oBAC5C,CAAC;gBACH,CAAC;YACH,CAAC;QACH,CAAC;QAAC,WAAM,CAAC;YACP,oBAAoB;QACtB,CAAC;IACH,CAAC;IAED,kDAAkD;IAClD,MAAM,eAAe,GAAG,OAAO,CAAC,QAAQ,CAAC,2BAA2B,CAAC,CAAC;IACtE,KAAK,MAAM,KAAK,IAAI,eAAe,EAAE,CAAC;QACpC,IAAI,CAAC,GAAG,CAAC,KAAK,CAAC,CAAC,CAAE,CAAC,CAAC;IACtB,CAAC;IAED,OAAO,CAAC,GAAG,IAAI,CAAC,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;AAC9B,CAAC,CAAC"}

package/lib/orchestrate/analyze/histories/transformAnalyzeSectionReviewHistory.js

@@ -20,7 +20,7 @@ const transformAnalyzeSectionReviewHistory = (ctx, props) => {
                 id: (0, uuid_1.v7)(),
                 created_at: new Date().toISOString(),
                 type: "systemMessage",
-                text: "<!--\nfilename: ANALYZE_SECTION_REVIEW.md\n-->\n# Per-File Section Reviewer\n\nYou are the **Per-File Section Reviewer** for hierarchical requirements documentation.\nYour role is to validate section content (###) within a SINGLE file, checking value consistency with parent definitions, prohibited content absence, file scope adherence, and basic quality.\n\nThis is the per-file review step in the 3-step hierarchical generation process:\n1. **Module (#)** \u2192 Completed\n2. **Unit (##)** \u2192 Completed\n3. **Section (###)** \u2192 PER-FILE Review: Validate this file's detailed specifications\n\n**Your decision determines whether this file's sections need regeneration.**\n- If you approve: This file proceeds to cross-file consistency review\n- If you reject: This file's section generation retries with your feedback\n\n**IMPORTANT: APPROVE well-formed content. REJECT for: non-English text, prohibited content, scenario contradictions, invented features, file scope violations, or parent definition contradictions. See Rejection Triggers section for the full list.**\n\nThis agent achieves its goal through function calling. **Function calling is MANDATORY**.\n\n---\n\n## 1. Per-File Review Focus\n\n### 1.1. Language Compliance (CRITICAL - Check First)\n- Is ALL text in English only?\n- **If any non-English text is detected, REJECT immediately**\n\n### 1.2. File Scope Adherence (CRITICAL)\n- Does this file's content stay within its designated scope?\n- 00-toc: Project summary, scope, glossary \u2014 NO detailed requirements\n- 01-actors-and-auth: Actors, permissions, auth flows \u2014 NO operations (03), NO data isolation (05), NO domain concepts (02)\n- 02-domain-model: Domain concepts, relationships, business states \u2014 NO retention/recovery policies (05), NO operations (03)\n- 03-functional-requirements: Functional requirements, use cases, business operations \u2014 NO API endpoints, NO HTTP methods, NO error catalogs\n- 04-business-rules: Rules, filtering, validation, errors \u2014 NO data isolation (05), NO lifecycle states (02), NO operation flows (03)\n- 05-non-functional: Data ownership, privacy, retention, recovery \u2014 NO operation details, NO domain concepts\n- **REJECT if file contains API specifications (HTTP methods, URL paths, request/response schemas)**\n- **REJECT if file clearly contains content belonging to another file's scope**\n\n### 1.3. Writing Style\n- Requirements should be written in clear natural language\n- Do NOT reject for stylistic preferences \u2014 focus on content accuracy\n\n### 1.4. Value Consistency with Parent Definitions (ADVISORY)\n- Section values should match parent module/unit definitions\n- Minor deviations: provide feedback, do NOT reject\n\n### 1.5. Prohibited Content Check\n- No database schemas, ERD, indexes, or cascade rules\n- No API specifications (HTTP methods, URL paths, request/response schemas, HTTP status codes)\n- No JSON request/response examples\n- No implementation details\n- No frontend specifications\n- **REJECT if API endpoints like `POST /users` or `GET /todos/{id}` are present**\n- **REJECT if HTTP status codes like `HTTP 200`, `HTTP 404` are present**\n- No technical field names or database column names (e.g., `passwordHash`, `isDeleted`, `isCompleted`, `userId`, `createdAt`, `deletedAt`, `updatedAt`, `todoId`, `ownerId`, `editedBy`, `editedAt`)\n- No camelCase identifiers \u2014 use natural language instead (e.g., \"completion status\" not `isCompleted`, \"deletion date\" not `deletedAt`, \"owner\" not `ownerId`)\n- No data format specifications (e.g., `ISO 8601`, `UUID v4`, `Base64`, `JWT`)\n- **REJECT if prohibited content is present in any form \u2014 including technical terms embedded in prose**\n\n### 1.6. Error Condition Clarity\n- Error conditions should be described in natural language\n- **Advisory**: Flag vague error descriptions but do NOT reject\n\n### 1.7. Intra-File Content Deduplication (ADVISORY)\n- Minor overlap or paraphrased references are acceptable\n- Flag duplicates in feedback, do NOT reject\n\n### 1.8. Keyword Coverage (ADVISORY)\n- Section content should adequately address keywords from parent unit\n- Provide feedback for gaps, do NOT reject\n\n### 1.9. Advisory Checks (flag in feedback only, NEVER reject)\n- **Meta-concepts**: Flag process-describing concepts \u2014 do NOT reject\n- **Verbosity**: Flag filler sentences \u2014 do NOT reject. NOTE: Detailed error branching, boundary value specifications, and concurrent operation scenarios are NOT verbosity \u2014 they are required depth\n- **Boilerplate sections**: Flag sections existing solely for purpose/scope \u2014 do NOT reject\n- **Section count**: Sections with 5-25 requirements are expected for detailed specifications \u2014 do NOT flag as excessive\n\n### 1.10. Hallucination Detection (CRITICAL)\n- Does the section contain features, numbers, or requirements not in original user input?\n- Common hallucinations to catch:\n  - Security mechanisms user didn't mention (2FA, OAuth2, JWT, encryption)\n  - Specific performance numbers (99.9% uptime, 500ms, 10-second timeout)\n  - Infrastructure requirements (CDN, caching, load balancing, storage planning)\n  - Compliance frameworks (GDPR, SOC2, PCI-DSS)\n  - Features user never requested (notifications, webhooks, rate limiting, i18n)\n- **05-non-functional**: Highest hallucination risk. Reject if it contains specific SLO numbers, timeout thresholds, or infrastructure requirements user did not mention.\n- **REJECT if section contains requirements not traceable to user input**\n\n### 1.11. Verbosity Detection (ADVISORY)\n- 3+ subsections explaining the same idea in different words = excessive verbosity\n- 02-domain-model: 10+ subsections for one concept is verbosity \u2014 suggest merging to 1-3\n- Flag in feedback with specific merge suggestions, do NOT reject\n\n---\n\n## 2. Decision Guidelines\n\n**APPROVE** when: no non-English text, no prohibited content, no scope violations, no contradiction with scenario/parent, and no invented features.\n\n**APPROVE with feedback** when: value inconsistencies, keyword gaps, verbosity, duplication, missing YAML blocks \u2014 provide constructive feedback but APPROVE.\n\n**REJECT** when ANY of:\n- Non-English text detected\n- Prohibited content present (in any form)\n- Features not traceable to original user requirements (hallucination)\n- File scope violation (content belongs in another file)\n- Contradiction with scenario concepts/actors\n- Invented features not in keywords\n- Contradiction with parent module/unit definitions\n- Reinterpretation of user's stated system characteristics\n- Intra-file behavioral contradiction (two sections in this file state opposite behaviors for the same flow)\n\n---\n\n## 3. Output Format\n\n### 3.1. File Approved\n```typescript\nprocess({\n  thinking: \"Values consistent, no prohibited content, content within file scope.\",\n  request: {\n    type: \"complete\",\n    fileResults: [\n      { fileIndex: 0, approved: true, feedback: \"All sections pass per-file review.\", revisedSections: null }\n    ]\n  }\n});\n```\n\n### 3.2. File Rejected (with granular identification)\n\n**IMPORTANT**: When rejecting, specify `rejectedModuleUnits` to identify exactly which module/unit pairs have issues.\n\n```typescript\nprocess({\n  thinking: \"Module 2, Unit 1 contains content that belongs in 02-domain-model.\",\n  request: {\n    type: \"complete\",\n    fileResults: [\n      {\n        fileIndex: 0,\n        approved: false,\n        feedback: \"Scope violation in Module 2, Unit 1.\",\n        revisedSections: null,\n        rejectedModuleUnits: [\n          { moduleIndex: 2, unitIndices: [1], feedback: \"Contains scope violation \u2014 move to 02-domain-model.\" }\n        ]\n      }\n    ]\n  }\n});\n```\n\n### 3.3. Approved with Revisions\nSet `revisedSections` for auto-correctable minor issues while approving.\n\n---\n\n## 4. Rejection Triggers\n\n**REJECT if ANY of these are true**:\n- Non-English text detected (Chinese, Korean, Japanese, etc.)\n- Prohibited content present in any form (database schemas, API specs, implementation details, technical field names)\n- Section contains features, workflows, or constraints not traceable to the original user requirements\n- File scope violation (content that belongs in another SRS file)\n- Section directly contradicts scenario concepts or actors\n- Section invents features, concepts, or workflows not present in scenario\n- Section contains specific numbers (SLAs, timeouts, thresholds) not stated by the user\n- Section adds security mechanisms, compliance frameworks, or infrastructure requirements the user did not mention\n- Section contradicts its own parent module/unit definitions\n- Section reinterprets the user's stated system characteristics\n- Section directly contradicts another section in the SAME file on the same behavioral flow (e.g., one section says \"auto-login after registration\" while another says \"separate login required after registration\")\n\n**Do NOT reject for**: value deviations from parent, duplicate requirements, keyword gaps, writing style, verbosity, boilerplate, meta-concepts, high requirement count per section (5-25 is expected), detailed error branching, boundary value specifications\n\n---\n\n## 5. Final Checklist\n\n**Before Approving, verify:**\n- [ ] ALL text is in English only\n- [ ] Content stays within designated file scope\n- [ ] No contradiction with scenario concepts or actors\n- [ ] No invented features or concepts\n- [ ] Every requirement is traceable to the original user requirements\n\n**Prohibited Content (MUST REJECT if present):**\n- [ ] Database schemas, ERD, indexes, cascade rules\n- [ ] API endpoints (`POST /users`, `GET /todos/{id}`)\n- [ ] HTTP methods or status codes (`HTTP 200`, `HTTP 404`)\n- [ ] JSON request/response examples\n- [ ] Field types or length constraints\n- [ ] Technical error codes (`TODO_NOT_FOUND`)\n- [ ] Technical field names (`passwordHash`, `isDeleted`, `isCompleted`, `userId`, `createdAt`, `deletedAt`, `updatedAt`, `todoId`, `ownerId`, `editedBy`, `editedAt`)\n- [ ] camelCase identifiers (ANY camelCase term = prohibited)\n- [ ] Data format specifications (`ISO 8601`, `UUID`, `Base64`, `JWT`)\n- [ ] Implementation details or frontend specifications\n\n**Business Language Check:**\n- [ ] Requirements describe WHAT, not HOW\n- [ ] Natural language error conditions, not error codes\n- [ ] User-facing terminology throughout" /* AutoBeSystemPromptConstant.ANALYZE_SECTION_REVIEW */,
+                text: "<!--\nfilename: ANALYZE_SECTION_REVIEW.md\n-->\n# Per-File Section Reviewer\n\nYou are the **Per-File Section Reviewer** for hierarchical requirements documentation.\nYour role is to validate section content (###) within a SINGLE file, checking value consistency with parent definitions, prohibited content absence, file scope adherence, and basic quality.\n\nThis is the per-file review step in the 3-step hierarchical generation process:\n1. **Module (#)** \u2192 Completed\n2. **Unit (##)** \u2192 Completed\n3. **Section (###)** \u2192 PER-FILE Review: Validate this file's detailed specifications\n\n**Your decision determines whether this file's sections need regeneration.**\n- If you approve: This file proceeds to cross-file consistency review\n- If you reject: This file's section generation retries with your feedback\n\n**IMPORTANT: APPROVE well-formed content. REJECT for: non-English text, prohibited content, scenario contradictions, invented features, file scope violations, or parent definition contradictions. See Rejection Triggers section for the full list.**\n\nThis agent achieves its goal through function calling. **Function calling is MANDATORY**.\n\n---\n\n## 1. Per-File Review Focus\n\n### 1.1. Language Compliance (CRITICAL - Check First)\n- Is ALL text in English only?\n- **If any non-English text is detected, REJECT immediately**\n\n### 1.2. File Scope Adherence (CRITICAL)\n- Does this file's content stay within its designated scope?\n- 00-toc: Project summary, scope, glossary \u2014 NO detailed requirements\n- 01-actors-and-auth: Actors, permissions, auth flows \u2014 NO operations (03), NO data isolation (05), NO domain concepts (02)\n- 02-domain-model: Domain concepts, relationships, business states \u2014 NO retention/recovery policies (05), NO operations (03)\n- 03-functional-requirements: Functional requirements, use cases, business operations \u2014 NO API endpoints, NO HTTP methods, NO error catalogs\n- 04-business-rules: Rules, filtering, validation, errors \u2014 NO data isolation (05), NO lifecycle states (02), NO operation flows (03)\n- 05-non-functional: Data ownership, privacy, retention, recovery \u2014 NO operation details, NO domain concepts\n- **REJECT if file contains API specifications (HTTP methods, URL paths, request/response schemas)**\n- **REJECT if file clearly contains content belonging to another file's scope**\n\n### 1.3. Writing Style\n- Requirements should be written in clear natural language\n- Do NOT reject for stylistic preferences \u2014 focus on content accuracy\n\n### 1.4. Value Consistency with Parent Definitions (ADVISORY)\n- Section values should match parent module/unit definitions\n- Minor deviations: provide feedback, do NOT reject\n\n### 1.5. Prohibited Content Check\n- No database schemas, ERD, indexes, or cascade rules\n- No API specifications (HTTP methods, URL paths, request/response schemas, HTTP status codes)\n- No JSON request/response examples\n- No implementation details\n- No frontend specifications\n- **REJECT if API endpoints like `POST /users` or `GET /todos/{id}` are present**\n- **REJECT if HTTP status codes like `HTTP 200`, `HTTP 404` are present**\n- No technical field names or database column names (e.g., `passwordHash`, `isDeleted`, `isCompleted`, `userId`, `createdAt`, `deletedAt`, `updatedAt`, `todoId`, `ownerId`, `editedBy`, `editedAt`)\n- No camelCase identifiers \u2014 use natural language instead (e.g., \"completion status\" not `isCompleted`, \"deletion date\" not `deletedAt`, \"owner\" not `ownerId`)\n- No data format specifications (e.g., `ISO 8601`, `UUID v4`, `Base64`, `JWT`)\n- **REJECT if prohibited content is present in any form \u2014 including technical terms embedded in prose**\n\n### 1.6. Error Condition Clarity\n- Error conditions should be described in natural language\n- **Advisory**: Flag vague error descriptions but do NOT reject\n\n### 1.7. Intra-File Content Deduplication (REJECT for substantive repetition)\n- Minor overlap or brief paraphrased references are acceptable\n- **REJECT if the same concept is defined or explained in full in 2+ places within the same file** \u2014 one section should define it, others should reference it briefly\n- **REJECT if a non-canonical file repeats the canonical definition verbatim** instead of referencing it (e.g., 03-functional-requirements restating data isolation rules that belong in 05-non-functional)\n- Brief mentions like \"as defined in section X\" or one-sentence references are NOT duplication\n\n### 1.8. Keyword Coverage (ADVISORY)\n- Section content should adequately address keywords from parent unit\n- Provide feedback for gaps, do NOT reject\n\n### 1.9. Advisory and Reject Checks\n- **Meta-concepts**: Flag process-describing concepts \u2014 do NOT reject\n- **Verbosity**: Flag filler sentences \u2014 do NOT reject. NOTE: Detailed error branching, boundary value specifications, and concurrent operation scenarios are NOT verbosity \u2014 they are required depth\n- **Boilerplate sections**: **REJECT sections that exist solely to describe purpose/scope without any substantive requirements** \u2014 every section must contain concrete, actionable requirements\n- **Section count**: Sections with 5-25 requirements are expected for detailed specifications \u2014 do NOT flag as excessive\n\n### 1.10. Hallucination Detection (CRITICAL)\n- Does the section contain features, numbers, or requirements not in original user input?\n- Common hallucinations to catch:\n  - Security mechanisms user didn't mention (2FA, OAuth2, JWT, encryption)\n  - Specific performance numbers (99.9% uptime, 500ms, 10-second timeout)\n  - Infrastructure requirements (CDN, caching, load balancing, storage planning)\n  - Compliance frameworks (GDPR, SOC2, PCI-DSS)\n  - Features user never requested (notifications, webhooks, rate limiting, i18n)\n- **05-non-functional**: Highest hallucination risk. Reject if it contains specific SLO numbers, timeout thresholds, or infrastructure requirements user did not mention.\n- **REJECT if section contains requirements not traceable to user input**\n\n### 1.11. Verbosity Detection (REJECT for excessive repetition)\n- **REJECT if 3+ subsections explain the same idea in different words** \u2014 this is excessive verbosity that inflates the document without adding information\n- **REJECT if 02-domain-model has 4+ subsections for a single concept** \u2014 merge to 1-3 subsections that each add distinct information\n- When rejecting, provide specific merge suggestions identifying which subsections should be consolidated\n- NOTE: Detailed error branching, boundary value specifications, and concurrent operation scenarios are NOT verbosity \u2014 they are required depth. Each subsection must add NEW information not covered by siblings\n\n---\n\n## 2. Decision Guidelines\n\n**APPROVE** when: no non-English text, no prohibited content, no scope violations, no contradiction with scenario/parent, and no invented features.\n\n**APPROVE with feedback** when: value inconsistencies, keyword gaps, minor stylistic issues \u2014 provide constructive feedback but APPROVE.\n\n**REJECT** when ANY of:\n- Non-English text detected\n- Prohibited content present (in any form)\n- Features not traceable to original user requirements (hallucination)\n- File scope violation (content belongs in another file)\n- Contradiction with scenario concepts/actors\n- Invented features not in keywords\n- Contradiction with parent module/unit definitions\n- Reinterpretation of user's stated system characteristics\n- Intra-file behavioral contradiction (two sections in this file state opposite behaviors for the same flow)\n\n---\n\n## 3. Output Format\n\n### 3.1. File Approved\n```typescript\nprocess({\n  thinking: \"Values consistent, no prohibited content, content within file scope.\",\n  request: {\n    type: \"complete\",\n    fileResults: [\n      { fileIndex: 0, approved: true, feedback: \"All sections pass per-file review.\", revisedSections: null }\n    ]\n  }\n});\n```\n\n### 3.2. File Rejected (with granular identification)\n\n**IMPORTANT**: When rejecting, specify `rejectedModuleUnits` to identify exactly which module/unit pairs have issues.\n\n```typescript\nprocess({\n  thinking: \"Module 2, Unit 1 contains content that belongs in 02-domain-model.\",\n  request: {\n    type: \"complete\",\n    fileResults: [\n      {\n        fileIndex: 0,\n        approved: false,\n        feedback: \"Scope violation in Module 2, Unit 1.\",\n        revisedSections: null,\n        rejectedModuleUnits: [\n          { moduleIndex: 2, unitIndices: [1], feedback: \"Contains scope violation \u2014 move to 02-domain-model.\" }\n        ]\n      }\n    ]\n  }\n});\n```\n\n### 3.3. Approved with Revisions\nSet `revisedSections` for auto-correctable minor issues while approving.\n\n---\n\n## 4. Rejection Triggers\n\n**REJECT if ANY of these are true**:\n- Non-English text detected (Chinese, Korean, Japanese, etc.)\n- Prohibited content present in any form (database schemas, API specs, implementation details, technical field names)\n- Section contains features, workflows, or constraints not traceable to the original user requirements\n- File scope violation (content that belongs in another SRS file)\n- Section directly contradicts scenario concepts or actors\n- Section invents features, concepts, or workflows not present in scenario\n- Section contains specific numbers (SLAs, timeouts, thresholds) not stated by the user\n- Section adds security mechanisms, compliance frameworks, or infrastructure requirements the user did not mention\n- Section contradicts its own parent module/unit definitions\n- Section reinterprets the user's stated system characteristics\n- Section directly contradicts another section in the SAME file on the same behavioral flow (e.g., one section says \"auto-login after registration\" while another says \"separate login required after registration\")\n- Excessive verbosity: 3+ subsections restating the same idea in different words (each subsection must add NEW information)\n- Substantive intra-file duplication: same concept fully defined/explained in 2+ places within the file\n- Boilerplate sections with no actionable requirements (pure purpose/scope descriptions)\n\n**Do NOT reject for**: value deviations from parent, keyword gaps, writing style, meta-concepts, high requirement count per section (5-25 is expected), detailed error branching, boundary value specifications\n\n---\n\n## 5. Final Checklist\n\n**Before Approving, verify:**\n- [ ] ALL text is in English only\n- [ ] Content stays within designated file scope\n- [ ] No contradiction with scenario concepts or actors\n- [ ] No invented features or concepts\n- [ ] Every requirement is traceable to the original user requirements\n\n**Prohibited Content (MUST REJECT if present):**\n- [ ] Database schemas, ERD, indexes, cascade rules\n- [ ] API endpoints (`POST /users`, `GET /todos/{id}`)\n- [ ] HTTP methods or status codes (`HTTP 200`, `HTTP 404`)\n- [ ] JSON request/response examples\n- [ ] Field types or length constraints\n- [ ] Technical error codes (`TODO_NOT_FOUND`)\n- [ ] Technical field names (`passwordHash`, `isDeleted`, `isCompleted`, `userId`, `createdAt`, `deletedAt`, `updatedAt`, `todoId`, `ownerId`, `editedBy`, `editedAt`)\n- [ ] camelCase identifiers (ANY camelCase term = prohibited)\n- [ ] Data format specifications (`ISO 8601`, `UUID`, `Base64`, `JWT`)\n- [ ] Implementation details or frontend specifications\n\n**Business Language Check:**\n- [ ] Requirements describe WHAT, not HOW\n- [ ] Natural language error conditions, not error codes\n- [ ] User-facing terminology throughout" /* AutoBeSystemPromptConstant.ANALYZE_SECTION_REVIEW */,
             },
             ...((_b = (_a = props.preliminary) === null || _a === void 0 ? void 0 : _a.getHistories()) !== null && _b !== void 0 ? _b : []),
             {

package/lib/orchestrate/analyze/histories/transformAnalyzeSectionReviewHistory.js.map

@@ -1 +1 @@
-{"version":3,"file":"transformAnalyzeSectionReviewHistory.js","sourceRoot":"","sources":["../../../../src/orchestrate/analyze/histories/transformAnalyzeSectionReviewHistory.ts"],"names":[],"mappings":";;;AAQA,yCAA2C;AAC3C,+BAA0B;AAM1B,6EAG4C;AAE5C;;;;;;;GAOG;AACI,MAAM,oCAAoC,GAAG,CAClD,GAAkB,EAClB,KAcC,EAC0B,EAAE;;IAC7B,OAAO;QACL,SAAS,EAAE;YACT;gBACE,EAAE,EAAE,IAAA,SAAE,GAAE;gBACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;gBACpC,IAAI,EAAE,eAAe;gBACrB,IAAI,0zUAAmD;aACxD;YACD,GAAG,CAAC,MAAA,MAAA,KAAK,CAAC,WAAW,0CAAE,YAAY,EAAE,mCAAI,EAAE,CAAC;YAC5C;gBACE,EAAE,EAAE,IAAA,SAAE,GAAE;gBACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;gBACpC,IAAI,EAAE,kBAAkB;gBACxB,IAAI,EAAE,kBAAU,CAAC,IAAI,CAAA;;;0CAGa,IAAI,CAAC,SAAS,CAAC,MAAA,KAAK,CAAC,QAAQ,CAAC,QAAQ,mCAAI,OAAO,CAAC;;mBAEzE,KAAK,CAAC,IAAI,CAAC,QAAQ;;qBAEjB,KAAK,CAAC,WAAW,CAAC,KAAK;uBACrB,KAAK,CAAC,WAAW,CAAC,OAAO;;;;UAKtC,KAAK,CAAC,sBAAsB,CAAC,MAAM,GAAG,CAAC;oBACrC,CAAC,CAAC,KAAK,CAAC,sBAAsB;yBACzB,GAAG,CACF,CAAC,CAAC,EAAE,EAAE,CACJ,YAAY,CAAC,CAAC,WAAW,GAAG,CAAC,KAAK,CAAC,CAAC,KAAK,gBAAgB,CAAC,CAAC,aAAa,CAAC,IAAI,CAAC,IAAI,CAAC,EAAE,CACxF;yBACA,IAAI,CAAC,IAAI,CAAC;oBACf,CAAC,CAAC,wCACN;;+CAEuC,KAAK,CAAC,WAAW,GAAG,CAAC;;qBAE/C,KAAK,CAAC,WAAW,GAAG,CAAC,KAAK,MAAA,MAAA,KAAK,CAAC,WAAW,CAAC,cAAc,CAAC,KAAK,CAAC,WAAW,CAAC,0CAAE,KAAK,mCAAI,SAAS;;UAE5G,KAAK,CAAC,mBAAmB;qBACxB,GAAG,CAAC,CAAC,YAAY,EAAE,SAAS,EAAE,EAAE;;oBAC/B,MAAM,WAAW,GACf,MAAA,KAAK,CAAC,SAAS,0CAAE,YAAY,CAAC,SAAS,CAAC,CAAC;oBAC3C,OAAO;oBACC,KAAK,CAAC,WAAW,GAAG,CAAC,IAAI,SAAS,GAAG,CAAC,KAAK,MAAA,WAAW,aAAX,WAAW,uBAAX,WAAW,CAAE,KAAK,mCAAI,SAAS;;UAEpF,YAAY,CAAC,eAAe;yBAC3B,GAAG,CACF,CAAC,OAAO,EAAE,EAAE,CAAC;gBACT,OAAO,CAAC,KAAK;UACnB,OAAO,CAAC,OAAO;SAChB,CACE;yBACA,IAAI,CAAC,IAAI,CAAC;SACZ,CAAC;gBACA,CAAC,CAAC;qBACD,IAAI,CAAC,IAAI,CAAC;;;;oBAID,KAAK,CAAC,IAAI,CAAC,QAAQ;qBAClB,MAAA,MAAA,IAAA,wDAAiC,EAAC,CAAC,MAAA,KAAK,CAAC,QAAQ,CAAC,QAAQ,mCAAI,EAAE,CAAkC,CAAC,CAAC,IAAI,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,QAAQ,KAAK,KAAK,CAAC,IAAI,CAAC,QAAQ,CAAC,0CAAE,WAAW,mCAAI,SAAS;;;;wBAI1K,KAAK,CAAC,QAAQ,CAAC,QAAQ,CAAC,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,IAAI,CAAC,CAAC,IAAI,CAAC,IAAI,CAAC;sBACvD,KAAK,CAAC,QAAQ,CAAC,MAAM,CAAC,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,GAAG,CAAC,CAAC,IAAI,IAAI,CAAC,CAAC,IAAI,GAAG,CAAC,CAAC,IAAI,CAAC,IAAI,CAAC;wBACjE,CAAC,MAAA,KAAK,CAAC,QAAQ,CAAC,QAAQ,mCAAI,EAAE,CAAC,CAAC,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,EAAE,CAAC,CAAC,IAAI,CAAC,IAAI,CAAC,IAAI,MAAM;;;;;;;;;UASnF,GAAG;qBACF,SAAS,EAAE;qBACX,MAAM,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,IAAI,KAAK,aAAa,CAAC;qBACvC,OAAO,CAAC,CAAC,CAAC,EAAE,EAAE,CACb,CAAC,CAAC,IAAI,KAAK,aAAa;oBACtB,CAAC,CAAC,CAAC,CAAC,QAAQ,CAAC,MAAM,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,IAAI,KAAK,MAAM,CAAC,CAAC,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,IAAI,CAAC;oBAChE,CAAC,CAAC,EAAE,CACP;qBACA,IAAI,CAAC,aAAa,CAAC;;;;;;;;;;;;;;UAepB,KAAK,CAAC,QAAQ;oBACZ,CAAC,CAAC;;;;;UAKJ,KAAK,CAAC,QAAQ;SACf;oBACG,CAAC,CAAC,EACN;OACD;aACA;SACF;QACD,WAAW,EACT,4FAA4F;KAC/F,CAAC;AACJ,CAAC,CAAC;AAtIW,QAAA,oCAAoC,wCAsI/C"}
+{"version":3,"file":"transformAnalyzeSectionReviewHistory.js","sourceRoot":"","sources":["../../../../src/orchestrate/analyze/histories/transformAnalyzeSectionReviewHistory.ts"],"names":[],"mappings":";;;AAQA,yCAA2C;AAC3C,+BAA0B;AAM1B,6EAG4C;AAE5C;;;;;;;GAOG;AACI,MAAM,oCAAoC,GAAG,CAClD,GAAkB,EAClB,KAcC,EAC0B,EAAE;;IAC7B,OAAO;QACL,SAAS,EAAE;YACT;gBACE,EAAE,EAAE,IAAA,SAAE,GAAE;gBACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;gBACpC,IAAI,EAAE,eAAe;gBACrB,IAAI,49WAAmD;aACxD;YACD,GAAG,CAAC,MAAA,MAAA,KAAK,CAAC,WAAW,0CAAE,YAAY,EAAE,mCAAI,EAAE,CAAC;YAC5C;gBACE,EAAE,EAAE,IAAA,SAAE,GAAE;gBACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;gBACpC,IAAI,EAAE,kBAAkB;gBACxB,IAAI,EAAE,kBAAU,CAAC,IAAI,CAAA;;;0CAGa,IAAI,CAAC,SAAS,CAAC,MAAA,KAAK,CAAC,QAAQ,CAAC,QAAQ,mCAAI,OAAO,CAAC;;mBAEzE,KAAK,CAAC,IAAI,CAAC,QAAQ;;qBAEjB,KAAK,CAAC,WAAW,CAAC,KAAK;uBACrB,KAAK,CAAC,WAAW,CAAC,OAAO;;;;UAKtC,KAAK,CAAC,sBAAsB,CAAC,MAAM,GAAG,CAAC;oBACrC,CAAC,CAAC,KAAK,CAAC,sBAAsB;yBACzB,GAAG,CACF,CAAC,CAAC,EAAE,EAAE,CACJ,YAAY,CAAC,CAAC,WAAW,GAAG,CAAC,KAAK,CAAC,CAAC,KAAK,gBAAgB,CAAC,CAAC,aAAa,CAAC,IAAI,CAAC,IAAI,CAAC,EAAE,CACxF;yBACA,IAAI,CAAC,IAAI,CAAC;oBACf,CAAC,CAAC,wCACN;;+CAEuC,KAAK,CAAC,WAAW,GAAG,CAAC;;qBAE/C,KAAK,CAAC,WAAW,GAAG,CAAC,KAAK,MAAA,MAAA,KAAK,CAAC,WAAW,CAAC,cAAc,CAAC,KAAK,CAAC,WAAW,CAAC,0CAAE,KAAK,mCAAI,SAAS;;UAE5G,KAAK,CAAC,mBAAmB;qBACxB,GAAG,CAAC,CAAC,YAAY,EAAE,SAAS,EAAE,EAAE;;oBAC/B,MAAM,WAAW,GACf,MAAA,KAAK,CAAC,SAAS,0CAAE,YAAY,CAAC,SAAS,CAAC,CAAC;oBAC3C,OAAO;oBACC,KAAK,CAAC,WAAW,GAAG,CAAC,IAAI,SAAS,GAAG,CAAC,KAAK,MAAA,WAAW,aAAX,WAAW,uBAAX,WAAW,CAAE,KAAK,mCAAI,SAAS;;UAEpF,YAAY,CAAC,eAAe;yBAC3B,GAAG,CACF,CAAC,OAAO,EAAE,EAAE,CAAC;gBACT,OAAO,CAAC,KAAK;UACnB,OAAO,CAAC,OAAO;SAChB,CACE;yBACA,IAAI,CAAC,IAAI,CAAC;SACZ,CAAC;gBACA,CAAC,CAAC;qBACD,IAAI,CAAC,IAAI,CAAC;;;;oBAID,KAAK,CAAC,IAAI,CAAC,QAAQ;qBAClB,MAAA,MAAA,IAAA,wDAAiC,EAAC,CAAC,MAAA,KAAK,CAAC,QAAQ,CAAC,QAAQ,mCAAI,EAAE,CAAkC,CAAC,CAAC,IAAI,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,QAAQ,KAAK,KAAK,CAAC,IAAI,CAAC,QAAQ,CAAC,0CAAE,WAAW,mCAAI,SAAS;;;;wBAI1K,KAAK,CAAC,QAAQ,CAAC,QAAQ,CAAC,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,IAAI,CAAC,CAAC,IAAI,CAAC,IAAI,CAAC;sBACvD,KAAK,CAAC,QAAQ,CAAC,MAAM,CAAC,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,GAAG,CAAC,CAAC,IAAI,IAAI,CAAC,CAAC,IAAI,GAAG,CAAC,CAAC,IAAI,CAAC,IAAI,CAAC;wBACjE,CAAC,MAAA,KAAK,CAAC,QAAQ,CAAC,QAAQ,mCAAI,EAAE,CAAC,CAAC,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,EAAE,CAAC,CAAC,IAAI,CAAC,IAAI,CAAC,IAAI,MAAM;;;;;;;;;UASnF,GAAG;qBACF,SAAS,EAAE;qBACX,MAAM,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,IAAI,KAAK,aAAa,CAAC;qBACvC,OAAO,CAAC,CAAC,CAAC,EAAE,EAAE,CACb,CAAC,CAAC,IAAI,KAAK,aAAa;oBACtB,CAAC,CAAC,CAAC,CAAC,QAAQ,CAAC,MAAM,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,IAAI,KAAK,MAAM,CAAC,CAAC,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,IAAI,CAAC;oBAChE,CAAC,CAAC,EAAE,CACP;qBACA,IAAI,CAAC,aAAa,CAAC;;;;;;;;;;;;;;UAepB,KAAK,CAAC,QAAQ;oBACZ,CAAC,CAAC;;;;;UAKJ,KAAK,CAAC,QAAQ;SACf;oBACG,CAAC,CAAC,EACN;OACD;aACA;SACF;QACD,WAAW,EACT,4FAA4F;KAC/F,CAAC;AACJ,CAAC,CAAC;AAtIW,QAAA,oCAAoC,wCAsI/C"}

package/lib/orchestrate/analyze/orchestrateAnalyze.js

@@ -16,6 +16,7 @@ const AutoBePreliminaryExhaustedError_1 = require("../../utils/AutoBePreliminary
 const AutoBeTimeoutError_1 = require("../../utils/AutoBeTimeoutError");
 const executeCachedBatch_1 = require("../../utils/executeCachedBatch");
 const fillTocDeterministic_1 = require("./fillTocDeterministic");
+const orchestrateAnalyzeExtractDecisions_1 = require("./orchestrateAnalyzeExtractDecisions");
 const orchestrateAnalyzeScenario_1 = require("./orchestrateAnalyzeScenario");
 const orchestrateAnalyzeScenarioReview_1 = require("./orchestrateAnalyzeScenarioReview");
 const orchestrateAnalyzeSectionCrossFileReview_1 = require("./orchestrateAnalyzeSectionCrossFileReview");
@@ -28,6 +29,7 @@ const FixedAnalyzeTemplate_1 = require("./structures/FixedAnalyzeTemplate");
 const buildConstraintConsistencyReport_1 = require("./utils/buildConstraintConsistencyReport");
 const buildErrorCodeRegistry_1 = require("./utils/buildErrorCodeRegistry");
 const buildHardValidators_1 = require("./utils/buildHardValidators");
+const detectDecisionConflicts_1 = require("./utils/detectDecisionConflicts");
 const detectProseConstraintConflicts_1 = require("./utils/detectProseConstraintConflicts");
 const validateScenarioBasics_1 = require("./utils/validateScenarioBasics");
 const ANALYZE_SCENARIO_MAX_RETRY = 2;
@@ -403,7 +405,7 @@ function buildDeterministicUnitEvent(ctx, props) {
  */
 function processStageSection(ctx, props) {
     return __awaiter(this, void 0, void 0, function* () {
-        var _a, _b, _c, _d, _e, _f, _g, _h, _j, _k, _l, _m, _o, _p, _q, _r, _s, _t, _u, _v, _w, _x;
+        var _a, _b, _c, _d, _e, _f, _g, _h, _j, _k, _l, _m, _o, _p, _q, _r, _s, _t, _u, _v, _w, _x, _y;
         // Exclude TOC (00-toc.md) — it is filled deterministically after all files
         const pendingIndices = new Set(props.fileStates
             .map((s, i) => (s.file.filename === "00-toc.md" ? -1 : i))
@@ -606,6 +608,26 @@ function processStageSection(ctx, props) {
                 file: state.file,
                 sectionEvents: state.sectionResults,
             }));
+            // Pass 2a-pre: LLM-based key decision extraction (parallel per file)
+            analyzeDebug(`section decision-extraction-start attempt=${attempt}`);
+            const fileDecisions = yield Promise.all(filesWithSections
+                .filter(({ file }) => file.filename !== "00-toc.md")
+                .map(({ file, sectionEvents }) => (0, orchestrateAnalyzeExtractDecisions_1.orchestrateAnalyzeExtractDecisions)(ctx, {
+                file,
+                sectionEvents,
+            }).catch((e) => {
+                analyzeDebug(`section decision-extraction-error file="${file.filename}" error=${e.message}`);
+                return { filename: file.filename, decisions: [] };
+            })));
+            analyzeDebug(`section decision-extraction-done attempt=${attempt} files=${fileDecisions.length} totalDecisions=${fileDecisions.reduce((sum, fd) => sum + fd.decisions.length, 0)}`);
+            // Pass 2a-pre2: Programmatic decision conflict detection
+            const decisionConflicts = (0, detectDecisionConflicts_1.detectDecisionConflicts)({
+                fileDecisions,
+            });
+            const fileDecisionConflictMap = (0, detectDecisionConflicts_1.buildFileDecisionConflictMap)(decisionConflicts);
+            if (decisionConflicts.length > 0) {
+                analyzeDebug(`section decision-conflicts-found count=${decisionConflicts.length}: ${decisionConflicts.map((c) => `${c.topic}.${c.decision}`).join(", ")}`);
+            }
             // Pass 2a: Programmatic cross-file validation (BEFORE LLM review)
             const criticalConflicts = (0, buildConstraintConsistencyReport_1.detectConstraintConflicts)({
                 files: filesWithSections,
@@ -652,6 +674,7 @@ function processStageSection(ctx, props) {
                 ...enumConflicts.map((c) => `Enum conflict: ${c.key} — ${c.values.map((v) => `enum(${v.enumSet}) in [${v.files.join(", ")}]`).join(" vs ")}`),
                 ...errorCodeConflicts.map((c) => `Error code conflict: ${c.conditionKey} — ${c.codes.map((cd) => `HTTP ${cd.httpStatus} in [${cd.files.join(", ")}]`).join(" vs ")}`),
                 ...proseConflicts.map((c) => `Prose constraint conflict: ${c.entityAttr} — canonical [${c.canonicalValues.join(", ")}] vs prose [${c.proseValues.join(", ")}] in ${c.file}`),
+                ...decisionConflicts.map((c) => `Decision conflict: ${c.topic}.${c.decision} — ${c.values.map((v) => `"${v.value}" in [${v.files.join(", ")}]`).join(" vs ")}`),
             ];
             const mechanicalViolationSummary = allMechanicalViolations.length > 0
                 ? allMechanicalViolations.join("\n")
@@ -679,6 +702,7 @@ function processStageSection(ctx, props) {
                         };
                     }),
                     mechanicalViolationSummary,
+                    fileDecisions,
                     progress: props.crossFileSectionReviewProgress,
                     promptCacheKey,
                     retry: attempt,
@@ -725,6 +749,7 @@ function processStageSection(ctx, props) {
                 const fileErrorCodeConflicts = (_j = fileErrorCodeConflictMap.get(filename)) !== null && _j !== void 0 ? _j : [];
                 const fileOversizedToc = (_k = oversizedTocMap.get(fileIndex)) !== null && _k !== void 0 ? _k : [];
                 const fileProseConflicts = (_l = fileProseConflictMap.get(filename)) !== null && _l !== void 0 ? _l : [];
+                const fileDecisionConflicts = (_m = fileDecisionConflictMap.get(filename)) !== null && _m !== void 0 ? _m : [];
                 const hasCriticalConflict = fileCriticalConflicts.length > 0 ||
                     fileAttrDuplicates.length > 0 ||
                     fileEnumConflicts.length > 0 ||
@@ -732,7 +757,8 @@ function processStageSection(ctx, props) {
                     fileStateFieldConflicts.length > 0 ||
                     fileErrorCodeConflicts.length > 0 ||
                     fileOversizedToc.length > 0 ||
-                    fileProseConflicts.length > 0;
+                    fileProseConflicts.length > 0 ||
+                    fileDecisionConflicts.length > 0;
                 // Decision logic:
                 // 1. per-file reject → reject (unchanged)
                 // 2. per-file approve + critical conflict detected → reject (NEW: patch-first)
@@ -749,6 +775,7 @@ function processStageSection(ctx, props) {
                     fileErrorCodeConflicts,
                     fileOversizedToc,
                     fileProseConflicts,
+                    fileDecisionConflicts,
                 });
                 if (approved) {
                     // NOTE: revisedSections intentionally ignored — approved means pass as-is.
@@ -766,16 +793,16 @@ function processStageSection(ctx, props) {
                 else if (!perFileApproved) {
                     // Per-file rejected: store only the latest per-file feedback (no accumulation)
                     state.sectionFeedback = formatStructuredIssuesForRetry({
-                        fallbackFeedback: (_m = perFileResult === null || perFileResult === void 0 ? void 0 : perFileResult.feedback) !== null && _m !== void 0 ? _m : "",
+                        fallbackFeedback: (_o = perFileResult === null || perFileResult === void 0 ? void 0 : perFileResult.feedback) !== null && _o !== void 0 ? _o : "",
                         issues: structuredPerFileIssues,
                     });
                     // Use only per-file rejectedModuleUnits (no cross-file merge)
-                    state.rejectedModuleUnits = normalizeRejectedModuleUnits((_o = perFileResult === null || perFileResult === void 0 ? void 0 : perFileResult.rejectedModuleUnits) !== null && _o !== void 0 ? _o : null, structuredPerFileIssues);
+                    state.rejectedModuleUnits = normalizeRejectedModuleUnits((_p = perFileResult === null || perFileResult === void 0 ? void 0 : perFileResult.rejectedModuleUnits) !== null && _p !== void 0 ? _p : null, structuredPerFileIssues);
                     // Fallback: infer targets from issues to avoid full-file rewrite
                     if (state.rejectedModuleUnits === null) {
                         state.rejectedModuleUnits = inferRejectedModuleUnitsFromIssues(structuredPerFileIssues, state.unitResults);
                     }
-                    analyzeDebug(`section reject file="${state.file.filename}" attempt=${attempt} perFileApproved=${perFileApproved} crossFileApproved=${crossFileApproved} critical=${hasCriticalConflict} targets=${formatRejectedModuleUnitsSummary(state.rejectedModuleUnits)} issues=${formatReviewIssuesSummary(structuredPerFileIssues)} feedback=${truncateForDebug((_p = state.sectionFeedback) !== null && _p !== void 0 ? _p : "", 500)}`);
+                    analyzeDebug(`section reject file="${state.file.filename}" attempt=${attempt} perFileApproved=${perFileApproved} crossFileApproved=${crossFileApproved} critical=${hasCriticalConflict} targets=${formatRejectedModuleUnitsSummary(state.rejectedModuleUnits)} issues=${formatReviewIssuesSummary(structuredPerFileIssues)} feedback=${truncateForDebug((_q = state.sectionFeedback) !== null && _q !== void 0 ? _q : "", 500)}`);
                 }
                 else {
                     // Critical conflict rejected (per-file approved but programmatic violations exist)
@@ -786,11 +813,12 @@ function processStageSection(ctx, props) {
                             ...fileAttrDuplicates,
                             ...fileEnumConflicts,
                             ...fileProseConflicts,
+                            ...fileDecisionConflicts,
                         ].join("; ")}` +
                             ((crossFileResult === null || crossFileResult === void 0 ? void 0 : crossFileResult.feedback) ? `\n${crossFileResult.feedback}` : ""),
                         issues: [...programmaticIssues, ...structuredCrossFileIssues],
                     });
-                    state.rejectedModuleUnits = normalizeRejectedModuleUnits((_q = crossFileResult === null || crossFileResult === void 0 ? void 0 : crossFileResult.rejectedModuleUnits) !== null && _q !== void 0 ? _q : null, [...programmaticIssues, ...structuredCrossFileIssues]);
+                    state.rejectedModuleUnits = normalizeRejectedModuleUnits((_r = crossFileResult === null || crossFileResult === void 0 ? void 0 : crossFileResult.rejectedModuleUnits) !== null && _r !== void 0 ? _r : null, [...programmaticIssues, ...structuredCrossFileIssues]);
                     // Fallback: infer targets from issues to avoid full-file rewrite
                     if (state.rejectedModuleUnits === null) {
                         state.rejectedModuleUnits = inferRejectedModuleUnitsFromIssues([...programmaticIssues, ...structuredCrossFileIssues], state.unitResults);
@@ -798,28 +826,28 @@ function processStageSection(ctx, props) {
                     analyzeDebug(`section reject file="${state.file.filename}" attempt=${attempt} perFileApproved=${perFileApproved} crossFileApproved=${crossFileApproved} critical=${hasCriticalConflict} targets=${formatRejectedModuleUnitsSummary(state.rejectedModuleUnits)} issues=${formatReviewIssuesSummary([
                         ...programmaticIssues,
                         ...structuredCrossFileIssues,
-                    ])} feedback=${truncateForDebug((_r = state.sectionFeedback) !== null && _r !== void 0 ? _r : "", 500)}`);
+                    ])} feedback=${truncateForDebug((_s = state.sectionFeedback) !== null && _s !== void 0 ? _s : "", 500)}`);
                 }
                 if (!approved) {
                     const contentSignature = buildSectionContentSignature(state);
                     const rejectionSignature = buildSectionRejectionSignature({
-                        rejectedModuleUnits: (_s = state.rejectedModuleUnits) !== null && _s !== void 0 ? _s : null,
-                        feedback: (_t = state.sectionFeedback) !== null && _t !== void 0 ? _t : "",
+                        rejectedModuleUnits: (_t = state.rejectedModuleUnits) !== null && _t !== void 0 ? _t : null,
+                        feedback: (_u = state.sectionFeedback) !== null && _u !== void 0 ? _u : "",
                     });
                     const isStagnant = state.lastSectionContentSignature === contentSignature &&
                         state.lastSectionRejectionSignature === rejectionSignature;
                     state.sectionStagnationCount = isStagnant
-                        ? ((_u = state.sectionStagnationCount) !== null && _u !== void 0 ? _u : 0) + 1
+                        ? ((_v = state.sectionStagnationCount) !== null && _v !== void 0 ? _v : 0) + 1
                         : 0;
-                    state.sectionRetryCount = ((_v = state.sectionRetryCount) !== null && _v !== void 0 ? _v : 0) + 1;
+                    state.sectionRetryCount = ((_w = state.sectionRetryCount) !== null && _w !== void 0 ? _w : 0) + 1;
                     state.lastSectionContentSignature = contentSignature;
                     state.lastSectionRejectionSignature = rejectionSignature;
-                    if (((_w = state.sectionRetryCount) !== null && _w !== void 0 ? _w : 0) > ANALYZE_SECTION_FILE_MAX_RETRY) {
+                    if (((_x = state.sectionRetryCount) !== null && _x !== void 0 ? _x : 0) > ANALYZE_SECTION_FILE_MAX_RETRY) {
                         analyzeDebug(`[orchestrateAnalyze] Section stage: force-passing (max retry exceeded: ${ANALYZE_SECTION_FILE_MAX_RETRY}) for file "${state.file.filename}"`);
                         pendingIndices.delete(fileIndex);
                         continue;
                     }
-                    if (((_x = state.sectionStagnationCount) !== null && _x !== void 0 ? _x : 0) >= ANALYZE_SECTION_STAGNATION_MAX) {
+                    if (((_y = state.sectionStagnationCount) !== null && _y !== void 0 ? _y : 0) >= ANALYZE_SECTION_STAGNATION_MAX) {
                         analyzeDebug(`[orchestrateAnalyze] Section stage: force-passing (stagnation detected ${state.sectionStagnationCount}x) for file "${state.file.filename}"`);
                         pendingIndices.delete(fileIndex);
                         continue;
@@ -996,6 +1024,13 @@ function buildProgrammaticSectionIssues(props) {
             fixInstruction: "Remove the restated constraint value and use a backtick reference to the canonical definition in 02-domain-model instead. Example: 'THE system SHALL validate `User.bio` per entity constraints (see 02-domain-model)'",
             evidence: detail,
         })),
+        ...props.fileDecisionConflicts.map((detail) => ({
+            ruleCode: "cross_file_decision_conflict",
+            moduleIndex: null,
+            unitIndex: null,
+            fixInstruction: "This file contradicts another file on a key behavioral decision. Align with the canonical source file for this topic.",
+            evidence: detail,
+        })),
     ];
 }
 function buildSectionIndicesPerUnit(issues, moduleIndex, unitIndices) {