Tracking de Migración — Python 3.13 + ARM64

Documento vivo. Actualizar cada vez que se migra un stack. Última actualización: 2026-03-19

Estado general de migración

Stack	Dominio	Estado	Fecha	Template
STACK_BACKOFFICE	Backoffice admin (torneos, equipos, fixtures)	✅ Migrado	2026-03-18	`backOfficeDev313.yaml`
STACK_BACKOFFICE_CONTENT	Backoffice contenido (notas, posts, notificaciones)	✅ Migrado	2026-03-18	`backOfficecontentDev313.yaml`
STACK_BACKOFFICE_TOURNAMENT	Backoffice de ediciones/torneos y partidos	✅ Migrado	2026-03-18	`botournamentDev313.yaml`
STACK_TORNEOS	Torneos, fixtures, estadísticas, ficha de partido	✅ Migrado	2026-03-18	`torneosDev313.yaml`
STACK_FLOW_CHANNEL	Canal de flow / mensajería de canales	✅ Migrado	2026-03-18	`flowchannelDev313.yaml`
STACK_PERFIL	Perfiles de usuario, registro, estadísticas personales	✅ Migrado	2026-03-18	`perfilDev313.yaml`
STACK_COLECTA	Fundraising (colectas de fondos para equipos)	✅ Migrado	2026-03-19	`colectaDev313.yaml`
STACK_DYNAMO	DynamoDB Streams → EventBridge → Step Functions (match events)	✅ Migrado	2026-03-19	`dynamoDev313.yaml`
STACK_WIDGETS	Widgets: feed, marketplace refresh, schedules (SQS + EventBridge)	✅ Migrado	2026-03-19	`widgetsDev313.yaml`
STACK_COMUNIDAD	Canales, mensajería, notificaciones, transfermarket, media	✅ Migrado	2026-05-20	`comunidad.yaml`
STACK_FOLLOWERS	Seguimiento de perfiles, búsqueda, recomendaciones de feed	✅ Migrado	2026-03-19	`followers.yaml`
STACK_MONITOREO	Monitoreo deportivo, grupos, estadísticas de lesiones y carga	✅ Migrado	2026-03-19	`monitoreo.yaml`

Los stacks aún no migrados pertenecen a las ramas Prod_new (Python 3.9) y Chat_Prod (Python 3.13 x86). Ver ARQUITECTURA_DEPLOY_PYTHON313_ARM64.md para el plan completo. Ver sección Análisis de origen por rama para el detalle de los stacks pendientes.

Análisis de origen por rama

Generado: 2026-03-19. Metodología: comparar contenido YAML y layers entre origin/Prod_new y origin/Chat_Prod.

Hallazgo principal

Prod_new es el source of truth para TODOS sus stacks. Chat_Prod solo tiene copias más antiguas/reducidas. No se identificó ningún stack cuyo origen real sea Chat_Prod entre los stacks de Prod_new: en todos los casos donde hay diferencias, Prod_new tiene más contenido que Chat_Prod.

Los stacks que pertenecen al dominio Chat/Posts/Pagos y NO existen en Prod_new (por tanto NO se migran desde aquí) son: STACK_AGENDA, STACK_CHAT, STACK_CONNECT, STACK_DASHBOARD, STACK_DATA, STACK_GAMES, STACK_GEMENIAUTO, STACK_GENERALNOTIFICATIONS, STACK_MULTIMEDIA, STACK_NOTIFICATION_PREFERENCES, STACK_PANELNOTIFICATION, STACK_PAYWEBHOOK, STACK_POSTS, STACK_SOCCERFRIENDLY, STACK_SOCIOS, STACK_TEAM.

Stacks pendientes de migrar (origen Prod_new)

Stack	Funciones	DB layer	Diff con Chat_Prod	Notas
STACK_COMPLEXS	15	PostgreSQL	+0 / -97 (Prod_new adelante)
STACK_DYNAMO_TABLES	0 (solo tablas)	Infra DynamoDB	+0 / -122 (Prod_new adelante)	Solo crea tablas, sin Lambdas
STACK_EVENTOSBO	26	Común	+6 / -7 (divergencia leve)	Chat_Prod hardcodeó `StageName: dev`
STACK_EVENTS	2	Común	+0 / -0 (idéntico)
STACK_HOYENTRENO	54	Común	+1 / -75 (Prod_new adelante)
STACK_INTEGRATION	22	PostgreSQL + DynamoDB	+0 / -0 (idéntico)
STACK_LOCATION	2	Común	+0 / -0 (idéntico)
STACK_MARKETPLACE	7	Común	+0 / -45 (Prod_new adelante)
~~STACK_MONITOREO~~	59	~~PostgreSQL + DynamoDB~~	~~+0 / -0 (idéntico)~~	~~Migrado~~
STACK_NOTES_IA	36	Común	+0 / -0 (idéntico)
STACK_NOTIFICATION	17	Común	+0 / -0 (idéntico)
STACK_NUTRITION	13	DynamoDB	+0 / -0 (idéntico)	Layer DynamoDB propio
STACK_PLAYNFO	17	Común	+0 / -0 (idéntico)
STACK_SERVICE_WEB	5	PostgreSQL	+0 / -0 (idéntico)
STACK_SPONSORS	3	Común	+0 / -34 (Prod_new adelante)
STACK_STORE	1	Común	+0 / -0 (idéntico)
STACK_TRIVIA_GAMING	63	Común	+0 / -0 (idéntico)	Más grande por funciones
STACK_WORDPRESS	4	Común	+0 / -0 (idéntico)
STACK_ZONA10	26	PostgreSQL	+0 / -0 (idéntico)

Diff: +N = líneas que Chat_Prod agregó; -N = líneas que Prod_new tiene y Chat_Prod no. Prod_new con más líneas = branch de origen.

STACK_BACKOFFICE

Resumen

Atributo	Valor
Runtime	Python 3.13
Arquitectura	ARM64 (Graviton)
API Gateway	`BackofficeDEV`
Template	`STACK_BACKOFFICE/backOfficeDev313.yaml`
Funciones Lambda	202
Endpoints	56 paths
Cognito	`us-east-2_1WuxwXceK`
Layer común	`!Ref CommonLayerArn` (SSM: `/mas10/layers/common/arm64/dev_313`)
Layer propio	`!Ref LayerBO`
Líneas template	3,095 (optimizado)

Cambios respecto a Python 3.9

Runtime: python3.13 en Globals
Architectures: [arm64] en Globals
Layer común referenciado vía SSM Parameter (CommonLayerArn) en lugar de ARN fijo
EndpointConfiguration: Type: REGIONAL en API Gateway
Globals optimization: Timeout: 10, MemorySize: 256, Layers movidos a Globals (funciones solo declaran overrides). Role se mantiene por función (no soportado en Globals por SAM CLI).

Módulos del layer propio (`layer/`)

Módulo	Descripción
`database_backOffice/`	Lógica de dominio PostgreSQL del backoffice
`query_bo/`	Templates SQL del stack
`utils_backOffice/`	Utilidades específicas
`aws_recursos_bo/`	Helpers AWS (S3, Cognito)
`gene_pdf_bo/`	Generación de PDFs (actas/planillas)
`warrant/`	Wrapper Cognito

Endpoints por dominio

Jugadores y perfiles

Path	Métodos
`/add_player_by_team`	GET, POST, PUT
`/add-player-by-team-admin-tor`	GET, POST, PUT
`/add-player-by-team-delegate`	GET, POST, PUT
`/players`	GET, PUT, DELETE
`/update_profile`	GET, PUT
`/update_profile_admin`	GET, PUT
`/update_profile_for_put`	GET, PUT
`/update_profile_for_put_admin`	GET, PUT
`/team/perfil/admin-players`	GET, PUT
`/team/perfil/players`	GET, PUT
`/team/perfil/matches`	GET

Equipos

Path	Métodos
`/team`	GET, POST, PUT, DELETE
`/team-search`	GET
`/team_search`	GET
`/team_sanction`	GET, PUT
`/team_users`	GET
`/teams-by-admin`	GET
`/teams-by-delegate`	GET
`/crm_team`	PUT
`/crm_users`	PUT

Torneos y fases

Path	Métodos
`/tournament`	GET, POST, PUT, DELETE
`/tournament-friendly`	POST
`/tournament-phases`	GET
`/tournament-steps`	DELETE
`/tournament-team`	GET, POST, PUT, DELETE
`/tournament-teams`	GET, POST, PUT
`/tournament/category`	GET, POST, PUT
`/tournament/seasons`	GET, POST, PUT
`/fase-tournament`	GET, POST, PUT
`/fase-team-tournament`	GET, POST, PUT
`/phase-team-meta`	GET

