docs: adjust the documentation policies
This commit is contained in:
@@ -89,8 +89,8 @@ Treat the parameter and dataclass field order of exported runtime APIs as a comp
|
||||
|
||||
- Documentation is published to the live site, so coordinate SDK behavior changes and docs carefully. If docs describe behavior that is not released yet, either delay the docs change until the SDK release is available or split it into a follow-up PR.
|
||||
- Treat translation-safe English as a documentation compatibility requirement. In new or materially rewritten translatable prose under `docs/` (excluding generated API reference pages), state the actor, scope, ownership, ordering, modality, and lifecycle boundary explicitly whenever they affect the meaning. Use exact API identifiers in inline code, and replace ambiguous pronouns, overloaded nouns, or shorthand when a small clarification can prevent a materially different translation. Do not change the documented behavior merely to make a sentence easier to translate.
|
||||
- Before declaring new or materially rewritten translatable prose complete, run `docs/scripts/translate_docs.py --mode full --file <path>` for every affected English page, inspect the generated Japanese, Korean, and Chinese against the English source, and revise the English or the narrowly applicable translation controls until no decision-relevant ambiguity, scope drift, identifier corruption, or unstable terminology remains. A successful translation command without semantic review is not sufficient. Pure link, formatting, or typo corrections that do not change translatable meaning may skip this translation review.
|
||||
- Do not hand-edit or commit generated files under `docs/ja`, `docs/ko`, or `docs/zh`; restore them after translation review. Add or change a fixed translation mapping only when actual cross-document translation evidence shows that one stable target term is correct across contexts. Prefer contextual guidance and established target-language developer terminology, including standard English terms, over a large or rigid mapping table. If the required translation credentials or review capability are unavailable, report the validation as incomplete instead of claiming the documentation change is ready.
|
||||
- For new or materially rewritten translatable prose, use a lightweight cross-language review of only the changed English sentences and their immediate context. Have an independent reviewer or review pass inspect the source from Japanese, Korean, and Chinese translation perspectives and report only concrete risks such as an ambiguous actor, scope, ownership, ordering, modality, lifecycle boundary, overloaded SDK term, or identifier corruption. Resolve concrete findings in the English source and review the revised lines once. Do not generate full localized pages for routine documentation changes. Pure link, formatting, typo, and other edits that do not change translatable meaning may skip this review.
|
||||
- If a concrete concern cannot be resolved confidently from the English source, use a temporary translation of only the disputed sentence or paragraph as a focused probe; do not write or commit generated localized files. Reserve `docs/scripts/translate_docs.py --mode full --file <path>` and broader Japanese, Korean, and Chinese output review for changes to the translation tooling or translation controls, explicit localization work, or an explicitly requested broad translation audit. Add or change a fixed translation mapping only when actual cross-document evidence shows that one stable target term is correct across contexts. Prefer contextual guidance and established target-language developer terminology, including standard English terms, over a large or rigid mapping table.
|
||||
- Treat runnable docs snippets as API compatibility checks. Before adding OpenAI API, provider, Responses, Realtime, WebSocket, or SDK constructor examples, verify the shown arguments and call shape against the actual implementation.
|
||||
- When adding or updating code in `examples/` or runnable `docs/` snippets, import Agents SDK decorators from `agents.decorators`. Prefer `tool` over `function_tool`; keep non-decorator SDK imports on their existing public import paths.
|
||||
- Do not let untrusted sandbox manifests opt themselves out of host filesystem or base-directory boundaries. Escape hatches for local source materialization must be controlled by trusted application code at the call site, not by serialized manifest data.
|
||||
|
||||
Reference in New Issue
Block a user