Skip to content

OAPE-815: Add Level 2 team context documentation #147

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
PillaiManish wants to merge 1 commit into
base: main
Choose a base branch
from
Draft

OAPE-815: Add Level 2 team context documentation #147

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
93 changes: 93 additions & 0 deletions docs/team/ci_cd_configuration.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,93 @@
# CI/CD Configuration

## CI System

The project uses **OpenShift CI (Prow)** for PR validation and merge gating, configured via
`.ci-operator.yaml` at the repo root.

### Build Root

```yaml
build_root_image:
name: builder
namespace: ocp
tag: rhel-9-golang-1.25-openshift-4.21
```

This defines the base image used for CI builds — RHEL 9 with Go 1.25 targeting OCP 4.21.

## Required Checks Before Merge

| Check | What It Runs |
|-------|--------------|
| `make verify` | `go vet` + `gofmt` + golangci-lint |
| `make test` | Unit tests via envtest (K8s 1.31.0 binaries) |

Both must pass for a PR to be mergeable. Use `/retest` to re-trigger failed checks.

## E2E Testing

E2E tests (`make test-e2e`) run against a live OpenShift cluster with a 45-minute timeout.
These are triggered on specific Prow jobs, not on every PR push.

## Image Builds

### Operator Image

The `Dockerfile` uses a multi-stage build:
- **Builder stage**: `registry.ci.openshift.org/ocp/builder:rhel-9-golang-1.25-openshift-4.21`
- **Runtime stage**: `registry.access.redhat.com/ubi9-minimal:9.4`
- Runs as non-root UID `65532:65532`
- FIPS-compliant: uses `CGO_ENABLED=1` for OpenSSL linkage

### Bundle Image

The `bundle.Dockerfile` packages OLM metadata (CSV, CRDs, scorecard tests) as a scratch-based
image for catalog inclusion.

## FIPS Requirement

Production and CI builds must use `hack/go-fips.sh` which sets:
- `GOEXPERIMENT=strictfipsruntime`
- Build tags: `strictfipsruntime,openssl`

A build that prints `WARN: building without FIPS support` is not shippable.

## OLM Bundle

Generated via `make bundle`, which produces:
- `bundle/manifests/` — ClusterServiceVersion + CRDs
- `bundle/metadata/` — annotations for OLM
- `bundle/tests/scorecard/` — OLM scorecard tests

Current version: `1.1.0` (set in `Makefile` `VERSION` variable).

## Release Branches

| Branch | Target | Go Version | OCP Version |
|--------|--------|------------|-------------|
| `main` | Development | 1.25 | 4.21 |
| `release-1.1` | Production release | 1.25 | 4.21 |
| `ai-staging-release-1.0.0` | Stage (Konflux) | 1.23 | 4.19 |
| `ai-staging-release-0.2.0` | Stage (Konflux, earlier) | 1.23 | 4.19 |

## Stage Builds (Konflux)

Stage builds publish to `registry.stage.redhat.io` via the Konflux/Tekton pipeline:

- **Registry path**: `registry.stage.redhat.io/zero-trust-workload-identity-manager/`
- **Components**: operator image + operator-bundle image
- **Pipeline checks**: `check-labels` (validates image `name` label matches registry path)
- **Branches**: `ai-staging-release-*` branches track stage releases

The bundle image requires a `LABEL name=` matching the registry path for the `check-labels`
pipeline task to pass.

## Deployment

| Method | Command |
|--------|---------|
| CRDs only | `make install` / `make uninstall` |
| Full operator | `make deploy IMG=<registry>/<image>:<tag>` |
| Local development | `make run` (runs against connected cluster) |
| Consolidated installer | `make build-installer` (generates `dist/install.yaml`) |
68 changes: 68 additions & 0 deletions docs/team/code_review_standards.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,68 @@
# Code Review Standards

## Reviewers and Approvers

All reviewers and approvers are listed in the `OWNERS` file at the repo root:

| GitHub Handle | Roles |
|---------------|-------|
| TrilokGeer | Reviewer, Approver |
| rausingh-rh | Reviewer, Approver |
| bharath-b-rh | Reviewer, Approver |
| swghosh | Reviewer, Approver |
| nhegde07 | Reviewer, Approver |

## Approval Requirements

A PR requires both:

- At least one `/lgtm` from a reviewer (signals "code looks good")
- At least one `/approve` from an approver (signals "change is appropriate for the project")

Both can come from the same person if they hold both roles.

## Prow Commands

| Command | Effect |
|---------|--------|
| `/lgtm` | Add LGTM label (reviewer approval) |
| `/lgtm cancel` | Remove LGTM label |
| `/approve` | Add Approved label (approver approval) |
| `/approve cancel` | Remove Approved label |
| `/hold` | Block merge (adds `do-not-merge/hold`) |
| `/hold cancel` | Release hold |
| `/retest` | Re-run failed CI checks |
| `/cc @username` | Request review from a specific person |
| `/assign @username` | Assign PR to someone |

## Turnaround Expectations

[TODO: team to fill in — target review turnaround time, e.g., "initial review within 1 business day"]

Comment on lines +38 to +41

@coderabbitai coderabbitai Bot Jul 3, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
set -euo pipefail

printf '\n--- target file excerpt ---\n'
nl -ba docs/team/code_review_standards.md | sed -n '1,120p'

printf '\n--- placeholder search in docs/team ---\n'
rg -n "\[TODO: team to fill in|draft|turnaround|review turnaround" docs/team -S || true

Repository: openshift/zero-trust-workload-identity-manager

Length of output: 253

🏁 Script executed:

#!/bin/bash
set -euo pipefail

printf '\n--- target file excerpt ---\n'
sed -n '1,140p' docs/team/code_review_standards.md | cat -n

printf '\n--- placeholder search in docs/team ---\n'
rg -n "\[TODO: team to fill in|draft|turnaround|review turnaround" docs/team -S || true

Repository: openshift/zero-trust-workload-identity-manager

Length of output: 3819

Fill in the review turnaround SLA. This section still reads as a placeholder; add the agreed target review turnaround time or mark the doc as draft until it’s finalized.