Fixture y partidos

Path	Métodos
`/fixture`	GET, POST, PUT, DELETE
`/fixture_info`	GET
`/fixture-auto`	POST, PUT
`/fixture-match-meta`	GET, POST
`/fixture-matches`	GET, POST, PUT, DELETE

Liga

Path	Métodos
`/league`	GET, POST, PUT, DELETE
`/league-info`	GET
`/league_teams`	GET
`/historic-skills`	GET

Ubicación

Path	Métodos
`/city`	GET, POST, PUT
`/country`	GET, POST, PUT
`/province`	GET, POST, PUT
`/localitys`	GET, POST, PUT

Catálogos y configuración

Path	Métodos
`/category`	GET, POST, PUT, DELETE
`/sport`	GET, POST, PUT
`/tags-metadata`	GET
`/metadata`	GET
`/configuration`	GET

Entrenamiento y nutrición

Path	Métodos
`/exercise`	GET, POST, PUT, DELETE
`/exercise-lang`	GET, PUT
`/typeexercise`	GET, POST, PUT, DELETE
`/training-library`	GET, POST, PUT, DELETE
`/nutrition`	GET, POST, PUT

Auth y usuarios

Path	Métodos
`/cognito`	GET
`/all-cognito`	POST
`/register-web`	POST

Otros

Path	Métodos
`/products`	GET, POST, PUT, DELETE
`/service-product`	GET, POST, PUT, DELETE
`/downloadparte`	GET

Resolución de conflictos

El deploy de backOfficeDev313 falló con CREATE_FAILED: TeamExternalPutDEV already exists in stack backOfficeDev.

Funciones afectadas (tenían DeletionPolicy: Retain + FunctionName explícito + Runtime: python3.9):

Función	FunctionName	Path	Problema
`TeamExternalPut`	`TeamExternalPut$ENV`	`/team/external` PUT	DeletionPolicy + Runtime python3.9
`TeamExternalOptions`	`TeamExternalOptions$ENV`	`/team/external` OPTIONS	DeletionPolicy + Runtime python3.9
`MatchManualProfileGet`	(auto)	`/match_manual_profile` GET	DeletionPolicy
`MatchManualProfileOptions`	(auto)	`/match_manual_profile` OPTIONS	DeletionPolicy

Fix aplicado (commits aeb6f6825 + d9b855fff + 9d0da5bcc):

Ronda 1 — Funciones Lambda:

Eliminado DeletionPolicy: Retain y UpdateReplacePolicy: Retain de las 4 funciones
Eliminado Runtime: python3.9 de TeamExternalPut y TeamExternalOptions (heredan python3.13 de Globals)
Actualizado stack viejo backOfficeDev via CloudFormation para liberar los nombres TeamExternalPutDEV y TeamExternalOptionsDEV:
- Descargado template del stack viejo
- Eliminadas funciones TeamExternal, sus permission resources y paths /team/external del swagger del API Gateway
- Subido template limpio a S3 y ejecutado update-stack

Ronda 2 — ApiKey y UsagePlan:

Tras liberar las funciones, el deploy falló de nuevo con ApiKey with name Backoffice-External-DEV already exists. Los recursos con nombre explícito en el template 313 también existían en el stack viejo.

Recurso (logical)	Tipo	Nombre/Physical ID
`BackofficeExternalApiKey`	`AWS::ApiGateway::ApiKey`	`Backoffice-External-DEV`
`BackofficeExternalUsagePlan`	`AWS::ApiGateway::UsagePlan`	`Backoffice-External-UsagePlan-DEV`
`BackofficeExternalUsagePlanKey`	`AWS::ApiGateway::UsagePlanKey`	(combo ApiKey+UsagePlan)

Fix: mismo procedimiento — descargar template de backOfficeDev, eliminar los 3 recursos + sus Outputs (BackofficeApiKeyId, BackofficeUsagePlanId), subir a S3 y update-stack.

⚠️ Lección aprendida: No basta con buscar funciones Lambda con FunctionName explícito. También hay que verificar ApiKeys, UsagePlans, LogGroups y cualquier recurso con Name hardcodeado que pueda chocar entre el stack viejo y el nuevo 313. Usar el script /tmp/check_conflicts.py (o similar) para comparar proactivamente.

⚠️ Replicar en QA y PROD al migrar. Ver Conflicto de nombres entre stacks en la guía.

STACK_BACKOFFICE_CONTENT

Resumen

Atributo	Valor
Runtime	Python 3.13
Arquitectura	ARM64 (Graviton)
API Gateway	`BackofficeContent313DEV`
Template	`STACK_BACKOFFICE_CONTENT/backOfficecontentDev313.yaml`
Funciones Lambda	195
Endpoints	66 paths
Layer común	`!Ref CommonLayerArn` (SSM: `/mas10/layers/common/arm64/dev_313`)
Layer propio	`!Ref LayerBOContent`
Líneas template	2,999 (optimizado)

Cambios respecto a Python 3.9

Runtime: python3.13 en Globals
Architectures: [arm64] en Globals
Layer común referenciado vía SSM Parameter (CommonLayerArn)
EndpointConfiguration: Type: REGIONAL en API Gateway
Globals optimization: Timeout: 60, MemorySize: 256, Layers movidos a Globals (funciones solo declaran overrides). Role se mantiene por función (no soportado en Globals por SAM CLI).

Módulos del layer propio (`layer/`)

Módulo	Descripción
`database_backOfficeC/`	Lógica de dominio PostgreSQL del backoffice content
`query_boc/`	Templates SQL del stack
`utils_backOfficeC/`	Utilidades específicas
`aws_recursos_boc/`	Helpers AWS (S3, Cognito)
`functions_boc/`	Funciones auxiliares de negocio
`gene_pdf_boc/`	Generación de PDFs de contenido
`scrapping_tags/`	Scraping de tags/metadata
`warrant/`	Wrapper Cognito

Endpoints por dominio

Notas y contenido generado

Path	Métodos
`/generate-text-db`	GET, POST, PUT, DELETE
`/generate_note_profile`	GET, POST, PUT, DELETE
`/generate_note_x_torneo`	GET, PUT
`/generate_note_x_torneo/search`	GET
`/global_notes`	GET, POST, PUT, DELETE
`/group_type_note`	GET
`/note_finish_match`	GET, PUT
`/note_post_fixture_featured`	GET, PUT
`/note_pre_fixture_goalscorer`	GET, PUT
`/note_pre_fixture_vmv`	GET, PUT
`/note_pre_fixture_vs`	GET, PUT
`/note_welcome`	GET, PUT

Billboard y Cards

Path	Métodos
`/billboard`	GET, POST, PUT, DELETE
`/billboard/search`	GET
`/card`	GET, POST, PUT, DELETE
`/card/search`	GET

Eventos

Path	Métodos
`/eventos`	GET
`/eventos/backgrounds`	GET, POST
`/eventos/filter`	GET
`/eventos/plantillas`	GET, POST, PUT, DELETE
`/eventos/stickers`	GET
`/eventos/stickers_category`	GET
`/eventos/type`	GET

Mensajería push / admin

Path	Métodos
`/message-by-admin-gral`	GET, POST
`/message-by-league`	GET, POST
`/message-by-phase`	GET, POST
`/message-by-player`	GET, POST
`/message-by-team`	GET, POST
`/message-by-tour`	GET, POST
`/message-of-phase`	GET, POST
`/message-of-player`	GET, POST
`/message-of-team`	GET, POST
`/message-of-tour`	GET, POST
`/msg-welcome-by-league`	GET, POST
`/noti-admin`	GET

Topics y push masivo

Path	Métodos
`/topic`	GET, POST, PUT
`/topic/members`	GET
`/push_csv`	GET, POST, PUT
`/push_csv_detail`	GET, POST
`/push_topic_detail`	GET, POST

Posts y perfiles sociales

Path	Métodos
`/profile_post`	GET, POST, PUT, DELETE
`/profile_post/search`	GET
`/profile_post_bo`	GET
`/profile_post_league`	GET
`/profile_post_league/search`	GET
`/profile_post_team`	GET, POST, PUT, DELETE
`/profile_post_team/search`	GET
`/profile_post_user_generic`	GET, POST, PUT, DELETE
`/profilepostusergeneric`	GET, POST, PUT
`/profilepostxpost`	GET, POST, PUT, DELETE
`/profilepostxpost/search`	GET
`/profilepostxpostleague`	GET, POST, PUT, DELETE
`/profilepostxpostteam`	GET, POST, PUT, DELETE
`/profilepostxpostteam/search`	GET

