create-yss-spec 3.3.1 → 3.3.4

package/template.manifest.json

@@ -1,12 +1,9 @@
 {
   "allowRootEntries": [
     ".agents",
-    ".claude",
     ".codex",
     ".cursor",
     ".pi",
-    ".qoder",
-    ".trae",
     ".vscode",
     "docs",
     "scripts"
@@ -14,10 +11,8 @@
   "allowRootFiles": [
     ".cursorrules",
     ".gitignore",
-    ".mcp.json",
     ".nvmrc",
     "AGENTS.md",
-    "CLAUDE.md",
     "CONTEXT.md",
     "DESIGN.md",
     "README.md",
@@ -49,7 +44,6 @@
     ".gitmodules"
   ],
   "excludePaths": [
-    ".claude/settings.local.json",
     ".codex/hooks.json",
     ".codex/settings.local.json",
     ".codex/skills/.DS_Store",
@@ -58,9 +52,53 @@
     "docs/.scratch",
     "docs/discovery",
     "docs/reviews",
-    "docs/adr"
+    "docs/adr",
+    "docs/process/maintenance-intensity.yaml",
+    "docs/process/schemas/maintenance-review-record.schema.json",
+    "docs/process/templates/maintenance-checkpoint-template.yaml",
+    "docs/process/template-verification-profiles.yaml",
+    "docs/process/template-engineering-overview.md",
+    "docs/agents/skills-maintenance.md",
+    "docs/agents/strategic-design-skills-integration.md",
+    "docs/agents/yss-ui-skills-integration.md",
+    "scripts/fixtures",
+    "scripts/audit-yss-backend-skills",
+    "scripts/cache-template-commit",
+    "scripts/capture-maintenance-candidate",
+    "scripts/evaluate-maintenance-review-round",
+    "scripts/export-yss-skills",
+    "scripts/generate-lifecycle-artifacts",
+    "scripts/generate-yss-skill-boundaries",
+    "scripts/inspect-maintenance-candidate",
+    "scripts/instantiate-harness",
+    "scripts/node-generate-lifecycle-artifacts.mjs",
+    "scripts/node-verify-lifecycle-registry.mjs",
+    "scripts/prepare-maintenance-review",
+    "scripts/run-template-verification",
+    "scripts/sync-strategic-handoff-tools",
+    "scripts/verify-maintenance-checkpoint",
+    "scripts/verify-maintenance-review-record",
+    "scripts/verify-governance-release",
+    "scripts/verify-retired-skill-ids",
+    "scripts/verify-skill-governance",
+    "scripts/verify-skill-registry",
+    "scripts/verify-template",
+    "scripts/verify-template-candidate",
+    "scripts/verify-template-fast",
+    "scripts/verify-upstream-skill-source",
+    "scripts/lib/maintenance-candidate.mjs",
+    "scripts/lib/maintenance-intensity.mjs",
+    "scripts/lib/maintenance-review.mjs",
+    "scripts/lib/maintenance-review-workflow.mjs",
+    "scripts/lib/scenario-checks.mjs",
+    "scripts/lib/skill-governance.mjs",
+    "scripts/lib/template-commit-cache.mjs",
+    "scripts/lib/template-verification.mjs",
+    "scripts/lib/template-verification-runner.mjs"
   ],
+  "excludePathSuffixes": ["-scenarios"],
   "renderPaths": [
+    ".gitignore",
     "AGENTS.md",
     "README.md",
     "yss-project.yaml"
@@ -81,6 +119,7 @@
       { "pattern": ".template-source/**", "ownership": "protected" },
       { "pattern": ".cursor/environment.json", "ownership": "protected" },
       { "pattern": ".gitmodules", "ownership": "user-owned" },
+      { "pattern": ".gitignore", "ownership": "managed-customizable" },
       { "pattern": "apps/**", "ownership": "user-owned" },
       { "pattern": "packages/**", "ownership": "user-owned" },
       { "pattern": "wiki/**", "ownership": "user-owned" },
@@ -91,17 +130,16 @@
       { "pattern": "yss-public-skills.json", "ownership": "generated" },
       { "pattern": ".agents/skills/.yss-skills-manifest.json", "ownership": "generated" },
       { "pattern": "AGENTS.md", "ownership": "managed-customizable" },
-      { "pattern": "CLAUDE.md", "ownership": "managed-customizable" },
       { "pattern": "CONTEXT.md", "ownership": "managed-customizable" },
       { "pattern": "DESIGN.md", "ownership": "managed-customizable" },
-      { "pattern": "README.md", "ownership": "managed-customizable" },
-      { "pattern": ".mcp.json", "ownership": "managed-customizable" }
+      { "pattern": "README.md", "ownership": "user-owned" }
     ]
   },
   "customizationPolicy": {
     "version": 1,
     "defaultStrategy": "replace-with-force",
     "rules": [
+      { "pattern": ".gitignore", "strategy": "manual" },
       { "pattern": "CONTEXT.md", "strategy": "manual" },
       { "pattern": "DESIGN.md", "strategy": "manual" }
     ]

package/template.snapshot.json

@@ -3,15 +3,15 @@
   "templateName": "yss-spec-project-template",
   "templateSource": "github:iloveZzz/yss-spec-project-template",
   "templateRepository": "https://github.com/iloveZzz/yss-spec-project-template.git",
-  "requestedRef": "ae2a3bdeca25249aed96d0a4d289b356d38417f9",
-  "templateCommit": "ae2a3bdeca25249aed96d0a4d289b356d38417f9",
-  "manifestHash": "e1e9f7d3e00c43b3e6cc889d961c94d684d08b852d8635c0a2f6b463b24432e6",
+  "requestedRef": "3e15bf3920520c1402e58ef78f303dc0353a1c99",
+  "templateCommit": "3e15bf3920520c1402e58ef78f303dc0353a1c99",
+  "manifestHash": "d194bb318a47c9c53b04292e97805c563ef7b296c2ca9b507cca498be7f52afe",
   "encodedPaths": {
     ".codex/skills/data-analytics/.gitignore": ".codex/skills/data-analytics/__yss_dotfile__.gitignore",
     ".codex/skills/product-design/.npmignore": ".codex/skills/product-design/__yss_dotfile__.npmignore",
     ".codex/skills/product-design/templates/prototype/.npmrc": ".codex/skills/product-design/templates/prototype/__yss_dotfile__.npmrc",
     ".gitignore": "__yss_dotfile__.gitignore"
   },
-  "snapshotHash": "b15d75307273b8d82f7e08b1b81a7d47ff88aa76cb7e05638ff5489620fe1888",
-  "generatedAt": "2026-09-10T02:41:41.548Z"
+  "snapshotHash": "6fe2b0f7444fdf19d3d23eca1c334195c551de01349d79ff0a1e468a3bb973f0",
+  "generatedAt": "2026-09-10T11:14:18.595Z"
 }

package/template/.claude/skills/.yss-skills-manifest.json

@@ -1,29 +0,0 @@
-{
-  "source": "/Users/zhudaoming/Projects/yss-spec-project-template/.agents/skills",
-  "mode": "link",
-  "skills": [
-    "yss-ui-business-page-generation",
-    "theme-token-usage",
-    "component-selection-imports",
-    "page-module-development",
-    "page-skeleton",
-    "page-list-module",
-    "page-form-module",
-    "ytable-usage",
-    "yedit-table-usage",
-    "ytree-usage",
-    "prototype-page-acceptance",
-    "api-integration",
-    "file-export-download",
-    "vue3-best-practices",
-    "frontend-commit",
-    "java-backend-commit",
-    "use-table-height",
-    "use-tree-height",
-    "yss-formily",
-    "formily-foundation",
-    "formily-linkage-effects",
-    "formily-mode-slot-detail",
-    "formily-step-flow"
-  ]
-}

package/template/.claude/skills/alibaba-java-code-style/SKILL.md

@@ -1,52 +0,0 @@
----
-name: alibaba-java-code-style
-description: Apply Alibaba Java Development Manual conventions when implementing, refactoring, or reviewing Java/JVM code, Spring-style services, MyBatis/ORM mappings, SQL, Maven dependencies, unit tests, exception/logging behavior, security checks, and design documentation. Use when the user asks for Java code规范, 阿里规范, P3C-style review, Java code style, or compliance with Alibaba Java coding guidelines.
----
-
-# Alibaba Java Code Style
-
-This skill distills the provided `阿里巴巴 Java 开发手册` 1.4.0 PDF into execution rules for Codex. Treat rules marked mandatory as review blockers unless the repository's own `AGENTS.md`, security constraints, or existing framework conventions explicitly require a different pattern.
-
-## Workflow
-
-1. Identify the touched surface:
-   - Java source, naming, constants, OOP, collections, concurrency, control flow, comments: read `references/java-programming.md`.
-   - Exceptions, logging, unit tests, or security: read `references/reliability-test-security.md`.
-   - MySQL, ORM/MyBatis, Maven dependencies, layering, server/JVM settings, or design artifacts: read `references/database-engineering-design.md`.
-2. Apply mandatory rules first, then use recommended rules to improve maintainability, performance, and readability.
-3. When reviewing, report mandatory violations as findings. Mention recommended violations when they create real risk or are already in the changed area.
-4. When implementing, prefer the repository's existing framework helpers and code generation skills over inventing new local infrastructure.
-5. If a rule touches a project safety boundary such as auth, payment, encryption, raw SQL, database migration scripts, or public base library API changes, produce a draft or `TODO-HUMAN-REVIEW` rather than silently finalizing risky code.
-
-## Core Priorities
-
-- 先消费 architecture_identity 与工程 Java/数据库基线。MVC 分层按 `docs/agents/backend-architecture-profiles.md`；MySQL 专属方言规则仅对批准的 MySQL 存储生效，不能要求 H2 骨架引入 MySQL 驱动。YSS 包装、命名及处理器差异逐项记录基线例外，安全、权限、敏感信息与 SQL 参数绑定不得豁免。
-- Keep names readable, English, and consistent with Java layer conventions.
-- Avoid null, equality, wrapper comparison, collection, and concurrency traps that compile cleanly but fail at runtime.
-- Make logs useful without wasting CPU, disk, or alert budget.
-- Keep unit tests automatic, independent, repeatable, and close to public behavior.
-- Bind SQL parameters, define explicit ORM mappings, and never rely on string-concatenated SQL.
-- Preserve layering: web/controller code validates and adapts; service/manager code owns business orchestration; DAO/repository code owns persistence.
-
-## Review Checklist
-
-- Naming and formatting are consistent: camel case, constants, package names, braces, spacing, line length, UTF-8/Unix line endings.
-- POJO, DTO, DO, VO, Query, enum, interface, implementation, and test names follow the expected suffixes and boolean naming rules.
-- `equals`, `hashCode`, wrapper comparisons, `toString`, `serialVersionUID`, constructors, access modifiers, and getters/setters avoid known pitfalls.
-- Collection code avoids unsafe `subList`, `Arrays.asList`, raw `toArray`, foreach removal, null-unsafe maps, and invalid comparators.
-- Thread code uses named thread pools, avoids `Executors` factories in production code, and handles locking order, date formatting, and scheduled tasks safely.
-- Exceptions are handled at the right layer, logged once with context and stack, and never swallowed or used for normal control flow.
-- Tests use assertions, avoid external dependence, live under `src/test/java`, and cover boundaries, correct cases, design cases, and error cases.
-- Security-sensitive inputs are validated, authorized, escaped, CSRF-protected, rate-limited, and never concatenated into SQL.
-- MySQL DDL/SQL/ORM code uses explicit fields, mappings, indexes, timestamps, `#{}`
-  parameter binding, and avoids dangerous cascades, stored procedures, `select *`, and uncontrolled pagination.
-
-## Source
-
-Based on the user-provided PDF: `阿里巴巴 Java 开发手册` version 1.4.0, Alibaba Group technical team, update date 2018-05-20.
-
-## 阶段 7 执行结果
-
-- 消费当前合同版本、changed files 和 verification results，只审查合同允许范围。
-- 必须把 mandatory violation 返回为 `violation`，并提供文件/位置/规则证据；高风险项保留 `TODO-HUMAN-REVIEW`。
-- 按统一 `YSS Skill Execution Result` 返回审查证据、偏离和新增安全/SQL/公共 API 影响，不得仅输出“符合规范”。

package/template/.claude/skills/alibaba-java-code-style/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "Alibaba Java Code Style"
-  short_description: "Apply Alibaba Java development guidelines"
-  default_prompt: "Use $alibaba-java-code-style to implement or review Java code against Alibaba Java development conventions."

package/template/.claude/skills/alibaba-java-code-style/references/database-engineering-design.md

@@ -1,147 +0,0 @@
-# Database, Engineering, And Design Rules
-
-Use this reference for MySQL DDL/SQL, ORM mappings, Maven/library dependency rules, application layering, server/JVM settings, and design artifacts.
-
-## MySQL Table Design
-
-Mandatory:
-
-- Boolean database fields must be named `is_xxx` and use `unsigned tinyint`, where `1` means yes and `0` means no. POJO boolean fields must not use `is` prefix, so define explicit ORM mappings.
-- Table and field names must be lowercase letters or digits. Do not start with digits, use uppercase, or use patterns such as `level_3_name`.
-- Table names must be singular.
-- Do not use MySQL reserved words such as `desc`, `range`, `match`, or `delayed`.
-- Index names: primary key `pk_字段名`, unique index `uk_字段名`, normal index `idx_字段名`.
-- Use `decimal` for decimals. Do not use `float` or `double` for precise stored values.
-- Use `char` for nearly fixed-length strings.
-- `varchar` length must not exceed 5000. For longer content, use `text` in a separate table keyed by the primary key to avoid hurting other index efficiency.
-- Every table must include `id`, `gmt_create`, and `gmt_modified`. `id` is `bigint unsigned` primary key with auto-increment step 1 for single tables; timestamps are `datetime`.
-
-Recommended/reference:
-
-- Prefer table names like `业务名称_表作用`.
-- Keep database name aligned with application name where possible.
-- Update field comments when field meaning or status values change.
-- Redundant fields are allowed for performance only when consistency is considered, the value is not frequently changed, and the field is not long `varchar` or `text`.
-- Consider sharding only when a single table exceeds about 5 million rows or 2 GB, or when projections clearly require it.
-- Choose compact unsigned integer types where domain ranges allow.
-
-## Indexes
-
-Mandatory:
-
-- Business-unique fields must have unique indexes, even when uniqueness is also checked in application code.
-- Do not join more than 3 tables. Join column types must be exactly consistent and associated columns must have indexes.
-- When indexing `varchar`, specify an index length based on real selectivity instead of indexing the whole field.
-- Page search must not use left fuzzy or full fuzzy queries such as `%keyword` or `%keyword%`; use a search engine when needed.
-
-Recommended/reference:
-
-- For `order by`, align the ordered field with the last part of the composite index where possible, such as `where a=? and b=? order by c` with index `a_b_c`.
-- Use covering indexes to avoid table lookups where suitable.
-- For deep pagination, use delayed join/subquery techniques to locate IDs first, or cap total pages.
-- SQL optimization target: at least `range`, preferably `ref`, best `const`.
-- Put the most selective equality column on the left side of composite indexes. When mixed with range conditions, place equality conditions first.
-- Avoid implicit type conversion, which can invalidate indexes.
-- Avoid both extremes: indexing every query and resisting necessary indexes such as unique indexes.
-
-## SQL And ORM
-
-Mandatory:
-
-- Use `count(*)` for row counts, not `count(column)` or `count(constant)`.
-- Know `count(distinct col)` ignores nulls; `sum(col)` over all-null rows returns null, so guard against NPE.
-- Use `ISNULL()` or the project-standard equivalent to test nulls; direct equality comparisons with null do not behave as true/false.
-- In pagination code, return immediately when count is 0 instead of running the page query.
-- Do not use foreign keys or cascades; model those relationships in application logic for distributed/high-concurrency systems.
-- Do not use stored procedures in application code.
-- For data correction, especially delete/update, select first and confirm before mutating.
-- In queries, never use `*`; explicitly list required fields.
-- POJO boolean fields must not use `is` prefix, while database fields must use `is_`; define explicit result mappings.
-- Do not rely on `resultClass` for ORM returns. Define `resultMap` or equivalent explicit mappings.
-- MyBatis/iBATIS XML parameters must use `#{}`. Do not use `${}` for user-controlled values because it risks SQL injection.
-- Do not return raw `HashMap`/`Hashtable` as query results; use typed objects.
-- Every update to a table record must update `gmt_modified` to the current time.
-
-Recommended/reference:
-
-- Avoid large `IN` lists; keep them under about 1000 items if unavoidable.
-- For internationalized storage, use UTF-8; use `utf8mb4` when storing emoji.
-- Avoid `TRUNCATE TABLE` in application code; it has no transaction and does not trigger delete behavior.
-- Do not create a large all-fields update API. Update only changed target fields to reduce mistakes, binlog size, and work.
-- Do not overuse `@Transactional`; consider database QPS and rollback/compensation for cache, search, messages, and statistics.
-
-## Application Layering
-
-Recommended/reference:
-
-- Follow downward dependencies:
-  - Open API layer: exposes service methods as RPC/HTTP, handles gateway security and traffic controls.
-  - Terminal display layer: templates, JavaScript rendering, JSP, or mobile display.
-  - Web layer: forwarding, access control, basic parameter validation, and simple non-reused business handling.
-  - Service layer: concrete business logic.
-  - Manager layer: common business handling, third-party platform adaptation, service common capability extraction, cache/middleware handling, and DAO composition.
-  - DAO layer: persistence interaction with MySQL, Oracle, HBase, etc.
-  - External interfaces: other departments' RPC APIs, base platforms, or third-party HTTP APIs.
-- Exception handling by layer:
-  - DAO catches broad persistence exceptions and wraps them as `DAOException`; do not log again if the upper layer will log.
-  - Service logs exceptions with parameters and context.
-  - Manager follows DAO behavior when deployed with Service, or Service behavior when independently deployed.
-  - Web should not keep throwing to users; render friendly errors when the page cannot proceed.
-  - Open API converts exceptions to error code and message.
-- Domain model meanings:
-  - `DO`: database table object, passed upward by DAO.
-  - `DTO`: transfer object from Service/Manager outward.
-  - `BO`: business object output by Service.
-  - `AO`: application object between Web and Service, close to display and not highly reusable.
-  - `VO`: view object for Web/template rendering.
-  - `Query`: query request object. If a query has more than 2 parameters, wrap them; do not pass `Map`.
-
-## Maven And Library Dependencies
-
-Mandatory:
-
-- Use GAV conventions where applicable: `GroupId` as `com.{company/BU}.business[.subBusiness]`, `ArtifactId` as `product-module`, version as `major.minor.patch`.
-- Version meaning: major for direction/large incompatibility/architecture changes, minor for mostly compatible major features, patch for compatible bugfixes/minor features. Initial formal release should be `1.0.0`.
-- Online applications must not depend on `SNAPSHOT` versions except explicitly allowed security packages.
-- Adding/upgrading a library must preserve dependency mediation outside the intended functional change. Compare `dependency:resolve`/`dependency:tree` and exclude accidental differences.
-- Library APIs may define enum types and accept enum parameters, but should not return enum values or POJOs containing enum values across external library boundaries.
-- Define one version variable for a group of related libraries to avoid version drift.
-- Do not declare the same `GroupId` and `ArtifactId` with different versions across subprojects.
-
-Recommended/reference:
-
-- Put dependency declarations under `<dependencies>` and version mediation under `<dependencyManagement>`.
-- Avoid adding configuration items to reusable libraries unless truly necessary.
-- Library publishers should keep APIs/dependencies minimal and behavior stable/traceable.
-
-## Server And JVM
-
-Recommended/reference:
-
-- For high-concurrency servers, reduce TCP `time_wait` timeout where operations policy allows.
-- Increase maximum file descriptors for high concurrent connection counts.
-- Set `-XX:+HeapDumpOnOutOfMemoryError` so OOM events produce diagnostic dumps.
-- In production, set JVM `Xms` and `Xmx` to the same size to avoid heap resizing pressure after GC.
-- Use `forward` for internal redirects. Generate external redirect URLs through URL builder utilities to avoid inconsistent maintenance and potential security risk.
-
-## Design Rules
-
-Mandatory:
-
-- Storage schemes and base data structures must pass review and be documented before production execution. Data structure changes such as adding fields also need review.
-- If more than one user type interacts with the system and related use cases exceed 5, use a use-case diagram.
-- If a business object's states exceed 3, use a state diagram and define trigger conditions for state transitions.
-- If a feature call chain involves more than 3 objects, use a sequence diagram and define inputs/outputs at each call.
-- If model classes exceed 5 and dependencies are complex, use a class diagram.
-- If more than 2 objects collaborate and the process is complex, use an activity diagram with swimlanes where useful.
-
-Recommended/reference:
-
-- Consider exception flows and business boundaries during requirements analysis and system design.
-- Classes should follow single responsibility.
-- Prefer composition/aggregation over inheritance. If inheritance is necessary, obey Liskov substitution.
-- Depend on abstractions and interfaces where it improves extension and maintenance.
-- Design for extension and closed modification in stable business domains.
-- Extract common business behavior or public behavior into shared modules, config, classes, or methods to avoid duplicated code/config.
-- Do not treat agile as only stories plus coding plus release; keep necessary design and documentation for key decisions.
-- Design identifies hard parts, variation points, boundaries, module relations, evolution principles, and nonfunctional requirements such as security, availability, and extensibility.

package/template/.claude/skills/alibaba-java-code-style/references/java-programming.md

@@ -1,178 +0,0 @@
-# Java Programming Rules
-
-Use this reference for Java implementation and review: naming, constants, formatting, OOP, collections, concurrency, control flow, comments, and general coding traps.
-
-## Naming
-
-Mandatory:
-
-- Do not start or end identifiers with `_` or `$`.
-- Do not mix pinyin and English; do not use Chinese identifiers. Widely recognized names such as `alibaba`, `taobao`, `youku`, and `hangzhou` are acceptable.
-- Use `UpperCamelCase` for classes, except suffix acronyms such as `DO`, `BO`, `DTO`, `VO`, `AO`, `PO`, and `UID`.
-- Use `lowerCamelCase` for methods, parameters, member variables, and local variables.
-- Use uppercase words separated by underscores for constants, with complete semantics such as `MAX_STOCK_COUNT`.
-- Name abstract classes with `Abstract` or `Base` prefixes, exception classes with `Exception` suffixes, and test classes as the tested class name plus `Test`.
-- Put brackets next to the type for arrays: `String[] args`, not `String args[]`.
-- Do not prefix POJO boolean properties with `is`; frameworks may mis-detect the property name. Map database `is_xxx` fields explicitly.
-- Package names must be lowercase, singular, dot-separated, and each segment should be one natural English word.
-- Avoid nonstandard abbreviations that hide meaning.
-
-Recommended/reference:
-
-- Prefer complete words for self-explanatory names.
-- If a module, interface, class, or method uses a design pattern, reflect the pattern in the name, such as `OrderFactory`, `LoginProxy`, or `ResourceObserver`.
-- Interface methods and fields should omit redundant `public` modifiers and include useful Javadoc.
-- For `Service` and `DAO`, expose interfaces and name implementations with `Impl`.
-- Capability interfaces may use adjective names such as `Translatable`.
-- Enum class names may end with `Enum`; enum members use uppercase underscores.
-- Layer method prefixes: `get` for one object, `list` for multiple objects, `count`, `save`/`insert`, `remove`/`delete`, and `update`.
-- Model suffixes: `xxxDO`, `xxxDTO`, `xxxVO`; do not name a class `xxxPOJO`.
-
-## Constants
-
-Mandatory:
-
-- Do not use magic values directly in code. Define named constants.
-- Use uppercase `L` for `long`/`Long` literals, never lowercase `l`.
-
-Recommended:
-
-- Do not keep every constant in one universal constant class. Group by function and scope.
-- Choose the smallest sensible reuse scope: cross-application library, application, submodule, package, or class-local `private static final`.
-- Use `enum` when values vary only within a fixed set, especially when values have attributes.
-
-## Formatting
-
-Mandatory:
-
-- For non-empty blocks, put `{` on the same line, newline after `{`, newline before `}`, and keep `} else {` on one line. Empty blocks may be `{}`.
-- Do not put spaces immediately inside parentheses. Put one space before `{`.
-- Put one space between reserved words and `(` for `if`, `for`, `while`, `switch`, and `do`.
-- Put one space around binary and ternary operators.
-- Use 4 spaces for indentation; do not use tab characters.
-- `//` comments must have exactly one space after the slashes.
-- Keep lines at or below 120 characters. When wrapping, indent the second line 4 spaces, keep operators and dots with the following line, wrap method arguments after commas, and do not break before `(`.
-- Add a space after commas in method definitions and calls.
-- Use UTF-8 and Unix line endings.
-
-Recommended:
-
-- Keep a single method under 80 lines, including signature, braces, code, comments, blank lines, and invisible characters.
-- Do not align variables by adding decorative spaces.
-- Insert one blank line between different logical or business sections; avoid multiple blank lines.
-
-## OOP And POJO
-
-Mandatory:
-
-- Access static members through the class name, not an object reference.
-- Add `@Override` to all overridden methods.
-- Use varargs only for same-type, same-meaning arguments; avoid `Object...`.
-- Do not change method signatures of externally used APIs or library APIs. Deprecate old interfaces with `@Deprecated` and document replacements.
-- Do not use deprecated classes or methods.
-- Call `equals` on constants or known non-null objects, or use `Objects.equals`.
-- Compare wrapper objects of the same type with `equals`, not `==`.
-- Use wrapper types for all POJO fields and RPC parameters/returns; prefer primitive types for local variables.
-- Do not set default values on DO/DTO/VO fields.
-- When adding fields to serializable classes, do not change `serialVersionUID` unless the change is intentionally incompatible.
-- Do not put business logic in constructors; use an init method or lifecycle hook.
-- POJO classes must implement `toString`; include `super.toString()` when extending another POJO.
-- Do not define both `isXxx()` and `getXxx()` for the same POJO property.
-
-Recommended:
-
-- Before indexing into `String.split` results, account for trailing separators.
-- Keep overloaded methods and multiple constructors adjacent.
-- Order methods as public/protected methods, private methods, then getters/setters, except overloaded groups.
-- Setter parameter names should match field names and use `this.field = field`.
-- Do not add business logic to getters or setters.
-- Use `StringBuilder.append` for string concatenation inside loops.
-- Use `final` for non-inheritable classes, non-overridable methods, immutable references, non-reassigned locals, or to avoid variable reuse confusion.
-- Be careful with `Object.clone`; default clone is shallow.
-- Minimize access scope: private constructors for non-instantiable classes, no public/default constructors in utility classes, private fields and methods unless broader access is truly required, and consider `final` for static fields.
-
-## Collections
-
-Mandatory:
-
-- If overriding `equals`, also override `hashCode`.
-- Objects stored in `Set` or used as `Map` keys must implement both `equals` and `hashCode`.
-- Do not cast `ArrayList.subList` results to `ArrayList`; it is a view.
-- Do not structurally modify the original list while iterating or changing a `subList`.
-- Convert collections to arrays with `toArray(new T[list.size()])`, not raw `toArray()`.
-- Do not call mutating methods on `Arrays.asList` results.
-- Respect PECS: `? extends T` is for producers/readers and cannot safely accept `add`; `? super T` is for consumers/writers and cannot safely provide typed `get`.
-- Do not remove/add elements inside foreach loops; use an `Iterator` and `iterator.remove()`. Lock the iterator if operations are concurrent.
-- Comparators must be symmetric, transitive, and handle equality consistently.
-
-Recommended:
-
-- Use diamond syntax or type inference where supported.
-- Specify initial collection capacity where size is known; for `HashMap`, use roughly `expectedSize / 0.75 + 1`, or default 16 when unknown.
-- Iterate maps with `entrySet` or `Map.forEach` when both key and value are needed.
-- Know map null support: `ConcurrentHashMap` and `Hashtable` reject null keys/values; `TreeMap` rejects null keys; `HashMap` allows null keys/values.
-- Use set uniqueness to de-duplicate rather than repeated `List.contains`.
-
-## Concurrency
-
-Mandatory:
-
-- Singleton acquisition and singleton methods must be thread-safe.
-- Name threads and thread pools meaningfully.
-- Provide thread resources through thread pools; do not create raw application threads casually.
-- Do not create production thread pools through `Executors`; use `ThreadPoolExecutor` so queue size, thread count, rejection policy, and resource limits are explicit.
-- Do not use static `SimpleDateFormat` without synchronization. Prefer `DateTimeFormatter`/`java.time`, `ThreadLocal`, or a safe date utility.
-- In high concurrency, minimize lock cost: prefer lock-free structures, small locked blocks, and object locks over class locks where suitable.
-- Keep a consistent lock acquisition order across resources to avoid deadlock.
-- For concurrent updates to one record, use application/cache locks or database optimistic locks with a `version` field; retry optimistic locks at least 3 times.
-- Prefer `ScheduledExecutorService` over `Timer` for multiple scheduled tasks, because one uncaught `TimerTask` exception stops other tasks.
-
-Recommended/reference:
-
-- With `CountDownLatch`, call `countDown` in `finally` or otherwise guarantee it runs even on exceptions.
-- Prefer `ThreadLocalRandom` over shared `Random`/`Math.random` in concurrent code.
-- If using double-checked locking on JDK 5+, declare the target field `volatile`.
-- `volatile` solves visibility for one writer/many readers but not compound writes; use `AtomicInteger`, `AtomicLong`, or `LongAdder` for counters.
-- Avoid unsynchronized high-concurrency `HashMap` resizing; use concurrent collections or locking.
-- Declare `ThreadLocal` fields as `static` when the per-thread value should be shared by all instances of the class.
-
-## Control Flow And Parameters
-
-Mandatory:
-
-- Every `switch` case must end with `break`, `return`, or a comment explaining fallthrough. Every `switch` must have a final `default`.
-- Always use braces for `if`, `else`, `for`, `while`, and `do`, even for one line.
-- In high-concurrency exit logic, avoid equality-only checks; prefer range checks that cannot be skipped by concurrent changes.
-- Do not exceed 3 levels of `if/else`; use guard clauses, strategy, or state pattern.
-
-Recommended:
-
-- Prefer guard clauses for exceptional branches.
-- Do not put complex expressions inside conditions. Assign them to well-named boolean variables first.
-- Move object creation, connection acquisition, unnecessary try/catch, and other expensive operations outside loops where possible.
-- Avoid negated logic when an equivalent positive condition is available.
-- Protect interface parameters, especially batch operations.
-- Validate parameters for low-frequency, expensive, high-stability, external, or sensitive-permission methods.
-- You may omit repeated validation for hot private or low-level methods only when callers have already validated and method docs state the expectation.
-
-## Comments And General Rules
-
-Mandatory:
-
-- Use Javadoc (`/** ... */`) for classes, fields, and methods. Do not use `//` as class or method API documentation.
-- Abstract methods and interface methods need Javadoc explaining purpose, parameters, returns, exceptions, and implementation notes.
-- Classes must include creator and creation date if the repository convention requires Alibaba manual compliance; otherwise follow local project header policy.
-- Place single-line comments above the code they explain. Align multi-line block comments with code.
-- Every enum value must have a comment explaining its purpose.
-- Precompile regular expressions; do not call `Pattern.compile` repeatedly inside method bodies.
-- Use `System.currentTimeMillis()` for current milliseconds, not `new Date().getTime()`. Use `System.nanoTime()` for elapsed time measurement; Java 8 may use `Instant`.
-
-Recommended/reference:
-
-- Prefer clear Chinese comments over awkward English; keep technical terms in English.
-- Update comments when changing parameters, returns, exceptions, or core logic.
-- Delete dead code. If temporarily commenting code, explain why above it.
-- Keep comments concise and focused on design intent, business meaning, and non-obvious logic.
-- Mark `TODO`/`FIXME` with owner, date, and expected handling time when possible.
-- Do not put complex logic in view templates.
-- Specify data structure capacity where possible.

package/template/.claude/skills/alibaba-java-code-style/references/reliability-test-security.md

@@ -1,89 +0,0 @@
-# Reliability, Test, And Security Rules
-
-Use this reference for exception handling, logging, unit testing, and security-sensitive Java work.
-
-## Exception Handling
-
-Mandatory:
-
-- Do not catch avoidable runtime exceptions such as `NullPointerException` or `IndexOutOfBoundsException`; prevent them with prechecks.
-- Do not use exceptions for normal process or branch control.
-- Keep try blocks focused on unstable code. Catch specific exception types where behavior differs.
-- Never swallow caught exceptions. Handle them, translate them to user-understandable content at the outer business boundary, or rethrow.
-- In transactional code, if a caught exception requires rollback, explicitly trigger rollback according to the framework.
-- Always close resources and streams in `finally` or use try-with-resources. Handle close exceptions appropriately.
-- Do not `return` from a `finally` block.
-- Caught exception types must match thrown exceptions exactly or be an appropriate parent type.
-
-Recommended/reference:
-
-- A method may return `null`, but must document when that can happen. Callers remain responsible for NPE prevention.
-- Check common NPE sources: auto-unboxing wrapper return values, database nulls, null elements inside non-empty collections, remote calls, session reads, and chained calls such as `a.getB().getC()`.
-- Distinguish unchecked and checked exceptions. Avoid `new RuntimeException()`, `Exception`, or `Throwable` without business meaning; prefer domain-specific exceptions such as `DAOException` or `ServiceException`.
-- Public external HTTP/API interfaces should use error codes. Internal application code may throw exceptions. Cross-application RPC can prefer a result wrapper with success flag, code, and brief message.
-- Avoid duplicate code; extract common validation or behavior into methods/classes/components.
-
-## Logging
-
-Mandatory:
-
-- Use SLF4J facade APIs, not direct Log4j/Logback APIs:
-
-```java
-private static final Logger logger = LoggerFactory.getLogger(Abc.class);
-```
-
-- Keep application logs for at least 15 days when configuring retention.
-- Name extension logs as `appName_logType_logName.log`, where `logType` can be `stats`, `monitor`, `access`, etc.
-- For `trace`/`debug`/`info`, use placeholder logging or guard with `isXxxEnabled`; do not eagerly concatenate strings.
-- Avoid duplicate log printing, such as missing `additivity=false` in Log4j configuration.
-- Exception logs must include both scene/context information and stack trace. If not handled locally, throw upward.
-
-Recommended:
-
-- Production must not output debug logs. Emit info selectively.
-- Use `warn` for user input errors when no system fault occurred; reserve `error` for system logic errors, exceptions, or important failures.
-- Prefer English error messages where possible; use Chinese only when English would be unclear. Internationalized or overseas deployments require English logs/comments.
-- Before adding logs, ask whether someone will read them and what action they enable.
-
-## Unit Tests
-
-Mandatory:
-
-- Unit tests must follow AIR: Automatic, Independent, Repeatable.
-- Tests must be fully automated and non-interactive. Use assertions, not `System.out`, for verification.
-- Tests must not call each other or depend on execution order.
-- Tests must be repeatable and isolated from external environments such as network, remote services, or middleware. Inject local or mock dependencies.
-- Unit test granularity should be small: usually method-level, at most class-level.
-- Incremental code for core businesses, core applications, and core modules must pass unit tests.
-- Test code belongs under `src/test/java`, not production source directories.
-
-Recommended/reference:
-
-- Basic target: statement coverage at least 70%; core modules should reach 100% statement and branch coverage where feasible.
-- Use BCDE coverage thinking:
-  - Border: boundary values, loop boundaries, special values, special times, data ordering.
-  - Correct: valid inputs and expected outputs.
-  - Design: cases derived from design documents.
-  - Error: invalid data, exception flows, and disallowed business inputs.
-- Database tests should prepare data through programmatic insert/import, not manual pre-existing database edits.
-- Database tests should rollback automatically or mark generated data with a clear prefix.
-- Refactor untestable code instead of writing awkward tests to satisfy coverage.
-- Avoid business code that makes tests hard: heavy constructors, excessive globals/statics, too many external dependencies, and deep conditionals.
-
-## Security
-
-Mandatory:
-
-- User-owned pages or functions must perform authorization checks, including horizontal permission checks.
-- Sensitive user data must be masked before display, such as mobile numbers with hidden middle digits.
-- SQL parameters from users must use parameter binding or metadata-limited fields. Do not concatenate SQL strings.
-- Every user request parameter must be validated. Consider memory overflow, malicious `order by`, open redirect, SQL injection, deserialization injection, and ReDoS risks.
-- Do not output user data to HTML without proper filtering or escaping.
-- Forms and AJAX submissions must enforce CSRF protection.
-- Platform resources such as SMS, email, phone calls, orders, and payments must implement replay prevention, rate limits, fatigue control, or captcha as appropriate.
-
-Recommended:
-
-- User-generated content such as posts, comments, and instant messages should have anti-abuse, rate-limit, and prohibited-content controls.
-- Treat auth, payment, encryption, raw SQL, and database migration work as high-risk. If repository instructions mark them human-review-only, add `TODO-HUMAN-REVIEW` and do not present drafts as production-ready.