{"owner":"apache","repo":"opendal","hasSkills":true,"totalSkillsCount":2,"totalTokensCount":4618,"categories":["root-instruction","anthropic-skill"],"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md",".agents/skills/opendal-release/SKILL.md"],"skills":{"AGENTS.md":"# AGENTS.md\n\nGuidance for AI coding agents working in this repository.\n\n## General Rules\n\n- Use English in repository files: code, comments, commit messages, PR titles, PR bodies, and technical docs.\n- Add comments only when they explain non-obvious intent or constraints.\n- Add tests when they verify real behavior or guard a regression; do not add placeholder tests.\n- Do not change public APIs or behavior tests unless the task explicitly requires it.\n\n## AI-Assisted Contributions\n\nFollow [AI-Assisted Contributions](CONTRIBUTING.md#ai-assisted-contributions)\npolicy.\n\n- Do not publish an Issue, Pull Request, Discussion, or review comment unless a\n human has meaningfully reviewed the content and explicitly asked you to submit\n it.\n- Do not implement or submit a service-specific change based only on source-code\n analysis, a mock or emulator, a synthetic malformed response, or another\n service's implementation. Reproduce the problem against the actual service\n first.\n- If actual-service reproduction is unavailable, stop before changing code or\n opening a Pull Request. Raise the hypothesis in a Discussion unless a\n maintainer has explicitly accepted it as a hardening or maintenance goal.\n- A test against a fabricated response can verify implementation behavior, but\n it does not establish that the change solves a real-world problem.\n- In a Pull Request, disclose each materially contributing harness, model, and\n reasoning effort setting, along with AI's role and any assumptions or unknowns\n that affect review. Follow the AI Usage Statement requirements in\n CONTRIBUTING.md. Do not repeat routine validation output.\n\nThe human contributor remains responsible for every submitted claim and change.\n\n## Helper Functions\n\n- Extract a helper only when it owns a stable, cohesive responsibility, such as\n a non-trivial invariant or algorithm, shared protocol encoding with identical\n semantics, a state-machine transition, or a trait or interface boundary.\n- Do not introduce an intermediate type or helper merely to deduplicate a short\n condition, merge, forwarding step, request parameter, or error mapping.\n Prefer a few duplicated lines when they keep each operation easier to read\n and maintain in isolation.\n- Keep operation-specific validation, lowering, request construction, and\n response handling at the dispatch, request-builder, or response-processing\n boundary that owns the behavior. A reader should be able to see how one\n operation maps its options without following a chain of generic helpers.\n- Before sharing code, verify that the call sites have the same contract,\n inputs, failure semantics, and reasons to change. Similar syntax alone does\n not justify an abstraction.\n- Reuse an existing helper only when it already expresses the same contract. Do\n not broaden it with operation-specific branches merely to obtain reuse.\n\n## Documentation Style\n\n- Prefer active voice. Name the type or component that performs an action, for example, “`RetryLayer` retries failed operations.”\n- Use direct, present-tense sentences.\n- Lead with what a public type or method does, then explain important constraints, defaults, and behavior.\n- Describe API semantics precisely. Verify option types, capability requirements, error behavior, and overwrite or versioning semantics against the implementation.\n- Keep terminology consistent with the codebase, especially `service`, `layer`, `operator`, `storage` and `operation`.\n- Use parallel structure in lists and punctuate complete sentences consistently.\n\n## Documentation Architecture\n\nOpenDAL splits documentation by audience. The website carries only content\nthat holds for OpenDAL across languages; Rust-specific documentation lives in\nrustdoc.\n\n- `core/core/src/docs/specs/` contains the living portable contracts, the one\n set of documents published to both destinations. Rustdoc publishes them\n under `opendal::docs::specs`; the website reads the same Markdown at\n `/docs/specifications/`.\n- `core/core/src/docs/concepts.rs`, `core/core/src/docs/internals/`, and\n `core/core/src/docs/performance/` contain the Rust core guides: Rust types,\n traits, implementation architecture, runtime resources, and transport\n tuning. They are rustdoc-only; do not publish them on the website.\n- `website/docs/` contains cross-language concepts and non-normative guidance,\n plus the per-language guides. Content there must hold for OpenDAL as a\n whole. Do not present Rust implementation detail as cross-language behavior,\n and do not claim every binding exposes a feature (layers, builders,\n concurrency controls) unless the bindings demonstrate it.\n- `core/core/src/docs/rfcs/` contains immutable accepted design history. An\n accepted RFC records the proposal that reached consensus; update a\n specification, not the accepted RFC, when the current contract changes.\n- `core/core/src/docs/upgrade.md` contains upgrade procedures, and\n `CHANGELOG.md` contains the release changelog. Rustdoc exposes them through\n `opendal::docs`.\n- `website/docusaurus.config.js` and `website/specifications.sidebars.js`\n define website publication and navigation for the specifications. Do not add\n a website section that republishes rustdoc content, and do not copy\n specifications into `website/docs/`.\n\nPublic API documentation under `core/core/src/types/` must explain the\nobservable behavior, capability requirements, and relevant errors at the API\nsite. Link to a specification only after the local API contract is\nself-contained.\n\n## Rust Workspace Commands\n\nThe Rust workspace for OpenDAL core lives under `core/`. There is no root `Cargo.toml`; run core cargo commands from `core/`.\n\n```bash\ncd core\n\n# Check and build\ncargo check\ncargo build --locked\ncargo build --all-features --locked\n\n# Lint, matching Core CI\ncargo clippy --workspace --all-targets --all-features -- -D warnings\n\n# Lint a focused service/layer feature set\ncargo clippy --all-targets --features=services-s3 -- -D warnings\n\n# Unit tests, matching Core CI\ncargo nextest run --workspace --no-fail-fast --all-features\n\n# Doc tests and docs\ncargo test --workspace --doc --all-features\ncargo doc --lib --no-deps --all-features\n\n# Behavior tests\nOPENDAL_TEST=s3 cargo test behavior --features tests,services-s3\n\n# Format core workspace\ncargo fmt --all\ncargo fmt --all -- --check\n```\n\nRepository-wide format checks run from the repository root:\n\n```bash\n./scripts/workspace.py cargo fmt -- --check\ntaplo format --check\n```\n\nCode generation and release helpers also run from the repository root:\n\n```bash\njust generate python\njust generate java\njust update-version\njust release\n```\n\n## Current Architecture\n\nOpenDAL's Rust core has been split into a facade crate plus smaller core, service, and layer crates.\n\n- `core/Cargo.toml`: Rust workspace root and `opendal` facade package.\n- `core/src/lib.rs`: facade crate that re-exports `opendal-core`, wires optional service/layer crates, and registers enabled services for `Operator::from_uri` / `Operator::via_iter`.\n- `core/core/`: `opendal-core`, containing public core types, raw traits, shared layers, HTTP utilities, docs, RFCs, and the always-available memory service.\n- `core/services//`: standalone service crates named `opendal-service-*`.\n- `core/layers//`: standalone layer crates named `opendal-layer-*`.\n- `core/testkit/`: behavior-test support.\n- `core/tests/behavior/`: core behavior test entrypoint.\n- `integrations/`: ecosystem integrations such as `object_store`, `parquet`, `dav-server`, `unftp-sbe`, and Spring.\n- `bindings/`: language bindings; each binding has its own build/test conventions.\n- `website/`: documentation website.\n- `dev/`: repository maintenance, code generation, and release tooling used by `just`.\n\nImportant consequences of the split:\n\n- Service and layer code no longer lives under `core/src/services` or `core/src/layers`.\n- Public API changes usually touch `core/core/src/...` and the facade exports in `core/src/lib.rs`.\n- Optional user-facing features are declared in `core/Cargo.toml` as `services-*` and `layers-*`, and usually map to optional `opendal-service-*` / `opendal-layer-*` dependencies.\n- The memory service is in `core/core/src/services/memory`; `services-memory` is a deprecated compatibility feature because memory is always enabled.\n\nService and layer composition uses these boundaries:\n\n- `Builder::build(self)` returns a typed `Service`. `Operator::new(builder)` returns a ready-to-use `Operator` with the default layers applied.\n- `raw::Service` implements storage operations with concrete associated body types. `raw::ServiceDyn` is its object-safe adapter, and `raw::Servicer` is `Arc`.\n- `Service::info()` returns immutable `raw::ServiceInfo` identity (scheme, root, and name). `Service::capability()` reports the capabilities of the current service stack.\n- Each service operation receives `&OperationContext`. Services obtain the composed HTTP transport and executor from this context; operation-specific inputs stay in `Op*` arguments.\n- `Operator` stores a base service, a base context, and an ordered layer list. Adding a layer or replacing the base context replays all service hooks, then all context hooks, to produce consistent dispatch state.\n\n## Service Implementation Pattern\n\nMost services follow this shape under `core/services//`:\n\n- `src/lib.rs`: crate docs, module declarations, public builder/config exports, and service registration function.\n- `src/backend.rs`: builder and `opendal_core::raw::Service` implementation.\n- `src/config.rs`: serializable config and builder conversion.\n- `src/core.rs`: shared service client, request construction, and service-specific helpers.\n- `src/error.rs`: service-specific error parsing.\n- `src/reader.rs`, `src/writer.rs`, `src/lister.rs`, `src/deleter.rs`, `src/copier.rs`, `src/composer.rs`: operation implementations when the service needs them.\n- `README.md`: service docs included into rustdoc by `src/lib.rs`.\n- `src/docs.md`: builder docs included into rustdoc by `src/backend.rs`.\n\nWhen adding or changing a service:\n\n1. Put implementation in `core/services//`.\n2. Implement `Builder` and `raw::Service` using `opendal_core`. Keep service identity in `ServiceInfo` and report supported behavior through `capability()`.\n3. Add or update the facade feature and optional dependency in `core/Cargo.toml`.\n4. Register the service in `core/src/lib.rs` when it should support URI/iterator construction.\n5. Add or update behavior-test setup under `.github/services//` when real backend testing is needed.\n6. Obtain runtime resources from the operation's `OperationContext` rather than caching them in the service constructed by the builder.\n7. Run focused clippy/tests first, then broaden validation based on the blast radius.\n\n## Layer Implementation Pattern\n\nReusable layers live under `core/layers//` as `opendal-layer-*` crates. Core layers that are required by `opendal-core` itself live under `core/core/src/layers/`.\n\nWhen adding or changing a public optional layer:\n\n1. Put reusable optional code in `core/layers//`.\n2. Depend on `opendal-core` and implement the object-safe `raw::Layer` trait. Use `apply_service(&self, inner: Servicer) -> Servicer` for operation wrappers and `apply_context(&self, service: Servicer, inner: OperationContext) -> OperationContext` for runtime resource wrappers; both hooks return their input unchanged by default.\n3. Add or update the corresponding `layers-*` feature and optional dependency in `core/Cargo.toml`.\n4. Re-export it from the facade when users should access it through `opendal::layers`.\n\nOperation wrappers implement `raw::Service`, store the inner `Servicer`, forward unchanged operations with their context, and report the wrapped stack's capabilities. Context hooks receive the final service stack. Resource wrappers should forward through the previous transport or executor when earlier layers must remain effective.\n\n## Testing Expectations\n\n- Use `cargo fmt --all -- --check` for Rust formatting inside `core/`; use `./scripts/workspace.py cargo fmt -- --check` for the repository-wide format check.\n- For core changes, `cargo clippy --workspace --all-targets --all-features -- -D warnings` is the CI-level lint gate.\n- For behavior changes, run the narrow behavior test, for example `OPENDAL_TEST=s3 cargo test behavior --features tests,services-s3`.\n- Behavior tests require backend credentials or fixture setup. Use `.env.example`, `fixtures/`, and `.github/services//` as the source of truth for service-specific setup.\n- Integration crates under `integrations/` have their own CI workflows and should be validated in their own directories when touched.\n- Binding changes should follow the binding's local README/build files and the matching `.github/workflows/ci_bindings_*.yml`.\n\n## Pull Requests\n\n- Before opening a PR, search for similar open PRs, issues, and in-progress branches that already address the same problem. Prefer contributing to or coordinating with existing work over opening a duplicate.\n- Always use `.github/pull_request_template.md` when creating a PR.\n- Keep PR titles and descriptions factual and concise.\n- Do not add AI-tool branding or co-author trailers.\n- If public APIs or user-facing behavior change, update docs and call out the user-facing impact in the PR template.\n\n## Important Notes\n\n- Minimum Rust version is 1.91, configured in `core/Cargo.toml` and checked by CI.\n- Use `opendal_core::raw::{Service, ServiceInfo, ServiceDyn, Servicer, Layer}` for internal service and layer boundaries, and `opendal_core::OperationContext` for runtime resources.\n- Use `opendal_core::raw::oio::{Read, Write, List, Delete, Copy, Compose}` for service operation bodies. `Read` opens range streams that implement `ReadStream`; type-erased handles use the corresponding `*Dyn` adapters.\n- Use `Operator` and `blocking::Operator` as the public API entry points.\n\n## Security\n\nSecurity model: [SECURITY.md](./SECURITY.md)\n\nAgents that scan this repository should consult `SECURITY.md` and the threat\nmodel it links (`SECURITY-THREAT-MODEL.md`) for the project's in-scope /\nout-of-scope declarations, adversary model, and known non-findings before\nreporting issues.\n",".agents/skills/opendal-release/SKILL.md":"---\nname: opendal-release\ndescription: Execute and verify Apache OpenDAL release-manager work, including weekly ATR candidates, RC tagging, required GitHub Actions checks, ASF SVN dist uploads, Nexus staging close/release, vote discussions, language package readiness, GitHub release, announcements, and release postmortems.\n---\n\n# OpenDAL Release\n\n## Overview\n\nUse this skill for Apache OpenDAL release-manager work. Treat releases as a state machine with externally visible legal and distribution effects, not as ordinary CI chores.\n\nThe primary repository runbook is `website/community/release/release.md`. The split source artifact source of truth is `dev/src/release/package.rs`. Read the relevant source in the current checkout when first needed. Reuse that context across release stages; refresh the affected sections when the checkout or source changes, or when an unresolved question requires it.\n\n## Ground Rules\n\n- Use `gh` for GitHub PRs, issues, discussions, checks, and Actions logs.\n- Do not use web search for repository state. Query live GitHub, SVN, Nexus, crates.io, PyPI, npm, and Maven URLs directly.\n- Do not claim any step succeeded until the external system confirms it.\n- Treat an RC as bound to its tag, target commit, and signed source artifacts. Manual RC tags are signed; weekly preparation creates a lightweight tag and compose signs the artifacts. Do not create a new RC merely because `main` advances after tagging.\n- Do not assume bindings or integrations share the top-level OpenDAL version. Each released binding or integration can have its own version.\n- ATR is the authority for ATR candidates. Other builds and language package staging are optional and do not block starting the vote. Use the manual SVN checklist only for candidates outside ATR.\n- Do not conflate Nexus `Close` before voting with Nexus `Release` after the vote passes.\n- Do not over-block on unrelated/noncritical CI if the release gate is explicitly narrowed.\n- Do not put SVN, Nexus, or mail credentials in commands, files, issue text, PRs, or release notes. Read them from environment variables or an interactive prompt and avoid shell history when possible.\n- Commit messages and public release text must not include agent attribution.\n\n## Version Scope Rules\n\nOpenDAL releases have multiple version scopes:\n\n- `opendal_version`: the final core OpenDAL release version, for example `0.56.0`.\n- `release_version`: the RC directory and RC tag version, for example `0.56.0-rc.4`.\n- Package versions: the versions of individual core, binding, and integration packages listed in `dev/src/release/package.rs`.\n\nRules:\n\n- Use `release_version` for RC tags, vote titles, staged website URLs, and ASF SVN `dist/dev/opendal/${release_version}/` directories.\n- Use `opendal_version` for the final release tag and ASF SVN `dist/release/opendal/${opendal_version}/`.\n- Use package-specific versions for generated source archive names, package repository checks, and language binding or integration readiness.\n- When verifying artifacts, build an explicit package-to-version map from `dev/src/release/package.rs`; do not infer binding or integration versions from `opendal_version`.\n- Weekly versions use the optional PR **Breaking changes** section and\n `breaking-changes` label. Require affected package names and migration text only\n for breaking PRs; do not ask compatible PRs to declare their impact. Follow\n `website/community/release/weekly.md#declaring-breaking-changes` for the format.\n- Inspect `.release/plan.json` at the candidate SHA for the frozen declarations,\n baseline and version decisions. Editing a PR does not change an existing RC.\n- When checking upgrade docs, only check released bindings and integrations that appear in the current package list, and only add upgrade notes for components with breaking changes.\n\n## Release State Model\n\nUse these states explicitly when reporting status:\n\n1. `planning`: release discussion/tracking issue/version bump not done.\n2. `bump-pr`: version/changelog/upgrade/dependency updates are in PR.\n3. `crates-bootstrapped`: the bootstrap workflow has authenticated every Rust crate in the scanned `main` publish plan, and every name exists with the exact Trusted Publisher and `trustpub_only` enabled.\n4. `rc-tagged`: RC tag exists and was pushed at the intended commit.\n5. `rc-ci`: required release workflows, triggered by tag push or explicit dispatch, are still running or failed.\n6. `artifacts-built`: local release tooling or source compose generated ASF source artifacts.\n7. `source-staged`: signed artifacts are uploaded to ATR compose or ASF SVN `dist/dev`; record which location and revision will be verified.\n8. `nexus-closed`: Java staging repo is closed and publicly accessible.\n9. `vote-open`: the formal vote is open and identifies the verified candidate and source location.\n10. `vote-passed`: at least 72 hours elapsed and binding vote requirements are met.\n11. `official-release`: final tag, approved source publication, package repositories, GitHub release, and announcement are complete.\n\nWeekly preparation replaces the manual bump-PR path and can compose sources while downstream builds run. A candidate Discussion confirms upload and dispatch, not readiness to vote.\nFor new `releases/-rc.N` branches, hourly ATR synchronization maintains\nthat Discussion through status comments. Start future ATR votes with automatic\nresolution and publication enabled, and verify both settings in the returned\ntask. ATR attempts resolution at the scheduled vote end; unresolved votes need\nmanual follow-up. Resolving a vote as passed starts final publication, announcement,\nversion-sync PR creation and same-version RC branch cleanup. Do not duplicate\nthose operations manually. Older weekly branches stay on the manual path.\n\nRetry transient failures against the same candidate and reuse existing signed artifacts. Create a new RC when source or workflow changes must be included, or the candidate is rejected; do not regenerate an RC merely to recover a missing dispatch or a staging permission failure.\n\n## Choose the Current Phase\n\nLoad only the references needed for the requested phase or unresolved issue. Continue from the established release state; opening this skill does not require restarting release preparation. References retain phase-specific gates and command examples. Repository paths and shell commands are relative to the repository root; Markdown links are relative to their containing file.\n\n- [Preparation](references/preparation.md): start a release or prepare version, changelog, and upgrade updates.\n- [Rust crate bootstrap](references/rust-bootstrap.md): reserve crate names or inspect the protected bootstrap prerequisites.\n- [Release candidate](references/rc.md): prepare a weekly ATR candidate or manual RC, inspect required CI, recover missing dispatches, stage source artifacts, or close Nexus staging.\n- [Go readiness](references/go.md): release or verify Go bindings and service modules when Go is in scope.\n- [Rust readiness](references/rust.md): inspect the publish plan, packaging constraints, or release helper CI.\n- [Vote](references/vote.md): check pre-vote readiness, prepare the vote, or determine and publish its result.\n- [Official release](references/official-release.md): publish after the vote passes and complete release follow-up.\n- [Troubleshooting](references/troubleshooting.md): diagnose a matching CI, registry, staging, or authentication failure.\n"},"files":{"AGENTS.md":"# AGENTS.md\n\nGuidance for AI coding agents working in this repository.\n\n## General Rules\n\n- Use English in repository files: code, comments, commit messages, PR titles, PR bodies, and technical docs.\n- Add comments only when they explain non-obvious intent or constraints.\n- Add tests when they verify real behavior or guard a regression; do not add placeholder tests.\n- Do not change public APIs or behavior tests unless the task explicitly requires it.\n\n## AI-Assisted Contributions\n\nFollow [AI-Assisted Contributions](CONTRIBUTING.md#ai-assisted-contributions)\npolicy.\n\n- Do not publish an Issue, Pull Request, Discussion, or review comment unless a\n human has meaningfully reviewed the content and explicitly asked you to submit\n it.\n- Do not implement or submit a service-specific change based only on source-code\n analysis, a mock or emulator, a synthetic malformed response, or another\n service's implementation. Reproduce the problem against the actual service\n first.\n- If actual-service reproduction is unavailable, stop before changing code or\n opening a Pull Request. Raise the hypothesis in a Discussion unless a\n maintainer has explicitly accepted it as a hardening or maintenance goal.\n- A test against a fabricated response can verify implementation behavior, but\n it does not establish that the change solves a real-world problem.\n- In a Pull Request, disclose each materially contributing harness, model, and\n reasoning effort setting, along with AI's role and any assumptions or unknowns\n that affect review. Follow the AI Usage Statement requirements in\n CONTRIBUTING.md. Do not repeat routine validation output.\n\nThe human contributor remains responsible for every submitted claim and change.\n\n## Helper Functions\n\n- Extract a helper only when it owns a stable, cohesive responsibility, such as\n a non-trivial invariant or algorithm, shared protocol encoding with identical\n semantics, a state-machine transition, or a trait or interface boundary.\n- Do not introduce an intermediate type or helper merely to deduplicate a short\n condition, merge, forwarding step, request parameter, or error mapping.\n Prefer a few duplicated lines when they keep each operation easier to read\n and maintain in isolation.\n- Keep operation-specific validation, lowering, request construction, and\n response handling at the dispatch, request-builder, or response-processing\n boundary that owns the behavior. A reader should be able to see how one\n operation maps its options without following a chain of generic helpers.\n- Before sharing code, verify that the call sites have the same contract,\n inputs, failure semantics, and reasons to change. Similar syntax alone does\n not justify an abstraction.\n- Reuse an existing helper only when it already expresses the same contract. Do\n not broaden it with operation-specific branches merely to obtain reuse.\n\n## Documentation Style\n\n- Prefer active voice. Name the type or component that performs an action, for example, “`RetryLayer` retries failed operations.”\n- Use direct, present-tense sentences.\n- Lead with what a public type or method does, then explain important constraints, defaults, and behavior.\n- Describe API semantics precisely. Verify option types, capability requirements, error behavior, and overwrite or versioning semantics against the implementation.\n- Keep terminology consistent with the codebase, especially `service`, `layer`, `operator`, `storage` and `operation`.\n- Use parallel structure in lists and punctuate complete sentences consistently.\n\n## Documentation Architecture\n\nOpenDAL splits documentation by audience. The website carries only content\nthat holds for OpenDAL across languages; Rust-specific documentation lives in\nrustdoc.\n\n- `core/core/src/docs/specs/` contains the living portable contracts, the one\n set of documents published to both destinations. Rustdoc publishes them\n under `opendal::docs::specs`; the website reads the same Markdown at\n `/docs/specifications/`.\n- `core/core/src/docs/concepts.rs`, `core/core/src/docs/internals/`, and\n `core/core/src/docs/performance/` contain the Rust core guides: Rust types,\n traits, implementation architecture, runtime resources, and transport\n tuning. They are rustdoc-only; do not publish them on the website.\n- `website/docs/` contains cross-language concepts and non-normative guidance,\n plus the per-language guides. Content there must hold for OpenDAL as a\n whole. Do not present Rust implementation detail as cross-language behavior,\n and do not claim every binding exposes a feature (layers, builders,\n concurrency controls) unless the bindings demonstrate it.\n- `core/core/src/docs/rfcs/` contains immutable accepted design history. An\n accepted RFC records the proposal that reached consensus; update a\n specification, not the accepted RFC, when the current contract changes.\n- `core/core/src/docs/upgrade.md` contains upgrade procedures, and\n `CHANGELOG.md` contains the release changelog. Rustdoc exposes them through\n `opendal::docs`.\n- `website/docusaurus.config.js` and `website/specifications.sidebars.js`\n define website publication and navigation for the specifications. Do not add\n a website section that republishes rustdoc content, and do not copy\n specifications into `website/docs/`.\n\nPublic API documentation under `core/core/src/types/` must explain the\nobservable behavior, capability requirements, and relevant errors at the API\nsite. Link to a specification only after the local API contract is\nself-contained.\n\n## Rust Workspace Commands\n\nThe Rust workspace for OpenDAL core lives under `core/`. There is no root `Cargo.toml`; run core cargo commands from `core/`.\n\n```bash\ncd core\n\n# Check and build\ncargo check\ncargo build --locked\ncargo build --all-features --locked\n\n# Lint, matching Core CI\ncargo clippy --workspace --all-targets --all-features -- -D warnings\n\n# Lint a focused service/layer feature set\ncargo clippy --all-targets --features=services-s3 -- -D warnings\n\n# Unit tests, matching Core CI\ncargo nextest run --workspace --no-fail-fast --all-features\n\n# Doc tests and docs\ncargo test --workspace --doc --all-features\ncargo doc --lib --no-deps --all-features\n\n# Behavior tests\nOPENDAL_TEST=s3 cargo test behavior --features tests,services-s3\n\n# Format core workspace\ncargo fmt --all\ncargo fmt --all -- --check\n```\n\nRepository-wide format checks run from the repository root:\n\n```bash\n./scripts/workspace.py cargo fmt -- --check\ntaplo format --check\n```\n\nCode generation and release helpers also run from the repository root:\n\n```bash\njust generate python\njust generate java\njust update-version\njust release\n```\n\n## Current Architecture\n\nOpenDAL's Rust core has been split into a facade crate plus smaller core, service, and layer crates.\n\n- `core/Cargo.toml`: Rust workspace root and `opendal` facade package.\n- `core/src/lib.rs`: facade crate that re-exports `opendal-core`, wires optional service/layer crates, and registers enabled services for `Operator::from_uri` / `Operator::via_iter`.\n- `core/core/`: `opendal-core`, containing public core types, raw traits, shared layers, HTTP utilities, docs, RFCs, and the always-available memory service.\n- `core/services//`: standalone service crates named `opendal-service-*`.\n- `core/layers//`: standalone layer crates named `opendal-layer-*`.\n- `core/testkit/`: behavior-test support.\n- `core/tests/behavior/`: core behavior test entrypoint.\n- `integrations/`: ecosystem integrations such as `object_store`, `parquet`, `dav-server`, `unftp-sbe`, and Spring.\n- `bindings/`: language bindings; each binding has its own build/test conventions.\n- `website/`: documentation website.\n- `dev/`: repository maintenance, code generation, and release tooling used by `just`.\n\nImportant consequences of the split:\n\n- Service and layer code no longer lives under `core/src/services` or `core/src/layers`.\n- Public API changes usually touch `core/core/src/...` and the facade exports in `core/src/lib.rs`.\n- Optional user-facing features are declared in `core/Cargo.toml` as `services-*` and `layers-*`, and usually map to optional `opendal-service-*` / `opendal-layer-*` dependencies.\n- The memory service is in `core/core/src/services/memory`; `services-memory` is a deprecated compatibility feature because memory is always enabled.\n\nService and layer composition uses these boundaries:\n\n- `Builder::build(self)` returns a typed `Service`. `Operator::new(builder)` returns a ready-to-use `Operator` with the default layers applied.\n- `raw::Service` implements storage operations with concrete associated body types. `raw::ServiceDyn` is its object-safe adapter, and `raw::Servicer` is `Arc`.\n- `Service::info()` returns immutable `raw::ServiceInfo` identity (scheme, root, and name). `Service::capability()` reports the capabilities of the current service stack.\n- Each service operation receives `&OperationContext`. Services obtain the composed HTTP transport and executor from this context; operation-specific inputs stay in `Op*` arguments.\n- `Operator` stores a base service, a base context, and an ordered layer list. Adding a layer or replacing the base context replays all service hooks, then all context hooks, to produce consistent dispatch state.\n\n## Service Implementation Pattern\n\nMost services follow this shape under `core/services//`:\n\n- `src/lib.rs`: crate docs, module declarations, public builder/config exports, and service registration function.\n- `src/backend.rs`: builder and `opendal_core::raw::Service` implementation.\n- `src/config.rs`: serializable config and builder conversion.\n- `src/core.rs`: shared service client, request construction, and service-specific helpers.\n- `src/error.rs`: service-specific error parsing.\n- `src/reader.rs`, `src/writer.rs`, `src/lister.rs`, `src/deleter.rs`, `src/copier.rs`, `src/composer.rs`: operation implementations when the service needs them.\n- `README.md`: service docs included into rustdoc by `src/lib.rs`.\n- `src/docs.md`: builder docs included into rustdoc by `src/backend.rs`.\n\nWhen adding or changing a service:\n\n1. Put implementation in `core/services//`.\n2. Implement `Builder` and `raw::Service` using `opendal_core`. Keep service identity in `ServiceInfo` and report supported behavior through `capability()`.\n3. Add or update the facade feature and optional dependency in `core/Cargo.toml`.\n4. Register the service in `core/src/lib.rs` when it should support URI/iterator construction.\n5. Add or update behavior-test setup under `.github/services//` when real backend testing is needed.\n6. Obtain runtime resources from the operation's `OperationContext` rather than caching them in the service constructed by the builder.\n7. Run focused clippy/tests first, then broaden validation based on the blast radius.\n\n## Layer Implementation Pattern\n\nReusable layers live under `core/layers//` as `opendal-layer-*` crates. Core layers that are required by `opendal-core` itself live under `core/core/src/layers/`.\n\nWhen adding or changing a public optional layer:\n\n1. Put reusable optional code in `core/layers//`.\n2. Depend on `opendal-core` and implement the object-safe `raw::Layer` trait. Use `apply_service(&self, inner: Servicer) -> Servicer` for operation wrappers and `apply_context(&self, service: Servicer, inner: OperationContext) -> OperationContext` for runtime resource wrappers; both hooks return their input unchanged by default.\n3. Add or update the corresponding `layers-*` feature and optional dependency in `core/Cargo.toml`.\n4. Re-export it from the facade when users should access it through `opendal::layers`.\n\nOperation wrappers implement `raw::Service`, store the inner `Servicer`, forward unchanged operations with their context, and report the wrapped stack's capabilities. Context hooks receive the final service stack. Resource wrappers should forward through the previous transport or executor when earlier layers must remain effective.\n\n## Testing Expectations\n\n- Use `cargo fmt --all -- --check` for Rust formatting inside `core/`; use `./scripts/workspace.py cargo fmt -- --check` for the repository-wide format check.\n- For core changes, `cargo clippy --workspace --all-targets --all-features -- -D warnings` is the CI-level lint gate.\n- For behavior changes, run the narrow behavior test, for example `OPENDAL_TEST=s3 cargo test behavior --features tests,services-s3`.\n- Behavior tests require backend credentials or fixture setup. Use `.env.example`, `fixtures/`, and `.github/services//` as the source of truth for service-specific setup.\n- Integration crates under `integrations/` have their own CI workflows and should be validated in their own directories when touched.\n- Binding changes should follow the binding's local README/build files and the matching `.github/workflows/ci_bindings_*.yml`.\n\n## Pull Requests\n\n- Before opening a PR, search for similar open PRs, issues, and in-progress branches that already address the same problem. Prefer contributing to or coordinating with existing work over opening a duplicate.\n- Always use `.github/pull_request_template.md` when creating a PR.\n- Keep PR titles and descriptions factual and concise.\n- Do not add AI-tool branding or co-author trailers.\n- If public APIs or user-facing behavior change, update docs and call out the user-facing impact in the PR template.\n\n## Important Notes\n\n- Minimum Rust version is 1.91, configured in `core/Cargo.toml` and checked by CI.\n- Use `opendal_core::raw::{Service, ServiceInfo, ServiceDyn, Servicer, Layer}` for internal service and layer boundaries, and `opendal_core::OperationContext` for runtime resources.\n- Use `opendal_core::raw::oio::{Read, Write, List, Delete, Copy, Compose}` for service operation bodies. `Read` opens range streams that implement `ReadStream`; type-erased handles use the corresponding `*Dyn` adapters.\n- Use `Operator` and `blocking::Operator` as the public API entry points.\n\n## Security\n\nSecurity model: [SECURITY.md](./SECURITY.md)\n\nAgents that scan this repository should consult `SECURITY.md` and the threat\nmodel it links (`SECURITY-THREAT-MODEL.md`) for the project's in-scope /\nout-of-scope declarations, adversary model, and known non-findings before\nreporting issues.\n",".agents/skills/opendal-release/SKILL.md":"---\nname: opendal-release\ndescription: Execute and verify Apache OpenDAL release-manager work, including weekly ATR candidates, RC tagging, required GitHub Actions checks, ASF SVN dist uploads, Nexus staging close/release, vote discussions, language package readiness, GitHub release, announcements, and release postmortems.\n---\n\n# OpenDAL Release\n\n## Overview\n\nUse this skill for Apache OpenDAL release-manager work. Treat releases as a state machine with externally visible legal and distribution effects, not as ordinary CI chores.\n\nThe primary repository runbook is `website/community/release/release.md`. The split source artifact source of truth is `dev/src/release/package.rs`. Read the relevant source in the current checkout when first needed. Reuse that context across release stages; refresh the affected sections when the checkout or source changes, or when an unresolved question requires it.\n\n## Ground Rules\n\n- Use `gh` for GitHub PRs, issues, discussions, checks, and Actions logs.\n- Do not use web search for repository state. Query live GitHub, SVN, Nexus, crates.io, PyPI, npm, and Maven URLs directly.\n- Do not claim any step succeeded until the external system confirms it.\n- Treat an RC as bound to its tag, target commit, and signed source artifacts. Manual RC tags are signed; weekly preparation creates a lightweight tag and compose signs the artifacts. Do not create a new RC merely because `main` advances after tagging.\n- Do not assume bindings or integrations share the top-level OpenDAL version. Each released binding or integration can have its own version.\n- ATR is the authority for ATR candidates. Other builds and language package staging are optional and do not block starting the vote. Use the manual SVN checklist only for candidates outside ATR.\n- Do not conflate Nexus `Close` before voting with Nexus `Release` after the vote passes.\n- Do not over-block on unrelated/noncritical CI if the release gate is explicitly narrowed.\n- Do not put SVN, Nexus, or mail credentials in commands, files, issue text, PRs, or release notes. Read them from environment variables or an interactive prompt and avoid shell history when possible.\n- Commit messages and public release text must not include agent attribution.\n\n## Version Scope Rules\n\nOpenDAL releases have multiple version scopes:\n\n- `opendal_version`: the final core OpenDAL release version, for example `0.56.0`.\n- `release_version`: the RC directory and RC tag version, for example `0.56.0-rc.4`.\n- Package versions: the versions of individual core, binding, and integration packages listed in `dev/src/release/package.rs`.\n\nRules:\n\n- Use `release_version` for RC tags, vote titles, staged website URLs, and ASF SVN `dist/dev/opendal/${release_version}/` directories.\n- Use `opendal_version` for the final release tag and ASF SVN `dist/release/opendal/${opendal_version}/`.\n- Use package-specific versions for generated source archive names, package repository checks, and language binding or integration readiness.\n- When verifying artifacts, build an explicit package-to-version map from `dev/src/release/package.rs`; do not infer binding or integration versions from `opendal_version`.\n- Weekly versions use the optional PR **Breaking changes** section and\n `breaking-changes` label. Require affected package names and migration text only\n for breaking PRs; do not ask compatible PRs to declare their impact. Follow\n `website/community/release/weekly.md#declaring-breaking-changes` for the format.\n- Inspect `.release/plan.json` at the candidate SHA for the frozen declarations,\n baseline and version decisions. Editing a PR does not change an existing RC.\n- When checking upgrade docs, only check released bindings and integrations that appear in the current package list, and only add upgrade notes for components with breaking changes.\n\n## Release State Model\n\nUse these states explicitly when reporting status:\n\n1. `planning`: release discussion/tracking issue/version bump not done.\n2. `bump-pr`: version/changelog/upgrade/dependency updates are in PR.\n3. `crates-bootstrapped`: the bootstrap workflow has authenticated every Rust crate in the scanned `main` publish plan, and every name exists with the exact Trusted Publisher and `trustpub_only` enabled.\n4. `rc-tagged`: RC tag exists and was pushed at the intended commit.\n5. `rc-ci`: required release workflows, triggered by tag push or explicit dispatch, are still running or failed.\n6. `artifacts-built`: local release tooling or source compose generated ASF source artifacts.\n7. `source-staged`: signed artifacts are uploaded to ATR compose or ASF SVN `dist/dev`; record which location and revision will be verified.\n8. `nexus-closed`: Java staging repo is closed and publicly accessible.\n9. `vote-open`: the formal vote is open and identifies the verified candidate and source location.\n10. `vote-passed`: at least 72 hours elapsed and binding vote requirements are met.\n11. `official-release`: final tag, approved source publication, package repositories, GitHub release, and announcement are complete.\n\nWeekly preparation replaces the manual bump-PR path and can compose sources while downstream builds run. A candidate Discussion confirms upload and dispatch, not readiness to vote.\nFor new `releases/-rc.N` branches, hourly ATR synchronization maintains\nthat Discussion through status comments. Start future ATR votes with automatic\nresolution and publication enabled, and verify both settings in the returned\ntask. ATR attempts resolution at the scheduled vote end; unresolved votes need\nmanual follow-up. Resolving a vote as passed starts final publication, announcement,\nversion-sync PR creation and same-version RC branch cleanup. Do not duplicate\nthose operations manually. Older weekly branches stay on the manual path.\n\nRetry transient failures against the same candidate and reuse existing signed artifacts. Create a new RC when source or workflow changes must be included, or the candidate is rejected; do not regenerate an RC merely to recover a missing dispatch or a staging permission failure.\n\n## Choose the Current Phase\n\nLoad only the references needed for the requested phase or unresolved issue. Continue from the established release state; opening this skill does not require restarting release preparation. References retain phase-specific gates and command examples. Repository paths and shell commands are relative to the repository root; Markdown links are relative to their containing file.\n\n- [Preparation](references/preparation.md): start a release or prepare version, changelog, and upgrade updates.\n- [Rust crate bootstrap](references/rust-bootstrap.md): reserve crate names or inspect the protected bootstrap prerequisites.\n- [Release candidate](references/rc.md): prepare a weekly ATR candidate or manual RC, inspect required CI, recover missing dispatches, stage source artifacts, or close Nexus staging.\n- [Go readiness](references/go.md): release or verify Go bindings and service modules when Go is in scope.\n- [Rust readiness](references/rust.md): inspect the publish plan, packaging constraints, or release helper CI.\n- [Vote](references/vote.md): check pre-vote readiness, prepare the vote, or determine and publish its result.\n- [Official release](references/official-release.md): publish after the vote passes and complete release follow-up.\n- [Troubleshooting](references/troubleshooting.md): diagnose a matching CI, registry, staging, or authentication failure.\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","rawUrl":"https://raw.githubusercontent.com/apache/opendal/HEAD/AGENTS.md","title":"AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"# AGENTS.md\n\nGuidance for AI coding agents working in this repository.\n\n## General Rules\n\n- Use English in repository files: code, comments, commit messages, PR titles, PR bodies, and technical docs.\n- Add comments only when they explain non-obvious intent or constraints.\n- Add tests when they verify real behavior or guard a regression; do not add placeholder tests.\n- Do not change public APIs or behavior tests unless the task explicitly requires it.\n\n## AI-Assisted Contributions\n\nFollow [AI-Assisted Contributions](CONTRIBUTING.md#ai-assisted-contributions)\npolicy.\n\n- Do not publish an Issue, Pull Request, Discussion, or review comment unless a\n human has meaningfully reviewed the content and explicitly asked you to submit\n it.\n- Do not implement or submit a service-specific change based only on source-code\n analysis, a mock or emulator, a synthetic malformed response, or another\n service's implementation. Reproduce the problem against the actual service\n first.\n- If actual-service reproduction is unavailable, stop before changing code or\n opening a Pull Request. Raise the hypothesis in a Discussion unless a\n maintainer has explicitly accepted it as a hardening or maintenance goal.\n- A test against a fabricated response can verify implementation behavior, but\n it does not establish that the change solves a real-world problem.\n- In a Pull Request, disclose each materially contributing harness, model, and\n reasoning effort setting, along with AI's role and any assumptions or unknowns\n that affect review. Follow the AI Usage Statement requirements in\n CONTRIBUTING.md. Do not repeat routine validation output.\n\nThe human contributor remains responsible for every submitted claim and change.\n\n## Helper Functions\n\n- Extract a helper only when it owns a stable, cohesive responsibility, such as\n a non-trivial invariant or algorithm, shared protocol encoding with identical\n semantics, a state-machine transition, or a trait or interface boundary.\n- Do not introduce an intermediate type or helper merely to deduplicate a short\n condition, merge, forwarding step, request parameter, or error mapping.\n Prefer a few duplicated lines when they keep each operation easier to read\n and maintain in isolation.\n- Keep operation-specific validation, lowering, request construction, and\n response handling at the dispatch, request-builder, or response-processing\n boundary that owns the behavior. A reader should be able to see how one\n operation maps its options without following a chain of generic helpers.\n- Before sharing code, verify that the call sites have the same contract,\n inputs, failure semantics, and reasons to change. Similar syntax alone does\n not justify an abstraction.\n- Reuse an existing helper only when it already expresses the same contract. Do\n not broaden it with operation-specific branches merely to obtain reuse.\n\n## Documentation Style\n\n- Prefer active voice. Name the type or component that performs an action, for example, “`RetryLayer` retries failed operations.”\n- Use direct, present-tense sentences.\n- Lead with what a public type or method does, then explain important constraints, defaults, and behavior.\n- Describe API semantics precisely. Verify option types, capability requirements, error behavior, and overwrite or versioning semantics against the implementation.\n- Keep terminology consistent with the codebase, especially `service`, `layer`, `operator`, `storage` and `operation`.\n- Use parallel structure in lists and punctuate complete sentences consistently.\n\n## Documentation Architecture\n\nOpenDAL splits documentation by audience. The website carries only content\nthat holds for OpenDAL across languages; Rust-specific documentation lives in\nrustdoc.\n\n- `core/core/src/docs/specs/` contains the living portable contracts, the one\n set of documents published to both destinations. Rustdoc publishes them\n under `opendal::docs::specs`; the website reads the same Markdown at\n `/docs/specifications/`.\n- `core/core/src/docs/concepts.rs`, `core/core/src/docs/internals/`, and\n `core/core/src/docs/performance/` contain the Rust core guides: Rust types,\n traits, implementation architecture, runtime resources, and transport\n tuning. They are rustdoc-only; do not publish them on the website.\n- `website/docs/` contains cross-language concepts and non-normative guidance,\n plus the per-language guides. Content there must hold for OpenDAL as a\n whole. Do not present Rust implementation detail as cross-language behavior,\n and do not claim every binding exposes a feature (layers, builders,\n concurrency controls) unless the bindings demonstrate it.\n- `core/core/src/docs/rfcs/` contains immutable accepted design history. An\n accepted RFC records the proposal that reached consensus; update a\n specification, not the accepted RFC, when the current contract changes.\n- `core/core/src/docs/upgrade.md` contains upgrade procedures, and\n `CHANGELOG.md` contains the release changelog. Rustdoc exposes them through\n `opendal::docs`.\n- `website/docusaurus.config.js` and `website/specifications.sidebars.js`\n define website publication and navigation for the specifications. Do not add\n a website section that republishes rustdoc content, and do not copy\n specifications into `website/docs/`.\n\nPublic API documentation under `core/core/src/types/` must explain the\nobservable behavior, capability requirements, and relevant errors at the API\nsite. Link to a specification only after the local API contract is\nself-contained.\n\n## Rust Workspace Commands\n\nThe Rust workspace for OpenDAL core lives under `core/`. There is no root `Cargo.toml`; run core cargo commands from `core/`.\n\n```bash\ncd core\n\n# Check and build\ncargo check\ncargo build --locked\ncargo build --all-features --locked\n\n# Lint, matching Core CI\ncargo clippy --workspace --all-targets --all-features -- -D warnings\n\n# Lint a focused service/layer feature set\ncargo clippy --all-targets --features=services-s3 -- -D warnings\n\n# Unit tests, matching Core CI\ncargo nextest run --workspace --no-fail-fast --all-features\n\n# Doc tests and docs\ncargo test --workspace --doc --all-features\ncargo doc --lib --no-deps --all-features\n\n# Behavior tests\nOPENDAL_TEST=s3 cargo test behavior --features tests,services-s3\n\n# Format core workspace\ncargo fmt --all\ncargo fmt --all -- --check\n```\n\nRepository-wide format checks run from the repository root:\n\n```bash\n./scripts/workspace.py cargo fmt -- --check\ntaplo format --check\n```\n\nCode generation and release helpers also run from the repository root:\n\n```bash\njust generate python\njust generate java\njust update-version\njust release\n```\n\n## Current Architecture\n\nOpenDAL's Rust core has been split into a facade crate plus smaller core, service, and layer crates.\n\n- `core/Cargo.toml`: Rust workspace root and `opendal` facade package.\n- `core/src/lib.rs`: facade crate that re-exports `opendal-core`, wires optional service/layer crates, and registers enabled services for `Operator::from_uri` / `Operator::via_iter`.\n- `core/core/`: `opendal-core`, containing public core types, raw traits, shared layers, HTTP utilities, docs, RFCs, and the always-available memory service.\n- `core/services//`: standalone service crates named `opendal-service-*`.\n- `core/layers//`: standalone layer crates named `opendal-layer-*`.\n- `core/testkit/`: behavior-test support.\n- `core/tests/behavior/`: core behavior test entrypoint.\n- `integrations/`: ecosystem integrations such as `object_store`, `parquet`, `dav-server`, `unftp-sbe`, and Spring.\n- `bindings/`: language bindings; each binding has its own build/test conventions.\n- `website/`: documentation website.\n- `dev/`: repository maintenance, code generation, and release tooling used by `just`.\n\nImportant consequences of the split:\n\n- Service and layer code no longer lives under `core/src/services` or `core/src/layers`.\n- Public API changes usually touch `core/core/src/...` and the facade exports in `core/src/lib.rs`.\n- Optional user-facing features are declared in `core/Cargo.toml` as `services-*` and `layers-*`, and usually map to optional `opendal-service-*` / `opendal-layer-*` dependencies.\n- The memory service is in `core/core/src/services/memory`; `services-memory` is a deprecated compatibility feature because memory is always enabled.\n\nService and layer composition uses these boundaries:\n\n- `Builder::build(self)` returns a typed `Service`. `Operator::new(builder)` returns a ready-to-use `Operator` with the default layers applied.\n- `raw::Service` implements storage operations with concrete associated body types. `raw::ServiceDyn` is its object-safe adapter, and `raw::Servicer` is `Arc`.\n- `Service::info()` returns immutable `raw::ServiceInfo` identity (scheme, root, and name). `Service::capability()` reports the capabilities of the current service stack.\n- Each service operation receives `&OperationContext`. Services obtain the composed HTTP transport and executor from this context; operation-specific inputs stay in `Op*` arguments.\n- `Operator` stores a base service, a base context, and an ordered layer list. Adding a layer or replacing the base context replays all service hooks, then all context hooks, to produce consistent dispatch state.\n\n## Service Implementation Pattern\n\nMost services follow this shape under `core/services//`:\n\n- `src/lib.rs`: crate docs, module declarations, public builder/config exports, and service registration function.\n- `src/backend.rs`: builder and `opendal_core::raw::Service` implementation.\n- `src/config.rs`: serializable config and builder conversion.\n- `src/core.rs`: shared service client, request construction, and service-specific helpers.\n- `src/error.rs`: service-specific error parsing.\n- `src/reader.rs`, `src/writer.rs`, `src/lister.rs`, `src/deleter.rs`, `src/copier.rs`, `src/composer.rs`: operation implementations when the service needs them.\n- `README.md`: service docs included into rustdoc by `src/lib.rs`.\n- `src/docs.md`: builder docs included into rustdoc by `src/backend.rs`.\n\nWhen adding or changing a service:\n\n1. Put implementation in `core/services//`.\n2. Implement `Builder` and `raw::Service` using `opendal_core`. Keep service identity in `ServiceInfo` and report supported behavior through `capability()`.\n3. Add or update the facade feature and optional dependency in `core/Cargo.toml`.\n4. Register the service in `core/src/lib.rs` when it should support URI/iterator construction.\n5. Add or update behavior-test setup under `.github/services//` when real backend testing is needed.\n6. Obtain runtime resources from the operation's `OperationContext` rather than caching them in the service constructed by the builder.\n7. Run focused clippy/tests first, then broaden validation based on the blast radius.\n\n## Layer Implementation Pattern\n\nReusable layers live under `core/layers//` as `opendal-layer-*` crates. Core layers that are required by `opendal-core` itself live under `core/core/src/layers/`.\n\nWhen adding or changing a public optional layer:\n\n1. Put reusable optional code in `core/layers//`.\n2. Depend on `opendal-core` and implement the object-safe `raw::Layer` trait. Use `apply_service(&self, inner: Servicer) -> Servicer` for operation wrappers and `apply_context(&self, service: Servicer, inner: OperationContext) -> OperationContext` for runtime resource wrappers; both hooks return their input unchanged by default.\n3. Add or update the corresponding `layers-*` feature and optional dependency in `core/Cargo.toml`.\n4. Re-export it from the facade when users should access it through `opendal::layers`.\n\nOperation wrappers implement `raw::Service`, store the inner `Servicer`, forward unchanged operations with their context, and report the wrapped stack's capabilities. Context hooks receive the final service stack. Resource wrappers should forward through the previous transport or executor when earlier layers must remain effective.\n\n## Testing Expectations\n\n- Use `cargo fmt --all -- --check` for Rust formatting inside `core/`; use `./scripts/workspace.py cargo fmt -- --check` for the repository-wide format check.\n- For core changes, `cargo clippy --workspace --all-targets --all-features -- -D warnings` is the CI-level lint gate.\n- For behavior changes, run the narrow behavior test, for example `OPENDAL_TEST=s3 cargo test behavior --features tests,services-s3`.\n- Behavior tests require backend credentials or fixture setup. Use `.env.example`, `fixtures/`, and `.github/services//` as the source of truth for service-specific setup.\n- Integration crates under `integrations/` have their own CI workflows and should be validated in their own directories when touched.\n- Binding changes should follow the binding's local README/build files and the matching `.github/workflows/ci_bindings_*.yml`.\n\n## Pull Requests\n\n- Before opening a PR, search for similar open PRs, issues, and in-progress branches that already address the same problem. Prefer contributing to or coordinating with existing work over opening a duplicate.\n- Always use `.github/pull_request_template.md` when creating a PR.\n- Keep PR titles and descriptions factual and concise.\n- Do not add AI-tool branding or co-author trailers.\n- If public APIs or user-facing behavior change, update docs and call out the user-facing impact in the PR template.\n\n## Important Notes\n\n- Minimum Rust version is 1.91, configured in `core/Cargo.toml` and checked by CI.\n- Use `opendal_core::raw::{Service, ServiceInfo, ServiceDyn, Servicer, Layer}` for internal service and layer boundaries, and `opendal_core::OperationContext` for runtime resources.\n- Use `opendal_core::raw::oio::{Read, Write, List, Delete, Copy, Compose}` for service operation bodies. `Read` opens range streams that implement `ReadStream`; type-erased handles use the corresponding `*Dyn` adapters.\n- Use `Operator` and `blocking::Operator` as the public API entry points.\n\n## Security\n\nSecurity model: [SECURITY.md](./SECURITY.md)\n\nAgents that scan this repository should consult `SECURITY.md` and the threat\nmodel it links (`SECURITY-THREAT-MODEL.md`) for the project's in-scope /\nout-of-scope declarations, adversary model, and known non-findings before\nreporting issues.\n","isInternal":false,"tokens":3108,"sizeBytes":14256},{"name":"SKILL.md","path":".agents/skills/opendal-release/SKILL.md","rawUrl":"https://raw.githubusercontent.com/apache/opendal/HEAD/.agents/skills/opendal-release/SKILL.md","title":"opendal-release","category":"anthropic-skill","format":"markdown","content":"---\nname: opendal-release\ndescription: Execute and verify Apache OpenDAL release-manager work, including weekly ATR candidates, RC tagging, required GitHub Actions checks, ASF SVN dist uploads, Nexus staging close/release, vote discussions, language package readiness, GitHub release, announcements, and release postmortems.\n---\n\n# OpenDAL Release\n\n## Overview\n\nUse this skill for Apache OpenDAL release-manager work. Treat releases as a state machine with externally visible legal and distribution effects, not as ordinary CI chores.\n\nThe primary repository runbook is `website/community/release/release.md`. The split source artifact source of truth is `dev/src/release/package.rs`. Read the relevant source in the current checkout when first needed. Reuse that context across release stages; refresh the affected sections when the checkout or source changes, or when an unresolved question requires it.\n\n## Ground Rules\n\n- Use `gh` for GitHub PRs, issues, discussions, checks, and Actions logs.\n- Do not use web search for repository state. Query live GitHub, SVN, Nexus, crates.io, PyPI, npm, and Maven URLs directly.\n- Do not claim any step succeeded until the external system confirms it.\n- Treat an RC as bound to its tag, target commit, and signed source artifacts. Manual RC tags are signed; weekly preparation creates a lightweight tag and compose signs the artifacts. Do not create a new RC merely because `main` advances after tagging.\n- Do not assume bindings or integrations share the top-level OpenDAL version. Each released binding or integration can have its own version.\n- ATR is the authority for ATR candidates. Other builds and language package staging are optional and do not block starting the vote. Use the manual SVN checklist only for candidates outside ATR.\n- Do not conflate Nexus `Close` before voting with Nexus `Release` after the vote passes.\n- Do not over-block on unrelated/noncritical CI if the release gate is explicitly narrowed.\n- Do not put SVN, Nexus, or mail credentials in commands, files, issue text, PRs, or release notes. Read them from environment variables or an interactive prompt and avoid shell history when possible.\n- Commit messages and public release text must not include agent attribution.\n\n## Version Scope Rules\n\nOpenDAL releases have multiple version scopes:\n\n- `opendal_version`: the final core OpenDAL release version, for example `0.56.0`.\n- `release_version`: the RC directory and RC tag version, for example `0.56.0-rc.4`.\n- Package versions: the versions of individual core, binding, and integration packages listed in `dev/src/release/package.rs`.\n\nRules:\n\n- Use `release_version` for RC tags, vote titles, staged website URLs, and ASF SVN `dist/dev/opendal/${release_version}/` directories.\n- Use `opendal_version` for the final release tag and ASF SVN `dist/release/opendal/${opendal_version}/`.\n- Use package-specific versions for generated source archive names, package repository checks, and language binding or integration readiness.\n- When verifying artifacts, build an explicit package-to-version map from `dev/src/release/package.rs`; do not infer binding or integration versions from `opendal_version`.\n- Weekly versions use the optional PR **Breaking changes** section and\n `breaking-changes` label. Require affected package names and migration text only\n for breaking PRs; do not ask compatible PRs to declare their impact. Follow\n `website/community/release/weekly.md#declaring-breaking-changes` for the format.\n- Inspect `.release/plan.json` at the candidate SHA for the frozen declarations,\n baseline and version decisions. Editing a PR does not change an existing RC.\n- When checking upgrade docs, only check released bindings and integrations that appear in the current package list, and only add upgrade notes for components with breaking changes.\n\n## Release State Model\n\nUse these states explicitly when reporting status:\n\n1. `planning`: release discussion/tracking issue/version bump not done.\n2. `bump-pr`: version/changelog/upgrade/dependency updates are in PR.\n3. `crates-bootstrapped`: the bootstrap workflow has authenticated every Rust crate in the scanned `main` publish plan, and every name exists with the exact Trusted Publisher and `trustpub_only` enabled.\n4. `rc-tagged`: RC tag exists and was pushed at the intended commit.\n5. `rc-ci`: required release workflows, triggered by tag push or explicit dispatch, are still running or failed.\n6. `artifacts-built`: local release tooling or source compose generated ASF source artifacts.\n7. `source-staged`: signed artifacts are uploaded to ATR compose or ASF SVN `dist/dev`; record which location and revision will be verified.\n8. `nexus-closed`: Java staging repo is closed and publicly accessible.\n9. `vote-open`: the formal vote is open and identifies the verified candidate and source location.\n10. `vote-passed`: at least 72 hours elapsed and binding vote requirements are met.\n11. `official-release`: final tag, approved source publication, package repositories, GitHub release, and announcement are complete.\n\nWeekly preparation replaces the manual bump-PR path and can compose sources while downstream builds run. A candidate Discussion confirms upload and dispatch, not readiness to vote.\nFor new `releases/-rc.N` branches, hourly ATR synchronization maintains\nthat Discussion through status comments. Start future ATR votes with automatic\nresolution and publication enabled, and verify both settings in the returned\ntask. ATR attempts resolution at the scheduled vote end; unresolved votes need\nmanual follow-up. Resolving a vote as passed starts final publication, announcement,\nversion-sync PR creation and same-version RC branch cleanup. Do not duplicate\nthose operations manually. Older weekly branches stay on the manual path.\n\nRetry transient failures against the same candidate and reuse existing signed artifacts. Create a new RC when source or workflow changes must be included, or the candidate is rejected; do not regenerate an RC merely to recover a missing dispatch or a staging permission failure.\n\n## Choose the Current Phase\n\nLoad only the references needed for the requested phase or unresolved issue. Continue from the established release state; opening this skill does not require restarting release preparation. References retain phase-specific gates and command examples. Repository paths and shell commands are relative to the repository root; Markdown links are relative to their containing file.\n\n- [Preparation](references/preparation.md): start a release or prepare version, changelog, and upgrade updates.\n- [Rust crate bootstrap](references/rust-bootstrap.md): reserve crate names or inspect the protected bootstrap prerequisites.\n- [Release candidate](references/rc.md): prepare a weekly ATR candidate or manual RC, inspect required CI, recover missing dispatches, stage source artifacts, or close Nexus staging.\n- [Go readiness](references/go.md): release or verify Go bindings and service modules when Go is in scope.\n- [Rust readiness](references/rust.md): inspect the publish plan, packaging constraints, or release helper CI.\n- [Vote](references/vote.md): check pre-vote readiness, prepare the vote, or determine and publish its result.\n- [Official release](references/official-release.md): publish after the vote passes and complete release follow-up.\n- [Troubleshooting](references/troubleshooting.md): diagnose a matching CI, registry, staging, or authentication failure.\n","frontmatter":{"name":"opendal-release","description":"Execute and verify Apache OpenDAL release-manager work, including weekly ATR candidates, RC tagging, required GitHub Actions checks, ASF SVN dist uploads, Nexus staging close/release, vote discussions, language package readiness, GitHub release, announcements, and release postmortems."},"isInternal":false,"tokens":1510,"sizeBytes":7476}],"systemPromptSnippet":"\n\n# AGENTS.md\n\nGuidance for AI coding agents working in this repository.\n\n## General Rules\n\n- Use English in repository files: code, comments, commit messages, PR titles, PR bodies, and technical docs.\n- Add comments only when they explain non-obvious intent or constraints.\n- Add tests when they verify real behavior or guard a regression; do not add placeholder tests.\n- Do not change public APIs or behavior tests unless the task explicitly requires it.\n\n## AI-Assisted Contributions\n\nFollow [AI-Assisted Contributions](CONTRIBUTING.md#ai-assisted-contributions)\npolicy.\n\n- Do not publish an Issue, Pull Request, Discussion, or review comment unless a\n human has meaningfully reviewed the content and explicitly asked you to submit\n it.\n- Do not implement or submit a service-specific change based only on source-code\n analysis, a mock or emulator, a synthetic malformed response, or another\n service's implementation. Reproduce the problem against the actual service\n first.\n- If actual-service reproduction is unavailable, stop before changing code or\n opening a Pull Request. Raise the hypothesis in a Discussion unless a\n maintainer has explicitly accepted it as a hardening or maintenance goal.\n- A test against a fabricated response can verify implementation behavior, but\n it does not establish that the change solves a real-world problem.\n- In a Pull Request, disclose each materially contributing harness, model, and\n reasoning effort setting, along with AI's role and any assumptions or unknowns\n that affect review. Follow the AI Usage Statement requirements in\n CONTRIBUTING.md. Do not repeat routine validation output.\n\nThe human contributor remains responsible for every submitted claim and change.\n\n## Helper Functions\n\n- Extract a helper only when it owns a stable, cohesive responsibility, such as\n a non-trivial invariant or algorithm, shared protocol encoding with identical\n semantics, a state-machine transition, or a trait or interface boundary.\n- Do not introduce an intermediate type or helper merely to deduplicate a short\n condition, merge, forwarding step, request parameter, or error mapping.\n Prefer a few duplicated lines when they keep each operation easier to read\n and maintain in isolation.\n- Keep operation-specific validation, lowering, request construction, and\n response handling at the dispatch, request-builder, or response-processing\n boundary that owns the behavior. A reader should be able to see how one\n operation maps its options without following a chain of generic helpers.\n- Before sharing code, verify that the call sites have the same contract,\n inputs, failure semantics, and reasons to change. Similar syntax alone does\n not justify an abstraction.\n- Reuse an existing helper only when it already expresses the same contract. Do\n not broaden it with operation-specific branches merely to obtain reuse.\n\n## Documentation Style\n\n- Prefer active voice. Name the type or component that performs an action, for example, “`RetryLayer` retries failed operations.”\n- Use direct, present-tense sentences.\n- Lead with what a public type or method does, then explain important constraints, defaults, and behavior.\n- Describe API semantics precisely. Verify option types, capability requirements, error behavior, and overwrite or versioning semantics against the implementation.\n- Keep terminology consistent with the codebase, especially `service`, `layer`, `operator`, `storage` and `operation`.\n- Use parallel structure in lists and punctuate complete sentences consistently.\n\n## Documentation Architecture\n\nOpenDAL splits documentation by audience. The website carries only content\nthat holds for OpenDAL across languages; Rust-specific documentation lives in\nrustdoc.\n\n- `core/core/src/docs/specs/` contains the living portable contracts, the one\n set of documents published to both destinations. Rustdoc publishes them\n under `opendal::docs::specs`; the website reads the same Markdown at\n `/docs/specifications/`.\n- `core/core/src/docs/concepts.rs`, `core/core/src/docs/internals/`, and\n `core/core/src/docs/performance/` contain the Rust core guides: Rust types,\n traits, implementation architecture, runtime resources, and transport\n tuning. They are rustdoc-only; do not publish them on the website.\n- `website/docs/` contains cross-language concepts and non-normative guidance,\n plus the per-language guides. Content there must hold for OpenDAL as a\n whole. Do not present Rust implementation detail as cross-language behavior,\n and do not claim every binding exposes a feature (layers, builders,\n concurrency controls) unless the bindings demonstrate it.\n- `core/core/src/docs/rfcs/` contains immutable accepted design history. An\n accepted RFC records the proposal that reached consensus; update a\n specification, not the accepted RFC, when the current contract changes.\n- `core/core/src/docs/upgrade.md` contains upgrade procedures, and\n `CHANGELOG.md` contains the release changelog. Rustdoc exposes them through\n `opendal::docs`.\n- `website/docusaurus.config.js` and `website/specifications.sidebars.js`\n define website publication and navigation for the specifications. Do not add\n a website section that republishes rustdoc content, and do not copy\n specifications into `website/docs/`.\n\nPublic API documentation under `core/core/src/types/` must explain the\nobservable behavior, capability requirements, and relevant errors at the API\nsite. Link to a specification only after the local API contract is\nself-contained.\n\n## Rust Workspace Commands\n\nThe Rust workspace for OpenDAL core lives under `core/`. There is no root `Cargo.toml`; run core cargo commands from `core/`.\n\n```bash\ncd core\n\n# Check and build\ncargo check\ncargo build --locked\ncargo build --all-features --locked\n\n# Lint, matching Core CI\ncargo clippy --workspace --all-targets --all-features -- -D warnings\n\n# Lint a focused service/layer feature set\ncargo clippy --all-targets --features=services-s3 -- -D warnings\n\n# Unit tests, matching Core CI\ncargo nextest run --workspace --no-fail-fast --all-features\n\n# Doc tests and docs\ncargo test --workspace --doc --all-features\ncargo doc --lib --no-deps --all-features\n\n# Behavior tests\nOPENDAL_TEST=s3 cargo test behavior --features tests,services-s3\n\n# Format core workspace\ncargo fmt --all\ncargo fmt --all -- --check\n```\n\nRepository-wide format checks run from the repository root:\n\n```bash\n./scripts/workspace.py cargo fmt -- --check\ntaplo format --check\n```\n\nCode generation and release helpers also run from the repository root:\n\n```bash\njust generate python\njust generate java\njust update-version\njust release\n```\n\n## Current Architecture\n\nOpenDAL's Rust core has been split into a facade crate plus smaller core, service, and layer crates.\n\n- `core/Cargo.toml`: Rust workspace root and `opendal` facade package.\n- `core/src/lib.rs`: facade crate that re-exports `opendal-core`, wires optional service/layer crates, and registers enabled services for `Operator::from_uri` / `Operator::via_iter`.\n- `core/core/`: `opendal-core`, containing public core types, raw traits, shared layers, HTTP utilities, docs, RFCs, and the always-available memory service.\n- `core/services//`: standalone service crates named `opendal-service-*`.\n- `core/layers//`: standalone layer crates named `opendal-layer-*`.\n- `core/testkit/`: behavior-test support.\n- `core/tests/behavior/`: core behavior test entrypoint.\n- `integrations/`: ecosystem integrations such as `object_store`, `parquet`, `dav-server`, `unftp-sbe`, and Spring.\n- `bindings/`: language bindings; each binding has its own build/test conventions.\n- `website/`: documentation website.\n- `dev/`: repository maintenance, code generation, and release tooling used by `just`.\n\nImportant consequences of the split:\n\n- Service and layer code no longer lives under `core/src/services` or `core/src/layers`.\n- Public API changes usually touch `core/core/src/...` and the facade exports in `core/src/lib.rs`.\n- Optional user-facing features are declared in `core/Cargo.toml` as `services-*` and `layers-*`, and usually map to optional `opendal-service-*` / `opendal-layer-*` dependencies.\n- The memory service is in `core/core/src/services/memory`; `services-memory` is a deprecated compatibility feature because memory is always enabled.\n\nService and layer composition uses these boundaries:\n\n- `Builder::build(self)` returns a typed `Service`. `Operator::new(builder)` returns a ready-to-use `Operator` with the default layers applied.\n- `raw::Service` implements storage operations with concrete associated body types. `raw::ServiceDyn` is its object-safe adapter, and `raw::Servicer` is `Arc`.\n- `Service::info()` returns immutable `raw::ServiceInfo` identity (scheme, root, and name). `Service::capability()` reports the capabilities of the current service stack.\n- Each service operation receives `&OperationContext`. Services obtain the composed HTTP transport and executor from this context; operation-specific inputs stay in `Op*` arguments.\n- `Operator` stores a base service, a base context, and an ordered layer list. Adding a layer or replacing the base context replays all service hooks, then all context hooks, to produce consistent dispatch state.\n\n## Service Implementation Pattern\n\nMost services follow this shape under `core/services//`:\n\n- `src/lib.rs`: crate docs, module declarations, public builder/config exports, and service registration function.\n- `src/backend.rs`: builder and `opendal_core::raw::Service` implementation.\n- `src/config.rs`: serializable config and builder conversion.\n- `src/core.rs`: shared service client, request construction, and service-specific helpers.\n- `src/error.rs`: service-specific error parsing.\n- `src/reader.rs`, `src/writer.rs`, `src/lister.rs`, `src/deleter.rs`, `src/copier.rs`, `src/composer.rs`: operation implementations when the service needs them.\n- `README.md`: service docs included into rustdoc by `src/lib.rs`.\n- `src/docs.md`: builder docs included into rustdoc by `src/backend.rs`.\n\nWhen adding or changing a service:\n\n1. Put implementation in `core/services//`.\n2. Implement `Builder` and `raw::Service` using `opendal_core`. Keep service identity in `ServiceInfo` and report supported behavior through `capability()`.\n3. Add or update the facade feature and optional dependency in `core/Cargo.toml`.\n4. Register the service in `core/src/lib.rs` when it should support URI/iterator construction.\n5. Add or update behavior-test setup under `.github/services//` when real backend testing is needed.\n6. Obtain runtime resources from the operation's `OperationContext` rather than caching them in the service constructed by the builder.\n7. Run focused clippy/tests first, then broaden validation based on the blast radius.\n\n## Layer Implementation Pattern\n\nReusable layers live under `core/layers//` as `opendal-layer-*` crates. Core layers that are required by `opendal-core` itself live under `core/core/src/layers/`.\n\nWhen adding or changing a public optional layer:\n\n1. Put reusable optional code in `core/layers//`.\n2. Depend on `opendal-core` and implement the object-safe `raw::Layer` trait. Use `apply_service(&self, inner: Servicer) -> Servicer` for operation wrappers and `apply_context(&self, service: Servicer, inner: OperationContext) -> OperationContext` for runtime resource wrappers; both hooks return their input unchanged by default.\n3. Add or update the corresponding `layers-*` feature and optional dependency in `core/Cargo.toml`.\n4. Re-export it from the facade when users should access it through `opendal::layers`.\n\nOperation wrappers implement `raw::Service`, store the inner `Servicer`, forward unchanged operations with their context, and report the wrapped stack's capabilities. Context hooks receive the final service stack. Resource wrappers should forward through the previous transport or executor when earlier layers must remain effective.\n\n## Testing Expectations\n\n- Use `cargo fmt --all -- --check` for Rust formatting inside `core/`; use `./scripts/workspace.py cargo fmt -- --check` for the repository-wide format check.\n- For core changes, `cargo clippy --workspace --all-targets --all-features -- -D warnings` is the CI-level lint gate.\n- For behavior changes, run the narrow behavior test, for example `OPENDAL_TEST=s3 cargo test behavior --features tests,services-s3`.\n- Behavior tests require backend credentials or fixture setup. Use `.env.example`, `fixtures/`, and `.github/services//` as the source of truth for service-specific setup.\n- Integration crates under `integrations/` have their own CI workflows and should be validated in their own directories when touched.\n- Binding changes should follow the binding's local README/build files and the matching `.github/workflows/ci_bindings_*.yml`.\n\n## Pull Requests\n\n- Before opening a PR, search for similar open PRs, issues, and in-progress branches that already address the same problem. Prefer contributing to or coordinating with existing work over opening a duplicate.\n- Always use `.github/pull_request_template.md` when creating a PR.\n- Keep PR titles and descriptions factual and concise.\n- Do not add AI-tool branding or co-author trailers.\n- If public APIs or user-facing behavior change, update docs and call out the user-facing impact in the PR template.\n\n## Important Notes\n\n- Minimum Rust version is 1.91, configured in `core/Cargo.toml` and checked by CI.\n- Use `opendal_core::raw::{Service, ServiceInfo, ServiceDyn, Servicer, Layer}` for internal service and layer boundaries, and `opendal_core::OperationContext` for runtime resources.\n- Use `opendal_core::raw::oio::{Read, Write, List, Delete, Copy, Compose}` for service operation bodies. `Read` opens range streams that implement `ReadStream`; type-erased handles use the corresponding `*Dyn` adapters.\n- Use `Operator` and `blocking::Operator` as the public API entry points.\n\n## Security\n\nSecurity model: [SECURITY.md](./SECURITY.md)\n\nAgents that scan this repository should consult `SECURITY.md` and the threat\nmodel it links (`SECURITY-THREAT-MODEL.md`) for the project's in-scope /\nout-of-scope declarations, adversary model, and known non-findings before\nreporting issues.\n\n\n---\nname: opendal-release\ndescription: Execute and verify Apache OpenDAL release-manager work, including weekly ATR candidates, RC tagging, required GitHub Actions checks, ASF SVN dist uploads, Nexus staging close/release, vote discussions, language package readiness, GitHub release, announcements, and release postmortems.\n---\n\n# OpenDAL Release\n\n## Overview\n\nUse this skill for Apache OpenDAL release-manager work. Treat releases as a state machine with externally visible legal and distribution effects, not as ordinary CI chores.\n\nThe primary repository runbook is `website/community/release/release.md`. The split source artifact source of truth is `dev/src/release/package.rs`. Read the relevant source in the current checkout when first needed. Reuse that context across release stages; refresh the affected sections when the checkout or source changes, or when an unresolved question requires it.\n\n## Ground Rules\n\n- Use `gh` for GitHub PRs, issues, discussions, checks, and Actions logs.\n- Do not use web search for repository state. Query live GitHub, SVN, Nexus, crates.io, PyPI, npm, and Maven URLs directly.\n- Do not claim any step succeeded until the external system confirms it.\n- Treat an RC as bound to its tag, target commit, and signed source artifacts. Manual RC tags are signed; weekly preparation creates a lightweight tag and compose signs the artifacts. Do not create a new RC merely because `main` advances after tagging.\n- Do not assume bindings or integrations share the top-level OpenDAL version. Each released binding or integration can have its own version.\n- ATR is the authority for ATR candidates. Other builds and language package staging are optional and do not block starting the vote. Use the manual SVN checklist only for candidates outside ATR.\n- Do not conflate Nexus `Close` before voting with Nexus `Release` after the vote passes.\n- Do not over-block on unrelated/noncritical CI if the release gate is explicitly narrowed.\n- Do not put SVN, Nexus, or mail credentials in commands, files, issue text, PRs, or release notes. Read them from environment variables or an interactive prompt and avoid shell history when possible.\n- Commit messages and public release text must not include agent attribution.\n\n## Version Scope Rules\n\nOpenDAL releases have multiple version scopes:\n\n- `opendal_version`: the final core OpenDAL release version, for example `0.56.0`.\n- `release_version`: the RC directory and RC tag version, for example `0.56.0-rc.4`.\n- Package versions: the versions of individual core, binding, and integration packages listed in `dev/src/release/package.rs`.\n\nRules:\n\n- Use `release_version` for RC tags, vote titles, staged website URLs, and ASF SVN `dist/dev/opendal/${release_version}/` directories.\n- Use `opendal_version` for the final release tag and ASF SVN `dist/release/opendal/${opendal_version}/`.\n- Use package-specific versions for generated source archive names, package repository checks, and language binding or integration readiness.\n- When verifying artifacts, build an explicit package-to-version map from `dev/src/release/package.rs`; do not infer binding or integration versions from `opendal_version`.\n- Weekly versions use the optional PR **Breaking changes** section and\n `breaking-changes` label. Require affected package names and migration text only\n for breaking PRs; do not ask compatible PRs to declare their impact. Follow\n `website/community/release/weekly.md#declaring-breaking-changes` for the format.\n- Inspect `.release/plan.json` at the candidate SHA for the frozen declarations,\n baseline and version decisions. Editing a PR does not change an existing RC.\n- When checking upgrade docs, only check released bindings and integrations that appear in the current package list, and only add upgrade notes for components with breaking changes.\n\n## Release State Model\n\nUse these states explicitly when reporting status:\n\n1. `planning`: release discussion/tracking issue/version bump not done.\n2. `bump-pr`: version/changelog/upgrade/dependency updates are in PR.\n3. `crates-bootstrapped`: the bootstrap workflow has authenticated every Rust crate in the scanned `main` publish plan, and every name exists with the exact Trusted Publisher and `trustpub_only` enabled.\n4. `rc-tagged`: RC tag exists and was pushed at the intended commit.\n5. `rc-ci`: required release workflows, triggered by tag push or explicit dispatch, are still running or failed.\n6. `artifacts-built`: local release tooling or source compose generated ASF source artifacts.\n7. `source-staged`: signed artifacts are uploaded to ATR compose or ASF SVN `dist/dev`; record which location and revision will be verified.\n8. `nexus-closed`: Java staging repo is closed and publicly accessible.\n9. `vote-open`: the formal vote is open and identifies the verified candidate and source location.\n10. `vote-passed`: at least 72 hours elapsed and binding vote requirements are met.\n11. `official-release`: final tag, approved source publication, package repositories, GitHub release, and announcement are complete.\n\nWeekly preparation replaces the manual bump-PR path and can compose sources while downstream builds run. A candidate Discussion confirms upload and dispatch, not readiness to vote.\nFor new `releases/-rc.N` branches, hourly ATR synchronization maintains\nthat Discussion through status comments. Start future ATR votes with automatic\nresolution and publication enabled, and verify both settings in the returned\ntask. ATR attempts resolution at the scheduled vote end; unresolved votes need\nmanual follow-up. Resolving a vote as passed starts final publication, announcement,\nversion-sync PR creation and same-version RC branch cleanup. Do not duplicate\nthose operations manually. Older weekly branches stay on the manual path.\n\nRetry transient failures against the same candidate and reuse existing signed artifacts. Create a new RC when source or workflow changes must be included, or the candidate is rejected; do not regenerate an RC merely to recover a missing dispatch or a staging permission failure.\n\n## Choose the Current Phase\n\nLoad only the references needed for the requested phase or unresolved issue. Continue from the established release state; opening this skill does not require restarting release preparation. References retain phase-specific gates and command examples. Repository paths and shell commands are relative to the repository root; Markdown links are relative to their containing file.\n\n- [Preparation](references/preparation.md): start a release or prepare version, changelog, and upgrade updates.\n- [Rust crate bootstrap](references/rust-bootstrap.md): reserve crate names or inspect the protected bootstrap prerequisites.\n- [Release candidate](references/rc.md): prepare a weekly ATR candidate or manual RC, inspect required CI, recover missing dispatches, stage source artifacts, or close Nexus staging.\n- [Go readiness](references/go.md): release or verify Go bindings and service modules when Go is in scope.\n- [Rust readiness](references/rust.md): inspect the publish plan, packaging constraints, or release helper CI.\n- [Vote](references/vote.md): check pre-vote readiness, prepare the vote, or determine and publish its result.\n- [Official release](references/official-release.md): publish after the vote passes and complete release follow-up.\n- [Troubleshooting](references/troubleshooting.md): diagnose a matching CI, registry, staging, or authentication failure.\n"}