Media y transcripción

Path	Métodos
`/reporter`	GET
`/reporter_media`	GET, POST
`/transcribe`	GET, POST

Configuración y catálogos

Path	Métodos
`/configurationContent`	GET
`/metadatacontent`	GET

Auth y usuarios

Path	Métodos
`/cognito`	GET
`/all-cognito`	POST
`/register-web`	POST

Proceso de migración — pasos aplicados por stack

Checklist usado al migrar cada stack de Python 3.9 → Python 3.13 + ARM64:

Próximos stacks a migrar

Pendiente definir orden de prioridad. Ver copilot-instructions para lista completa de stacks en Prod_new.

STACK_COLECTA

Resumen

Atributo	Valor
Runtime	Python 3.13
Arquitectura	ARM64 (Graviton)
API Gateway	`Colecta313$ENV` (renombrado de `Colecta$ENV`)
Template	`STACK_COLECTA/colecta.yaml`
Funciones Lambda	6
Endpoints	2 paths
Layer común	`!Ref CommonLayerArn` (SSM: `/mas10/layers/common/arm64/dev_313`)
Layer propio	`!Ref LayerColecta`

Cambios respecto a Python 3.9

Runtime: python3.13 en Globals
Architectures: [arm64] en Globals
MemorySize: 1024 y Timeout: 200 movidos a Globals (todas las funciones los comparten)
Layers movidos a Globals: [LayerColecta, CommonLayerArn]
Layer común referenciado vía SSM Parameter (CommonLayerArn) — eliminado recurso LayerCommon
DependsOn: ColectaAPiLogGroup agregado al API Gateway
AccessLogSetting.DestinationArn cambiado de !GetAtt a !Sub con ARN explícito
DeploymentPreference: Enabled: false eliminado de cada función
LayerColecta: CompatibleRuntimes: python3.13, CompatibleArchitectures: arm64, BuildMethod: python3.13

Recursos renombrados (evitar colisión con Prod_new)

Recurso	Nombre original	Nombre 313	Estrategia
API Gateway	`Colecta$ENV`	`Colecta313$ENV`	Renombrado
LogGroup	`api-gateway/mas10-colecta-api/$DD_ENV`	`api-gateway/mas10-colecta-api-313/$DD_ENV`	Renombrado
FunctionNames (6)	`FundraisingPost$ENV`, etc.	Sin cambio	Stack viejo eliminado

Nota: Los FunctionNames se mantienen con nombres originales porque pueden ser invocados por otros servicios. Se elimina el stack viejo colectaDev para liberar los nombres. El dominio fundraising-dev.liricus.com.ar se preserva y su base path mapping se reconfigura post-deploy.

Módulos del layer propio (`layer/`)

Módulo	Descripción
`database_colecta/`	Lógica de dominio PostgreSQL de colectas
`query_colecta/`	Templates SQL del stack
`utils_colecta/`	Utilidades específicas

Endpoints

Path	Métodos
`/fundraising`	GET, POST, PUT
`/fundraising/members/moviments`	POST, PUT, DELETE

STACK_DYNAMO

Resumen

Atributo	Valor
Runtime	Python 3.13
Arquitectura	ARM64 (Graviton)
API Gateway	`Dynamo313$ENV` (renombrado de `Dynamo$ENV`)
Template	`STACK_DYNAMO/dynamo.yaml`
Funciones Lambda	13
Endpoints	13 paths
Layer común	`!Ref CommonLayerArn` (SSM: `/mas10/layers/common/arm64/dev_313`)
Layer propio	`!Ref LayerDynamo`

Cambios respecto a Python 3.9

Datadog eliminado por completo: Transform, apiKey hardcodeado
Runtime: python3.13 en Globals
Architectures: [arm64] en Globals (era x86_64 por función)
Layers movidos a Globals: [LayerDynamo, CommonLayerArn]
Layer común referenciado vía SSM Parameter (CommonLayerArn) — eliminado recurso LayerCommon
DependsOn: DynamoAPiLogGroup agregado al API Gateway
EndpointConfiguration: Type: REGIONAL agregado
AccessLogSetting.DestinationArn cambiado de !GetAtt a !Sub con ARN explícito
LayerDynamo: CompatibleRuntimes: python3.13, CompatibleArchitectures: arm64, BuildMethod: python3.13
Funciones PrepareInsertMatchEventsGet, PrepareModifyMatchEventsGet: mantienen MemorySize: 512, Timeout: 240 como override
Función InsertEventsGet: mantiene MemorySize: 512 como override

Recursos renombrados (evitar colisión con Prod_new)

Recurso	Nombre original	Nombre 313	Estrategia
API Gateway	`Dynamo$ENV`	`Dynamo313$ENV`	Renombrado
LogGroup	`api-gateway/mas10-dynamo-api/$ENV`	`api-gateway/mas10-dynamo-api-313/$ENV`	Renombrado
FunctionNames (13)	`MatchInsertGet$ENV`, etc.	Sin cambio	Stack viejo eliminado
Pipes/Rules/EventBus/StateMachines	varios	Sin cambio	Stack viejo eliminado

Nota: Stack viejo dynamoDev eliminado para liberar los nombres. No tiene dominio custom asociado.

Módulos del layer propio (`layer/`)

Módulo	Descripción
`database_dynamo/`	Operaciones DynamoDB (perfiles, matches, equipos)
`utils_dynamo/`	Utilidades específicas

Arquitectura

DynamoDB Streams → EventBridge Pipes (3: Insert/Modify/Remove) → EventBus → EventBridge Rules → Step Functions (3 State Machines):

MatchInsertWorkflow: Procesa inserción de partidos → actualiza perfiles de usuarios/equipos → inserta eventos de contenido
MatchModifyWorkflow: Procesa modificación de partidos (parallel con prode) → actualiza perfiles → prepara eventos
MatchRemoveWorkflow: Procesa eliminación de partidos → limpia perfiles de usuarios/equipos

Endpoints

Path	Handler
`/match_insert`	`MatchInsertGet`
`/match_modify`	`MatchModifyGet`
`/match_remove`	`MatchRemoveGet`
`/match_user_insert`	`MatchUserInsertGet`
`/match_user_modify`	`MatchUserModifyGet`
`/match_user_remove`	`MatchUserRemoveGet`
`/match_team_insert`	`MatchTeamInsertGet`
`/match_team_modify`	`MatchTeamModifyGet`
`/match_team_remove`	`MatchTeamRemoveGet`
`/match_prode_modify`	`MatchProdeModifyGet`
`/prepare_new_match_events`	`PrepareInsertMatchEventsGet`
`/prepare_modify_match_events`	`PrepareModifyMatchEventsGet`
`/insert_events`	`InsertEventsGet`

STACK_BACKOFFICE_TOURNAMENT

Resumen

Atributo	Valor
Runtime	Python 3.13
Arquitectura	ARM64 (Graviton)
API Gateway	`botournamentDEV`
Template	`STACK_BACKOFFICE_TOURNAMENT/botournamentDev313.yaml`
Funciones Lambda	27
Endpoints	13 paths
Layer común	`!Ref CommonLayerArn` (SSM: `/mas10/layers/common/arm64/dev_313`)
Layer propio	`!Ref LayerBoTournament`
Líneas template	496 (optimizado)

Cambios respecto a Python 3.9

Transform Datadog comentado
Runtime: python3.13 en Globals (eliminado por función)
Architectures: [arm64] en Globals
Layer común referenciado vía SSM Parameter (CommonLayerArn) — eliminado LayerCommon resource
EndpointConfiguration: Type: REGIONAL en API Gateway
FunctionName eliminado de cada función
DeploymentPreference: Enabled: false eliminado
LayerBoTournament actualizado: CompatibleRuntimes: python3.13, CompatibleArchitectures: arm64, BuildMethod: python3.13
DatadogPocLogGroupSubscriptionFilter comentado
Log Group: variables $DD_ENV reemplazadas por valor fijo dev
Globals optimization: Timeout: 10, MemorySize: 256, Layers movidos a Globals (funciones solo declaran overrides). Role se mantiene por función (no soportado en Globals por SAM CLI).

Módulos del layer propio (`layer/`)

Módulo	Descripción
`database_bo_tournament/`	Lógica de dominio PostgreSQL del backoffice tournament
`querys_bo_tournament/`	Templates SQL del stack
`Database/`	Helpers de base de datos

Endpoints

