Back to Details

ln-740-quality-setup

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

ln-740-quality-setup

ln-740 代码质量搭建

Type: L2 Domain Coordinator Category: 7XX Project Bootstrap Parent: ln-700-project-bootstrap
Coordinates code quality tooling configuration for the project.
类型： L2 域协调器 分类： 7XX 项目初始化 父级： ln-700-project-bootstrap
负责协调项目的代码质量工具配置。

Purpose & Scope

目标与范围

Does:
  • Detects project technology stack (TypeScript/React, .NET, Python)
  • Checks for existing quality configurations
  • Delegates to specialized workers for each quality aspect
  • Verifies final configuration works correctly
Does NOT:
  • Generate configuration files directly (workers do this)
  • Modify source code
  • Run in isolation (requires ln-720 structure first)
负责：
  • 检测项目技术栈（TypeScript/React、.NET、Python）
  • 检查现有质量配置
  • 将各质量相关任务委托给专门的处理模块
  • 验证最终配置可正常工作
不负责：
  • 直接生成配置文件（由专门处理模块完成）
  • 修改源代码
  • 独立运行（需先完成ln-720的结构搭建）

When to Use

适用场景

TriggerAction
After ln-720-structure-migrator completesAutomatic delegation from ln-700
Manual quality setup neededInvoke directly with project path
Existing project needs quality toolsRun with existing config detection
触发条件操作
ln-720结构迁移工具完成后由ln-700自动触发委托
需要手动搭建质量工具直接传入项目路径调用
现有项目需添加质量工具运行时检测现有配置

Workflow Overview

工作流概述

PhaseActionOutput
1Stack DetectionIdentified technologies
2Existing Config CheckSkip/merge/replace decisions
3Parallel DelegationWorker invocations
4VerificationWorking quality pipeline
阶段操作输出
1技术栈检测已识别的技术栈
2现有配置检查跳过/合并/替换决策
3并行任务分配调用各处理模块
4验证可正常运行的质量流水线

Phase 1: Stack Detection

阶段1：技术栈检测

Detect project technologies to determine which quality tools to configure.
Detection Rules:
File PatternTechnologyLinter Stack
package.json
+ 
tsconfig.json
TypeScript/ReactESLint + Prettier
*.csproj
or 
*.sln
.NETeditorconfig + Roslyn
pyproject.toml
or 
requirements.txt
PythonRuff
Multiple detectedMixedConfigure all detected
Actions:
  1. Glob for technology indicators
  2. Build technology list
  3. Log detected stack to user
检测项目技术栈，以确定需配置的质量工具。
检测规则：
文件模式技术栈代码检查器栈
package.json
+ 
tsconfig.json
TypeScript/ReactESLint + Prettier
*.csproj
或 
*.sln
.NETeditorconfig + Roslyn
pyproject.toml
或 
requirements.txt
PythonRuff
检测到多种技术栈混合栈配置所有检测到的工具
操作步骤：
  1. 匹配技术栈标识文件
  2. 构建技术栈列表
  3. 向用户日志输出已检测到的技术栈

Phase 2: Existing Configuration Check

阶段2：现有配置检查

Before delegating, check what configurations already exist.
Config Files to Check:
TechnologyConfig Files
TypeScript
eslint.config.*
, 
.prettierrc*
, 
tsconfig.json
.NET
.editorconfig
, 
Directory.Build.props
Python
ruff.toml
, 
pyproject.toml [tool.ruff]
Pre-commit
.husky/
, 
.pre-commit-config.yaml
Tests
vitest.config.*
, 
pytest.ini
, 
*.Tests.csproj
Decision Matrix:
Existing ConfigActionConfirmation
None foundCreate newNo
Partial foundMerge (add missing)Ask user
Complete foundSkipInform user
User requests replaceBackup + replaceYes
在委托任务前，检查项目已有的配置。
需检查的配置文件：
技术栈配置文件
TypeScript
eslint.config.*
, 
.prettierrc*
, 
tsconfig.json
.NET
.editorconfig
, 
Directory.Build.props
Python
ruff.toml
, 
pyproject.toml [tool.ruff]
提交前钩子
.husky/
, 
.pre-commit-config.yaml
测试
vitest.config.*
, 
pytest.ini
, 
*.Tests.csproj
决策矩阵：
现有配置情况操作确认方式
未找到任何配置创建新配置无需确认
找到部分配置合并（添加缺失项）询问用户
找到完整配置跳过配置通知用户
用户要求替换备份后替换需确认

Phase 3: Parallel Delegation

阶段3：并行任务分配

