> For the complete documentation index, see [llms.txt](https://emeditweb.gitbook.io/pulsar-stellar-sdk/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://emeditweb.gitbook.io/pulsar-stellar-sdk/governance/code-of-conduct.md). # Code of Conduct This code applies to everyone who takes part in the Pulsar Stellar toolkit: across the code repositories, the documentation, issues, pull requests, reviews, and the Telegram group. Taking part means agreeing to it. ## The standard Pulsar is a small, technical project. The bar is simple: treat other people the way a good colleague would. We expect participants to: * Keep discussion technical and specific. Critique the code, the design, or the argument, not the person. * Assume the other person is acting in good faith, and ask before assuming the worst. * Accept that a maintainer may decline a change, and that "no" with a reason is a complete answer. * Respect the project's scope and its stated limits. This code is unaudited and testnet-only, and claiming otherwise to a newcomer helps no one. * Give credit. Name the people whose work you build on. We do not accept: * Harassment, whether public or private. This includes sustained disruption, unwelcome personal attention, and deliberate intimidation. * Demeaning, discriminatory, or insulting comments, including those about a person's identity or background. * Publishing another person's private information without their explicit consent. * Sexualized language or imagery in any project space. * Encouraging any of the above. ## Scope This code covers every space the project runs, and it covers public spaces where someone represents the project, for example posting from a project account or speaking as a maintainer at an event. ## Reporting If someone's behavior breaks this code, report it privately to the head maintainer, EmeditWeb, at their GitHub profile, [github.com/EmeditWeb](https://github.com/EmeditWeb). Do not raise it in a public issue or in the Telegram group. A report stays between you and the maintainers. Include what happened, where, when, and who was involved, and any record you have, such as a link or a screenshot. You do not have to be the target of the behavior to report it. The project is solo-maintained today, so a report reaches the head maintainer directly. If a report concerns the head maintainer, say so plainly when you send it. As the maintainer group grows, this section will name a separate contact for a report that concerns the head maintainer. ## Enforcement The maintainers are responsible for enforcement. On a confirmed report, and in proportion to what happened, a maintainer may: * Give a private warning that names the behavior and what is expected instead. * Edit or remove offending comments, commits, issues, or other contributions. * Temporarily or permanently block the person from project spaces. The maintainers will keep a reporter's identity confidential. A person subject to enforcement is told what rule was broken, where feasible. ## A note on honesty This code is not a legal document and does not promise an outcome or a timeline. It states the standard the project holds and what the maintainers can do. It will be revised as the project and its group of maintainers grow. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://emeditweb.gitbook.io/pulsar-stellar-sdk/governance/code-of-conduct.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `build a script that syncs our docs to a CMS` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.