Path	Métodos	Servicio
`/edition`	GET, POST, PUT, DELETE	`services/edition/`
`/edition_detail`	GET	`services/edition/edition_detail/`
`/edition_detail_team`	GET	`services/team_in_detail/`
`/edition_format`	GET	`services/edition/edition_format/`
`/edition_format_detail`	GET	`services/edition/edition_format_detail/`
`/category`	GET	`services/category/`
`/category_fixture`	GET	`services/category/fixture/`
`/matches`	GET, PUT, DELETE	`services/matches/`
`/players_teams_link`	PUT	`services/players_team_link/`
`/players_teams_unlink`	PUT	`services/players_teams_unlink/`
`/team`	GET	`services/team/`

STACK_TORNEOS

Resumen

Atributo	Valor
Runtime	Python 3.13
Arquitectura	ARM64 (Graviton)
API Gateway	`Torneos313$ENV` (renombrado de `Torneos$ENV`)
Template	`STACK_TORNEOS/torneosDev313.yaml`
Funciones Lambda	95
Endpoints	36 paths
Cognito	`us-east-2_1WuxwXceK`
Layer común	`!Ref CommonLayerArn` (SSM: `/mas10/layers/common/arm64/$DD_ENV`)
Layer propio	`!Ref LayerTorneos`
Líneas template	1,471 (optimizado)

Cambios respecto a Python 3.9

Runtime: python3.13 en Globals
Architectures: [arm64] en Globals
Layer común referenciado vía SSM Parameter (CommonLayerArn) en lugar de recurso LayerCommon
EndpointConfiguration: Type: REGIONAL en API Gateway
Eliminado DeploymentPreference de Globals
Eliminado recurso LayerCommon (reemplazado por SSM)
Globals optimization: Timeout: 10, MemorySize: 512, Layers movidos a Globals (funciones solo declaran overrides). Role se mantiene por función (no soportado en Globals por SAM CLI).

Recursos renombrados (evitar colisión con Prod_new)

Recurso	Nombre original	Nombre 313
API Gateway	`Torneos$ENV`	`Torneos313$ENV`
LogGroup	`api-gateway/mas10-torneos-api-8/$ENV`	`api-gateway/mas10-torneos-api-313/$ENV`
EventBridge warming	`torneos-warming-rule-$ENV`	`torneos313-warming-rule-$ENV`
Schedule tournament	`SCHEDULE_TOURNAMENT_PUT_$ENV`	`SCHEDULE_TOURNAMENT_PUT_313_$ENV`
Schedule statistics	`SCHEDULE_TEAM_STATISTICS_GET_1$ENV`	`SCHEDULE_TEAM_STATISTICS_GET_313_$ENV`

Fix especial: MyPostulationDelete

La función MyPostulationDelete tenía indentación incorrecta en el template original (6 espacios en vez de 4 para Type:). Se corrigió la indentación durante la migración.

Módulos del layer propio (`layer/`)

Módulo	Descripción
`database_torneos/`	Lógica de dominio PostgreSQL de torneos
`querys_torneo/`	Templates SQL del stack
`utils_torneos/`	Utilidades específicas
`aws_recursos/`	Helpers AWS (S3, etc.)
`wordpress_recursos/`	Integración WordPress

Endpoints (36 paths)

Path	Servicios
`/credential/`	Credenciales
`/current-localitys`	Localidades actuales
`/data-api-football`	API football externa
`/documents/`	Documentos
`/favourite-items`	Favoritos
`/feed_mas10`	Feed v1
`/feed_mas10_v3`	Feed v3
`/ficha-partido`	Ficha de partido
`/fixture-matches`	Partidos de fixture
`/get-note-type`	Tipos de nota
`/get-team-user`	Equipos por usuario
`/invitation`	Invitaciones
`/league-by-user`	Ligas por usuario
`/leave-team`	Abandonar equipo
`/match`	Partidos
`/match-details`	Detalles de partido
`/match-veedor`	Veedor de partido
`/my-postulation`	Postulaciones propias
`/perfiles/torneo/statistics/`	Estadísticas de perfil en torneo
`/perfiles/torneo/teams/`	Equipos de perfil en torneo
`/pi-create-match`	Crear picadito
`/pi-group`	Grupos de picadito
`/pi-matches`	Partidos de picadito
`/pi-members-match`	Miembros de picadito
`/pi-my-matches`	Mis picaditos
`/postulations`	Postulaciones
`/rancking-fans-by-tournament`	Ranking de fans
`/score`	Puntuación
`/select-team`	Selección de equipo
`/send-code`	Envío de código
`/statistics`	Estadísticas
`/statistics-details`	Detalles de estadísticas
`/statistics_v2`	Estadísticas v2
`/tournament-demo`	Torneo demo
`/tournament-friendly`	Torneo amistoso
`/user-by-type`	Usuarios por tipo

Guía paso a paso para migrar un stack

Checklist completa basada en los errores y fixes encontrados migrando STACK_BACKOFFICE, STACK_BACKOFFICE_CONTENT y STACK_BACKOFFICE_TOURNAMENT.

Pre-requisitos

Estar en la rama dev_313
Layer common ARM64 publicado y SSM actualizado (/mas10/layers/common/arm64/dev_313)

Paso 1 — Obtener el stack desde Prod_new

# Traer los archivos del stack desde la rama Prod_new
git checkout origin/Prod_new -- STACK_{NOMBRE}/

Paso 2 — Transformar el template base (`{stack}.yaml`)

Aplicar todos estos cambios en el archivo {stack}.yaml (el base, no el Dev313):

2.1 Comentar Datadog Transform

# ANTES
Transform:
  - AWS::Serverless-2016-10-31
  - Name: DatadogServerless
    Parameters: ...

# DESPUÉS
Transform:
  - AWS::Serverless-2016-10-31
#  - Name: DatadogServerless
#    Parameters: ...

2.2 Agregar parámetro SSM para layer common

Parameters:
  CommonLayerArn:
    Type: AWS::SSM::Parameter::Value<String>
    Default: /mas10/layers/common/arm64/dev_313

2.3 Actualizar Globals

Globals:
  Function:
    Timeout: 30
    Runtime: python3.13
    Architectures:
      - arm64

2.4 Eliminar el recurso `LayerCommon` completo

El layer common ahora viene por SSM. Eliminar todo el bloque LayerCommon: Type: AWS::Serverless::LayerVersion.

2.5 Reemplazar todas las referencias al layer

# ANTES
Layers:
  - !Ref LayerCommon
  - !Ref Layer{StackName}

# DESPUÉS
Layers:
  - !Ref CommonLayerArn
  - !Ref Layer{StackName}

2.6 Actualizar layer propio del stack

Layer{StackName}:
  Type: AWS::Serverless::LayerVersion
  Properties:
    CompatibleRuntimes:
      - python3.13
    CompatibleArchitectures:
      - arm64
  Metadata:
    BuildMethod: python3.13

2.7 Eliminar propiedades por función (heredan de Globals)

De cada función Lambda, eliminar:

Runtime: (hereda python3.13 de Globals)
DeploymentPreference: (no necesario)
FunctionName: (dejar que CloudFormation genere el nombre)

2.8 Configurar API Gateway como REGIONAL

  MyApi:
    Type: AWS::Serverless::Api
    Properties:
      EndpointConfiguration:
        Type: REGIONAL

⚠️ La cuenta tiene un límite de 120 APIs EDGE. Todos los stacks nuevos deben usar REGIONAL.

2.9 Comentar SubscriptionFilter de Datadog

#  DatadogPocLogGroupSubscriptionFilter:
#    Type: AWS::Logs::SubscriptionFilter
#    ...

Paso 3 — Renombrar recursos con nombre explícito (CRÍTICO)

Este es el error más difícil de diagnosticar. CloudFormation tiene un hook EarlyValidation::ResourceExistenceCheck que rechaza crear recursos cuyo nombre ya existe en la cuenta pero fuera del stack.

Los stacks de Prod_new ya crearon recursos con nombres como botournamentDEV o api-gateway/mas10-botournament-api1/dev. El stack 313 es un stack nuevo, así que CloudFormation no puede crear recursos con el mismo nombre.

Buscar y renombrar todos los recursos con Name o LogGroupName hardcodeados:

# API Gateway — agregar sufijo "313"
# ANTES
Name: botournament$ENV      # → botournamentDEV (ya existe)
# DESPUÉS
Name: botournament313$ENV    # → botournament313DEV (nuevo)

# LogGroup — agregar sufijo "-313"
# ANTES
LogGroupName: "api-gateway/mas10-botournament-api1/$DD_ENV"  # ya existe
# DESPUÉS
LogGroupName: "api-gateway/mas10-botournament-api-313/$DD_ENV"  # nuevo

Recursos a revisar:

