Choose the repository that owns the behavior you want to change. Read its current README, contribution instructions and agent instructions before editing.
Describe the concrete problem and expected result. Treat proposed contracts and unavailable capabilities as boundaries, not implemented behavior. New canonical exchange contracts belong in Contracts; shared portfolio rules belong in Governance.
For a change, include the relevant tests, documentation and evidence. Preserve existing work and do not introduce credentials, private data or unrelated source material. Use the licenses and attribution requirements applicable to each file; do not change an imported license by renaming or moving a file.
An old commit, a test fixture or an agent report does not establish that a capability is currently available. Review the exact revision and the evidence relevant to the change. Follow the repository’s signing and review requirements before integration.
For a suspected vulnerability, use the private reporting route described in SECURITY.md rather than a public issue.