feat(reparent): complete miner/rack reparent matrix + cascade device.building_id

[flesher]

Summary

Closes the remaining gaps in the rack/miner reparent matrix on top of the atomic-reparent foundation shipped by PRs #463 (foundation), #464 (cross-site atomic), #466 (group RPCs), and #468 (bulk SQL + concurrency hardening). Operators can now move miners directly into a building (new bulk + single-miner action), move racks directly to a different site from the rack list (row + bulk), and get a confirmation dialog before any rack reparent silently clears rack.building_id. Under the hood, this PR also introduces device.building_id as a peer to device.site_id and keeps it in lockstep with rack membership across every reparent path.

How it works

Miner → building (AssignDevicesToBuilding). The new RPC on BuildingService follows the exact transactional shape AssignDevicesToSite established in PR #464: lock the target building, row-lock the devices in sorted-identifier order, run a per-device conflict check (rack at a different building), and either return PerDeviceBuildingConflict[] with zero writes or apply the batch atomically. The atomic write sets device.building_id, then cascades device.site_id to the target building's site so the two columns stay aligned. An optional force_clear_conflicting_rack_membership flag — gated by rack:manage permission — drops conflicting rack memberships in the same transaction so cross-building moves don't strand miners.

The miner-list client (MinerReparentPicker) drives this with a two-step UI: first call without force; if the response carries conflicts, raise a "Move miners between buildings?" dialog; on Continue, re-dispatch with force=true. Same shape as the cross-site dialog already in place.

Rack → site, with building-clear confirm. The rack list now exposes assignRacksToSite (shipped earlier) as a row action and a bulk action via a new bulkExtraActions slot on FleetGroupActionsMenu. Before dispatching, the client checks each selected rack's current building against the target site using already-loaded allBuildings; if any rack would have its building_id silently cleared (server behavior on a cross-site move), a "Move racks between sites?" dialog fires with the affected building labels. No new RPC — purely a client-side parity fix with the cross-building miner confirm.

device.building_id cascade. Migration 000091 adds the column with ON DELETE SET NULL and backfills it from existing rack membership in the same transaction so the new column ships in a consistent state. Four new sqlc queries (UnassignDeviceBuildingsByRack, CascadeRackDeviceBuildings[Bulk], CascadeAddedDeviceBuildings) mirror the existing site_id cascade family. They're wired into every rack-affecting write path so a rack reparent or membership change keeps member devices' building_id in step:

Path	Trigger	Cascade
AssignRacksToBuilding	Rack moves to a different building	CascadeRackDeviceBuildingsBulk(rackIDs, targetBuildingID) — independent of the site cascade, so a same-site building move still propagates.
AssignRacksToSite	Cross-site move clears rack.building_id	CascadeRackDeviceBuildingsBulk(rackIDs, nil) for the same rack set.
AssignDevicesToRack	Devices added to a rack	CascadeAddedDeviceBuildings so new members inherit the rack's building.
DeleteCollection (rack)	Rack soft-delete	UnassignDeviceBuildingsByRack — clears member building only where it still matches the rack's stamped building.
UpdateCollection (rack), SaveRack	Membership replace on a rack with a building	CascadeRackDeviceBuildings(rackID, rack.BuildingID).

Each cascade query uses IS DISTINCT FROM to skip no-op rows and preserves direct AssignDevicesToBuilding assignments that have diverged from the rack.

Diagrams

sequenceDiagram
  autonumber
  participant UI as "Miner list / Single miner menu"
  participant Picker as "MinerReparentPicker (kind=building)"
  participant Svc as "BuildingService.AssignDevicesToBuilding"
  participant DB as "Postgres (single tx)"

  UI->>Picker: "Add to building"
  Picker->>Svc: "target_building_id, ids, force=false"
  Svc->>DB: "lock building, lock devices, find conflicts"
  alt "device in rack at other building"
    Svc-->>Picker: "conflicts[], no writes"
    Picker->>UI: Move-miners-between-buildings dialog
    UI->>Picker: "Continue"
    Picker->>Svc: "target_building_id, ids, force=true"
    Svc->>DB: "RemoveDevicesFromAnyRack(conflicting ids)"
  end
  Svc->>DB: "UPDATE device SET building_id = target"
  Svc->>DB: "CASCADE device.site_id to target building site"
  Svc-->>Picker: "reassigned_count, site_reassigned_device_count"
  Picker->>UI: "toast + refetch"