AWS::Serverless::Api → propiedad Name
AWS::Logs::LogGroup → propiedad LogGroupName
Cualquier otro recurso con nombre explícito (DynamoDB tables, SQS queues, etc.)

Paso 4 — Verificar el build script

El archivo build_{stack}.sh debe apuntar al stack correcto:

# Verificar que el nombre sea correcto (no copiado de otro stack)
bash ../deploy.sh {stack_correcto} $ubi $enviroment

Paso 5 — Optimizar template con Globals

Mover propiedades repetidas a Globals para reducir líneas y facilitar mantenimiento:

Globals:
  Function:
    Timeout: 10           # valor más común del stack
    MemorySize: 256       # valor más común del stack
    Runtime: python3.13
    Architectures:
      - arm64
    Layers:
      - !Ref LayerStackName
      - !Ref CommonLayerArn

⚠️ Role NO es soportado en Globals por SAM CLI. Debe declararse en cada función individualmente.

Luego eliminar de cada función las propiedades que ya heredan de Globals (Timeout, MemorySize, Layers). Solo mantener las que tengan valores diferentes (overrides). Role: $ROLE debe permanecer en cada función.

Tip: Identificar el valor más frecuente de cada propiedad con grep -c "Timeout: 10" stack.yaml y moverlo a Globals. Funciones con valores distintos conservan su propiedad como override.

Paso 6 — Commit y push

git add STACK_{NOMBRE}/
git commit -m "feat: migrate STACK_{NOMBRE} to Python 3.13 ARM64"
git push origin dev_313

Paso 7 — Verificar deploy en pipeline

Si el deploy falla:

Unable to upload artifact LayerCommon → Faltó eliminar el recurso LayerCommon del template (Paso 2.4)

EarlyValidation::ResourceExistenceCheck → Hay recursos con nombres que ya existen en la cuenta (Paso 3). Verificar con:

aws logs describe-log-groups --log-group-name-prefix "api-gateway/mas10-{stack}" --region us-east-1
aws apigateway get-rest-apis --query "items[?contains(name,'{stack}')]" --region us-east-1

REVIEW_IN_PROGRESS → El stack quedó colgado de un intento anterior. deploy.sh ahora lo borra automáticamente antes de reintentar.
limit of 120 apis for EDGE endpoint type → Faltó agregar EndpointConfiguration: Type: REGIONAL al API Gateway (Paso 2.8).
CREATE_FAILED — {ResourceName} already exists in stack {stackViejo} → Recursos con nombre explícito (FunctionName, Name, UsagePlanName) que pertenecen al stack viejo. Ver sección Conflicto de nombres entre stacks para procedimiento detallado.

Conflicto de nombres entre stacks (FunctionName, ApiKey, UsagePlan, etc.)

Caso real: STACK_BACKOFFICE — TeamExternalPutDEV y Backoffice-External-DEV fallaban con CREATE_FAILED: already exists in stack backOfficeDev.

Causa raíz: Cuando un recurso tiene nombre explícito (ej: FunctionName: TeamExternalPut$ENV, Name: Backoffice-External-$ENV) CloudFormation mantiene la propiedad de ese nombre en el stack viejo aunque el recurso se borre de AWS. El stack nuevo intenta crear un recurso con el mismo nombre → CloudFormation lo rechaza porque "pertenece" al otro stack.

Aplica a cualquier recurso con nombre hardcodeado:

AWS::Lambda::Function → FunctionName
AWS::ApiGateway::ApiKey → propiedad Name
AWS::ApiGateway::UsagePlan → UsagePlanName
AWS::ApiGateway::UsagePlanKey → combinación ApiKey+UsagePlan
AWS::Logs::LogGroup → LogGroupName
AWS::SQS::Queue → QueueName
AWS::Events::Rule → Name

Diagnóstico:

# Ver todos los recursos con nombres explícitos en el template 313
grep -n "FunctionName:\|Name:\|LogGroupName:\|QueueName:\|UsagePlanName:" {stack}.yaml | grep -v "#"

# Ver a qué stack pertenecen en CloudFormation
aws cloudformation list-stack-resources --stack-name {stackViejo} \
  --query 'StackResourceSummaries[?contains(LogicalResourceId, `External`) || contains(LogicalResourceId, `ApiKey`)].{Logical:LogicalResourceId,Physical:PhysicalResourceId,Type:ResourceType}' \
  --profile local --region us-east-1 --output table

Fix (3 pasos):

Paso A: Eliminar DeletionPolicy: Retain, UpdateReplacePolicy: Retain y Runtime: python3.9 de las funciones afectadas en {stack}.yaml (template del nuevo stack 313).

Paso B: Actualizar el template del stack viejo eliminando todos los recursos conflictivos (funciones, ApiKeys, UsagePlans, permissions, paths del swagger y Outputs que los referencien).

# 1. Obtener el template actual del stack viejo (output es JSON con TemplateBody como dict)
aws cloudformation get-template --stack-name {stackViejo} \
  --profile local --region us-east-1 --output json > /tmp/stack_viejo.json

# 2. Usar script Python para limpiar (ejemplo real de STACK_BACKOFFICE)
python3 << 'PYEOF'
import json
with open('/tmp/stack_viejo.json') as f:
    d = json.load(f)
tb = d['TemplateBody']
resources = tb['Resources']

# Recursos a eliminar (funciones + permissions + ApiKey + UsagePlan)
to_remove = [
    'TeamExternalPut', 'TeamExternalOptions',
    'TeamExternalPutPutTeamExternalPermissiondev',
    'TeamExternalOptionsOptionsTeamExternalPermissiondev',
    'BackofficeExternalApiKey',
    'BackofficeExternalUsagePlan',
    'BackofficeExternalUsagePlanKey',
]
for key in to_remove:
    if key in resources:
        del resources[key]
        print(f'Removed resource: {key}')

# Limpiar paths del swagger del API Gateway
api_key = 'BackofficeDevApi'
if api_key in resources:
    paths = resources[api_key].get('Properties', {}).get('Body', {}).get('paths', {})
    for p in ['/team/external']:
        if p in paths:
            del paths[p]
            print(f'Removed API path: {p}')

# Limpiar Outputs que referencien recursos eliminados
for oname in list(tb.get('Outputs', {}).keys()):
    s = json.dumps(tb['Outputs'][oname])
    for r in to_remove:
        if r in s:
            del tb['Outputs'][oname]
            print(f'Removed output: {oname}')
            break

# Verificar 0 referencias restantes
remaining = json.dumps(tb).count('TeamExternal') + json.dumps(tb).count('BackofficeExternal')
print(f'Referencias restantes: {remaining}')  # DEBE ser 0

with open('/tmp/stack_viejo_clean.json', 'w') as f:
    json.dump(tb, f)
PYEOF

# 3. Subir a S3 (template > 51KB no se puede enviar directo)
aws s3 cp /tmp/stack_viejo_clean.json \
  s3://{BUCKET_DEPLOY}/tmp/stack_viejo_clean.json \
  --profile local --region us-east-1

# 4. Actualizar el stack viejo
aws cloudformation update-stack \
  --stack-name {stackViejo} \
  --template-url "https://{BUCKET_DEPLOY}.s3.us-east-1.amazonaws.com/tmp/stack_viejo_clean.json" \
  --capabilities CAPABILITY_IAM CAPABILITY_AUTO_EXPAND \
  --profile local --region us-east-1

# 5. Esperar
aws cloudformation wait stack-update-complete \
  --stack-name {stackViejo} --profile local --region us-east-1

Paso C: Re-disparar el pipeline del stack 313 (push o commit vacío).

git commit --allow-empty -m "fix({stack}): re-trigger deploy after releasing names from {stackViejo}"
git push origin dev_313

⚠️ Replicar en QA y PROD: Este mismo problema ocurrirá al migrar a QA (backOfficeQa → backOfficeQa313) y PROD (backOfficeProd → backOfficeProd313). Aplicar el mismo procedimiento cambiando el nombre del stack y el sufijo de entorno.

Resumen de archivos que se modifican por stack

Archivo	Cambio
`STACK_{NOMBRE}/{stack}.yaml`	Template base transformado (pasos 2 y 3)
`STACK_{NOMBRE}/build_{stack}.sh`	Verificar nombre correcto (paso 4)
`docs/MIGRACION_313_STACKS.md`	Agregar entrada del stack migrado

Archivos de infra que ya están corregidos (no tocar)

Archivo	Fix aplicado
`deploy.sh`	Auto-delete de stacks en `REVIEW_IN_PROGRESS` + diagnóstico con `describe-stack-events`
`deploy_smart.sh`	Mismo fix de `REVIEW_IN_PROGRESS`
`config_templates.sh`	Funciones `config_templates_dev_313`, `qa_313`, `prod_313`
`publish_layer.sh`	Publicación de layer ARM64 + SSM

