Contribute a reviewable change
Change the owning source, update the public explanation and bring evidence for the behavior you touched.
Source and verification context ⌄
Source-guided
Examinar el código ↗Repository links may require access. Source inspection is separate from a clean public-package installation.
Get the shape of this guide.
Move through the ideas, inspect their relationships, or make a focused reading path. The complete guide stays below.
Read the instructions for the selected checkout
Begin with the repository's AGENTS.md and the instructions in the owning package. The integration branch is actively changing, so locate the current owner rather than relying on a historical directory map.
Leer el contexto de apoyo
Keep the problem statement small: the incorrect behavior, why it matters, the intended change and the compatibility impact. A focused issue or pull request is easier to review than a large cleanup tied to an unrelated feature.
Explore a section, then continue with the complete article below.
Read the instructions for the selected checkout
Begin with the repository's AGENTS.md and the instructions in the owning package. The integration branch is actively changing, so locate the current owner rather than relying on a historical directory map.
Keep the problem statement small: the incorrect behavior, why it matters, the intended change and the compatibility impact. A focused issue or pull request is easier to review than a large cleanup tied to an unrelated feature.
Make the contribution easy to evaluate.Explore a situation · 3 ways to look closer＋
A focused change becomes more useful when the next person can reproduce the question it answers.
Connect the correction to its evidence.
A guide describes an input, command or execution guarantee inaccurately.
Update the explanation and the examples that depend on it.
A source-only capability should not become a public installation claim through wording.
Link the exact source or executed example that supports the correction, with the same release context in human and agent guidance.
Where this explanation comes from
An authored situation, grounded in the linked source guides. Choosing a case explores its expected responsibilities; it does not execute an operation.
Change the owning source
Application routes are thin wrappers; reusable docs and marketing bodies live in their bundles. Portable contract declarations, runtime execution and provider integrations have different owners. Respect those boundaries when choosing where a fix belongs.
For generated docs or agent configuration, update the canonical input and use the existing generator. Hand-editing a generated file can hide the problem until the next regeneration.
| Change | Likely owning source | Accompanying update |
|---|---|---|
| Learning article | Library docs content and manifest | Navigation, related links and metadata |
| Contract declaration | Canonical model or domain package | Reference docs and compatibility examples |
| Runtime behavior | Owning runtime or adapter | Focused behavior and failure tests |
| Published package change | Owning package | Release notes/capsule through the current workflow |
Bring the evidence that matters
Run the narrow checks required by the checkout for the changed area. Include a meaningful failing case when behavior is fixed. If a change affects a public package boundary, distinguish source tests from emitted declarations and an isolated consumer.
Report commands actually run and any blocked checks. Do not describe a source reading, a stubbed provider or a metadata smoke test as a production qualification.
Explain the result to the next maintainer
A useful change description leads with the problem, then explains the new behavior and its validation. Mention intentional compatibility changes and the migration path. Keep unrelated reformatting and architectural moves out of the same review.
The repository's contribution guidance calls for paired changeset and release-capsule records for published-package release work. Follow the current release workflow in the chosen checkout rather than copying old command sequences from a different branch.