Skip to content

Dev#11

Merged
FutureUnreal merged 2 commits intomainfrom
dev
Feb 7, 2026
Merged

Dev#11
FutureUnreal merged 2 commits intomainfrom
dev

Conversation

@FutureUnreal
Copy link
Member

@FutureUnreal FutureUnreal commented Feb 7, 2026

变更说明

关联 Issue / 需求

自测方式

  • 后端:cd backend && uv run uvicorn app.main:app --reload --port 8090
  • 前端:cd frontend && pnpm --filter @whalewhisper/web dev

风险 & 回滚

Checklist

  • 已保证改动聚焦(不混杂无关重构)
  • 已更新相关文档(如 README / 配置示例)
  • 未提交任何密钥/个人信息
  • CI(PR Checks)通过

📝 PR 说明(Codex 自动生成)

  • 变更概览:新增 CONTRIBUTING.md(中英双语),集中说明项目贡献规范与协作流程:分支命名、Conventional Commits、后端/前端代码风格、提交前测试清单,以及 PR / Issue 提交流程与检查项,降低贡献者上手成本并统一协作标准。
  • 影响范围:docs
  • 如何验证
    • 在 GitHub 上预览 CONTRIBUTING.md,确认目录/锚点与中英导航链接可正常跳转、代码块渲染正常。
    • 重点复核文档中的流程约定是否符合当前仓库策略(如 PR 目标分支为 devmain 仅用于发布)。
    • (可选)按文档“测试”章节在本地执行基础检查命令,确认示例可用。
  • 风险点:仅新增文档,风险较低;若指南中示例命令/端口/分支策略与实际项目不一致,可能对贡献者造成误导。

FutureUnreal and others added 2 commits February 8, 2026 00:29
* chore: add comprehensive contributing guide

* Update CONTRIBUTING.md

Co-authored-by: greptile-apps[bot] <165735046+greptile-apps[bot]@users.noreply.github.com>

* Update CONTRIBUTING.md

Co-authored-by: greptile-apps[bot] <165735046+greptile-apps[bot]@users.noreply.github.com>

---------

Co-authored-by: greptile-apps[bot] <165735046+greptile-apps[bot]@users.noreply.github.com>
@github-actions github-actions bot added needs-review Needs careful review (large/complex changes) size/L PR size: < 1000 lines changed labels Feb 7, 2026
@qodo-code-review
Copy link

Review Summary by Qodo

Add comprehensive bilingual contributing guide

📝 Documentation

Grey Divider

Walkthroughs

Description
• Add comprehensive bilingual contributing guide (Chinese/English)
• Document development setup, branch naming, and commit conventions
• Provide code style guidelines for Python backend and TypeScript/Vue frontend
• Include testing procedures, PR workflow, and issue reporting templates
Diagram
flowchart LR
  A["Contributing Guide"] --> B["Chinese Section"]
  A --> C["English Section"]
  B --> D["Setup Instructions"]
  B --> E["Code Style & Testing"]
  B --> F["PR & Issue Templates"]
  C --> D
  C --> E
  C --> F
Loading

Grey Divider

File Changes

1. CONTRIBUTING.md 📝 Documentation +659/-0

Comprehensive bilingual contributing guide with setup and standards

• Created new comprehensive contributing guide with 659 lines of documentation
• Bilingual content: Chinese (中文) and English sections with parallel structure
• Covers project introduction, code of conduct, development setup for backend (Python/FastAPI) and
 frontend (TypeScript/Vue)
• Documents branch naming conventions, commit message format (Conventional Commits), code style
 guidelines, testing procedures
• Includes PR submission workflow, issue reporting templates with examples, and community engagement
 guidelines

CONTRIBUTING.md


Grey Divider

Qodo Logo

@greptile-apps
Copy link
Contributor

greptile-apps bot commented Feb 7, 2026

Greptile Overview

Greptile Summary

Added comprehensive bilingual (Chinese/English) contributing guide covering all essential aspects of the contribution process. The guide includes detailed setup instructions for backend (Python with uv or venv) and frontend (pnpm), branch naming conventions, commit message format following Conventional Commits, code style guidelines for Python (PEP 8) and TypeScript/Vue, testing procedures, and PR workflow requirements.

