Cal.diy 领域知识库深度解读Managed Event Types、组织层级与 OAuth 客户端等核心数据模型实战指南【免费下载链接】cal.diyScheduling infrastructure for absolutely everyone.项目地址: https://gitcode.com/GitHub_Trending/ca/cal.diy本指南以 Cal.diy 仓库中面向开发者的领域知识文档 agents/knowledge-base.md 为主线系统讲解其产品与代码库层面的关键领域约定托管事件类型Managed Event Types的父子结构与可预订规则、组织与团队在数据表层面的存储差异、两类 OAuth 客户端的区分方式、本地开发数据库账号、日志级别以及一批高频功能的源码落点轮询调度、日历缓存、DataTable、API 文档生成、Workflow 与 Webhook 的边界。阅读后可快速建立领域概念 → Prisma 数据模型 → 源码目录的三级映射避免在跨模块开发中误用概念、找错文件。一、托管事件类型一张表里的父与子核心规则每当创建一个托管事件类型Managed Event Type时系统会同时写入两类行——面向团队的父托管事件类型在EventType表中带有teamId以及面向每个被分配用户的子托管事件类型在EventType表中带有userId。例如为团队创建托管事件类型并分派给 Alice 与 Bob 两人则会在EventType表中插入 3 行1 个父 2 个子。最重要的约束只有子托管事件类型可以被实际预订。从 packages/prisma/schema.prisma 中EventType模型的字段定义可以印证这一设计model EventType { id Int id default(autoincrement()) title String slug String // ... team Team? relation(fields: [teamId], references: [id], onDelete: Cascade) teamId Int? owner User? relation(owner, fields: [userId], references: [id], onDelete: Cascade) userId Int? // 父子关系managed eventtype parentId Int? parent EventType? relation(managed_eventtype, fields: [parentId], references: [id], onDelete: Cascade) children EventType[] relation(managed_eventtype) // ... unique([userId, parentId]) index([parentId]) index([parentId, teamId]) }parent/children通过名为managed_eventtype的 Prisma 自关联self-relation建立一个父节点可以级联出多个子节点teamId与userId同时可选nullable分别标识父与子两种角色归属unique([userId, parentId])保证同一个用户在同一父事件类型下只能有一个子记录避免重复分派index([parentId, teamId])则服务于按团队查询其全部托管事件类型的高频场景。开发者在实现托管事件类型相关能力如批量同步、权限校验、预订逻辑时应始终以子记录可被预订、父记录仅作为模板与分派依据为前提设计查询与写操作例如从parentId出发展开子记录后预订流程必须落在带userId的行上。二、组织与团队共用一个Team表知识库强调了一个容易混淆的事实组织和团队都存储在Team表中区分方式是字段取值而非表名组织OrganizationisOrganization字段为true组织内的团队Team within an organization带有parentId其值指向所属组织的Team行。在 schema.prisma 中可找到完整佐证。Team模型包含isOrganization Boolean default(false)字段以及指向自身的组织关联model Team { id Int id default(autoincrement()) name String // ... isOrganization Boolean default(false) parentId Int? parent Team? relation(organization, fields: [parentId], references: [id], onDelete: Cascade) children Team[] relation(organization) // 代码注释if a Team has parentId it is a team, // if parentId is null it is an organization ... unique([slug, parentId]) index([parentId]) }schema 中的注释还补充了一个边界情况如果parentId为 null 但它同时带有managedOrganization关联则说明该组织是由另一个组织管理的组织。由此可以归纳判断矩阵场景isOrganizationparentId组织true通常为null或关联到上级管理组织组织内的团队false指向所属组织普通独立团队falsenull查询某个组织下的所有团队时正确做法是按parentId 组织ID过滤Team表而不是去别的表寻找团队数据。三、两类 OAuth 客户端别把两者混为一谈代码库中并存两类 OAuth 客户端它们在 Prisma schema 中是两张不同的表、服务对象也完全不同类型数据表用途OAuth clientOAuthClient允许第三方应用连接用户的 Cal.com 账户Platform OAuth clientPlatformOAuthClient供平台客户把 Cal.com 排期能力直接集成进他们自己的平台一句话记忆当有人说 platform OAuth client指的一定是PlatformOAuthClient表中的记录而不是OAuthClient。两表的字段差异同样印证其定位差异。见 schema.prisma 中的OAuthClientmodel OAuthClient { clientId String id unique redirectUri String clientSecret String? clientType OAuthClientType default(CONFIDENTIAL) name String isTrusted Boolean default(false) status OAuthClientStatus default(APPROVED) userId Int? // 归属某个用户 user User? relation(fields: [userId], references: [id], onDelete: SetNull) accessCodes AccessCode[] // ... }而PlatformOAuthClientschema.prisma面向的是组织级平台客户结构明显更平台化model PlatformOAuthClient { id String id default(cuid()) name String secret String permissions Int redirectUris String[] organizationId Int // 归属某个组织Team organization Team relation(fields: [organizationId], references: [id], onDelete: Cascade) users User[] teams Team[] relation(CreatedByOAuthClient) accessTokens AccessToken[] refreshToken RefreshToken[] authorizationTokens PlatformAuthorizationToken[] bookingRedirectUri String? areEmailsEnabled Boolean default(false) // ... }可见传统 OAuth client 隶属于单个用户userId用于授权第三方 App 访问该用户的账户而 Platform OAuth client 隶属于组织organizationId直接管理一批用户与团队并带有bookingRedirectUri、areEmailsEnabled等与平台化排期集成相关的配置项。开发涉及 OAuth 的模块前务必先确认业务目标属于哪一种再选择对应数据表与实现链路避免误用PlatformOAuthClient的 token 流程去处理个人账户授权。四、本地开发数据库与测试账号仓库整体是一个 monorepo主 Web 应用位于apps/web目录后续 UI 落点均以它为根。初始化本地开发数据库时会顺带创建一组测试用户密码与用户名相同见 scripts/seed.ts 中 seed 数据的真实写入例如username: pro/password: pro与username: free/password: freefree:free—— 对应免费版示例用户pro:pro—— 对应 Pro 版示例用户这组账号常用于本地联调登录、事件类型创建、预订流程手工验证等场景。需要指出的是scripts/seed.ts承担了用户、团队、组织与事件类型等大量初始化数据具体账号是否存在还取决于实际 seed 配置建议以本地yarn db:seed或仓库 deploy 文档中说明的初始化方式执行后的结果为准。五、日志级别通过环境变量控制输出详细度知识库给出了日志冗长度的控制方式在.env中设置NEXT_PUBLIC_LOGGER_LEVEL取值与级别对应如下值级别0silly1trace2debug3info4warn5error6fatal源码层面的实现可参见 packages/lib/logger.ts其中 minLevel 的读取逻辑为export const loggerConfig: ISettingsParamunknown { minLevel: parseInt(process.env.NEXT_PUBLIC_LOGGER_LEVEL || 4), maskValuesOfKeys: [password, passwordConfirmation, credentials, credential], // ... };两点实现事实值得注意其一NEXT_PUBLIC_前缀意味着该变量会被打包进前端产物因而适合在前端与 Node 侧统一读取其二代码默认值取4即未显式配置时默认最低记录级别为warn需要更详细的 debug/silly 日志时必须显式调低该值。此外maskValuesOfKeys会对password、credentials等敏感键做脱敏排查问题时请勿因关闭脱敏而引入凭据泄露风险。六、Google Calendar 中的 Cal.diy 事件识别在处理外部日历同步数据时可以用事件标识规则区分哪些记录来自 Cal.diy如果事件的 iCalUID 以Cal.diy结尾即视为 Cal.diy 预订产生的事件。示例2GBXSdEixretciJfKVmYN8Cal.diy该标识被用于在数据存储与隐私处理层面将 Cal.diy 的预订与其他日历事件区分开。实现涉及日历同步/解析的模块例如基于 iCal 的解析、外部日历写入回读的去重时应按此约定匹配并过滤避免把第三方日历事件误当作 Cal.diy 预订处理。七、UI 关键组件落点与对齐规范知识库为常见页面明确了源码位置事件类型列表页apps/web/modules/event-types/views/event-types-listing-view.tsx预订管理页apps/web/modules/bookings/views/bookings-view.tsx同时给出了一条 UI 一致性要求跨页面共享的元素页签 tabs、搜索栏、筛选按钮应保持对齐方式一致。这意味着在事件类型页与预订页开发新功能时应优先复用既有共享组件如各 view 目录公共的筛选区而不是各自新造一套布局。八、DataTable统一参考GUIDE.md凡是涉及表格展示尤其是事件类型、预订等后台列表的实现都应参考 DataTable 的官方实现规范packages/features/data-table/GUIDE.md。该文档提供了列定义、排序、筛选、分页等实现模式与最佳实践。先阅读 GUIDE 再动手能保证新表格与现有列表交互一致并减少重复造轮子。九、Round-Robin 轮询调度优先复用getLuckyUser实现轮询Round-Robin、权重分配、优先级排序这类从一组可用成员里选人的逻辑时知识库明确要求优先复用现有代码而不是新写一套。相关实现集中在packages/features/bookings/lib/getLuckyUser.ts该文件承载了以下能力基于权重的选择weight-based selection优先级排序priority ranking轮询公平性算法round-robin fairness algorithms工程建议新需求先审查getLuckyUser及其调用方是否已覆盖场景如需扩展优先在既有函数上增加参数或扩展分支保持团队内同一调度语义只有一个实现的约束。十、日历缓存系统Provider 代码放对目录日历缓存系统calendar cache system在代码库中遵循固定的组织模式实现时注意两点通用/数据库侧的模式与工具位于packages/features/calendar-cache-sql包括缓存表结构、读写约定等Provider 专属的缓存服务实现必须放进对应的 provider 目录。例如 Outlook / Office 365 的日历缓存服务代码应放在 packages/app-store/office365calendar 目录内而不是散落在通用缓存目录里。这一约定让通用缓存机制与各家日历服务的差异逻辑解耦也便于后续为其他 providerGoogle、Apple 等补充各自的缓存适配实现时按目录对号入座。十一、API 文档OpenAPI 由 NestJS 控制器自动生成平台 V2 API 的 OpenAPI 规范文件位于 docs/api-reference/v2/openapi.json但它是从 NestJS 控制器自动生成的产物手工编辑会被后续生成流程覆盖。因此要持久化地修改 API 文档正确姿势是在控制器源码中通过 NestJS 装饰器声明元数据使用ApiQuery、ApiOperation等装饰器描述接口行为、参数与说明控制器位于apps/api/v2/src/modules/*/controllers/*.controller.ts各业务模块按子目录组织例如 bookings、event-types 等模块的 controller 目录。流程上形成闭环改控制器装饰器 → 重新运行文档生成 →openapi.json更新。任何直接改 json的做法都属于临时改动必须避免。这一约束同样适用于 API 消费者想了解接口的真实定义应以生成后的openapi.json或在线文档为准同时理解它反映的是当前控制器代码的实时状态。十二、Workflows 与 Webhooks两个完全独立的系统这是一个高频踩坑点Cal.diy 中的 Workflows工作流与 Webhooks网络钩子是两个完全独立的功能实现与文件结构互不相同切勿混用。Workflow 相关常量定义在 packages/features/ee/workflows/lib/constants.ts不在 webhooks 目录下开发 workflow 触发逻辑时不要参考或复用 webhook 的触发实现——两者是各自独立的系统。从功能语义看Workflow 主要用于预订生命周期内的通知/自动化动作如邮件、短信提醒等Webhook 则用于把事件推送给外部服务。领域知识库特别强调在代码组织与实现层面将二者视为完全分离的子系统是避免逻辑串扰、保证各自演进边界清晰的重要工程约束。十三、总结把领域知识落成开发前 checklist综合全文agents/knowledge-base.md本质上是 Cal.diy 仓库的领域词典 代码地图。在动手开发前可将其中的结论沉淀为快速自查清单涉及托管事件类型父行带teamId、子行带userId只有子行可被预订先确认操作目标是父还是子涉及组织/团队归属都查Team表用isOrganization与parentId判断层级涉及 OAuth先分清是OAuthClient个人账户第三方授权还是PlatformOAuthClient组织级平台集成涉及排期选中人优先看 packages/features/bookings/lib/getLuckyUser.ts涉及表格 UI先读 packages/features/data-table/GUIDE.md涉及 API 文档只改 NestJS 控制器装饰器不动openapi.json涉及触发器Workflows 与 Webhooks 是两套系统各查各的目录。把这套映射关系内化之后无论是跨模块排障、扩展既有能力还是实现新功能都能以更少的探索成本直接命中正确的数据表与源码位置。【免费下载链接】cal.diyScheduling infrastructure for absolutely everyone.项目地址: https://gitcode.com/GitHub_Trending/ca/cal.diy创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Cal.diy 领域知识库深度解读：Managed Event Types、组织层级与 OAuth 客户端等核心数据模型实战指南
Cal.diy 领域知识库深度解读Managed Event Types、组织层级与 OAuth 客户端等核心数据模型实战指南【免费下载链接】cal.diyScheduling infrastructure for absolutely everyone.项目地址: https://gitcode.com/GitHub_Trending/ca/cal.diy本指南以 Cal.diy 仓库中面向开发者的领域知识文档 agents/knowledge-base.md 为主线系统讲解其产品与代码库层面的关键领域约定托管事件类型Managed Event Types的父子结构与可预订规则、组织与团队在数据表层面的存储差异、两类 OAuth 客户端的区分方式、本地开发数据库账号、日志级别以及一批高频功能的源码落点轮询调度、日历缓存、DataTable、API 文档生成、Workflow 与 Webhook 的边界。阅读后可快速建立领域概念 → Prisma 数据模型 → 源码目录的三级映射避免在跨模块开发中误用概念、找错文件。一、托管事件类型一张表里的父与子核心规则每当创建一个托管事件类型Managed Event Type时系统会同时写入两类行——面向团队的父托管事件类型在EventType表中带有teamId以及面向每个被分配用户的子托管事件类型在EventType表中带有userId。例如为团队创建托管事件类型并分派给 Alice 与 Bob 两人则会在EventType表中插入 3 行1 个父 2 个子。最重要的约束只有子托管事件类型可以被实际预订。从 packages/prisma/schema.prisma 中EventType模型的字段定义可以印证这一设计model EventType { id Int id default(autoincrement()) title String slug String // ... team Team? relation(fields: [teamId], references: [id], onDelete: Cascade) teamId Int? owner User? relation(owner, fields: [userId], references: [id], onDelete: Cascade) userId Int? // 父子关系managed eventtype parentId Int? parent EventType? relation(managed_eventtype, fields: [parentId], references: [id], onDelete: Cascade) children EventType[] relation(managed_eventtype) // ... unique([userId, parentId]) index([parentId]) index([parentId, teamId]) }parent/children通过名为managed_eventtype的 Prisma 自关联self-relation建立一个父节点可以级联出多个子节点teamId与userId同时可选nullable分别标识父与子两种角色归属unique([userId, parentId])保证同一个用户在同一父事件类型下只能有一个子记录避免重复分派index([parentId, teamId])则服务于按团队查询其全部托管事件类型的高频场景。开发者在实现托管事件类型相关能力如批量同步、权限校验、预订逻辑时应始终以子记录可被预订、父记录仅作为模板与分派依据为前提设计查询与写操作例如从parentId出发展开子记录后预订流程必须落在带userId的行上。二、组织与团队共用一个Team表知识库强调了一个容易混淆的事实组织和团队都存储在Team表中区分方式是字段取值而非表名组织OrganizationisOrganization字段为true组织内的团队Team within an organization带有parentId其值指向所属组织的Team行。在 schema.prisma 中可找到完整佐证。Team模型包含isOrganization Boolean default(false)字段以及指向自身的组织关联model Team { id Int id default(autoincrement()) name String // ... isOrganization Boolean default(false) parentId Int? parent Team? relation(organization, fields: [parentId], references: [id], onDelete: Cascade) children Team[] relation(organization) // 代码注释if a Team has parentId it is a team, // if parentId is null it is an organization ... unique([slug, parentId]) index([parentId]) }schema 中的注释还补充了一个边界情况如果parentId为 null 但它同时带有managedOrganization关联则说明该组织是由另一个组织管理的组织。由此可以归纳判断矩阵场景isOrganizationparentId组织true通常为null或关联到上级管理组织组织内的团队false指向所属组织普通独立团队falsenull查询某个组织下的所有团队时正确做法是按parentId 组织ID过滤Team表而不是去别的表寻找团队数据。三、两类 OAuth 客户端别把两者混为一谈代码库中并存两类 OAuth 客户端它们在 Prisma schema 中是两张不同的表、服务对象也完全不同类型数据表用途OAuth clientOAuthClient允许第三方应用连接用户的 Cal.com 账户Platform OAuth clientPlatformOAuthClient供平台客户把 Cal.com 排期能力直接集成进他们自己的平台一句话记忆当有人说 platform OAuth client指的一定是PlatformOAuthClient表中的记录而不是OAuthClient。两表的字段差异同样印证其定位差异。见 schema.prisma 中的OAuthClientmodel OAuthClient { clientId String id unique redirectUri String clientSecret String? clientType OAuthClientType default(CONFIDENTIAL) name String isTrusted Boolean default(false) status OAuthClientStatus default(APPROVED) userId Int? // 归属某个用户 user User? relation(fields: [userId], references: [id], onDelete: SetNull) accessCodes AccessCode[] // ... }而PlatformOAuthClientschema.prisma面向的是组织级平台客户结构明显更平台化model PlatformOAuthClient { id String id default(cuid()) name String secret String permissions Int redirectUris String[] organizationId Int // 归属某个组织Team organization Team relation(fields: [organizationId], references: [id], onDelete: Cascade) users User[] teams Team[] relation(CreatedByOAuthClient) accessTokens AccessToken[] refreshToken RefreshToken[] authorizationTokens PlatformAuthorizationToken[] bookingRedirectUri String? areEmailsEnabled Boolean default(false) // ... }可见传统 OAuth client 隶属于单个用户userId用于授权第三方 App 访问该用户的账户而 Platform OAuth client 隶属于组织organizationId直接管理一批用户与团队并带有bookingRedirectUri、areEmailsEnabled等与平台化排期集成相关的配置项。开发涉及 OAuth 的模块前务必先确认业务目标属于哪一种再选择对应数据表与实现链路避免误用PlatformOAuthClient的 token 流程去处理个人账户授权。四、本地开发数据库与测试账号仓库整体是一个 monorepo主 Web 应用位于apps/web目录后续 UI 落点均以它为根。初始化本地开发数据库时会顺带创建一组测试用户密码与用户名相同见 scripts/seed.ts 中 seed 数据的真实写入例如username: pro/password: pro与username: free/password: freefree:free—— 对应免费版示例用户pro:pro—— 对应 Pro 版示例用户这组账号常用于本地联调登录、事件类型创建、预订流程手工验证等场景。需要指出的是scripts/seed.ts承担了用户、团队、组织与事件类型等大量初始化数据具体账号是否存在还取决于实际 seed 配置建议以本地yarn db:seed或仓库 deploy 文档中说明的初始化方式执行后的结果为准。五、日志级别通过环境变量控制输出详细度知识库给出了日志冗长度的控制方式在.env中设置NEXT_PUBLIC_LOGGER_LEVEL取值与级别对应如下值级别0silly1trace2debug3info4warn5error6fatal源码层面的实现可参见 packages/lib/logger.ts其中 minLevel 的读取逻辑为export const loggerConfig: ISettingsParamunknown { minLevel: parseInt(process.env.NEXT_PUBLIC_LOGGER_LEVEL || 4), maskValuesOfKeys: [password, passwordConfirmation, credentials, credential], // ... };两点实现事实值得注意其一NEXT_PUBLIC_前缀意味着该变量会被打包进前端产物因而适合在前端与 Node 侧统一读取其二代码默认值取4即未显式配置时默认最低记录级别为warn需要更详细的 debug/silly 日志时必须显式调低该值。此外maskValuesOfKeys会对password、credentials等敏感键做脱敏排查问题时请勿因关闭脱敏而引入凭据泄露风险。六、Google Calendar 中的 Cal.diy 事件识别在处理外部日历同步数据时可以用事件标识规则区分哪些记录来自 Cal.diy如果事件的 iCalUID 以Cal.diy结尾即视为 Cal.diy 预订产生的事件。示例2GBXSdEixretciJfKVmYN8Cal.diy该标识被用于在数据存储与隐私处理层面将 Cal.diy 的预订与其他日历事件区分开。实现涉及日历同步/解析的模块例如基于 iCal 的解析、外部日历写入回读的去重时应按此约定匹配并过滤避免把第三方日历事件误当作 Cal.diy 预订处理。七、UI 关键组件落点与对齐规范知识库为常见页面明确了源码位置事件类型列表页apps/web/modules/event-types/views/event-types-listing-view.tsx预订管理页apps/web/modules/bookings/views/bookings-view.tsx同时给出了一条 UI 一致性要求跨页面共享的元素页签 tabs、搜索栏、筛选按钮应保持对齐方式一致。这意味着在事件类型页与预订页开发新功能时应优先复用既有共享组件如各 view 目录公共的筛选区而不是各自新造一套布局。八、DataTable统一参考GUIDE.md凡是涉及表格展示尤其是事件类型、预订等后台列表的实现都应参考 DataTable 的官方实现规范packages/features/data-table/GUIDE.md。该文档提供了列定义、排序、筛选、分页等实现模式与最佳实践。先阅读 GUIDE 再动手能保证新表格与现有列表交互一致并减少重复造轮子。九、Round-Robin 轮询调度优先复用getLuckyUser实现轮询Round-Robin、权重分配、优先级排序这类从一组可用成员里选人的逻辑时知识库明确要求优先复用现有代码而不是新写一套。相关实现集中在packages/features/bookings/lib/getLuckyUser.ts该文件承载了以下能力基于权重的选择weight-based selection优先级排序priority ranking轮询公平性算法round-robin fairness algorithms工程建议新需求先审查getLuckyUser及其调用方是否已覆盖场景如需扩展优先在既有函数上增加参数或扩展分支保持团队内同一调度语义只有一个实现的约束。十、日历缓存系统Provider 代码放对目录日历缓存系统calendar cache system在代码库中遵循固定的组织模式实现时注意两点通用/数据库侧的模式与工具位于packages/features/calendar-cache-sql包括缓存表结构、读写约定等Provider 专属的缓存服务实现必须放进对应的 provider 目录。例如 Outlook / Office 365 的日历缓存服务代码应放在 packages/app-store/office365calendar 目录内而不是散落在通用缓存目录里。这一约定让通用缓存机制与各家日历服务的差异逻辑解耦也便于后续为其他 providerGoogle、Apple 等补充各自的缓存适配实现时按目录对号入座。十一、API 文档OpenAPI 由 NestJS 控制器自动生成平台 V2 API 的 OpenAPI 规范文件位于 docs/api-reference/v2/openapi.json但它是从 NestJS 控制器自动生成的产物手工编辑会被后续生成流程覆盖。因此要持久化地修改 API 文档正确姿势是在控制器源码中通过 NestJS 装饰器声明元数据使用ApiQuery、ApiOperation等装饰器描述接口行为、参数与说明控制器位于apps/api/v2/src/modules/*/controllers/*.controller.ts各业务模块按子目录组织例如 bookings、event-types 等模块的 controller 目录。流程上形成闭环改控制器装饰器 → 重新运行文档生成 →openapi.json更新。任何直接改 json的做法都属于临时改动必须避免。这一约束同样适用于 API 消费者想了解接口的真实定义应以生成后的openapi.json或在线文档为准同时理解它反映的是当前控制器代码的实时状态。十二、Workflows 与 Webhooks两个完全独立的系统这是一个高频踩坑点Cal.diy 中的 Workflows工作流与 Webhooks网络钩子是两个完全独立的功能实现与文件结构互不相同切勿混用。Workflow 相关常量定义在 packages/features/ee/workflows/lib/constants.ts不在 webhooks 目录下开发 workflow 触发逻辑时不要参考或复用 webhook 的触发实现——两者是各自独立的系统。从功能语义看Workflow 主要用于预订生命周期内的通知/自动化动作如邮件、短信提醒等Webhook 则用于把事件推送给外部服务。领域知识库特别强调在代码组织与实现层面将二者视为完全分离的子系统是避免逻辑串扰、保证各自演进边界清晰的重要工程约束。十三、总结把领域知识落成开发前 checklist综合全文agents/knowledge-base.md本质上是 Cal.diy 仓库的领域词典 代码地图。在动手开发前可将其中的结论沉淀为快速自查清单涉及托管事件类型父行带teamId、子行带userId只有子行可被预订先确认操作目标是父还是子涉及组织/团队归属都查Team表用isOrganization与parentId判断层级涉及 OAuth先分清是OAuthClient个人账户第三方授权还是PlatformOAuthClient组织级平台集成涉及排期选中人优先看 packages/features/bookings/lib/getLuckyUser.ts涉及表格 UI先读 packages/features/data-table/GUIDE.md涉及 API 文档只改 NestJS 控制器装饰器不动openapi.json涉及触发器Workflows 与 Webhooks 是两套系统各查各的目录。把这套映射关系内化之后无论是跨模块排障、扩展既有能力还是实现新功能都能以更少的探索成本直接命中正确的数据表与源码位置。【免费下载链接】cal.diyScheduling infrastructure for absolutely everyone.项目地址: https://gitcode.com/GitHub_Trending/ca/cal.diy创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
