Contributing
Creating issues
Search for existing work, discuss scope before implementation, and provide enough context for maintainers to act.
When to open an issue
Open an issue before implementing bugs, proposals, or larger changes so the intended behavior and scope can be discussed.
A reproducible bug or regression.
A new user-facing capability or provider integration.
A behavioral change that affects public APIs, configuration, persistence, or compatibility.
A larger refactor, migration, or Studio change that benefits from agreement on boundaries.
A documentation gap whose intended guidance needs clarification.
Search before creating
Search both open and closed issues for the same behavior, error, or proposal.
Try alternative terminology used by the API, CLI, database, provider, or Studio.
Add useful reproduction details to an existing issue instead of creating a duplicate.
Understand the intended scope before claiming or beginning a substantial change.
Use the issue template
The repository's General issue template uses four sections. Replace the prompts with concrete details.
GitHub issue
## What
Describe the change.
## Why
Why is this needed?
## Expected outcome
What should the expected outcome?
## Notes
Additional context or constraints.Writing a bug report
Provide minimal, ordered reproduction steps.
Describe both the expected and actual behavior.
Include relevant error output or logs after removing secrets and private memory content.
Include the Node.js, MemoGrafter, operating-system, PostgreSQL, and pgvector versions when relevant.
State whether Redis, queue mode, or recall caching is enabled.
Include a minimal example or failing test when practical.
Writing a proposal
Describe the intended user or contributor workflow.
Explain why existing APIs or behavior do not solve the problem.
Identify proposed public API, configuration, schema, CLI, or documentation changes.
Call out compatibility and migration concerns.
Describe alternatives considered and why they were not selected.
Note the expected testing and documentation work.
Keep issues safe and focused
Never post database passwords, provider keys, access tokens, private memory content, or complete connection strings.
Keep one logical problem or proposal per issue.
Use a concise title that describes the failure or desired outcome.
Expect maintainers to refine the scope before implementation.
Reference the issue from the related branch, commits, and pull request where practical.