Invoke workers for each quality aspect. Workers can run in parallel as they configure independent tools.
Delegation Order:
ln-740 (this)
    |
    +---> ln-741-linter-configurator
    |         - ESLint/Prettier (TypeScript)
    |         - editorconfig/Roslyn (.NET)
    |         - Ruff (Python)
    |
    +---> ln-742-precommit-setup
    |         - Husky + lint-staged (Node.js)
    |         - pre-commit framework (Python)
    |         - commitlint
    |
    +---> ln-743-test-infrastructure
              - Vitest (TypeScript)
              - xUnit (.NET)
              - pytest (Python)
Pass detected stack and existing configs to workers via direct Skill tool invocation.
为各质量相关任务调用对应的处理模块。由于各工具配置相互独立，处理模块可并行运行。
任务分配顺序：
ln-740 (当前模块)
    |
    +---> ln-741-linter-configurator
    |         - ESLint/Prettier (TypeScript)
    |         - editorconfig/Roslyn (.NET)
    |         - Ruff (Python)
    |
    +---> ln-742-precommit-setup
    |         - Husky + lint-staged (Node.js)
    |         - pre-commit framework (Python)
    |         - commitlint
    |
    +---> ln-743-test-infrastructure
              - Vitest (TypeScript)
              - xUnit (.NET)
              - pytest (Python)
通过直接调用Skill工具，将检测到的技术栈和现有配置传递给各处理模块。

Phase 4: Verification

阶段4：验证

After all workers complete, verify the quality pipeline works.
Verification Steps:
CheckCommandExpected
Lint runs
npm run lint
/ 
ruff check .
/ 
dotnet format --verify-no-changes
No errors
Format runs
npm run format:check
/ 
ruff format --check
No changes needed
Tests run
npm test
/ 
pytest
/ 
dotnet test
Sample tests pass
Hooks workCreate test commitHooks trigger
On Failure:
  1. Log specific failure
  2. Suggest fix or re-run specific worker
  3. Do NOT mark as complete until verification passes
所有处理模块完成后，验证质量流水线可正常运行。
验证步骤：
检查项命令预期结果
代码检查运行
npm run lint
/ 
ruff check .
/ 
dotnet format --verify-no-changes
无错误
代码格式化检查
npm run format:check
/ 
ruff format --check
无需修改代码
测试运行
npm test
/ 
pytest
/ 
dotnet test
示例测试通过
钩子功能验证创建测试提交钩子触发执行
失败处理：
  1. 记录具体失败信息
  2. 建议修复方案或重新运行对应处理模块
  3. 验证通过前，不得标记任务完成

Critical Rules

核心规则

RULE 1: Never overwrite existing user configurations without explicit confirmation.
RULE 2: Workers run AFTER stack detection - do not invoke workers without knowing the stack.
RULE 3: Verification phase is MANDATORY - quality setup is not complete until tools run successfully.
RULE 4: eslint-config-prettier is REQUIRED when both ESLint and Prettier are configured.
规则1： 未经用户明确确认，不得覆盖现有用户配置。
规则2： 处理模块需在技术栈检测完成后运行 - 不得在未知技术栈的情况下调用处理模块。
规则3： 验证阶段为必填项 - 只有工具可成功运行，才算完成质量搭建。
规则4： 同时配置ESLint和Prettier时，必须使用eslint-config-prettier。

Definition of Done

完成标准

  • All detected technology stacks have appropriate quality tools
  • Existing configurations preserved or backed up
  • Lint command runs without errors
  • Format command runs without errors
  • Test command runs and sample tests pass
  • Pre-commit hooks trigger on test commit
  • User informed of all installed tools and commands
  • 所有检测到的技术栈均已配置合适的质量工具
  • 现有配置已保留或备份
  • 代码检查命令可无错误运行
  • 代码格式化命令可正常执行且无需修改代码
  • 测试命令可运行且示例测试通过
  • 提交前钩子可在测试提交时触发
  • 已向用户告知所有安装的工具及对应的命令

Reference Files

参考文件

FilePurpose
stack_detection.mdDetailed detection rules
verification_checklist.mdFull verification checklist
文件用途
stack_detection.md详细检测规则
verification_checklist.md完整验证清单
版本： 2.0.0 最后更新： 2026-01-10

Error Handling

—
ErrorCauseResolution
No stack detectedEmpty projectAsk user for intended stack
Worker failedMissing dependenciesInstall prerequisites, retry
Verification failedConfig errorCheck specific tool output, fix
Hooks not workingGit not initializedRun 
git init
first
Version: 2.0.0 Last Updated: 2026-01-10
—