Loading

flowchart TD
  A["Rack list: Add to site (row or bulk)"] --> B{"Any rack's current<br/>building belongs to<br/>a different site?"}
  B -- no --> C["AssignRacksToSite"]
  B -- yes --> D[Move-racks-between-sites confirm]
  D -- Cancel --> E["Close picker, no write"]
  D -- Continue --> C
  C --> F["Server: update rack.site_id,<br/>clear rack.building_id,<br/>cascade device.site_id<br/>and device.building_id"]

Loading

flowchart LR
  subgraph "Reparent write paths"
    A1["AssignRacksToBuilding"]
    A2["AssignRacksToSite"]
    A3["AssignDevicesToRack"]
    A4["DeleteCollection (rack)"]
    A5["UpdateCollection / SaveRack"]
  end
  subgraph "Cascade family (sqlc)"
    C1["CascadeRackDeviceBuildingsBulk"]
    C2["CascadeAddedDeviceBuildings"]
    C3["UnassignDeviceBuildingsByRack"]
    C4["CascadeRackDeviceBuildings"]
  end
  A1 --> C1
  A2 --> C1
  A3 --> C2
  A4 --> C3
  A5 --> C4
  C1 --> D[(device.building_id)]
  C2 --> D
  C3 --> D
  C4 --> D

Loading

Areas of the code involved

