Contributing to Memact

Welcome! Memact is an open protocol and reference implementation for portable, user-owned context. We're thrilled you want to contribute.

---

Open Source Programs

SSoC (Summer of Source Code) 2026 — SSoC26

Memact participates in SSoC26 — a summer open source program for students and early-career engineers. If you're joining through SSoC26, please read every section of this guide carefully.

SSoC26 Rules

1. One issue at a time. You may hold up to 10 active assignments across all Memact repos simultaneously (greylist contributors: 1).
2. Request assignment, don't self-assign. Comment /assign or "assign me" on the issue. The automation bot assigns you within 2 hours.
3. No bot pings. Do not comment repeatedly to ask for assignment status — the bot runs on a schedule.
4. Stale policy. If you haven't made progress or updated your PR within 3 days of assignment, you will receive a stale reminder. Continued inactivity may result in unassignment.
5. One PR per issue. Open exactly one PR for each issue. Duplicate PRs will be flagged automatically.
6. Dummy PRs are required for some repos. For certain repos, you must open a tracking "dummy" PR in the Context repo referencing your work PR and the issue number. Follow the repo-specific CONTRIBUTING guide.
7. Unassign yourself if you can no longer work on an issue by commenting /unassign — this frees the issue for other contributors.
8. No plagiarism or AI-only submissions. AI-assisted code is allowed as a tool, not as a replacement for understanding. Reviewers will ask questions; be ready to explain your code.
9. Labels are automatic. The SSoC26 bot labels issues and PRs — do not apply difficulty labels yourself.
10. Respect the code of conduct. Be kind, constructive, and professional in all comments and reviews.

---

General Open Source Contribution Rules

These rules apply to all contributors regardless of open source program participation.

Before You Start

• Check that the issue is open and unassigned before commenting to request assignment.
• Read the repo-specific README and any CONTRIBUTING.md in that repository.
• Understand the Memact protocol and architecture — PRs that violate repository boundaries will be rejected.

Claiming an Issue

Comment on the issue with one of:

• /assign
• "assign me"
• "I'd like to work on this"
• "Can I work on this?"

The automation bot will assign you. Do not open a PR before you are assigned.

Opening a Pull Request

• Branch name: use feat/issue-<number>-short-description, fix/issue-<number>-..., or chore/....
• PR title: follow Conventional Commits — feat:, fix:, docs:, chore:, refactor:, test:.
• PR body: reference the linked issue with Fixes #<number> or Closes #<number>.
• Keep PRs small and focused — one issue, one PR. Large unrelated changes will be split or rejected.
• Do not open draft PRs unless you need early feedback; the AI reviewer only runs on ready PRs.

Code Quality Standards

• No debug statements — remove all console.log, debugger, print() before submitting.
• No TODO/FIXME markers — resolve placeholders before review.
• No hardcoded secrets — never commit API keys, tokens, or passwords.
• Tests required — new functionality must include tests. Bug fixes should include a regression test.
• Follow existing style — match the formatting, naming conventions, and patterns already in the repo.
• Document public APIs — new exports, functions, and types must have JSDoc/docstring comments.

Respect Repository Boundaries

Memact is a multi-repo protocol. Each repository has a strict responsibility boundary:

Repo	Owns	Must NOT own
Access	Auth, consent, permissions, revocation, sharing scopes, audit	Memory, claim semantics, business identity
Context	Categorization, ranking, relevance, freshness, contradiction resolution	Consent bypass, canonical user history
Memory	Persistence, journals, replay, indexing, retrieval support	Protocol policy, business logic
Contracts	Shared schemas, validators, protocol contracts	Business logic of any kind
SDK	CAP/CCP/CRP wrappers, auth helpers, developer experience	Product policy, protocol semantics
Notebook	User approvals, rectification, search, timeline, connected apps	Data persistence, auth logic

PRs that mix responsibilities across these boundaries will be rejected, regardless of code quality.

PR Review Process

1. The SSoC26 automation bot runs an AI review (Gemini + Groq) on every non-draft PR.
2. A human maintainer reviews and merges.
3. Address all blocking AI review comments before requesting human review.
4. Non-blocking suggestions are at your discretion but appreciated.

What Happens After Merge

• Your PR is squash-merged.
• Your contribution is recorded in the project history under the Apache 2.0 license.
• The linked issue is automatically closed if your PR body uses a closing keyword (Fixes #, Closes #).

---

Architecture Overview

Memact implements an open protocol for portable, user-owned context.

Core doctrine:

• Activity is not identity.
• Identity belongs to users, not apps.
• Apps contribute observations; users approve identity claims.
• Context is portable and permissioned.
• Freshness, confidence, relevance, provenance, and explainability matter.

Evidence flow:

Raw Activity → Evidence → Claim → Approval → Approved Claim → Memory → Retrieval

Protocols:

• CAP — Context Access Protocol: apps request approved context with consent and least-context principles.
• CCP — Context Contribution Protocol: apps contribute observations/evidence.
• CRP — Context Retrieval Protocol: retrieval of approved, permissioned context.

Prefer extending CAP, CCP, or CRP over inventing new protocols.

---

License

By contributing to Memact, you agree that your contributions will be licensed under the Apache License 2.0. See LICENSE.

---

Code of Conduct

All contributors are expected to be respectful, inclusive, and constructive. Harassment of any kind is not tolerated.

---

Questions?

Open a Discussion or ask in the relevant issue thread.