docs: Approve code review policy and CODEOWNERS layout

[jmccaffrey-nv]

Adds an initial draft of the PLC +2 Code Review gate (MVSB-32942) along with a sectioned CODEOWNERS file mapping subsystems to placeholder @NVIDIA/flashdreams-* teams. The doc embeds the literal Security Review Checklist from NVIDIA's PLC: Code Review Excellence training as an LLM-fillable table for reviewers.

Both files are drafts pending team consensus on:

• subsystem boundaries and per-recipe owner teams,
• which paths require @NVIDIA/flashdreams-security sign-off,
• branch protection settings to flip on (require Code Owner review, dismiss stale approvals, no admin bypass).

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

[janickm]

this is fragile and not secure anyway, could we request pgp-signed commits instead?

[jmccaffrey-nv]

OSRB Contribution requested this specific DCO language . We can add pgp-signed commits in addition, but I think need to keep Signed-off-by trailer , unless consult with OSRB to change to PGP signatures .

Use the following Developer Certificate of Origin (DCO) for 3rd party contributions to the NVIDIA project code: Link to DCO: https://developercertificate.org/ (Example NV project with DCO contribution process: https://github.com/NVIDIA/TensorRT/blob/main/CONTRIBUTING.md)

[jmccaffrey-nv]

Re-reading, https://developercertificate.org/ itself doesn't call for git commit --sign-off, possibly we can switch to PGP signing , change CONTRIBUTING.md, and keep the verbatim DCO text .

[jmccaffrey-nv]

There's another confluence version from OSRB which does have CONTRIBUTING.md template of --signoff .
But as that is outside of DCO exactly in CONTRIBUTING.md, probably we can substitute PGP-signed if that adds authentication .

https://nvidia.atlassian.net/wiki/spaces/OSS/pages/3293716536/DCO

#### Signing Your Work
* We require that all contributors "sign-off" on their commits. This certifies that the contribution is your original work, or you have rights to submit it under the same license, or a compatible license.
  * Any contribution which contains commits that are not Signed-Off will not be accepted.
* To sign off on a commit you simply use the `--signoff` (or `-s`) option when committing your changes:
  ```bash
  $ git commit -s -m "Add cool feature."

This will append the following to your commit message:

Signed-off-by: Your Name <[email protected]>

• Full text of the DCO (https://developercertificate.org/):
  ...

[janickm]

only allowing the security team and not maintainers to update the lock / project files could be a bottleneck - can we make sure to have at least one (ideally more) security team members in each timezone (EU/US)?

[jmccaffrey-nv]

We can ensure we have timezone coverage in @NVIDIA/flashdreams-security.

My thinking with this CODEOWNERS setup is to control the dependencies more tightly than contributions in flashdreams code or integrations/ .

[greptile-apps]

Greptile Summary

This PR introduces the initial CODEOWNERS mapping and the accompanying code-review policy document (docs/code_review.md) for the FlashDreams repository, establishing a three-team ownership model and embedding NVIDIA's PLC security-review checklist.

• .github/CODEOWNERS — correctly layered rules using "last match wins" semantics, covering default, integrations, licensing/attribution, dependency manifests, and review-policy paths across three placeholder GitHub teams.
• docs/code_review.md — explains the PR approval flow, ownership table, security-sensitive paths, and a 23-item LLM-fillable security checklist; references CONTRIBUTING.md for fork/DCO mechanics.
• The document describes branch-protection settings (Code Owner review required, stale-approval dismissal, no admin bypass) in present tense as already active, while the PR description lists them as still pending — this gap needs to be resolved before or immediately after merge to avoid misrepresenting the project's enforcement posture.

Confidence Score: 3/5

The CODEOWNERS file is safe to merge; the policy document needs its branch-protection claims aligned with what is actually enabled before or at merge time.

The CODEOWNERS syntax, rule ordering, and glob scoping are all correct. The policy document's present-tense description of branch-protection settings that have not yet been enabled is the key concern — it could cause contributors or auditors to assume enforcement is in place before it actually is.

docs/code_review.md — branch-protection tense/status needs to reflect what is actually enabled at merge time.

Important Files Changed

Filename	Overview
docs/code_review.md	New code-review policy document; branch-protection settings are written as already enabled but are still pending per the PR description, which will mislead readers after merge. Minor ownership discrepancy in the subsystem table for ludus-renderer/pyproject.toml.
.github/CODEOWNERS	New CODEOWNERS file with well-commented, layered ownership rules; glob scoping, rule ordering, and "last match wins" semantics are correct. The ludus-renderer/pyproject.toml rule diverges slightly from the doc table but is internally consistent.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Contributor opens PR] --> B[GitHub reads CODEOWNERS\ncomputes owning teams]
    B --> C{Paths touched}
    C -->|integrations/*| D["@NVIDIA/flashdreams-integrations\nor @NVIDIA/flashdreams-maintainers"]
    C -->|LICENSE, LICENSES/, NOTICE, reuse.toml\npyproject.toml, uv.lock| E["@NVIDIA/flashdreams-security"]
    C -->|integrations/*/pyproject.toml| F["@NVIDIA/flashdreams-integrations\nor @NVIDIA/flashdreams-security"]
    C -->|.github/CODEOWNERS, docs/code_review.md| G["@NVIDIA/flashdreams-maintainers\nor @NVIDIA/flashdreams-security"]
    C -->|everything else| H["@NVIDIA/flashdreams-maintainers"]
    D & E & F & G & H --> I[Code owner approves\nvia GitHub review UI]
    I --> J{CI green?\nDCO signed?}
    J -->|Yes| K[Maintainer squash-merges]
    J -->|No| L[Fix and re-push\nstale approval dismissed]
    L --> I

Loading

_{Reviews (1): Last reviewed commit: "docs: unify ownership tiers for licensin..." | Re-trigger Greptile}

[greptile-apps]

Branch protection described as active before it is configured

The document uses present tense throughout the "How review and merge work on GitHub" section ("is configured so that … enabled"), and the "No bypass, no waiver" section repeats those settings as current fact. The PR description, however, calls these out as still pending: "branch protection settings to flip on (require Code Owner review, dismiss stale approvals, no admin bypass)". Once this document merges, any reader — including a new contributor or an auditor validating PLC compliance — will believe all of these controls are already enforced. If a direct push or admin bypass is exercised before the settings are actually enabled, the documentation will actively misrepresent the project's security posture. Consider using future tense ("will be configured") or adding a clearly-visible callout (e.g., a > **TODO:** block) until the branch-protection settings are confirmed live.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

[greptile-apps]

Doc table misrepresents ludus-renderer/pyproject.toml ownership

The "Dependency manifests & lockfiles" row lists nested ludus-renderer/{pyproject.toml,uv.lock} with @NVIDIA/flashdreams-security as the sole owner. In the actual CODEOWNERS file, however, integrations/alpadreams/ludus-renderer/pyproject.toml is assigned to @NVIDIA/flashdreams-integrations @NVIDIA/flashdreams-security (i.e., either team can approve). Only the uv.lock for that path is security-only. A reviewer consulting the table to understand who must approve a ludus-renderer/pyproject.toml change will get incorrect information, potentially thinking security sign-off is mandatory when an integrations approval alone would satisfy the branch-protection check.