🤖 Prompt for AI Agents 
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@docs/team/code_review_standards.md` around lines 38 - 41, The Turnaround
Expectations section is still a placeholder, so update the code_review_standards
doc to either state the agreed review turnaround SLA or clearly mark it as draft
until finalized. Use the existing “Turnaround Expectations” heading and replace
the TODO text with the actual target timing so the standard is explicit and
actionable.

## What Reviewers Should Check

- [ ] Tests are present for new/changed logic
- [ ] `make verify` passes (lint, fmt, vet)
- [ ] No hardcoded image references (images must come from environment variables)
- [ ] Status conditions are updated when reconciliation behavior changes
- [ ] Static resources use bindata YAML; only spec-dependent resources are built in Go
- [ ] API changes include updated CRD markers and `make manifests` was run
- [ ] Error messages use `%w` wrapping with actionable context
- [ ] No unrelated changes bundled into the PR

## Merge Criteria

A PR is eligible to merge when:

1. CI is green (`make verify` + `make test` pass)
2. At least one `/lgtm` and one `/approve` are present
3. No `/hold` label is active
4. No unresolved review comments marked as "changes requested"

## PR Best Practices

- Keep PRs focused — one logical change per PR
- Write a clear description explaining the *why*, not just the *what*
- If a PR touches multiple controllers, explain the cross-cutting reason
- Address review feedback with additional commits (do not force-push during review)
- Use draft PRs for work-in-progress that needs early feedback
92 changes: 92 additions & 0 deletions docs/team/dependency_map.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,92 @@
# Dependency Map

## Upstream Dependencies (What We Consume)

### SPIFFE/SPIRE Project

We consume upstream container images — we do not build SPIRE from source.

| Component | Version | Source |
|-----------|---------|--------|
| SPIRE Server | 1.14.7 | `ghcr.io/spiffe/spire-server` |
| SPIRE Agent | 1.14.7 | `ghcr.io/spiffe/spire-agent` |
| SPIFFE CSI Driver | 0.2.8 | `ghcr.io/spiffe/spiffe-csi-driver` |
| SPIRE Controller Manager | 0.6.4 | `ghcr.io/spiffe/spire-controller-manager` |
| SPIRE OIDC Discovery Provider | 1.14.7 | `ghcr.io/spiffe/oidc-discovery-provider` |

### Go Libraries

| Dependency | Version | Purpose |
|------------|---------|---------|
| `sigs.k8s.io/controller-runtime` | v0.22.4 | Controller framework |
| `k8s.io/api` | v1.35.3 | Kubernetes API types |
| `k8s.io/apimachinery` | v1.35.3 | API machinery utilities |
| `k8s.io/client-go` | v1.35.3 | Kubernetes client |
| `github.com/openshift/api` | latest | OpenShift API types (Routes, SCCs) |
| `github.com/openshift/build-machinery-go` | latest | OpenShift build helpers (bindata) |
| `github.com/spiffe/spire-controller-manager` | v0.6.4 | ClusterSPIFFEID CRD types |
| `github.com/spiffe/go-spiffe/v2` | v2.6.0 | SPIFFE ID parsing (indirect) |

### Build Infrastructure

| Dependency | Purpose |
|------------|---------|
| OpenShift CI (Prow) | PR validation, merge gating |
| Konflux/Tekton | Stage and production image pipelines |
| Operator SDK v1.39.0 | Bundle generation, scorecard |
| OLM | Operator lifecycle on-cluster |

## Downstream Consumers (Who Depends On Us)

### OpenShift Service Mesh (OSSM)

OSSM consumes the SPIRE Agent's Workload API socket for mTLS identity in the service mesh
data plane. The integration point is the agent socket path
(`/run/spire/agent-sockets/spire-agent.sock`) mounted via the SPIFFE CSI Driver.
Comment on lines +43 to +45

@coderabbitai coderabbitai Bot Jul 3, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
set -euo pipefail

printf '\n== File size ==\n'
wc -l docs/team/dependency_map.md

printf '\n== Relevant lines ==\n'
cat -n docs/team/dependency_map.md | sed -n '35,55p'

printf '\n== Search for SPIFFE/SPIRE mount path references ==\n'
rg -n "spire-agent\.sock|agent-sockets|Workload API socket|SPIFFE CSI Driver|SPIRE Agent" docs . --glob '!**/.git/**'

Repository: openshift/zero-trust-workload-identity-manager

Length of output: 13651

🏁 Script executed:

#!/bin/bash
set -euo pipefail

printf '\n== Any SPIFFE CSI Driver mount-path wording in repo ==\n'
rg -n "mounted via the SPIFFE CSI Driver|mounted path|socket directory|socket file" docs . --glob '!**/.git/**'

printf '\n== If docs mention the directory explicitly elsewhere ==\n'
rg -n "/run/spire/agent-sockets(?:/spire-agent\.sock)?" docs . --glob '!**/.git/**'

Repository: openshift/zero-trust-workload-identity-manager

Length of output: 2496

🌐 Web query:

SPIFFE CSI Driver mount socket directory workload API socket path documentation

💡 Result:

The SPIFFE CSI Driver is designed to inject the SPIFFE Workload API socket into workload pods as an ephemeral inline volume, avoiding the need for direct hostPath access in those pods [1][2]. Key architectural and configuration details regarding the socket directories include: 1. Workload API Socket Directory: The SPIFFE CSI Driver and the Workload API implementation (such as the SPIRE Agent) must share the directory containing the Workload API Unix Domain Socket [1]. This is typically achieved using a hostPath volume on the node [1][3]. An emptyDir volume is generally avoided for this purpose because restarting the CSI driver pod would invalidate the mount for existing workloads [1][3]. 2. CSI Driver Configuration: - Workload API Socket Directory: The driver is configured with the flag -workload-api-socket-dir, which specifies the path where it expects to find the Workload API socket provided by the SPIFFE implementation (e.g., /spire-agent-socket) [3][4]. - CSI Socket Path: The path for the communication between the Kubelet and the CSI driver itself is configured via -csi-socket-path, commonly placed in a directory like /var/lib/kubelet/plugins/csi.spiffe.io [3][4]. 3. Workload Usage: Workload pods define the volume using the csi driver name csi.spiffe.io [5]. The driver performs a read-only bind mount of the directory containing the Workload API socket into the workload container at the specified mountPath [1][2]. Once a pod is destroyed, the driver automatically removes this bind mount [2]. For implementation, ensure that the hostPath volume shared between the SPIRE agent and the SPIFFE CSI driver has the appropriate permissions and type (e.g., DirectoryOrCreate) [3][4]. Documentation suggests referencing the official SPIFFE CSI Driver repository for deployment examples and manifest configurations [1][6].

Citations:

Describe the mounted directory, not the socket file
/run/spire/agent-sockets is the mounted path; spire-agent.sock lives inside it. Naming the socket file here can mislead operators about the config value.

Suggested wording 
- The integration point is the agent socket path (`/run/spire/agent-sockets/spire-agent.sock`) mounted via the SPIFFE CSI Driver.
+ The integration point is the agent socket directory (`/run/spire/agent-sockets`, containing `spire-agent.sock`) mounted via the SPIFFE CSI Driver.
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
OSSM consumes the SPIRE Agent's Workload API socket for mTLS identity in the service mesh
data plane. The integration point is the agent socket path
(`/run/spire/agent-sockets/spire-agent.sock`) mounted via the SPIFFE CSI Driver.
OSSM consumes the SPIRE Agent's Workload API socket for mTLS identity in the service mesh
data plane. The integration point is the agent socket directory (`/run/spire/agent-sockets`, containing `spire-agent.sock`) mounted via the SPIFFE CSI Driver.
🤖 Prompt for AI Agents 
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@docs/team/dependency_map.md` around lines 43 - 45, The dependency map text is
naming the SPIRE Agent socket file instead of the mounted directory, which can
confuse operators about the actual mount value. Update the wording in the
OSSM/SPIRE integration description to refer to the mounted path used by the
SPIFFE CSI Driver, and use the existing dependency map phrasing around the
integration point to keep the location clear without calling out the socket
filename.


