بنقرة واحدة
forge
يحتوي forge على 13 من skills المجمعة من C5C3، مع تغطية مهنية على مستوى المستودع وصفحات skill داخل الموقع.
Skills في هذا المستودع
Audit Status condition coverage end-to-end for every forge operator — every condition type set by a sub-reconciler must appear in that operator's subReconcilerConditionTypes map (so metrics labels resolve), every sub-reconciler must have a unit test, and every condition the operator's reference docs document must be set somewhere in code. Use when asked to check condition coverage, after adding or renaming a sub-reconciler or a condition type, or when a Prometheus condition_type label suddenly shows up as UNKNOWN.
Audit the forge documentation for drift against the implementation — the architecture/docs/ chapters vs the operator code, the docs/ user-facing reference vs the deploy/ infrastructure stack. Use when asked to check documentation drift, after adding or removing a sub-reconciler, status condition, operator binary, or infrastructure component, or before tagging a release.
Audit whether every Keystone / c5c3 CR fixture under tests/e2e/ and tests/e2e-chaos/ still validates against the *current* CRD schema — no removed Spec field is still referenced, every fixture's apiVersion / kind matches a real CRD, every invalid-cr fixture is reachable from a Chainsaw test, and the existing verify-invalid-cr-fixtures generator stays in sync with its hand-edited outputs. Use when asked to check fixture drift, after editing the Keystone CRD or the validating webhook, or before a release.
Audit the forge Go workspace for dependency-version drift between the operators/<op>/go.mod files and internal/common/go.mod — controller-runtime, k8s.io/api, k8s.io/apimachinery, k8s.io/client-go, the Go directive, and the toolchain pin must stay in lockstep so the workspace builds the same versions everywhere. Use when asked to check workspace deps, after running `go get` in one module, or after Renovate bumps controller-runtime in only one of the modules.
Audit whether every OpenStack release under releases/<version>/ is fully wired through the forge repo — the mandatory release config files, the per-release Tempest config directory the CI matrix generator hard-requires, the per-release basic-deployment e2e variant, the default-release references in deploy/kind/, hack/, and ci.yaml, the Renovate regression tests, the upgrade-path e2e suites, and the version-pattern lockstep across CRD marker, webhook, and release.ParseRelease. Use when asked to check release wiring, after adding or removing a releases/<version>/ directory, or before a release when a stale default tag or an orphan Tempest directory would fail the pipeline.
Audit whether every pinned version in the forge repo — OpenStack release tags under releases/<version>/source-refs.yaml, shell-script VERSION constants under hack/, kind / FluxCD HelmRelease versions under deploy/kind/ and deploy/flux-system/, and tool-version pins in Makefile + .github/workflows — is covered by either a native Renovate manager or a customManager rule in renovate.json with a paired packageRules entry, and that tool pins duplicated between the Makefile and ci.yaml stay in lockstep. Use when asked to check Renovate coverage, after adding a new pinned dependency, or when a previously-bumped pin silently stopped receiving updates.
Audit whether every onboarded OpenStack service stays in structural lockstep with the keystone reference implementation across the five onboarding layers — container image under images/<svc>/, service operator under operators/<svc>/, CI/e2e/deploy wiring, ControlPlane integration in operators/c5c3/, and the documentation set under docs/. Use when asked to check service parity, after merging or while reviewing a service-onboarding PR, or when a second (or later) service starts drifting from the scaffolding conventions keystone defines.
Audit whether every CR validation rule stays in parity across its four representations — the declarative kubebuilder markers and XValidation/CEL rules in operators/<op>/api/ and internal/common/types, the validating webhook in *_webhook.go, the webhook unit tests, and the invalid-cr e2e rejection corpus under tests/e2e/<op>/invalid-cr/. Use when asked to check validation parity, after adding or changing a validation rule or webhook, or after a CEL rule had to be demoted to webhook-only enforcement.
Diagnose a failing chainsaw e2e job in the forge CI — resolve the failed run, pull the failed-step logs and JUnit/diagnostic evidence, map the failure back to the suite directory under tests/, classify it against the known flake patterns, and reproduce it locally against a kind cluster. Use when a CI e2e job fails (e2e-infra, e2e-operator, e2e-chaos, e2e-prometheus, e2e-controlplane, e2e-operator-upgrade, tempest), when asked to debug a chainsaw suite, or when reproducing an e2e failure locally.
Analyze and prepare the addition of a new OpenStack release (e.g. 2026.2) into forge — inventory the touch points the auto-discovery does not cover (release config files under releases/<version>/, the Tempest config directory the CI matrix generator hard-requires, per-release e2e variants, constraint overrides), and walk the decision points: moving the default release, extending the upgrade-path tests, and retiring an old release. Use when asked to add or onboard a new OpenStack release, to bump the release matrix, or to remove an old release from the repo.
Analyze and prepare the onboarding of a new OpenStack service into forge — inventory the five layers (container image, service operator, CI/e2e, ControlPlane integration, documentation) against the Keystone reference implementation, check what keystone scaffolding must be generalized into internal/common first, and draft the phased meta issue ready to be split into sub-issues. Use when asked to onboard or add a new OpenStack service (e.g. Glance, Nova, Neutron, Placement), to prepare a service meta issue, or to assess readiness for the next service operator.
Audit whether every forge operator CRD is in sync across its three representations — the Go +kubebuilder source under operators/<op>/api/, the controller-gen output under operators/<op>/config/crd/bases/, and the Helm chart copy under operators/<op>/helm/<op>-operator/crds/. Use when asked to check CRD drift, after editing a *_types.go file or a kubebuilder marker, or before a release to catch a CRD that the cluster will reject because the schema is older than the controller.
Audit SPDX / REUSE compliance across the forge source tree — every *.go, *.sh, hand-authored YAML, and CI workflow file should carry matching SPDX-FileCopyrightText and SPDX-License-Identifier headers, every license referenced in a header has a corresponding text under LICENSES/, and architecture/REUSE.toml stays well-formed. Use when asked to check SPDX or REUSE coverage, after adding a new source file, or before tagging a release where SAP supply-chain audits require clean REUSE output.