Key documentation additions:

  • Mandates all PRs target dev branch (not main)
  • Establishes branch naming conventions (feature/, fix/, hotfix/, chore/)
  • Defines commit types and format (feat, fix, chore, refactor, test, docs)
  • Provides code style guidelines with examples
  • Documents testing requirements for both backend and frontend
  • Includes detailed issue reporting templates

Note: This PR itself has an incomplete description (checkboxes not filled) and the title "Dev" doesn't follow the guide's own conventions - should be something like chore: add comprehensive contributing guide

Confidence Score: 5/5

  • This PR is safe to merge - it only adds documentation with no code changes
  • The PR adds a well-structured, comprehensive contributing guide without any code changes, security risks, or breaking changes. The documentation is thorough, bilingual, and provides clear guidelines for contributors. The only meta-issue is that the PR itself doesn't follow its own guidelines (incomplete description, non-descriptive title), but this doesn't affect the safety or quality of the documentation being added.
  • No files require special attention

Important Files Changed

Filename Overview
CONTRIBUTING.md Added comprehensive bilingual contributing guide with setup instructions, branch strategy, commit conventions, code style guidelines, and testing requirements

Sequence Diagram

sequenceDiagram
    participant Contributor
    participant LocalRepo as Local Repository
    participant GitHub
    participant CI as CI/CD Pipeline
    participant Maintainer

    Contributor->>GitHub: Fork/Clone repository
    Contributor->>LocalRepo: git checkout dev
    Contributor->>LocalRepo: git pull origin dev
    Contributor->>LocalRepo: git checkout -b feature/new-feature
    
    Contributor->>LocalRepo: Make code changes
    Contributor->>LocalRepo: Run local tests (backend/frontend)
    
    alt Tests Pass
        Contributor->>LocalRepo: git commit -m "feat: description"
        Contributor->>GitHub: git push origin feature/new-feature
        Contributor->>GitHub: Create PR targeting dev branch
        
        GitHub->>CI: Trigger CI checks
        CI->>CI: Run backend tests
        CI->>CI: Run frontend tests
        CI->>GitHub: Report CI status
        
        alt CI Passes
            GitHub->>Maintainer: Notify for review
            Maintainer->>GitHub: Review code
            
            alt Approved
                Maintainer->>GitHub: Squash and merge to dev
                GitHub->>LocalRepo: Update dev branch
            else Changes Requested
                Maintainer->>Contributor: Request changes
                Contributor->>LocalRepo: Make updates
                Contributor->>GitHub: Push to same branch
            end
        else CI Fails
            GitHub->>Contributor: Notify CI failure
            Contributor->>LocalRepo: Fix issues
        end
    else Tests Fail
        Contributor->>LocalRepo: Fix issues locally
    end
Loading

@qodo-code-review
Copy link

Code Review by Qodo

🐞 Bugs (4) 📘 Rule violations (0) 📎 Requirement gaps (0)

Grey Divider


Action required

1. Wrong engines.yaml schema 🐞 Bug ✓ Correctness
Description
• CONTRIBUTING.md shows an engines.yaml structure (providers map + inline api_key) that does
  not match what the backend actually parses (engines list + api_key_env).
• Following the guide will likely result in engines not being registered (or API keys not being
  picked up), breaking LLM/ASR/TTS at runtime.
• It also encourages putting secrets directly into a repo-tracked YAML, which conflicts with the
  repo’s secret-handling guidance.
Code

CONTRIBUTING.md[R80-89]

+编辑 `backend/config/engines.yaml` 配置 LLM/ASR/TTS 提供商:
+
+```yaml
+llm:
+  default: openai
+  providers:
+    openai:
+      api_key: "your-api-key"
+      model: "gpt-4"
+```
Evidence
The committed backend config uses an engines: list and api_key_env fields, and the engine loader
only reads engines and api_key_env (not providers / api_key). Repo security guidance also
explicitly calls out redacting API keys/tokens; the PR template’s checklist includes “未提交任何密钥/个人信息”.

backend/config/engines.yaml[1-33]
backend/app/services/engines/loader.py[38-43]
backend/app/services/engines/loader.py[67-81]
.github/SECURITY.md[13-18]
.github/pull_request_template.md[18-23]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
CONTRIBUTING.md documents an `engines.yaml` format that the backend does not support (`providers` + inline `api_key`). The backend expects `engines` lists and reads keys from `api_key_env`.