Area / package / file	What changed	Why it matters for review
proto/buildings/v1/buildings.proto	New AssignDevicesToBuilding RPC + request/response + PerDeviceBuildingConflict enum.	The public contract for the new action; reviewers should sanity-check validators (max_items: 10000, optional target) and the conflict-reason enum.
server/generated/**, client/.../generated/**	Regenerated proto + sqlc.	Generated — skip.
server/migrations/000091_*.{up,down}.sql	New device.building_id column with FK + index + backfill.	Schema change. Backfill seeds the column from existing rack membership; reviewer should verify the FK uses ON DELETE SET NULL and the backfill filters soft-deleted rows.
server/sqlc/queries/building.sql	New AssignDevicesToBuilding, CascadeDevicesSiteForBuilding, FindDeviceBuildingConflicts, GetBuildingSiteID.	Site-cascade analogs for the building-id direction; all use IS DISTINCT FROM for no-op skip.
server/sqlc/queries/device_set.sql	New UnassignDeviceBuildingsByRack, CascadeRackDeviceBuildings[Bulk], CascadeAddedDeviceBuildings.	Cascade family mirrors the existing *Sites* queries one-for-one.
server/internal/domain/buildings/{service,models}.go	New AssignDevicesToBuilding service method, PerDeviceBuildingConflict domain type, cascadeBuildingRackIDs tracking in AssignRacksToBuilding.	Heart of the new RPC + the building-cascade addition to the existing flow. Reviewer should focus on lock ordering and the force-clear branch's residual-conflict check.
server/internal/domain/sites/service.go	AssignRacksToSite now fires CascadeRackDeviceBuildingsBulk after the site cascade.	Keeps cross-site rack moves clearing both columns.
server/internal/domain/collection/service.go	AssignDevicesToRack, DeleteCollection rack branch, UpdateCollection rack branch, SaveRack (replaceRackMembershipAndSlots) now all call the building-cascade peer.	The widest blast radius; reviewer should verify the cascade conditions match the existing site-cascade ones (skip on nil to preserve direct assignments).
server/internal/domain/stores/{interfaces,sqlstores}/{building,collection}.go + mocks	New store methods + regenerated mocks.	Thin wrappers; mock churn is mechanical.
server/internal/handlers/buildings/{handler,translate}.go	New AssignDevicesToBuilding handler + translators.	Permission gating: site:manage always, plus rack:manage when force_clear=true. Mirrors AssignDevicesToSite.
client/src/protoFleet/api/buildings.ts	useBuildings().assignDevicesToBuilding hook that surfaces conflicts via onError(msg, conflicts).	Matches the useSites().assignDevicesToSite shape.
client/.../MinerActionsMenu/MinerReparentPicker.tsx	New kind="building" branch + cross-building confirm dialog + force-retry.	Reviewer should confirm the dialog promise plumbing matches the cross-site path (settle on Cancel + Continue).
client/.../MinerActionsMenu/{MinerActionsMenu,SingleMinerActionsMenu}.tsx	"Add to building" inserted between Add-to-site and Add-to-rack.	Pure ordering + glue.
client/.../FleetGroupActionsMenu/{FleetGroupActionsMenu,FleetGroupListActionBar}.tsx	New bulkExtraActions prop slot for multi-select reparent actions.	Single API change; replaces a scopes.length > 1 filter that previously dropped extras entirely.
client/.../pages/RacksPage.tsx	Row + bulk "Add to site" actions + dispatchRackSiteAssign helper + summarizeBuildingClearance + "Move racks between sites?" dialog.	All rack→site dispatch paths now route through the helper so the confirm fires uniformly.
*_test.go, *.test.tsx	New cascade test + updated mock expectations across affected packages.	Mock churn from new store methods; one new positive test (TestAssignRacksToBuilding_sameSiteCascadesBuilding).

Key technical decisions & trade-offs

• device.building_id as a denormalized peer to device.site_id (Option A) rather than routing miner→building through a rack (Option B) or auto-picking a rack (Option C). Option A makes "miner directly in a building" a representable state and gives the new action the same operator UX as Add-to-site; the cost is a denormalization that must be cascaded everywhere, which this PR pays in full.
• Conflict UX: server-driven for miner→building, client-driven for rack→site. The new RPC returns PerDeviceBuildingConflict[] and the client retries with force=true — same shape as AssignDevicesToSite. The rack→site confirm uses already-loaded building data to detect clearance client-side instead of adding a probe RPC; both flows render the same dialog shape.
• Backfill in the migration, not a separate job. Existing rack members get device.building_id populated from their rack's building_id in the same transaction as the column add, so the cascade has a consistent starting state from the moment the column exists. Trade-off: the migration runs an UPDATE device that scales with rack-membership count; acceptable at current fleet sizes.
• Cascade preserves direct assignments via IS DISTINCT FROM and "match-only" predicates. When unassigning on rack delete, UnassignDeviceBuildingsByRack only nulls devices whose building_id still matched the rack's — operators who used AssignDevicesToBuilding to override don't lose their assignment when the rack goes away. Mirrors the existing site behavior.
• New bulkExtraActions prop on FleetGroupActionsMenu rather than reusing extraActions (which is hidden when more than one scope is selected). Keeps the row-vs-bulk semantics explicit; the existing extras ("View rack", "Edit rack") wouldn't make sense in bulk.
• Explicit-target convention. The new RPC rejects an explicit target_building_id == 0; nil is the only sentinel for Unassigned. Matches AssignDevicesToSite to avoid the "I forgot to populate the int" ambiguity.

Testing & validation

• just lint — clean (eslint, golangci-lint, buf lint).
• Server unit tests in domain/buildings, handlers/buildings, domain/sites, handlers/sites, domain/collection — all pass. New: TestAssignDevicesToBuilding_{writesAndCascadesOnSuccess,rejectsCrossBuildingConflict,unassignedTargetSkipsLockAndCascade,forceClearCascadesRackMembership,rejectsEmptyIdentifiers} + TestAssignRacksToBuilding_sameSiteCascadesBuilding (pins the same-site building cascade gap the site cascade alone left). Existing tests updated to expect the new cascade calls.
• Client vitest — 986 passed, 1 skipped; tsc --noEmit clean.
• Generated code (buf generate, sqlc generate, mockgen) regenerated and verified in sync.
• Not run: sqlstores integration tests (need local Postgres — pre-existing failures unrelated to this diff); E2E (slow, docker-compose).

Pre-merge smoke test (manual)

Recommended click-through since E2E wasn't run:

• Move miners between buildings with mixed-site rack memberships → "Move miners between buildings?" dialog renders + Continue completes.
• Bulk-move racks to a new site where some have buildings → "Move racks between sites?" dialog lists the right building labels.
• Single-rack row "Add to site" → confirm dialog flow works identically to bulk.
• Activity log shows devices.reassigned_to_building events with correct metadata (target_building_id, device_count, site_reassigned_device_count, optional force_cleared_* keys).

Deferred / out of scope

• Building-scoped read consumers (GetBuildingStats, miner-list "building" filter) still resolve through rack membership. The new column makes "unracked miners directly in a building" representable, but no list view / count / filter surfaces it yet — deferred to the BuildingPage refresh.
• No proto-level awareness in the rack→site confirm. The check is purely client-side using already-loaded allBuildings; the server still cascades silently with clearedBuildingCount in the response.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: dacf011072

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[github-actions]

🔐 Codex Security Review

Note: This is an automated security-focused code review generated by Codex.
It should be used as a supplementary check alongside human review.
False positives are possible - use your judgment.

Scope summary

• Reviewed pull request diff only (c01deacc27c4d97727ebe3e469abffab22fca142...c162c4acc1851b44ab1927ff1013d23cbdf7f5a8, exact PR three-dot diff)
• Model: gpt-5.5

💡 Click "edited" above to see previous reviews for this PR.

---

Review Summary

Overall Risk: HIGH

Findings

[HIGH] AssignDevicesToBuilding Uses Org-Scoped Auth For Site-Scoped Mutation

• Category: Auth
• Location: server/internal/handlers/buildings/handler.go:131
• Description: The new AssignDevicesToBuilding handler checks site:manage with an empty authz.ResourceContext{} before resolving the target building’s site. In this auth model, nil SiteID is an org-scoped action, so site-specific narrowing is not applied. The same pattern is used for the optional rack:manage check on line 140.
• Impact: A user with a broad org grant that is intentionally narrowed at a site can still move devices into buildings in that narrowed site, cascade device.site_id, and with force_clear_conflicting_rack_membership, delete rack memberships without a site/rack-scoped authorization check.
• Recommendation: Resolve the target building’s site_id before authorizing and call RequirePermission with authz.ResourceContext{SiteID: targetSiteID}. For force-clear, authorize against the affected rack/site contexts before deleting memberships. Add regression tests for org-scope grants narrowed by a site-specific assignment.

[MEDIUM] Direct Building Assignments Are Invisible To Building-Scoped Miner Reads

• Category: Reliability
• Location: server/internal/domain/buildings/service.go:757
• Description: The new flow writes device.building_id directly, but existing building-scoped miner filtering still only matches rack membership via device_set_rack.building_id. GetBuildingStats uses that filter, so devices successfully assigned to a building without rack membership are not counted or returned in DeviceIdentifiers.
• Impact: Operators can receive a successful “moved to building” result, but the building page, building-scoped miner lists, stats, telemetry rollups, and bulk actions can omit those miners. This makes the new direct-assignment feature behave inconsistently and can lead to missed operations or misleading fleet state.
• Recommendation: Update the miner building filter to include device.building_id = ANY(...) in addition to rack-derived dsr.building_id, and define how include_no_building interacts with direct assignments. Add an integration test that calls AssignDevicesToBuilding for an unracked miner and verifies building-scoped miner queries and GetBuildingStats include it.

Notes

No cryptostealing, pool hijack, shell execution, Nmap/discovery, plugin, Docker/Nginx, JWT, or protobuf wire-format issues were apparent in the reviewed diff.

---

_{Generated by Codex Security Review |
Triggered by: @flesher |
Review workflow run}

[Copilot]

Pull request overview

Extends the fleet hierarchy “reparent” surface to support assigning miners directly to buildings via a new device.building_id denormalized column and AssignDevicesToBuilding RPC, and ensures device.building_id stays consistent across rack/site/building reparent operations (mirroring existing device.site_id cascades). Also adds ProtoFleet UI actions to reparent racks to sites/buildings and miners to buildings, including confirmation dialogs for destructive cross-scope moves.

Changes:

• Add device.building_id (migration 000090) and implement BuildingService.AssignDevicesToBuilding with conflict detection + optional rack-membership force-clear.
• Add SQL + store-layer cascades to keep device.building_id in sync for rack-affecting writes (assign/move/delete/save/update membership).
• Add ProtoFleet UI actions for “Add to building” (miners) and “Add to site/building” (racks), including a cross-site building-clear confirmation dialog.

Reviewed changes

Copilot reviewed 28 out of 38 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
server/sqlc/queries/device_set.sql	Adds building-id cascade/unassign queries for rack membership operations
server/sqlc/queries/building.sql	Adds AssignDevicesToBuilding + conflict lookup + building→site cascade query
server/migrations/000090_add_building_id_to_device.up.sql	Adds device.building_id FK + index + backfill from rack membership
server/migrations/000090_add_building_id_to_device.down.sql	Rolls back the device.building_id column + FK + index
server/internal/handlers/sites/handler_test.go	Updates site handler tests to expect building cascade call
server/internal/handlers/buildings/translate.go	Adds request/response translation helpers for new RPC conflict shape
server/internal/handlers/buildings/handler.go	Adds AssignDevicesToBuilding handler + permission gating
server/internal/handlers/buildings/handler_test.go	Adds/updates building handler tests to cover building cascades
server/internal/domain/stores/sqlstores/collection.go	Implements building cascade/unassign store methods for racks
server/internal/domain/stores/sqlstores/building.go	Implements building-store methods for assign + conflicts + site cascade
server/internal/domain/stores/interfaces/mocks/mock_collection_store.go	Updates mocks for new collection-store building cascade methods
server/internal/domain/stores/interfaces/mocks/mock_building_store.go	Updates mocks for new building-store methods
server/internal/domain/stores/interfaces/collection.go	Extends CollectionStore interface with building cascade/unassign methods
server/internal/domain/stores/interfaces/building.go	Extends BuildingStore interface with assign/conflict/site-cascade methods
server/internal/domain/sites/service.go	Adds device.building_id cascade when racks move across sites
server/internal/domain/sites/service_test.go	Adds expectations for the new building cascade behavior
server/internal/domain/collection/service.go	Adds building cascades to collection updates, deletes, rack assigns, and SaveRack
server/internal/domain/collection/service_test.go	Updates tests to assert building cascades fire appropriately
server/internal/domain/buildings/service.go	Implements AssignDevicesToBuilding service flow + adds building cascade in AssignRacksToBuilding
server/internal/domain/buildings/service_test.go	Adds tests for AssignDevicesToBuilding and same-site building cascades
server/internal/domain/buildings/models/models.go	Adds domain models for per-device building conflicts + request/result shapes
server/generated/sqlc/models.go	Generated (sqlc): adds Device.BuildingID field
server/generated/sqlc/device.sql.go	Generated (sqlc): selects/scans building_id in device queries
server/generated/sqlc/device_set.sql.go	Generated (sqlc): adds new building cascade/unassign query methods
server/generated/sqlc/db.go	Generated (sqlc): prepares/closes new statements
server/generated/sqlc/building.sql.go	Generated (sqlc): adds new building queries + helpers
server/generated/grpc/buildings/v1/buildingsv1connect/buildings.connect.go	Generated (buf/connect): wires new AssignDevicesToBuilding RPC
proto/buildings/v1/buildings.proto	Adds AssignDevicesToBuilding RPC + conflict response types
client/src/protoFleet/features/fleetManagement/pages/RacksPage.tsx	Adds rack “Add to site/building” actions (row + bulk) with confirmation dialog
client/src/protoFleet/features/fleetManagement/components/MinerActionsMenu/SingleMinerActionsMenu.tsx	Adds “Add to building” miner action + messaging updates
client/src/protoFleet/features/fleetManagement/components/MinerActionsMenu/MinerReparentPicker.tsx	Adds building reparent flow with conflict-driven confirmation dialog
client/src/protoFleet/features/fleetManagement/components/MinerActionsMenu/MinerActionsMenu.tsx	Adds bulk “Add to building” miner action + messaging updates
client/src/protoFleet/features/fleetManagement/components/MinerActionsMenu/MinerActionsMenu.test.tsx	Updates action ordering expectations to include building action
client/src/protoFleet/features/fleetManagement/components/FleetGroupActionsMenu/FleetGroupListActionBar.tsx	Adds bulkExtraActions hook to inject bulk-only actions into menus
client/src/protoFleet/features/fleetManagement/components/FleetGroupActionsMenu/FleetGroupActionsMenu.tsx	Supports distinct extra-actions rendering for row vs bulk presentations
client/src/protoFleet/api/generated/buildings/v1/buildings_pb.ts	Generated (buf TS): new RPC/messages/enums for AssignDevicesToBuilding
client/src/protoFleet/api/buildings.ts	Adds assignDevicesToBuilding API wrapper + conflict mapping

Files not reviewed (2)

• server/internal/domain/stores/interfaces/mocks/mock_building_store.go: Generated file
• server/internal/domain/stores/interfaces/mocks/mock_collection_store.go: Generated file

[flesher]

Filed follow-up #492 for the rack→site server-driven preview discussed in review — keeping the current client-side detection here to keep this PR focused on the column + cascade work.

[flesher]

Rebased on main + addressed PR feedback in 96c64a1:

• Migration renumbered 000090 → 000091 (collision with Add reviewable diff line to PR descriptions #487's 000090_allow_mqtt_reassert).
• Fixed cross-building confirm to only fire when all conflicts are clearable (Copilot).
• Registered AssignDevicesToBuilding in ProcedurePermissions (Codex P2).
• Updated stale comments on dedupeStrings + FindDeviceBuildingConflicts (Copilot).
• Filed Multi site: Surface device.building_id in miner list building filter + GetBuildingStats #493 to track surfacing device.building_id in the building filter + GetBuildingStats device scope (Codex P1) — this is the deferred consumer-side work already named in the PR's non-goals.

The useCurtailmentPlanPreview > ignores an older initial preview after a newer refresh flake in CI isn't in my diff (unrelated test, no changes here); should clear on re-run.

Force-pushed after rebase.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 96c64a1448

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[flesher]

Security review triage (5f5824a)

Triaged the Codex Security Review findings:

Finding	Disposition
HIGH #1 — building reassignment can corrupt rack/site invariants (cross-site rack with no building)	Fixed. New DEVICE_IN_RACK_AT_OTHER_SITE conflict reason catches the case where a device's rack lives at a different site than the target building, even with no building on the rack. Force-clear treats it identically to the building variant.
HIGH #2 — direct building assignments invisible to building-scoped queries	Deferred via #493 — matches the explicit non-goal already in the PR description.
HIGH #3a — direct device.building_id not cleared on building soft-delete	Fixed. DeleteBuilding now calls ClearDeviceBuildingsByBuilding in the same tx.
HIGH #3b — AssignBuildingsToSite doesn't cascade device.site_id for direct-FK devices	Fixed. New CascadeDirectDeviceSitesByBuildings runs alongside the rack-path cascade; the aggregate device count covers both.
HIGH #3c — DeleteSite doesn't clear direct device.building_id	Fixed. DeleteSite clears device.building_id for the cascade-deleted buildings before they're soft-deleted.
MEDIUM #4 — site-less building leaves stale device.site_id	Fixed. Cascade fires whenever target_building_id is set, including site-less targets (cascades to NULL).
MEDIUM #5 — building all-mode can exceed 10k cap client-side	Fixed. Same preflight as the site path; specific error message instead of a generic server-validation failure.

Plus the inline Copilot/Codex comments from the previous round — also fixed in 96c64a1 + 5f5824a (cross-building dialog only fires for clearable conflicts; ProcedurePermissions registered; stale comments rewritten; SaveRack building-clear cascade wired). All review threads now resolved.

CI re-running on 5f5824a.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 5f5824a835

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: ee642802cd

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: ecef2adaed

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 1b688a2931

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: e5c240905a

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 23db0b9899

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: c56ad90308

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".