**Coordination required when**: changing the default socket path, agent DaemonSet labels,
or SDS configuration.

### Cluster Administrators

Cluster admins deploy and configure the operator via OLM. They create the singleton CRs
(`ZeroTrustWorkloadIdentityManager`, `SpireServer`, `SpireAgent`, etc.) to configure the
SPIRE stack for their cluster.

### OLM Catalog

The operator bundle is published to the OLM catalog via Konflux pipelines. Downstream
catalog builds consume our bundle image from `registry.stage.redhat.io` (stage) or
`registry.redhat.io` (production).

## Cross-Team Coordination

| Team | Integration Point | When to Coordinate |
|------|-------------------|-------------------|
| **OSSM** | SPIRE agent socket path, SDS config | Socket path changes, agent config changes |
| **OCP Release** | Release branch cuts, image mirroring | New release branches, version bumps |
| **Konflux/CPaaS** | Stage and production image pipelines | New components, registry path changes, label fixes |
| **Security/Compliance** | FIPS requirements, CVE response | Dependency updates, security patches |

## Impact Analysis Quick Reference

**If we change something, who might be affected?**

| Change Type | Affected Parties |
|-------------|-----------------|
| Agent socket path | OSSM, any workload using CSI driver volumes |
| CRD API fields | Cluster admins, documentation, OLM CSV |
| Operator image | Konflux pipeline, OLM catalog |
| Bundle metadata | OLM catalog, Konflux check-labels |
| Go dependency bump | CI build, FIPS compliance verification |
| SPIRE version bump | All operands, E2E tests, OSSM compatibility |

**If someone else changes something, are we affected?**

