Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
200 lines (131 loc) · 4.03 KB

CONTRIBUTING.md

File metadata and controls

200 lines (131 loc) · 4.03 KB
Raw

Contributing to Context Bridge

Thank you for contributing to Context Bridge.

This document explains how to participate in the project.

1. Project vision

Context Bridge is infrastructure for managing, organizing, and transferring context between AI assistants.

Contributions should respect:

  • portability
  • privacy
  • modularity
  • software quality

2. Before you contribute

Before changing code, read docs/, especially:

  • Architecture
  • API
  • Security
  • Roadmap / release plan

3. Local setup

git clone <repository>
pnpm install
pnpm test

4. Code organization

Monorepo layout:

apps/
packages/
docs/
tests/

Place each feature in the appropriate module.

5. Git policy (branches, commits, push)

5.1 Branches

Branch Role
main Stable code, build/tests green, ready to clone
develop Optional continuous integration branch
feature/* One feature / one phase
fix/* Bug fix
docs/* Documentation only

Examples: feature/chatgpt-driver, fix/storage-cascade-delete, docs/english-universal.

Rule: never land work on main that fails pnpm test, pnpm lint, or pnpm build.

5.2 Conventional Commits

Required format:

type(scope): description
Type Usage
feat New feature
fix Bug fix
test Tests
docs Documentation
chore Tooling, config, monorepo, deps
refactor Refactor without behavior change
build Build / packaging

Recommended scopes: core, storage, drivers, search, summarizer, exporters, extension, docs, repo.

Rules:

  • imperative, short technical English
  • clear intent (why)
  • one commit = one unit of meaning (phase, module, or fix)

Examples:

feat(core): add conversation and context pack services
feat(storage): persist conversations with Dexie
feat(drivers): add ChatGPT detect extract normalize flow
feat(extension): add ChatGPT import button
chore(repo): scaffold pnpm monorepo and tooling
docs: translate product documentation to English

5.3 How to split work

Work Commit
Architecture / PRD / roadmap docs docs: ...
Monorepo scaffold chore(repo): ...
Core entities + services feat(core): ...
Dexie / IndexedDB feat(storage): ...
Manual JSON/text import feat(core): add manual import pipeline
ChatGPT / Claude driver feat(drivers): ...
Extension UI feat(extension): ...
Tests only test(scope): ...
Fix fix(scope): ...

Forbidden: node_modules, secrets, .env, kitchen-sink mega-commits, force-push to main, skipping hooks without explicit agreement.

5.4 Pre-commit checklist

  1. pnpm lint
  2. pnpm test
  3. pnpm build if the change affects the build
  4. Review the diff
  5. Conventional Commit message

5.5 Push policy

Situation Action
First publish Push main after a clean series of commits
Work in progress Push feature/* regularly
Integration PR / merge into main
Hotfix fix/* → review → main

Only push code that builds and passes tests. No broken WIP on main.

6. Pull Requests

A PR should include: description, rationale, affected modules, tests, architecture impact.

7. Adding a feature

Idea → Documentation → Architecture → Interface → Code → Tests → Review

8. Required tests

Unit tests, plus integration tests when needed.

9. Code style

Strict TypeScript, ESLint, Prettier, modular architecture.

10. Security

No API keys in the repo, no user data in logs, minimal permissions.

11. Documentation

Update docs/ for every important feature. Documentation is maintained in English.

12. AI-generated code

Allowed; the contributor remains responsible (understanding, security, tests).

13. Review

Quality, architecture, security, maintainability.

14. Thanks

Every contribution helps build open, portable, reliable personal AI memory.