Create Link Uniformity Diagnostic v1 (2026-07-07)

This document corrects the erroneous conclusion from the 2026-07-06 'P0-3 Create Bypasses Rule Engine'.

The conclusion is based on actual code testing (rule-engine.js / capability-runtime.js / AmlBuilder.js / useCapabilityCreate.js),

not grep snippet inference.

0. First, an apology

Yesterday's statement, 'Frontend buildAML() directly connects to SCSAI + backend unified-create.js directly connects to SCSAI, double bypass of the rule engine',

was wrong on both counts:

1. The phrase 'directly connects to SCSAI' was incorrect—the frontend goes through bomService._SCSAIApiRequest → fetch('/SCSAI-api/ApplyItem') → Vite proxy → backend → SCSAI; the browser does not directly contact SCSAI.
2. The characterization 'bypasses the rule engine' was incorrect—the system already has a unified creation entry point (/api/rule-engine/create-item and CapabilityRuntime.create) that goes through the rule engine's complete lifecycle. I declared 'bypass' after grepping unified-create/buildAML without reading the create-item implementation or the rule engine itself.

1. What exactly is the rule engine, where is it stored, and how is it used

1.1 What it is

• Core Implementation: The UnifiedRuleEngine class in server/routes/rule-engine.js (formerly named RuleEngine, now unified).
• Unified Six-Capability API (handled by handleRuleEngine dispatch):
• /api/rule-engine/identify Identify object
• /api/rule-engine/repair Repair object
• /api/rule-engine/optimize Optimize object
• /api/rule-engine/compare Compare object
• /api/rule-engine/create-item Unified object creation (integrates the full lifecycle of the rule engine)
• /api/rule-engine/validate Validate
• /api/rule-engine/create_post/execute-create-post Post-creation rules
• Unified Layer: CapabilityRuntime in server/core/capability-runtime.js. All six capabilities (create/identify/repair/optimize/compare/generate/update/delete) first call _initRuleEngine() → engine.execute(scope,...). If a rule is triggered, it follows the rule; otherwise, it falls back to AML/LLM.

1.2 Where to Store Rule Templates / Prompts

• Primary Configuration Repository: sciot_import.db (Single Source of Truth)
• sciot_rules_v2 — ★ Unified Rules Table (Core, includes scope/action_script/severity)
• sciot_prompts — Object-level Prompts (Backward compatible)
• sciot_templates — Templates (Includes llm_fields / auto_fields field classification)
• sciot_rules — Legacy Rules Table (Known technical debt, not fully migrated)
• Authoritative Design Document: docs/rules-templates-prompts-system.md (v3.5, 58k words)

1.3 Creating Lifecycle (Ideal State, create-item Implementation)

validate → create_pre → Assemble AML → (Frontend/Backend Submission applyAML) → create_post

• validate: Data Validation Rules
• create_pre: Default Value Population, Auto-numbering, Data Preprocessing (Corresponds to SCSAI onBeforeAdd)
• create_post: Post-creation side effects (action_script with scope='create_post')

II. Are the Four Entry Points Truly Unified? (Core Question)

| Entry Point | Creation Path | Frontend Rules (validate/create_pre) | Backend (create_post) | Unified Layer |

|---|---|---|---|---|

| Business Page useCapabilityCreate.js | buildAML() + /SCSAI-api/ApplyItem | ❌ Skipped | ✅ execute-create-post | ❌ Bypasses CapabilityRuntime |

| Dialog/AI | Via ai-agent.js → CapabilityRuntime | ✅ | ✅ | ✅ |

| Feishu | Via staff-router/feishu-router → (Indirectly CapabilityRuntime or smartCreate) | To be confirmed | To be confirmed | Partial |

| Mini Program | Backend miniapp-routes → (To be confirmed if CapabilityRuntime) | To be confirmed | To be confirmed | Partial |

| Import/worker object-importer / lite-scheduler | capabilityRuntime.create() | ✅ | ✅ | ✅ |

| create-item API | engine.createItem full lifecycle | ✅ | Frontend needs to supplement execute-create-post | ✅ |

Empirical evidence:

• useCapabilityCreate.js L1671 buildAML(mainAmlData,...) → L1681 bomService._SCSAIApiRequest('ApplyItem', mainAml) → L1964 fetch('/api/rule-engine/execute-create-post',...)

→ Business page only triggers create_post, skipping validate/create_pre.

• capability-runtime.js L451/501/549/574 Each capability _initRuleEngine() then engine.execute(scope,...).
• object-importer.js:684 this.capabilityRuntime.create(...); lite-scheduler.js:236 new CapabilityRuntime(...) is given to the worker.

Conclusion:

• "All entry points create based on the unified rule engine" — this holds true on the server-side chain of AI dialogue / worker / import (the unified CapabilityRuntime layer).
• The most critical manual creation path on the business page is fragmented: it uses buildAML for assembly, submits directly, only supplements create_post, without going through CapabilityRuntime or the front-end rules of create-item.
• The documentation itself notes: "There are two prompt generation paths for Create scenarios (pre-generated vs. front-end PromptBuilder dynamic assembly), with medium consistency risk."

3. Has "any object can be created" been achieved? How?

Capability level: ✅ Achieved

• AmlBuilder.buildAML (business page/front-end) covers:
• Ordinary scalar attributes (L40-46)
• Item type attributes (L48-55: item_properties includes add/get actions, correctly generated)
• Complex relationship objects (L57-114: relationships include same-name relationships/heteronymous relationships, related_id references, sub-object item_properties, item_number query references)
• Nesting (L60)
• UnifiedRuleEngine.createItem (backend rule engine) also covers all field types, and documentation v3.4 has fixed the field classification bug where 'WBS's wbs_id (Item type) was incorrectly placed into Relationships' (changed to three field types: properties / item_properties / relationships).

Therefore,

'Including object classes, complex relationship objects, and Item/List properties can all be created'—the capability exists; it's not that it hasn't been achieved.

IV. Where is the real problem (specific, layered)

Problem A (Uniformity, medium risk, confirmed): Business page creation skips front-end rules

• Manifestation: The business page buildAML path does not run validate/create_pre, only create_post.
• Consequence: Default value population, auto-numbering, and data validation defined in validate/create_pre do not take effect during manual creation on the business page—inconsistent front-end processing for the same object when created via CapabilityRuntime (worker/AI) versus via the business page.
• This is the concrete implementation of the document 'In Consistency Risk'.

Issue B (Uniformity, low risk, confirmed): Two prompt generation paths.

• Path A: Server-side pre-generation (sciot_prompts, deterministic concatenation).
• Path B: Frontend PromptBuilder/AmlBuilder dynamic assembly.
• Potential inconsistency in output → For the same object class, the prompts/structures seen by the AI and those assembled by the frontend may differ.

Issue C (Not a creation issue, known debt): Incomplete migration of the sciot_rules old table.

• The sciot_import.db has two sets of rule tables coexisting; some users/modules still read the old table. This is a P1 issue.

The above is not a 'lack of creation capability', but rather 'the creation path is not unified at the front end of the rules engine'.

V. What I Did Not Do (To prevent false positives)

• Did not modify any code (As instructed: diagnose first, don't make changes that could cause more issues).
• Whether Feishu/Mini Program entry points go through CapabilityRuntime: This time only confirmed they do not directly instantiate it; indirect paths (via staff-router / miniapp-routes calling capability-api) require further investigation, marked as 'To be confirmed'.
• Did not provide 'solutions', as the user requested first to clarify what was done and where the real problems lie, rather than rushing to make changes.