STACK_FLOW_CHANNEL

Resumen

Atributo	Valor
Runtime	Python 3.13
Arquitectura	ARM64 (Graviton)
API Gateway	`flow313$ENV` (renombrado de `flow$ENV`)
Template	`STACK_FLOW_CHANNEL/flowchannelDev313.yaml`
Funciones Lambda	5
Endpoints	4 paths
Layer común	`!Ref CommonLayerArn` (SSM: `/mas10/layers/common/arm64/dev_313`)
Layer propio	ninguno
Líneas template	~115

Cambios respecto a Python 3.9

Runtime: python3.13 en Globals
Architectures: [arm64] en Globals
Layer común referenciado vía SSM Parameter (CommonLayerArn) — eliminado recurso LayerCommon inline
EndpointConfiguration: Type: REGIONAL en API Gateway (ya existía)
Eliminado DeploymentPreference: Enabled: false de cada función
Globals optimization: Timeout: 200, MemorySize: 512, Layers movidos a Globals. AddChannelOptions mantiene override Timeout: 10, MemorySize: 128. Role se mantiene por función (no soportado en Globals por SAM CLI).
LogGroup renombrado para evitar colisión con Prod_new

Recursos renombrados (evitar colisión con Prod_new)

Recurso	Nombre original	Nombre 313
API Gateway	`flow$ENV`	`flow313$ENV`
LogGroup	`api-gateway/mas10-flow-api/$ENV`	`api-gateway/mas10-flow-api-313/$ENV`

Endpoints

Path	Métodos	Handler
`/FlowChannel`	POST	`post.lambda_handler`
`/AddChannel`	POST, OPTIONS	`add_channel.lambda_handler`, `option.lambda_handler`
`/SendImage`	POST	`send_image.lambda_handler`
`/SendMessage`	POST	`send_message.lambda_handler`

STACK_PERFIL

Resumen

Atributo	Valor
Runtime	Python 3.13
Arquitectura	ARM64 (Graviton)
API Gateway	`Perfil313$ENV` (renombrado de `Perfil$ENV`)
Template	`STACK_PERFIL/perfil.yaml`
Funciones Lambda	40
Endpoints	17 paths
Cognito	`us-east-2_1WuxwXceK`
Layer común	`!Ref CommonLayerArn` (SSM: `/mas10/layers/common/arm64/dev_313`)
Layer propio	`!Ref LayerPerfil`
Líneas template	~800 (optimizado)

Cambios respecto a Python 3.9

Datadog eliminado por completo: Transform, DD_SERVICE/DD_ENV env vars, DD_TRACE/DD_SERVERLESS/DD_TELEMETRY overrides, tags DD_ENV/DD_SERVICE del LogGroup, DatadogPocLogGroupSubscriptionFilter, apiKey hardcodeado
Runtime: python3.13 en Globals
Architectures: [arm64] en Globals
Layers movido a Globals: [LayerPerfil, CommonLayerArn]
Layer común referenciado vía SSM Parameter (CommonLayerArn) — eliminado recurso LayerCommon
EndpointConfiguration: Type: REGIONAL en API Gateway
DependsOn: PerfilAPiLogGroup en API Gateway
AccessLogSetting.DestinationArn cambiado de !GetAtt PerfilAPiLogGroup.Arn a !Sub "arn:aws:logs:..."
Eliminado Timeout: 10 y Timeout: 30 por función (heredan de Globals)
Eliminado Layers: por función (heredan de Globals)
LayerPerfil: CompatibleRuntimes: python3.13, CompatibleArchitectures: arm64, BuildMethod: python3.13
Role se mantiene por función (no soportado en Globals por SAM CLI)

Recursos renombrados (evitar colisión con Prod_new)

Recurso	Nombre original	Nombre 313	Estrategia
API Gateway	`Perfil$ENV`	`Perfil313$ENV`	Renombrado
LogGroup	`api-gateway/mas10-profile-api-4/$DD_ENV`	`api-gateway/mas10-profile-api-313/$DD_ENV`	Renombrado
FunctionName	`StatsRefreshGetV2$ENV`	`StatsRefreshGetV2$ENV`	Stack viejo eliminado
FunctionName	`StatsRefreshGet$ENV`	`StatsRefreshGet$ENV`	Stack viejo eliminado
FunctionName	`TrajectoryGet$ENV`	`TrajectoryGet$ENV`	Stack viejo eliminado
FunctionName	`TournamentHistoryGet$ENV`	`TournamentHistoryGet$ENV`	Stack viejo eliminado
SQS Queue	`sqs_stats_refresh$ENV.fifo`	`sqs_stats_refresh$ENV.fifo`	Stack viejo eliminado
EventBridge warming	`perfil-warming-rule-$ENV`	`perfil-warming-rule-$ENV`	Stack viejo eliminado

Nota: Los FunctionNames, SQS Queue y EventBridge se mantienen con nombres originales porque son invocados por otros servicios. Se eliminó el stack viejo perfilDev para liberar los nombres. El dominio profiledev.liricus.com.ar se preservó y su base path mapping se reconfigura post-deploy.

Módulos del layer propio (`layer/`)

Módulo	Descripción
`database_perfil/`	Lógica de dominio PostgreSQL del perfil
`query_perfil/`	Templates SQL del stack
`utils_perfil/`	Utilidades específicas
`email_send/`	Helper de envío de emails

Endpoints

Path	Métodos
`/check-version`	GET, OPTIONS
`/coach-athletes`	GET, OPTIONS
`/e-mail`	POST, OPTIONS
`/languages`	GET, PUT, OPTIONS
`/like-note`	GET, POST, OPTIONS
`/location/`	GET, POST, PUT, DELETE, OPTIONS
`/next-play-by-user`	GET, OPTIONS
`/profile`	GET, PUT, DELETE, OPTIONS
`/register`	POST, OPTIONS
`/sticker-border`	GET, OPTIONS
`/summary`	GET, OPTIONS
`/summary/teams`	GET
`/terms-and-conditions`	POST
`/tips`	GET, OPTIONS
`/tocke`	GET, OPTIONS
`/tournament-history`	GET
`/trajectory`	GET, OPTIONS

STACK_WIDGETS

Metadata

Campo	Valor
Rama origen	`Prod_new`
Stack DEV	`widgetsDev` (eliminado) → `widgetsDev313`
Template	`STACK_WIDGETS/widgets.yaml`
Funciones	8 Lambdas (7 Refresh* schedulers + 1 API endpoint)
Otros recursos	DynamoDB `ContentTable`, SQS FIFO `sqs_transfer_market_refresh`, EventBridge warming rule

Cambios aplicados

Runtime: python3.13, Architectures: arm64 en Globals
MemorySize: 512 en Globals (default); funciones Refresh* mantienen override MemorySize: 1024, Timeout: 840
Layers: [LayerWidgets, SSM CommonLayer] en Globals; eliminados por función
Datadog Transform eliminado por completo
DD_SERVICE y DD_ENV eliminados de variables de entorno
DatadogPocLogGroupSubscriptionFilter eliminado
LayerCommon resource eliminado → SSM /mas10/layers/common/arm64/dev_313
LayerWidgets: CompatibleRuntimes: python3.13, CompatibleArchitectures: arm64, BuildMethod: python3.13
API renombrada Widgets313$ENV, DependsOn: WidgetsApiLogGroup, EndpointConfiguration: REGIONAL
AccessLogSetting corregido a !Sub ARN (evita EarlyValidation)
WidgetsApiLogGroup renombrado: mas10-widgets-api-313/$ENV, tags DD eliminados
Schedule Names: $DD_ENV → $ENV
ContentTable DynamoDB: deletion protection deshabilitada para dev; tabla recreada por nuevo stack

Resolución de conflictos

Recurso	Estrategia
`widgetsDev` stack	Eliminado (libera FunctionNames)
`widgetdev.liricus.com.ar`	Base path mapping eliminado; dominio preservado para recrear post-deploy
`ContentDEV` DynamoDB	Deletion protection deshabilitada; tabla eliminada con stack; recreada por `widgetsDev313`

Post-deploy pendiente

# Recrear base path mapping para widgetdev.liricus.com.ar
API_ID=$(aws apigateway get-rest-apis --query "items[?name=='Widgets313DEV'].id" --output text --region us-east-1 --profile local)
aws apigateway create-base-path-mapping --domain-name widgetdev.liricus.com.ar --rest-api-id "$API_ID" --stage dev --region us-east-1 --profile local