| External Change | Impact on Us |
|----------------|--------------|
| Upstream SPIRE release | Need to bump operand images, test compatibility |
| OpenShift API changes | May need to update Route/SCC handling |
| controller-runtime release | May need reconciler updates |
| Konflux pipeline changes | May affect stage/prod image builds |
| OCP release branch cut | Need corresponding release branch |
60 changes: 60 additions & 0 deletions docs/team/development_standards.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,60 @@
# Development Standards

## Language and Toolchain

- **Go 1.25** (specified in `go.mod`)
- **Vendored dependencies** — all dependencies are committed via `go mod vendor`; run
`make vendor` after any dependency change
- **Scaffolding** — Kubebuilder v4 with Operator SDK v1.39.0 extensions

## Code Organization

- One controller per CRD kind, located in `pkg/controller/<crd-name>/`
- Static Kubernetes resources (RBAC, ServiceAccounts, Services) live as YAML in `bindata/`
and are loaded via go-bindata at runtime
- Resources whose shape depends on CR spec fields are constructed programmatically in Go
- Shared utilities (constants, labels, validation, proxy) go in `pkg/controller/utils/`
- API type definitions live in `api/v1alpha1/`; run `make manifests` after any change

## Formatting and Style

- `gofmt` and `goimports` are enforced — run `make fmt` before committing
- Line length limit (`lll`) applies to `api/` files; relaxed for `pkg/` files
- Duplicate code detection (`dupl`) applies to `api/` files; relaxed for `pkg/`
- Use `fmt.Errorf("context: %w", err)` for error wrapping (never `%v`)

## Linting

golangci-lint is run via `make lint` with the following enabled linters:

`dupl`, `errcheck`, `exportloopref`, `ginkgolinter`, `goconst`, `gocyclo`, `gofmt`,
`goimports`, `gosimple`, `govet`, `ineffassign`, `lll`, `misspell`, `nakedret`, `prealloc`,
`revive`, `staticcheck`, `typecheck`, `unconvert`, `unparam`, `unused`

Configuration: `.golangci.yml` (5 minute timeout, parallel runners enabled).

@coderabbitai coderabbitai Bot Jul 3, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win

Hyphenate the timeout description.

5 minute timeout should be 5-minute timeout; that's the wording the lint warning is pointing at.

Suggested fix 
-Configuration: `.golangci.yml` (5 minute timeout, parallel runners enabled).
+Configuration: `.golangci.yml` (5-minute timeout, parallel runners enabled).
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
Configuration: `.golangci.yml` (5 minute timeout, parallel runners enabled).
Configuration: `.golangci.yml` (5-minute timeout, parallel runners enabled).
🧰 Tools
🪛 LanguageTool

[grammar] ~34-~34: Use a hyphen to join words.
Context: ...used Configuration:.golangci.yml` (5 minute timeout, parallel runners enabled...

(QB_NEW_EN_HYPHEN)

🤖 Prompt for AI Agents 
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@docs/team/development_standards.md` at line 34, Update the wording in the
development standards entry so the timeout description is hyphenated correctly;
the phrase in the configuration note for `.golangci.yml` should read “5-minute
timeout” instead of “5 minute timeout.” Locate the text in the standards
document and adjust only that label so it matches the lint warning’s wording.

Source: Linters/SAST tools


## Build Commands

| Command | Purpose |
|---------|---------|
| `make build` | Full cycle: manifests + generate + fmt + vet + compile |
| `make manifests` | Regenerate CRDs, RBAC, webhook config from markers |
| `make generate` | Regenerate DeepCopy methods |
| `make verify` | vet + fmt + lint (CI gate) |
| `make vendor` | `go mod tidy` + `go mod vendor` |

## FIPS Compliance

Production builds must use `hack/go-fips.sh` which sets `GOEXPERIMENT=strictfipsruntime`.
`CGO_ENABLED=1` is required so the runtime links against OpenSSL for FIPS-validated crypto.
Never set `CGO_ENABLED=0` in CI or production builds.

## Detailed Guides

For in-depth patterns, see:

