---
id: w6/m4/t007
title: "Render parity: ownerId scoping across REST/GraphQL/MCP"
worker: worker6
status: done
estimate: 25m
depends_on: [w6/m4/t006]
---

## Objective

Verify `ownerId` scoping is consistent across REST, GraphQL, and MCP for Postgres and KeyValue now that t001/t002 fixed/added the underlying labeling, matching Render's `ownerId` semantics (RESEARCH-workspaces.md finding 7).

## Context

- `docs/ADR006-bex-api.md` — bex-api is meant to be Render-compatible across REST/GraphQL/MCP.
- `apps/service.go`'s `ownerId` contract (already correct) is the reference shape for Postgres/KeyValue to match.
- Render's REST owners surface is read-only (RESEARCH-workspaces.md finding 9) — no mutation parity concern here, only list-filter correctness.

## Steps

1. Confirm `ownerId` is accepted/returned identically across Postgres's and KeyValue's REST/GraphQL/MCP adapters (same field name, same filter semantics as Apps).
2. Spot-check the fix against a real multi-workspace scenario (two workspaces, each with its own Postgres/KeyValue, confirm no cross-workspace leakage in list results).
3. Note any remaining drift in `docs/ADR018-render-parity.md` if warranted.

## Files

- `lego/backend/internal/postgres/{rest,graphql,mcp}.go`
- `lego/backend/internal/keyvalue/{rest,graphql,mcp}.go`
- `docs/ADR018-render-parity.md` (update if warranted)

## Acceptance criteria

- [ ] `ownerId` filter behavior confirmed identical across REST/GraphQL/MCP for both Postgres and KeyValue
- [ ] No cross-workspace leakage observed in a two-workspace spot check

## Out of scope

- Dashboard UI surfacing of `ownerId` (not currently exposed there for any resource type).
