ECC Ruby/Rails 架构模式指南从 Rails Way 到 Solid Queue、Hotwire 与认证选型的工程决策手册【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC导读本文基于 ECC 仓库中 Ruby 语言规则集的核心文件 patterns.md系统讲解在 Ruby on Rails 项目中如何做出可持续的架构决策从先用 Rails Way的分层演进原则到持久化选型PostgreSQL 与 Rails 8 SQLite 默认值、后台任务Solid Queue 与 Sidekiq、前端方案Hotwire 与 SPA以及认证体系Rails 8 认证生成器与 Devise的取舍标准。读完本文你将获得一套可直接用于 Rails 8 项目评审与架构设计的决策框架并理解 ECC 如何通过公共规则 语言专属规则的分层结构把这些工程准则落地为 Agent 可执行的规范。一、规则定位Ruby 专属层如何扩展公共模式在 ECC 的规则体系中rules/目录采用公共层 语言层的分层结构见 rules/README.mdrules/ ├── common/ # 语言无关的通用原则总是安装 │ └── patterns.md # 骨架项目、仓库模式、API 响应格式等 └── ruby/ # Ruby / Rails 专属 ├── coding-style.md ├── patterns.md # 本文主体 ├── hooks.md ├── security.md └── testing.mdpatterns.md 的文件头明确声明This file extends common/patterns.md with Ruby and Rails specific content.也就是说通用模式如 Repository 模式、API 响应信封格式在 common/patterns.md 中定义而 Ruby 层只补充 Rails 语境下特有的架构决策点。规则优先级上语言专属规则优先于公共规则类似于 CSS 特指度或.gitignore优先级因此 Ruby 团队在架构评审时以本文为最高优先依据。该文件通过 YAML frontmatter 声明其生效范围Agent 在以下文件上会自动激活这套规则paths: - **/*.rb - **/*.rake - **/Gemfile - **/app/**/*.erb - **/config/routes.rb二、Rails Way First从约定俗成到有节制地抽象规则的第一条铁律是先走 Rails WayRails Way First它包含三个递进的原则1. 中小功能先用纯 Rails MVC 与 Active Record 约定对中小规模功能不急于引入任何自定义架构层。控制器处理请求、模型处理领域逻辑、Active Record 处理持久化这是 Rails 生态被验证过的最短路径也符合 coding-style.md 中先遵循 Rails 命名与目录约定再考虑自定义结构的要求。2. 分层抽象的唯一触发条件职责过载只有当模型/控制器边界承载了多重职责时才引入以下对象对象类型典型职责Service Object跨模型的业务流程编排如订单结算、导入导出Query Object复杂查询条件封装替代控制器内散落的 where 链Form Object多模型表单校验与参数收集Decorator / Presenter视图层展示逻辑封装这条规则的本质是按需抽象而非默认仪式——这与 coding-style.md 中的表述完全一致Put reusable domain behavior in models, concerns, service objects, query objects, or form objects based on actual complexity, not as default ceremony.3. 命名要反映业务操作而非通用层名提取出的对象必须按其所执行的业务操作命名严禁使用Manager、Processor这类泛化层名。例如# 不推荐无法传达业务语义 class OrderManager def process; end end # 推荐直接表达业务操作 class OrderCheckout def call(order, payment_params); end end class InvoiceGenerator def call(order); end end这种命名约束的价值在于类名即文档评审代码时一眼就能看出该对象承担的具体业务职责避免出现一个什么都做的上帝 Manager。三、持久化选型PostgreSQL 优先与 Rails 8 SQLite 默认值的边界1. 多主机生产环境优先 PostgreSQL对于多主机multi-host生产 Rails 应用除非现有平台有明确理由使用 MySQL 或 SQLite否则优先 PostgreSQL。理由包括PostgreSQL 的事务、索引能力、JSON 支持以及与 Rails 生态如全文搜索、几何类型的深度整合。2. Rails 8 的 SQLite 默认值适用边界Rails 8 将 SQLite 设为默认数据库规则对此给出了清醒的边界判断Rails 8 的 SQLite 默认配置适合单主机或小规模部署但不会自动适配共享多服务系统。这意味着若你的应用是单体小部署、并发写入压力不大SQLite 的开箱即用体验极具吸引力但一旦涉及多服务共享数据库、高并发写入或集群部署就必须迁移到 PostgreSQL 这类服务端数据库。3. 原始 SQL 的封装纪律规则要求所有原始 SQL 都必须放在查询对象Query Object或模型作用域model scope背后且所有动态值必须参数化。# 推荐封装在模型 scope 中动态值参数化 class Order ApplicationRecord scope :paid_since, -(since) { where(paid_at ?, since) # 参数化杜绝字符串拼接 } end # 推荐复杂查询封装为 Query Object class MonthlyRevenueQuery def initialize(relation Order.all) relation relation end def call(year:, month:) relation .where(status: :paid) .where(paid_at ? AND paid_at ?, Date.new(year, month), Date.new(year, month).next_month) .sum(:amount_cents) end end这条纪律与 security.md 中绝不将请求、Cookie、Header、Job 或 Webhook 值插值进 SQL 字符串的硬性要求互为表里是防 SQL 注入的第一道防线。四、后台任务与运行时服务Solid Queue 与 Sidekiq 的取舍规则给出了清晰的二选一决策树Solid Queue —— 绿地 Rails 8 项目的默认选择对于吞吐量适中、部署要求简单的绿地 Rails 8 应用使用Solid Queue。Solid Queue 是 Rails 8 自带的数据库驱动后台任务系统其核心优势是无需额外基础设施——直接复用应用数据库部署模型与 Rails 应用完全一致符合简单部署的诉求。Sidekiq —— 需要成熟能力时的升级路径当应用需要成熟的可观测性、高吞吐量、已有 Redis 基础设施或Pro/Enterprise 功能时使用Sidekiq。Sidekiq 基于 Redis 的架构决定了它适合以下场景需要成熟的监控、重试统计、批量任务等 Pro/Enterprise 能力已经运维 Redis不希望再引入新的存储组件任务吞吐量高需要独立于主数据库的任务队列。缓存与实时通道Solid Cache / Solid Cable vs Redis类似的决策逻辑也适用于缓存与 WebSocket组件适用条件Solid Cache / Solid Cable其部署模型数据库驱动、与应用同构与当前应用匹配时Redis需要共享跨服务行为、高扇出high fanout、高级数据结构时核心判据是部署模型是否匹配如果你的应用是多服务共享 Redis 的体系单独为 Rails 应用引入数据库驱动缓存反而割裂了基础设施反之简单单体应用用 Redis 则引入了不必要的运维负担。五、前端策略Hotwire 优先SPA 按需引入1. 服务端渲染优先 Hotwire对于服务端渲染的 Rails 应用规则明确推荐Hotwire全家桶TurboTurbo Drive 加速页面导航Turbo Frames 局部更新Turbo Streams 通过 WebSocket 推送增量 DOM 变更Stimulus轻量级 JavaScript 框架为 HTML 添加渐进增强行为Importmap无 Node 构建步骤的 JavaScript 依赖管理PropshaftRails 8 默认的资产管道替代 Sprockets。这四件套让 Rails 团队无需引入独立前端构建链即可获得接近 SPA 的交互体验与 Rails 的约定优于配置哲学一脉相承。2. 何时引入 React / Vue / Inertia.js / 独立 SPA规则给出三个引入客户端前端的正当理由交互复杂度页面存在复杂的状态管理、拖拽、实时协作等高交互需求既有产品架构公司已有成熟的 React/Vue 前端体系与组件库团队所有权前端团队独立维护前端代码库。3. 视图层的职责边界规则对视图层提出明确约束视图组件View Component、局部模板partial、Presenter 只负责渲染决策持久化与授权逻辑严禁进入模板。%# 错误示范模板内直接操作持久化与鉴权 % % if current_user.can?(:admin) User.dangerous_operation!(current_user) % ... % end % %# 正确示范模板只做渲染判断 % % if render_admin_panel? % % render AdminPanelComponent.new(user: current_user) % % end %这条规则保证了模板的可测试性与安全性与 security.md 中转义模板输出、将html_safe/raw视为安全敏感代码的要求配套。六、认证方案Rails 8 生成器与 Devise 的边界认证选型同样遵循简单优先复杂再升级的原则场景一简单会话认证 → Rails 8 认证生成器对简单的会话认证与密码重置需求使用Rails 8 认证生成器。Rails 8 内置的认证生成器bin/rails generate authentication会生成基于会话的认证、密码重置所需的最小代码集无额外 Gem 依赖代码完全透明可控适合新项目的默认起点。场景二复杂认证需求 → Devise 或其他成熟认证系统当需求包含OAuth、MFA、confirmable/lockable 流程、多模型认证或已有大规模 Devise 使用痕迹时使用 Devise 或其它成熟认证系统。具体触发条件包括需求说明OAuth第三方登录Google、GitHub 等MFA多因素认证TOTP、短信等confirmable / lockable邮箱确认、账号锁定防暴力破解多模型认证Admin 与 User 等多模型分别认证既有 Devise 足迹团队或组织已有成熟的 Devise 定制经验这与 security.md 的认证章节完全同源且 security 规则补充了配套要求登录及权限变更后轮换会话、账户恢复流程使用带过期时间的单次令牌 限流 审计日志。七、规则体系的配套延伸本文档并非孤立存在它与 Ruby 规则集的其他文件形成完整闭环rules/ruby/coding-style.mdRuby 3.3 运行时目标、YJIT 启用前提先度量启动时间、内存与吞吐再开、# frozen_string_literal: true约定、RuboCop 配置Rails 8 从rubocop-rails-omakase起步rules/ruby/testing.mdMinitest/RSpec 二选一不混用、测试金字塔模型/服务测试 → 请求测试 → Capybara 系统测试、fixtures 与 factory_bot 的选用rules/ruby/security.mdCSRF 保持开启、强参数防批量赋值、凭据管理、bundle-audit/brakeman依赖检查skills/backend-patterns/SKILL.md本文档参考章节指向的服务边界与适配器模式深度参考涵盖 Repository 模式、Service Layer、Middleware、缓存策略Cache-Aside、错误处理指数退避重试、限流必须使用 Redis 等共享存储禁止进程内计数器等通用实现模式。规则与技能的分工正如 rules/README.md 所述Rules 告诉你做什么whatSkills 告诉你怎么做how。八、落地实践如何将本文规则应用到项目1. 通过 ECC 安装脚本安装 Ruby 规则集./install.sh ruby # 或与其他语言规则集组合安装 ./install.sh ruby typescript python2. 手动安装保留目录结构重要提示必须复制整个目录切勿用/*拍平。公共层与语言层存在同名文件如patterns.md拍平会导致语言专属文件覆盖公共规则并破坏../common/相对引用。mkdir -p ~/.claude/rules/ecc cp -r rules/common ~/.claude/rules/ecc/ cp -r rules/ruby ~/.claude/rules/ecc/项目级规则同理复制到项目根目录的.claude/rules/ecc/下。3. 用规则做架构评审清单当你评审一个 Rails 8 项目或为 Agent 编写 Ruby 代码任务时可以逐条对照本文作为检查清单分层是否过度/不足中小功能是否仍保持 Rails MVC 原味抽象是否仅在职责过载时引入对象命名Service/Query 对象是否以业务操作命名OrderCheckout而非OrderManager持久化多主机是否选了 PostgreSQL原始 SQL 是否封装且参数化后台任务绿地应用是否默认 Solid Queue需要 Redis 生态时才上 Sidekiq前端服务端渲染是否优先 Hotwire模板里有没有混入持久化/鉴权认证简单会话用 Rails 8 生成器OAuth/MFA 等多模型需求才用 Devise这套清单既是代码评审的抓手也是 Agent 在 Ruby 文件*.rb、*.rake、Gemfile、*.erb、config/routes.rb上自动激活的上下文规则确保 AI 辅助开发与人工评审遵循同一套架构标准。结语ECC 的 Ruby 模式规则提供了一个极具操作性的工程哲学默认相信框架约定抽象必须由真实复杂度驱动选型以部署模型与运维现实为准绳。从 Rails Way First 到 Solid Queue/Sidekiq、Hotwire/SPA、Rails 8 认证/Devise 的三组决策边界本质上都在回答同一个问题——当前应用的复杂度与部署现实配得上什么样的架构 将这套规则固化进 Agent 的路径触发条件frontmatter 中的paths即可让每一次 Ruby 代码生成与评审都自动对齐团队的最佳实践。【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 ECC Ruby/Rails 架构模式指南：从 Rails Way 到 Solid Queue、Hotwire 与认证选型的工程决策手册
ECC Ruby/Rails 架构模式指南从 Rails Way 到 Solid Queue、Hotwire 与认证选型的工程决策手册【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC导读本文基于 ECC 仓库中 Ruby 语言规则集的核心文件 patterns.md系统讲解在 Ruby on Rails 项目中如何做出可持续的架构决策从先用 Rails Way的分层演进原则到持久化选型PostgreSQL 与 Rails 8 SQLite 默认值、后台任务Solid Queue 与 Sidekiq、前端方案Hotwire 与 SPA以及认证体系Rails 8 认证生成器与 Devise的取舍标准。读完本文你将获得一套可直接用于 Rails 8 项目评审与架构设计的决策框架并理解 ECC 如何通过公共规则 语言专属规则的分层结构把这些工程准则落地为 Agent 可执行的规范。一、规则定位Ruby 专属层如何扩展公共模式在 ECC 的规则体系中rules/目录采用公共层 语言层的分层结构见 rules/README.mdrules/ ├── common/ # 语言无关的通用原则总是安装 │ └── patterns.md # 骨架项目、仓库模式、API 响应格式等 └── ruby/ # Ruby / Rails 专属 ├── coding-style.md ├── patterns.md # 本文主体 ├── hooks.md ├── security.md └── testing.mdpatterns.md 的文件头明确声明This file extends common/patterns.md with Ruby and Rails specific content.也就是说通用模式如 Repository 模式、API 响应信封格式在 common/patterns.md 中定义而 Ruby 层只补充 Rails 语境下特有的架构决策点。规则优先级上语言专属规则优先于公共规则类似于 CSS 特指度或.gitignore优先级因此 Ruby 团队在架构评审时以本文为最高优先依据。该文件通过 YAML frontmatter 声明其生效范围Agent 在以下文件上会自动激活这套规则paths: - **/*.rb - **/*.rake - **/Gemfile - **/app/**/*.erb - **/config/routes.rb二、Rails Way First从约定俗成到有节制地抽象规则的第一条铁律是先走 Rails WayRails Way First它包含三个递进的原则1. 中小功能先用纯 Rails MVC 与 Active Record 约定对中小规模功能不急于引入任何自定义架构层。控制器处理请求、模型处理领域逻辑、Active Record 处理持久化这是 Rails 生态被验证过的最短路径也符合 coding-style.md 中先遵循 Rails 命名与目录约定再考虑自定义结构的要求。2. 分层抽象的唯一触发条件职责过载只有当模型/控制器边界承载了多重职责时才引入以下对象对象类型典型职责Service Object跨模型的业务流程编排如订单结算、导入导出Query Object复杂查询条件封装替代控制器内散落的 where 链Form Object多模型表单校验与参数收集Decorator / Presenter视图层展示逻辑封装这条规则的本质是按需抽象而非默认仪式——这与 coding-style.md 中的表述完全一致Put reusable domain behavior in models, concerns, service objects, query objects, or form objects based on actual complexity, not as default ceremony.3. 命名要反映业务操作而非通用层名提取出的对象必须按其所执行的业务操作命名严禁使用Manager、Processor这类泛化层名。例如# 不推荐无法传达业务语义 class OrderManager def process; end end # 推荐直接表达业务操作 class OrderCheckout def call(order, payment_params); end end class InvoiceGenerator def call(order); end end这种命名约束的价值在于类名即文档评审代码时一眼就能看出该对象承担的具体业务职责避免出现一个什么都做的上帝 Manager。三、持久化选型PostgreSQL 优先与 Rails 8 SQLite 默认值的边界1. 多主机生产环境优先 PostgreSQL对于多主机multi-host生产 Rails 应用除非现有平台有明确理由使用 MySQL 或 SQLite否则优先 PostgreSQL。理由包括PostgreSQL 的事务、索引能力、JSON 支持以及与 Rails 生态如全文搜索、几何类型的深度整合。2. Rails 8 的 SQLite 默认值适用边界Rails 8 将 SQLite 设为默认数据库规则对此给出了清醒的边界判断Rails 8 的 SQLite 默认配置适合单主机或小规模部署但不会自动适配共享多服务系统。这意味着若你的应用是单体小部署、并发写入压力不大SQLite 的开箱即用体验极具吸引力但一旦涉及多服务共享数据库、高并发写入或集群部署就必须迁移到 PostgreSQL 这类服务端数据库。3. 原始 SQL 的封装纪律规则要求所有原始 SQL 都必须放在查询对象Query Object或模型作用域model scope背后且所有动态值必须参数化。# 推荐封装在模型 scope 中动态值参数化 class Order ApplicationRecord scope :paid_since, -(since) { where(paid_at ?, since) # 参数化杜绝字符串拼接 } end # 推荐复杂查询封装为 Query Object class MonthlyRevenueQuery def initialize(relation Order.all) relation relation end def call(year:, month:) relation .where(status: :paid) .where(paid_at ? AND paid_at ?, Date.new(year, month), Date.new(year, month).next_month) .sum(:amount_cents) end end这条纪律与 security.md 中绝不将请求、Cookie、Header、Job 或 Webhook 值插值进 SQL 字符串的硬性要求互为表里是防 SQL 注入的第一道防线。四、后台任务与运行时服务Solid Queue 与 Sidekiq 的取舍规则给出了清晰的二选一决策树Solid Queue —— 绿地 Rails 8 项目的默认选择对于吞吐量适中、部署要求简单的绿地 Rails 8 应用使用Solid Queue。Solid Queue 是 Rails 8 自带的数据库驱动后台任务系统其核心优势是无需额外基础设施——直接复用应用数据库部署模型与 Rails 应用完全一致符合简单部署的诉求。Sidekiq —— 需要成熟能力时的升级路径当应用需要成熟的可观测性、高吞吐量、已有 Redis 基础设施或Pro/Enterprise 功能时使用Sidekiq。Sidekiq 基于 Redis 的架构决定了它适合以下场景需要成熟的监控、重试统计、批量任务等 Pro/Enterprise 能力已经运维 Redis不希望再引入新的存储组件任务吞吐量高需要独立于主数据库的任务队列。缓存与实时通道Solid Cache / Solid Cable vs Redis类似的决策逻辑也适用于缓存与 WebSocket组件适用条件Solid Cache / Solid Cable其部署模型数据库驱动、与应用同构与当前应用匹配时Redis需要共享跨服务行为、高扇出high fanout、高级数据结构时核心判据是部署模型是否匹配如果你的应用是多服务共享 Redis 的体系单独为 Rails 应用引入数据库驱动缓存反而割裂了基础设施反之简单单体应用用 Redis 则引入了不必要的运维负担。五、前端策略Hotwire 优先SPA 按需引入1. 服务端渲染优先 Hotwire对于服务端渲染的 Rails 应用规则明确推荐Hotwire全家桶TurboTurbo Drive 加速页面导航Turbo Frames 局部更新Turbo Streams 通过 WebSocket 推送增量 DOM 变更Stimulus轻量级 JavaScript 框架为 HTML 添加渐进增强行为Importmap无 Node 构建步骤的 JavaScript 依赖管理PropshaftRails 8 默认的资产管道替代 Sprockets。这四件套让 Rails 团队无需引入独立前端构建链即可获得接近 SPA 的交互体验与 Rails 的约定优于配置哲学一脉相承。2. 何时引入 React / Vue / Inertia.js / 独立 SPA规则给出三个引入客户端前端的正当理由交互复杂度页面存在复杂的状态管理、拖拽、实时协作等高交互需求既有产品架构公司已有成熟的 React/Vue 前端体系与组件库团队所有权前端团队独立维护前端代码库。3. 视图层的职责边界规则对视图层提出明确约束视图组件View Component、局部模板partial、Presenter 只负责渲染决策持久化与授权逻辑严禁进入模板。%# 错误示范模板内直接操作持久化与鉴权 % % if current_user.can?(:admin) User.dangerous_operation!(current_user) % ... % end % %# 正确示范模板只做渲染判断 % % if render_admin_panel? % % render AdminPanelComponent.new(user: current_user) % % end %这条规则保证了模板的可测试性与安全性与 security.md 中转义模板输出、将html_safe/raw视为安全敏感代码的要求配套。六、认证方案Rails 8 生成器与 Devise 的边界认证选型同样遵循简单优先复杂再升级的原则场景一简单会话认证 → Rails 8 认证生成器对简单的会话认证与密码重置需求使用Rails 8 认证生成器。Rails 8 内置的认证生成器bin/rails generate authentication会生成基于会话的认证、密码重置所需的最小代码集无额外 Gem 依赖代码完全透明可控适合新项目的默认起点。场景二复杂认证需求 → Devise 或其他成熟认证系统当需求包含OAuth、MFA、confirmable/lockable 流程、多模型认证或已有大规模 Devise 使用痕迹时使用 Devise 或其它成熟认证系统。具体触发条件包括需求说明OAuth第三方登录Google、GitHub 等MFA多因素认证TOTP、短信等confirmable / lockable邮箱确认、账号锁定防暴力破解多模型认证Admin 与 User 等多模型分别认证既有 Devise 足迹团队或组织已有成熟的 Devise 定制经验这与 security.md 的认证章节完全同源且 security 规则补充了配套要求登录及权限变更后轮换会话、账户恢复流程使用带过期时间的单次令牌 限流 审计日志。七、规则体系的配套延伸本文档并非孤立存在它与 Ruby 规则集的其他文件形成完整闭环rules/ruby/coding-style.mdRuby 3.3 运行时目标、YJIT 启用前提先度量启动时间、内存与吞吐再开、# frozen_string_literal: true约定、RuboCop 配置Rails 8 从rubocop-rails-omakase起步rules/ruby/testing.mdMinitest/RSpec 二选一不混用、测试金字塔模型/服务测试 → 请求测试 → Capybara 系统测试、fixtures 与 factory_bot 的选用rules/ruby/security.mdCSRF 保持开启、强参数防批量赋值、凭据管理、bundle-audit/brakeman依赖检查skills/backend-patterns/SKILL.md本文档参考章节指向的服务边界与适配器模式深度参考涵盖 Repository 模式、Service Layer、Middleware、缓存策略Cache-Aside、错误处理指数退避重试、限流必须使用 Redis 等共享存储禁止进程内计数器等通用实现模式。规则与技能的分工正如 rules/README.md 所述Rules 告诉你做什么whatSkills 告诉你怎么做how。八、落地实践如何将本文规则应用到项目1. 通过 ECC 安装脚本安装 Ruby 规则集./install.sh ruby # 或与其他语言规则集组合安装 ./install.sh ruby typescript python2. 手动安装保留目录结构重要提示必须复制整个目录切勿用/*拍平。公共层与语言层存在同名文件如patterns.md拍平会导致语言专属文件覆盖公共规则并破坏../common/相对引用。mkdir -p ~/.claude/rules/ecc cp -r rules/common ~/.claude/rules/ecc/ cp -r rules/ruby ~/.claude/rules/ecc/项目级规则同理复制到项目根目录的.claude/rules/ecc/下。3. 用规则做架构评审清单当你评审一个 Rails 8 项目或为 Agent 编写 Ruby 代码任务时可以逐条对照本文作为检查清单分层是否过度/不足中小功能是否仍保持 Rails MVC 原味抽象是否仅在职责过载时引入对象命名Service/Query 对象是否以业务操作命名OrderCheckout而非OrderManager持久化多主机是否选了 PostgreSQL原始 SQL 是否封装且参数化后台任务绿地应用是否默认 Solid Queue需要 Redis 生态时才上 Sidekiq前端服务端渲染是否优先 Hotwire模板里有没有混入持久化/鉴权认证简单会话用 Rails 8 生成器OAuth/MFA 等多模型需求才用 Devise这套清单既是代码评审的抓手也是 Agent 在 Ruby 文件*.rb、*.rake、Gemfile、*.erb、config/routes.rb上自动激活的上下文规则确保 AI 辅助开发与人工评审遵循同一套架构标准。结语ECC 的 Ruby 模式规则提供了一个极具操作性的工程哲学默认相信框架约定抽象必须由真实复杂度驱动选型以部署模型与运维现实为准绳。从 Rails Way First 到 Solid Queue/Sidekiq、Hotwire/SPA、Rails 8 认证/Devise 的三组决策边界本质上都在回答同一个问题——当前应用的复杂度与部署现实配得上什么样的架构 将这套规则固化进 Agent 的路径触发条件frontmatter 中的paths即可让每一次 Ruby 代码生成与评审都自动对齐团队的最佳实践。【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考