Módulos del layer propio (`layer/`)

Módulo	Descripción
`database_widgets/`	Lógica de dominio del stack
`querys_widgets/`	Templates SQL

Funciones

Función	Handler	Trigger	Timeout	MemorySize
`RefreshMarketPlaceTrigger$ENV`	`trigger.lambda_handler`	API POST `/refresh-trigger`	840	1024
`RefreshMarketPlace$ENV`	`post.lambda_handler`	SQS + Schedule `cron(0 00 * * ? *)`	840	1024
`RefreshMyTeam$ENV`	`post.lambda_handler`	Schedule `cron(0 00 * * ? *)`	840	1024
`RefreshProdeMatch$ENV`	`post.lambda_handler`	Schedule `cron(0 00 * * ? *)`	840	1024
`RefreshNotes$ENV`	`post.lambda_handler`	Schedule `cron(0 00 * * ? *)`	840	1024
`RefreshComplexs$ENV`	`post.lambda_handler`	Schedule `cron(0 00 * * ? *)`	840	1024
`RefreshTraining$ENV`	`post.lambda_handler`	Schedule `cron(0 00 * * ? *)`	840	1024
`GetFeedWidgets$ENV`	`get.lambda_handler`	API GET `/feed`	100	512

STACK_COMUNIDAD

Metadata

Campo	Valor
Rama origen	`Prod_new`
Stack DEV	`comunidadDev` (eliminado) → `comunidadDev` (nuevo)
Template	`STACK_COMUNIDAD/comunidad.yaml`
Funciones	39 Lambdas
Otros recursos	EventBridge warming rule, API Key + UsagePlan (Transfermarket)

Cambios aplicados

Runtime: python3.13, Architectures: arm64 en Globals
Timeout: 100, MemorySize: 512 en Globals (era Timeout: 30 en Globals sin MemorySize); eliminados por función
Layers: [LayerComunidad, SSM CommonLayer] en Globals; eliminados por función
LayerCommon resource eliminado → SSM /mas10/layers/common/arm64/dev_313
LayerComunidad: CompatibleRuntimes: python3.13, BuildMethod: python3.13, BuildArchitecture: arm64
API renombrada Comunidad313$ENV, DependsOn: ComunidadAPiLogGroup, EndpointConfiguration: REGIONAL
AccessLogSetting corregido a !Sub ARN (evita EarlyValidation)
ComunidadAPiLogGroup renombrado: mas10-comunidad-api-313/$ENV, tags DD eliminados
DeploymentPreference: Enabled: false eliminado de 5 funciones
$DD_ENV eliminado (era solo en LogGroupName)

Resolución de conflictos

Recurso	Estrategia
`comunidadDev` stack	Eliminado (libera FunctionNames explícitos)
`comunidaddev.liricus.com.ar`	Base path mapping eliminado; dominio preservado para recrear post-deploy
`comunidadQa` stack	Pendiente (eliminar antes de deploy QA)

Post-deploy pendiente

# Recrear base path mapping para comunidaddev.liricus.com.ar
API_ID=$(aws apigateway get-rest-apis --query "items[?name=='Comunidad313DEV'].id" --output text --region us-east-1 --profile local)
aws apigateway create-base-path-mapping --domain-name comunidaddev.liricus.com.ar --rest-api-id "$API_ID" --stage dev --region us-east-1 --profile local

Overrides por función (excepciones a los Globals)

Función	Override	Motivo
`ChatMessageNameMigration`	`MemorySize: 1024`	Tarea de migración pesada
`OldChatMessageMigration`	`MemorySize: 1024`	Tarea de migración pesada
`MessageChatSessionGet`	`MemorySize: 1024` + `Layers: [SSM]`	Solo usa layer común (sin LayerComunidad)
`ChatTransfermarketPost`	`Environment.API_KEY_ENABLED: "true"` + `Auth: NONE`	Endpoint con API Key externa

Módulos del layer propio (`layer/`)

Módulo	Descripción
`database_comunidad/`	Operaciones DynamoDB de mensajería y canales
`querys_comunidad/`	Queries del dominio
`utils_comunidad/`	Formateador de respuestas, utilidades

STACK_FOLLOWERS

Metadata

Campo	Valor
Rama origen	`Prod_new`
Stack DEV	`followersDev` (eliminado) → nuevo
Template	`STACK_FOLLOWERS/followers.yaml`
Funciones	9 Lambdas
Otros recursos	EventBridge warming rule, API Key + UsagePlan (endpoints externos)

Cambios aplicados

Runtime: python3.13, Architectures: arm64 en Globals
Timeout: 60, MemorySize: 256 en Globals (era Timeout: 30); eliminados por función
Layers: [LayerFollowers, SSM CommonLayer] en Globals; eliminados por función (ambas ordenes)
LayerCommon resource eliminado → SSM /mas10/layers/common/arm64/dev_313
LayerFollowers: CompatibleRuntimes: python3.13, BuildMethod: python3.13, BuildArchitecture: arm64
API renombrada Followers313$ENV, DependsOn: FollowersAPiLogGroup, EndpointConfiguration: REGIONAL
AccessLogSetting corregido a !Sub ARN (evita EarlyValidation)
FollowersAPiLogGroup: indentación corregida (6→4 espacios), LogGroupName: "mas10-followers-api-313/$ENV" agregado
DeploymentPreference: Enabled: false eliminado de todas las funciones
DeletionPolicy: Retain + UpdateReplacePolicy: Retain preservados en 6 funciones

Resolución de conflictos

Recurso	Estrategia
`followersDev` stack	Eliminado (libera FunctionNames explícitos)
`followersdev.liricus.com.ar`	Base path mapping eliminado; dominio preservado para recrear post-deploy
`followersQa` stack	Pendiente (eliminar antes de deploy QA)

Post-deploy pendiente

# Recrear base path mapping para followersdev.liricus.com.ar
API_ID=$(aws apigateway get-rest-apis --query "items[?name=='Followers313DEV'].id" --output text --region us-east-1 --profile local)
aws apigateway create-base-path-mapping --domain-name followersdev.liricus.com.ar --rest-api-id "$API_ID" --stage dev --region us-east-1 --profile local

Módulos del layer propio (`layer/`)

Módulo	Descripción
`database_followers/`	Operaciones PostgreSQL del dominio
`querys_followers/`	Templates SQL
`utils_followers/`	Utilidades específicas
`subs_old/`	Lógica legacy de subscripciones

Funciones y endpoints

Función	Path	Método	Notas
`FollowProfilePost$ENV`	`/follow_profile`	POST	DeletionPolicy: Retain
`FollowProfileDelete$ENV`	`/follow_profile`	DELETE	DeletionPolicy: Retain
`FollowProfilePut$ENV`	`/follow_profile`	PUT	DeletionPolicy: Retain
`FollowProfileOptions$ENV`	`/follow_profile`	OPTIONS	DeletionPolicy: Retain, Auth: NONE
`FollowProfileExternal$ENV`	`/external/follow_profile`	POST	DeletionPolicy: Retain, ApiKeyRequired: true, Auth: NONE
`FollowProfileExternalOptions$ENV`	`/external/follow_profile`	OPTIONS	DeletionPolicy: Retain, Auth: NONE
`SearchProfilesGet$ENV`	`/search_profiles`	GET	Auth: NONE
`SearchProfilesOptions$ENV`	`/search_profiles`	OPTIONS	Auth: NONE
`FeedRecommendationsGet$ENV`	`/feedrecommendations`	GET	Warming target

STACK_MONITOREO

Metadata

Campo	Valor
Rama origen	`Prod_new`
Stack DEV	`monitoreoDev` (existente, sin conflictos de nombres) → nuevo `monitoreoDev313`
Template	`STACK_MONITOREO/monitoreo.yaml`
Funciones	59 Lambdas
Otros recursos	EventBridge Schedule (`SCHEDULE_MONITOREO_$ENV`)

Cambios aplicados