- [Error Handling Guidelines](../error-handling-guidelines.md)
- [API Contracts Guidelines](../api-contracts-guidelines.md)
- [Security Guidelines](../security-guidelines.md)
- [Performance Guidelines](../performance-guidelines.md)
- [Integration Guidelines](../integration-guidelines.md)
57 changes: 57 additions & 0 deletions docs/team/team_overview.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,57 @@
# Team Overview

## Who We Are

The Zero Trust Workload Identity team operates within Hybrid Platforms, responsible for
bringing SPIFFE/SPIRE-based workload identity to OpenShift clusters through a Day-2 operator.

## Mission

Enable zero-trust security for OpenShift workloads by providing automated, policy-driven
workload identity management — issuing, rotating, and verifying cryptographic identities
without requiring application changes.

## What We Own

- **zero-trust-workload-identity-manager** operator — the controller binary, its CRDs, and
all reconciliation logic for deploying and managing the SPIRE stack
- **Operator lifecycle** — OLM bundle, ClusterServiceVersion, catalog entries
- **Operand configuration** — SPIRE Server, SPIRE Agent, SPIFFE CSI Driver, SPIRE Controller
Manager, and OIDC Discovery Provider as deployed on OpenShift
- **Release branches** — production (`release-1.1`) and staging (`ai-staging-release-*`)
- **CI configuration** — OpenShift CI (Prow) jobs and Konflux pipelines for this operator

## What We Do NOT Own

- **Upstream SPIRE development** — we consume upstream releases, we don't maintain the SPIRE
codebase itself
- **OpenShift Service Mesh (OSSM)** — OSSM integrates with our SPIRE agent socket, but OSSM
is owned by a separate team
- **Cluster security policy** — we follow org-wide security guidelines; we don't set them
- **OCP platform release process** — we participate in release cuts but don't own the process

## Team Members

Current reviewers and approvers (from OWNERS):

| GitHub Handle | Role |
|---------------|------|
| TrilokGeer | Reviewer, Approver |
| rausingh-rh | Reviewer, Approver |
| bharath-b-rh | Reviewer, Approver |
| swghosh | Reviewer, Approver |
| nhegde07 | Reviewer, Approver |

[TODO: team to fill in — Tech Lead, Engineering Manager, Product Manager roles]

## Org Placement

[TODO: team to fill in — which pillar/group this team sits under within Hybrid Platforms]

## Repositories

| Repository | Purpose |
|------------|---------|
| `openshift/zero-trust-workload-identity-manager` | Main operator repo |

[TODO: team to fill in — any other repos the team owns or contributes to]
Comment on lines +45 to +57

@coderabbitai coderabbitai Bot Jul 3, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
set -euo pipefail

printf '\n## File contents\n'
git ls-files docs/team/team_overview.md
wc -l docs/team/team_overview.md
cat -n docs/team/team_overview.md | sed -n '1,220p'

printf '\n## Nearby team docs and references\n'
fd -a 'team_overview.md|team' docs . 2>/dev/null | sed -n '1,200p' || true
rg -n --hidden --no-messages 'Hybrid Platforms|Tech Lead|Engineering Manager|Product Manager|zero-trust-workload-identity-manager|TODO: team to fill in' docs . | sed -n '1,240p' || true

Repository: openshift/zero-trust-workload-identity-manager

Length of output: 35555

Fill in the remaining team details docs/team/team_overview.md:45-57 — the Tech Lead/Engineering Manager/Product Manager, org placement, and owned-repo sections are still placeholders. If those details aren’t final yet, mark this page as draft until they are.

🤖 Prompt for AI Agents 
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@docs/team/team_overview.md` around lines 45 - 57, The team overview still
contains placeholder sections for leadership, org placement, and repositories,
so update the docs/team/team_overview.md content with the actual Tech Lead,
Engineering Manager, Product Manager, and Hybrid Platforms pillar/group details,
plus any additional owned repos. If those values are not confirmed yet, mark the
page as draft in the team_overview document instead of leaving TODO
placeholders. Refer to the existing sections in team_overview to keep the
structure consistent.

Loading