Etapa 0: permisos y atribucion para edicion de mapas

[leocagli]

Parte de #2 (modo construcción). Depende de la capa de persistencia.

Problema

Editar el mundo es una operación destructiva: un error borra una ciudad. Hoy no hay ningún control de quién puede tocar qué, porque no hay edición de mapas en absoluto.

Lo que ya existe

La API tiene un mecanismo de admin funcionando, que es el enganche natural:

GAME_DATA_ADMIN_EMAIL
GAME_DATA_ADMIN_ACCOUNT_ID
GAME_DATA_ADMIN_PROXY_TOKEN

Se usa en las rutas PUT /admin/game-data/* que ya existen para objetos, NPCs, recetas y balance.

Alcance

1. Extender ese mecanismo a las rutas de edición de mapas.
2. Permisos por mapa, no globales: un colaborador debería poder editar el mapa que se le asignó sin poder tocar Ullathorpe.
3. Todas las mutaciones quedan atribuidas a una cuenta (quién, qué, cuándo).
4. Rechazar ediciones sobre mapas marcados como protegidos (los mapas de ciudad principales, por ejemplo).

Criterios de aceptación

• Una cuenta sin permiso recibe 403 al intentar editar un mapa
• Una cuenta con permiso sobre el mapa 50 no puede editar el mapa 1
• Toda mutación registra la cuenta que la hizo
• Los mapas protegidos rechazan escritura incluso para admins, salvo un override explícito
• Tests de integración cubriendo los cuatro casos anteriores

Archivos relevantes

• api/src/config.ts (líneas 97 a 99: las tres variables de admin)
• api/src/server.ts (rutas /admin/game-data/* como referencia)

Nota

GAME_DATA_ADMIN_* no está documentado en .env.example. Conviene documentarlo como parte de esta issue.

[ChuckGPTX]

Hi @leocagli — I reviewed the current source for #4 using OpenAI Codex with the account owner’s authorization. I also see the four linked PRs (#47, #110, #129 and #360), so I have not started another competing implementation.

In current main, map mutations in api/src/server.ts use requireAdminEmailSession(). paintTiles() and placeTileEntity() receive the actor account ID, whereas clearTile() does not. A useful acceptance test should exercise deletion/discard attribution as well as painting, and verify that permission for map 50 cannot authorize writes to map 1 or bypass a protected-map restriction.

Is there an available paid contribution to finish this issue—such as integrating the preferred PR and adding the missing route-level regression coverage—within the listed $50 reward? If so, please identify the preferred branch/scope, assign the work, and link the current GrantFox campaign registration and payout terms. I will follow CONTRIBUTING.md and wait for assignment before opening a PR. Any work would disclose AI assistance and report the tests actually run. No award or completed work is claimed here.

[no0bie]

Plan: wire map-edit 403s + per-map grants + attribution in api/src/repositories/mapPermissions.ts and existing admin routes; Spanish JSDoc; map-permissions.integration.test.ts for unauthorized 403, grants, and attribution log.

[alidonghao118-commits]

Hi @leocagli, I found a concrete integration gap between the current editor proxy and #110 / #360: frontend/app/api/editor/[...path]/route.ts::handleEditorProxy() drops x-protected-map-override, while both proposed backends read that header. The explicit override never reaches the API through /api/editor.

I reproduced this using the actual route handlers at commit 12b967c163f4eca01e80f758aeedc8b153bfc249, with stubbed Next dependencies and fetch. The original fails the PUT/POST/DELETE header-forwarding checks. A ten-line local patch passes all 18 transport checks: it forwards only this header on map mutations, preserves its value for backend interpretation, and retains the existing credential, body and query handling.

I'd like to finish the proxy/API integration and add request-level tests against the selected backend: denied writes leave map and audit data unchanged; map-50 permission does not grant access to map 1; protected-map overrides still require the appropriate session; successful writes record that account.

Could you assign me this scope under the listed $50 reward and confirm which PR to build on?

[no0bie]

Hi @leocagli — Applied via GrantFox as @no0bie. Local claim-ready patch covers the acceptance criteria (per-map grants, attribution, protected-map override) plus the editor-proxy x-protected-map-override forward that #110/#360 backends expect, with integration + unit tests green. Ready to open the PR as soon as assigned under the listed $50. Could you assign me this issue?