### Issue Context
The backend loader (`backend/app/services/engines/loader.py`) only loads `config[&#x27;...&#x27;][&#x27;engines&#x27;]` (list) and only reads API keys from `api_key_env`.

### Fix Focus Areas
- CONTRIBUTING.md[78-90]
- CONTRIBUTING.md[397-409]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools



Remediation recommended

2. Missing frontend typecheck 🐞 Bug ✓ Correctness
Description
• CONTRIBUTING.md instructs running pnpm run typecheck from frontend/, but the repo defines no
  typecheck script at the workspace root or the web app package.
• Contributors following the checklist will hit a command-not-found failure and may assume the repo
  is broken.
Code

CONTRIBUTING.md[R231-236]

+```bash
+cd frontend
+
+# 类型检查
+pnpm run typecheck
+
Evidence
frontend/package.json has no typecheck script, and frontend/apps/web/package.json also defines
only dev/build/preview. Therefore pnpm run typecheck will fail as written.

frontend/package.json[1-11]
frontend/apps/web/package.json[5-9]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
CONTRIBUTING.md tells contributors to run `pnpm run typecheck` in `frontend/`, but no such script exists.

### Issue Context
This causes immediate failures when following the contribution checklist.

### Fix Focus Areas
- CONTRIBUTING.md[229-239]
- CONTRIBUTING.md[548-558]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


3. Python version mismatch 🐞 Bug ✓ Correctness
Description
• CONTRIBUTING.md claims contributors should use “Python 3.8+” typing, but the backend declares
  requires-python >=3.10 and CI runs Python 3.11.
• This inconsistency can lead contributors to set up unsupported environments and then hit
  runtime/type errors.
Code

CONTRIBUTING.md[R165-170]

+- 遵循 PEP 8 规范
+- 使用 4 空格缩进
+- 类型注解:优先使用 Python 3.8+ 类型提示
+- 异步优先:FastAPI 路由使用 `async def`
+- 配置驱动:使用 YAML 配置文件而非硬编码
+
Evidence
Backend packaging metadata sets the minimum supported Python to 3.10, and CI enforces 3.11. The
CONTRIBUTING.md text stating 3.8+ conflicts with these repo-enforced constraints.

backend/pyproject.toml[1-6]
.github/workflows/pr-check.yml[32-38]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
CONTRIBUTING.md states Python 3.8+ guidance, but the backend requires &gt;=3.10 and CI runs 3.11.

### Issue Context
This mismatch leads to contributors using unsupported Python versions.

### Fix Focus Areas
- CONTRIBUTING.md[163-170]
- CONTRIBUTING.md[482-489]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


4. Ambiguous PR base branch 🐞 Bug ⛯ Reliability
Description
• CONTRIBUTING.md states “all PRs must target dev”, but the repo’s own CI/branching doc explicitly
  recommends dev → PR → main as part of the workflow.
• This can confuse maintainers/contributors about whether release PRs to main are
  allowed/expected, and creates conflicting guidance across repo docs.
Code

CONTRIBUTING.md[R105-107]

+> ⚠️ 重要:所有 PR 必须提交到 `dev` 分支
+> 📌 注意:`main` 分支仅用于发布,不要直接推送或合并到 main
+
Evidence
CONTRIBUTING.md uses absolute language about PR targets, while .github/CI_CD_SETUP.md documents a
two-step PR flow that includes PRs to main. These two statements cannot both be literally true
without clarifying “feature PRs” vs “release PRs”.

.github/CI_CD_SETUP.md[148-151]
.github/workflows/pr-check.yml[3-6]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
CONTRIBUTING.md states every PR must target `dev`, but repo docs recommend a `dev` → PR → `main` flow.

### Issue Context
Clarifying this avoids conflicting contributor guidance.

### Fix Focus Areas
- CONTRIBUTING.md[103-107]
- CONTRIBUTING.md[422-426]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


Grey Divider

ⓘ The new review experience is currently in Beta. Learn more

Grey Divider

Qodo Logo

Comment on lines +80 to +89
编辑 `backend/config/engines.yaml` 配置 LLM/ASR/TTS 提供商:

```yaml
llm:
default: openai
providers:
openai:
api_key: "your-api-key"
model: "gpt-4"
```

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Action required

1. Wrong engines.yaml schema 🐞 Bug ✓ Correctness

• CONTRIBUTING.md shows an engines.yaml structure (providers map + inline api_key) that does
  not match what the backend actually parses (engines list + api_key_env).
• Following the guide will likely result in engines not being registered (or API keys not being
  picked up), breaking LLM/ASR/TTS at runtime.
• It also encourages putting secrets directly into a repo-tracked YAML, which conflicts with the
  repo’s secret-handling guidance.
Agent Prompt
### Issue description
CONTRIBUTING.md documents an `engines.yaml` format that the backend does not support (`providers` + inline `api_key`). The backend expects `engines` lists and reads keys from `api_key_env`.

### Issue Context
The backend loader (`backend/app/services/engines/loader.py`) only loads `config['...']['engines']` (list) and only reads API keys from `api_key_env`.

### Fix Focus Areas
- CONTRIBUTING.md[78-90]
- CONTRIBUTING.md[397-409]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

@FutureUnreal FutureUnreal merged commit 72506ac into main Feb 7, 2026
6 checks passed
@github-actions
Copy link

github-actions bot commented Feb 7, 2026

🤖 Codex PR Review

PR Summary

  • Adds CONTRIBUTING.md (+659 / -0), introducing a bilingual (中文/English) contributing guide.
  • Covers branch/commit conventions, setup, testing commands, PR checklist, and issue reporting.
  • PR metadata: 1 file changed, 659 additions, 0 deletions.

Key Risks

  • The new guide contains a few broken links / non-existent commands that will frustrate contributors and reduce trust in the instructions.

Findings

  • [Medium] [DOCS] CONTRIBUTING.md:7 — Language navigation links likely broken (emoji headings change GitHub anchors)

    • Evidence: - 🇨🇳 [中文贡献指南](#中文贡献指南) and - 🇺🇸 [English Contributing Guide](#english-contributing-guide)
    • Why it matters: On GitHub, headings starting with emoji typically produce anchors with a leading - (e.g. #-...), so these links won’t jump to the intended sections.
    • Suggested fix: Update the links (and the note at the top) to match GitHub anchors:
      > 🇺🇸 English version is provided after the Chinese section. Scroll to [English Contributing Guide](#-english-contributing-guide) for the translation.
      
      - 🇨🇳 [中文贡献指南](#-中文贡献指南)
      - 🇺🇸 [English Contributing Guide](#-english-contributing-guide)
  • [Medium] [DOCS] CONTRIBUTING.md:235 — Frontend “typecheck” step uses a script that doesn’t exist

    • Evidence: pnpm run typecheck
    • Why it matters: frontend/package.json and frontend/apps/web/package.json don’t define a typecheck script, so contributors will hit an immediate error and may skip TS checking entirely.
    • Suggested fix: Change the guide to a command that works with current tooling (TypeScript is present in apps/web):
      cd frontend
      
      # 类型检查 / Type check (apps/web)
      pnpm -C apps/web exec tsc --noEmit
      (Apply the same change in the English section where it repeats.)
  • [Low] [DOCS] CONTRIBUTING.md:179 — Python example contradicts the stated “Python 3.8+” guidance

    • Evidence: - 类型注解:优先使用 Python 3.8+ 类型提示 followed by async def health_check() -> dict[str, str]:
    • Why it matters: dict[str, str] is Python 3.9+ syntax; copy/pasting this example on Python 3.8 will fail.
    • Suggested fix: Use typing.Dict (and drop the unused Optional) in both CN/EN examples:
      from typing import Dict
      from fastapi import APIRouter
      
      router = APIRouter()
      
      @router.get("/health")
      async def health_check() -> Dict[str, str]:
          return {"status": "ok"}
  • [Low] [DOCS] CONTRIBUTING.md:189 — References a non-existent frontend path for shared utilities

    • Evidence: - 工具函数:放在 \frontend/packages/shared` ...` (also repeated in English)
    • Why it matters: frontend/packages/shared does not exist in the repo; this guidance will confuse contributors about where to place shared code.
    • Suggested fix: Point to existing workspace packages (or describe the pattern without naming a missing folder), e.g.:
      - 工具函数:优先放在对应的 workspace 包(如 `frontend/packages/app-core`)的 `src/utils/`,或模块内 `utils/` 目录

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

needs-review Needs careful review (large/complex changes) size/L PR size: < 1000 lines changed

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant