eliteforge-framework-specification

EliteForge Framework Specification (Nightly)

Objectives

In Java development, prioritize reuse of the unified framework and by default avoid reinventing the wheel. Once a capability is matched, the framework's Starter and the corresponding framework abstract API must be used; falling back to Spring official starters is not allowed, nor is bypassing the framework abstraction layer. Output actionable answers based on the nightly manual and avoid answering "from experience" detached from the documentation.

Reuse-first constraints (core)

1. First match unified framework capabilities
   After receiving a feature requirement, first determine whether the manual already has a corresponding Starter/tool capability.

2. If matched, the framework's Starter is mandatory
   If it is already covered, you must output a plan of "directly integrate the unified framework Starter" and must not give Spring official starters (such as spring-boot-starter-web、spring-boot-starter-cache) or self-built wheels as the first choice.

3. If matched, use of the framework abstract API is mandatory
   If the manual provides a framework abstract interface/service, that interface/service must be used first, and you must not bypass the abstraction layer to directly call underlying components.

4. Falling back to Spring official Starters is prohibited
   In any scenario where a framework capability is matched, you must not output suggestions to "first use Spring official starters as a fallback/substitute".

1. Mandatory example for caching capability
   When the user raises a caching requirement, you must use cisdigital-elite-forge-infra-cache-spring-boot3-starter + CacheService。
   It is prohibited to use StringRedisTemplate/RedisTemplate as the business implementation, and it is prohibited to use them as a shortcut for "quick connectivity verification".

2. Handling boundaries when not covered
   Only when the manual has no corresponding capability, or it clearly cannot satisfy the scenario, may you give suggestions to "fill the capability gap in the framework/upgrade the version/build a custom extension", and explain the reason and boundary; even then, you must not recommend Spring official starters or underlying components that bypass the abstraction layer as a fallback.

Execution flow

1. Identify the question type
   First determine whether it belongs to 系统要求、新项目接入、存量升级、Starter 选型、具体模块配置/使用/扩展、升级差异 or 排障。

2. Minimal localization section
   First read references/toc.md to locate the section line numbers, then read references/framework-nightly-readme.md corresponding fragments as needed.
   Search first and then read locally to avoid loading the entire document.

3. Extract actionable information
   Extract 依赖坐标、配置项、注解/接口、框架抽象API、步骤顺序、约束条件、版本要求。
   When examples are needed, prioritize the minimal examples in the manual that can be directly implemented.

4. Structured output
   Answer according to a fixed structure:结论（是否命中统一框架能力）、推荐Starter、必须使用的框架抽象API、步骤、示例（可选）、注意事项（含禁止回退/禁止绕过抽象层）、文档定位。

Quick search instructions

# 先看目录索引（标题 + 行号）
cat references/toc.md

# 按关键字定位（starter、模块、配置项、注解）
rg -n "starter|系统要求|接入统一框架|升级统一框架|Web Mvc|服务间调用|Mybatis-Plus|加解密|缓存抽象层|多数据源|代码生成器|资源抽象层" references/framework-nightly-readme.md

# 按行号读取局部内容（示例：1600-1705行）
sed -n '1600,1705p' references/framework-nightly-readme.md

High-frequency question mapping

• 有哪些 starter: First look at 1.2.2 提供统一的Starter依赖治理
• 环境要求是什么: see 2 系统要求
• 新项目怎么接入: see 3.1 新项目直接在线生成
• 老项目怎么升级接入: see 3.2 存量项目手动升级
• 统一框架升级步骤: see 4 升级统一框架
• 模块如何配置/使用: see 5.x 对应模块章节

Starter list (quick answer)

• cisdigital-elite-forge-infra-web-spring-boot3-starter
• cisdigital-elite-forge-infra-httpexchange-spring-boot3-starter
• cisdigital-elite-forge-infra-mybatis-plus-spring-boot3-starter
• cisdigital-elite-forge-infra-crypto-spring-boot3-starter
• cisdigital-elite-forge-infra-cache-spring-boot3-starter
• cisdigital-elite-forge-infra-dynamic-datasource-spring-boot3-starter
• cisdigital-elite-forge-infra-code-generator
• cisdigital-elite-forge-infra-resource-spring-boot3-starter

Output constraints

• Clearly mark that the manual is nightlyand includes experimental capabilities.
• When version selection is involved, prioritize citing the manual's wording "latest release version" and do not fabricate specific version numbers.
• When modification suggestions are involved, first give the "minimal viable integration path (Starter first)", then give optional enhancements.
• When a framework capability is matched, only provide the unified framework's Starter solution; you must not use spring-boot-starter-* As an alternative, fallback, or last resort.
• When framework capabilities are hit, the "framework abstraction API landing point" must be provided (for example, in a caching scenario it must be CacheService); implementations that bypass the abstraction layer such as StringRedisTemplate/RedisTemplate must not be provided.
• Connectivity verification, minimal viable verification, and PoC must also follow the framework abstraction layer; "quick verification first" must not be used as a reason to bypass it.
• When the manual does not cover it, clearly state that "the current framework has no corresponding Starter yet, and the capability needs to be completed/version upgraded or a self-developed extension is needed," and do not guide a fallback to the official Spring starter.
• Information that does not appear in the manual must be clearly marked as "requires user supplementation or external confirmation."

Reference Materials

• Table of Contents Index:references/toc.md
• Complete Manual:references/framework-nightly-readme.md