Runtime: python3.13, Architectures: arm64 en Globals
Timeout: 30, MemorySize: 512 en Globals (valores más comunes); eliminados por función
Layers: [LayerMonitoreo, CommonLayerArn] en Globals; eliminados por función
DD_SERVICE y DD_ENV eliminados de variables de entorno en Globals
Datadog Transform comentado por completo
DatadogPocLogGroupSubscriptionFilter comentado
LayerCommon resource eliminado → SSM /mas10/layers/common/arm64/dev_313
LayerChromedriver resource eliminado (no referenciado por ninguna función)
LayerMonitoreo: CompatibleRuntimes: python3.13, CompatibleArchitectures: arm64, BuildMethod: python3.13
API renombrada Monitoreo313$ENV, DependsOn: MonitoreoAPiLogGroup, EndpointConfiguration: REGIONAL
AccessLogSetting corregido a !Sub ARN (evita EarlyValidation)
MonitoreoAPiLogGroup renombrado: mas10-monitoreo-api-313/$ENV, tags DD eliminados
DeletionPolicy: Retain + UpdateReplacePolicy: Retain eliminados de 2 funciones (AthletesWithOlmV2Get, AthletesWithOlmV2Options)
DeploymentPreference: Enabled: false eliminado de 3 funciones
FunctionName: ...$DD_ENV → $ENV en 3 funciones (StatisticsMonitoringUserGet, GraficosOptions, GraficosGet)
Schedule: SCHEDULE_MONITOREO_$DD_ENV → SCHEDULE_MONITOREO_$ENV

Resolución de conflictos

Recurso	Estrategia
`monitoreoDev` stack	SIN conflictos — `$DD_ENV` (lowercase) vs `$ENV` (uppercase) genera nombres distintos
`monitoreodev.liricus.com.ar`	Base path mapping apunta a `Monitoreodev`; actualizar post-deploy a `Monitoreo313DEV`

Post-deploy pendiente

API_ID=$(aws apigateway get-rest-apis --query "items[?name=='Monitoreo313DEV'].id" --output text --region us-east-1 --profile local)
aws apigateway delete-base-path-mapping --domain-name monitoreodev.liricus.com.ar --base-path "(none)" --region us-east-1 --profile local
aws apigateway create-base-path-mapping --domain-name monitoreodev.liricus.com.ar --rest-api-id "$API_ID" --stage dev --region us-east-1 --profile local

Módulos del layer propio (`layer/`)

Módulo	Descripción
`database_monitoreo/`	Lógica de dominio PostgreSQL + DynamoDB del monitoreo
`utils_monitoreo/`	Utilidades específicas (channel, monitoring_group, response_formatter)
`aws_recursos/`	Helpers AWS (S3)
`email_send/`	Helper de envío de emails
`gene_pdf/`	Generación de PDFs
`warrant/`	Wrapper Cognito
`wordpress_recursos/`	Integración WordPress

Overrides por función

Función	Timeout	MemorySize	Notas
`CompetitionDayMonitoringPost`	200	1024
`CreateTrainingMonitoringPut`	300	1024
`CronNotificationMonitoringPost`	500	1024	+ Schedule cron(0 * * * ? *)
`CronNotificationMonitoringOptions`	500	—
`GroupMonithoringAthletesPendingGet`	—	1024
`StatisticsLesionesUser*`	300	—
`StatisticsMonitoringUserGet`	200	—	FunctionName: StatisticsMonitoringUserGet$ENV
`UserLesiones*`	300	—
`VideosTuto*`	300	—
`GraficosOptions`	300	1024	FunctionName: GraficosOptions$ENV
`GraficosGet`	300	1024	FunctionName: GraficosGet$ENV
`GMAthletesDOne*`	300	—

Estado general de migración​

Análisis de origen por rama​

Hallazgo principal​

Stacks pendientes de migrar (origen Prod_new)​

STACK_BACKOFFICE​

Resumen​

Cambios respecto a Python 3.9​

Módulos del layer propio (layer/)​

Endpoints por dominio​

Jugadores y perfiles​

Equipos​

Torneos y fases​

Fixture y partidos​

Liga​

Ubicación​

Catálogos y configuración​

Entrenamiento y nutrición​

Auth y usuarios​

Otros​

Resolución de conflictos​

STACK_BACKOFFICE_CONTENT​

Resumen​

Cambios respecto a Python 3.9​

Módulos del layer propio (layer/)​

Endpoints por dominio​

Notas y contenido generado​

Billboard y Cards​

Eventos​

Mensajería push / admin​

Topics y push masivo​

Posts y perfiles sociales​

Media y transcripción​

Configuración y catálogos​

Auth y usuarios​

Proceso de migración — pasos aplicados por stack​

Próximos stacks a migrar​

STACK_COLECTA​

Resumen​

Cambios respecto a Python 3.9​

Recursos renombrados (evitar colisión con Prod_new)​

Módulos del layer propio (layer/)​

Endpoints​

STACK_DYNAMO​

Resumen​

Cambios respecto a Python 3.9​

Recursos renombrados (evitar colisión con Prod_new)​

Módulos del layer propio (layer/)​

Arquitectura​

Endpoints​

STACK_BACKOFFICE_TOURNAMENT​

Resumen​

Cambios respecto a Python 3.9​

Módulos del layer propio (layer/)​

Endpoints​

STACK_TORNEOS​

Resumen​

Cambios respecto a Python 3.9​

Recursos renombrados (evitar colisión con Prod_new)​

Fix especial: MyPostulationDelete​

Módulos del layer propio (layer/)​

Endpoints (36 paths)​

Guía paso a paso para migrar un stack​

Pre-requisitos​

Paso 1 — Obtener el stack desde Prod_new​

Paso 2 — Transformar el template base ({stack}.yaml)​

2.1 Comentar Datadog Transform​

2.2 Agregar parámetro SSM para layer common​

2.3 Actualizar Globals​

2.4 Eliminar el recurso LayerCommon completo​

2.5 Reemplazar todas las referencias al layer​

2.6 Actualizar layer propio del stack​

2.7 Eliminar propiedades por función (heredan de Globals)​

2.8 Configurar API Gateway como REGIONAL​

2.9 Comentar SubscriptionFilter de Datadog​

Paso 3 — Renombrar recursos con nombre explícito (CRÍTICO)​

Paso 4 — Verificar el build script​

Paso 5 — Optimizar template con Globals​

Paso 6 — Commit y push​

Paso 7 — Verificar deploy en pipeline​

Conflicto de nombres entre stacks (FunctionName, ApiKey, UsagePlan, etc.)​

Estado general de migración

Análisis de origen por rama

Hallazgo principal

Stacks pendientes de migrar (origen Prod_new)

STACK_BACKOFFICE

Resumen

Cambios respecto a Python 3.9

Módulos del layer propio (`layer/`)

Endpoints por dominio

Jugadores y perfiles

Equipos

Torneos y fases

Fixture y partidos

Liga

Ubicación

Catálogos y configuración

Entrenamiento y nutrición

Auth y usuarios

Otros

Resolución de conflictos

STACK_BACKOFFICE_CONTENT

Resumen

Cambios respecto a Python 3.9

Módulos del layer propio (`layer/`)

Endpoints por dominio

Notas y contenido generado

Billboard y Cards

Eventos

Mensajería push / admin

Topics y push masivo

Posts y perfiles sociales

Media y transcripción

Configuración y catálogos

Auth y usuarios

Proceso de migración — pasos aplicados por stack

Próximos stacks a migrar

STACK_COLECTA

Resumen

Cambios respecto a Python 3.9

Recursos renombrados (evitar colisión con Prod_new)

Módulos del layer propio (`layer/`)

Endpoints

STACK_DYNAMO

Resumen

Cambios respecto a Python 3.9

Recursos renombrados (evitar colisión con Prod_new)

Módulos del layer propio (`layer/`)

Arquitectura

Endpoints

STACK_BACKOFFICE_TOURNAMENT

Resumen

Cambios respecto a Python 3.9

Módulos del layer propio (`layer/`)

Endpoints

STACK_TORNEOS

Resumen

Cambios respecto a Python 3.9

Recursos renombrados (evitar colisión con Prod_new)

Fix especial: MyPostulationDelete

Módulos del layer propio (`layer/`)

Endpoints (36 paths)

Guía paso a paso para migrar un stack

Pre-requisitos

Paso 1 — Obtener el stack desde Prod_new

Paso 2 — Transformar el template base (`{stack}.yaml`)

2.1 Comentar Datadog Transform

2.2 Agregar parámetro SSM para layer common

2.3 Actualizar Globals

2.4 Eliminar el recurso `LayerCommon` completo

2.5 Reemplazar todas las referencias al layer

2.6 Actualizar layer propio del stack

2.7 Eliminar propiedades por función (heredan de Globals)

2.8 Configurar API Gateway como REGIONAL

2.9 Comentar SubscriptionFilter de Datadog

Paso 3 — Renombrar recursos con nombre explícito (CRÍTICO)

Paso 4 — Verificar el build script

Paso 5 — Optimizar template con Globals

Paso 6 — Commit y push

Paso 7 — Verificar deploy en pipeline

Conflicto de nombres entre stacks (FunctionName, ApiKey, UsagePlan, etc.)