For AI agents: the complete documentation index is available at https://payhon.github.io/AppKernia/llms.txt, the full documentation bundle is available at https://payhon.github.io/AppKernia/llms-full.txt, and this page is available as Markdown at https://payhon.github.io/AppKernia/community/index.md.
AppKernia

参与社区

AppKernia 想解决的是开发者共同经历的问题，所以它也应该由开发者共同塑造。

你不需要先成为 Go、React、UTS 或鸿蒙专家才有资格参与。一次清楚的问题复现、一处文档修正、一个缺失的错误态、一次真实设备验证，都可能比一段宏大的重构更有价值。

贡献阶梯

从这里开始你可以做什么交付重点
Issue提供最小复现、环境、首个失败命令与期望/实际结果不含凭据，证据可重复
文档修正文案、链接、示例、双语缺口或验证边界zh-CN/en-US 同步，命令真实
测试补单元、Contract、Integration、E2E 或平台回归先证明测试会在旧行为下失败
设备验证在明确 OS、版本、设备上复验 Mobile区分编译、模拟器与真机
代码按契约链修改 Server、Admin、Mobile 或基础设施最小范围、完整测试、无 Secret

一个 PR 的标准路径

  1. 先搜索已有 Issue、Roadmap、ADR 和对应蓝图，确认问题没有被重复解决。
  2. 对行为变化创建或关联 Issue，写清范围、验收条件与不在范围内的事项。
  3. 小步实现；接口改动同步 OpenAPI、数据库/权限（如涉及）、生成 Client 与测试。
  4. 用户可见文案同时维护 zh-CN 和 en-US，UI 改动保存设计决策与截图证据。
  5. 运行受影响项目的 check/build/test，并在 PR 中列出命令、退出码和未验证边界。
  6. 回应 Review 时解释证据和取舍；不要用大规模无关重构掩盖原问题。
第一次贡献如果不知道从哪里开始，可以先提交一个带完整复现的 Issue，或修正一处你刚刚踩过的文档。维护者会帮助把问题归入合适的蓝图和验证层级。

参与前请遵守仓库的 CODE_OF_CONDUCT.md。我们希望这里保持专业、友善，讨论聚焦证据和问题本身。

如果项目的方向对你有帮助，也欢迎在 GitHub 留下 Star。我们不展示虚构数字；每一颗真实的 Star 都会帮助更多正在寻找完整跨端基座的开发者看见它。