Un plan de Xuda es un registro con quince campos, y el backend lee cuatro de ellos.
Los siete peldaños de membresía son registros en PLAN_OBJ: config.json:1820 free, :1850 pro, :1880 team, :1910 agency, :1940 enterprise_t1, :1969 enterprise_t2, :1998 enterprise_t3. Cada uno lleva un mapa features idéntico de quince claves, cinco numéricas y diez de texto, y el conjunto de claves es el mismo en los siete, así que un peldaño sin una capacidad la escribe como N/A en lugar de omitir la clave. Cuatro de esas quince las lee código en ejecución: projects y team_members por validate_user_plan (account_module:3932 y :3947), drive y ai_credits por get_effective_entitlements (:666-701). Las otras once, incluidas las ocho cadenas de capacidad Available y N/A, no las lee nada. Lo que decide si un método se ejecuta es un registro aparte: 30 de las 1010 entradas de cpi_methods en config.json llevan un min_plan, y http_module compara los rangos de plan contra él en cada solicitud (:542-547, aplicado en :868). La membresía es además solo una de dieciséis categorías de plan en el mismo objeto, 7 registros de 72, así que el resto del precio es un conjunto de escaleras que se apilan a su lado y no dentro de ella.
Claves de características en cada registro de membresía, el mismo conjunto en los siete
De esas quince, las que lee algún código en ejecución
De 1010 cpi_methods con un min_plan, el control que realmente rechaza
Categorías de plan en PLAN_OBJ, y membership es una de ellas
Los siete peldaños y los cinco números de cada uno, exactamente como están almacenados.
Estas son las cinco claves numéricas del mapa features de cada registro de membresía, copiadas sin reformatear. Un campo llamado plan_category divide los siete en 4 estándar y 3 enterprise, y cada registro lleva además un título de una palabra: Try, Deploy, Colab, Sale, Sync, Host, Own. Un campo note está definido solo en dos registros, pro con Best Value y team con Most Popular, mientras que agency lleva una cadena vacía. Instances se imprime como 0 en los tres peldaños inferiores en lugar de dejarse en blanco, porque el sentido de esa fila es que agency, con 500, es el primer valor distinto de cero. Solo enterprise_t3 usa la cadena unlimited, y la usa en las cinco celdas; planFeatures.js:5-15 establece la regla de lectura a la que la plataforma se somete: un número siempre es un tope real y solo esa cadena literal significa ilimitado, y por eso ningún número grande de esta tabla se reescribe como la palabra. La limitación honesta va en el mismo párrafo: PLAN_OBJ no lleva ningún campo de periodo de facturación en ninguno de los siete registros, así que la lectura mensual la pone el renderizador, pricing.vue:129 y :359, y no el registro.
Proyectos | Miembros del equipo | Instancias | GB de Drive | Créditos de IA | |
|---|---|---|---|---|---|
| Free, $0 | 5 | 1 | 0 | 15 | 30 |
| Pro, $49 | 50 | 2 | 0 | 50 | 600 |
| Team, $149 | 250 | 100 | 0 | 250 | 1600 |
| Agency, $399 | 1000 | 1000 | 500 | 1000 | 3500 |
| Enterprise T1, $1999 | 5000 | 5000 | 2000 | 5000 | 10000 |
| Enterprise T2, $4999 | 10000 | 10000 | 5000 | 10000 | 50000 |
| Enterprise T3, consultar | unlimited | unlimited | unlimited | unlimited | unlimited |
Entran quince claves. Salen cuatro.
El mapa features no es un objeto de ajustes que la plataforma consulte. Son quince claves de las cuales cuatro tienen un consumidor, y las cuatro no se comportan igual: dos de ellas rechazan una llamada con un código, y dos solo elevan un número que otra cosa gasta o factura. Las once restantes no tienen ningún lector en cpi, dashboard/src ni shared.
Dos de las quince pueden detenerle, y ambas son un simple mayor o igual.
validate_user_plan (account_module:3891) no llama a get_effective_entitlements y no comparte código con ella. Cuenta las apps master de la cuenta desde una vista de CouchDB, lee PLAN_OBJ[membership_plan].features directamente del registro y compara. Ambas ramas se activan solo cuando app_obj.app_type es master, y el proyecto de sistema propio de la cuenta queda exento mediante !app_obj.is_account_project, de modo que una cuenta que está en su tope aún puede iniciar sesión en lugar de quedar bloqueada fuera de lo único que le permitiría mejorar de plan.
- Projects: la comparación es ret_obj.master >= plan.features.projects en :3932, y se invoca desde app_module:1282 y :1301, que es el momento en que se crea un proyecto.
- Team members: el conteo de la vista >= plan.features.team_members en :3947, invocado desde team_module:265, :675 y :1280, así que todas las rutas de compartición pasan por la misma línea.
- Las campañas publicitarias quedan exentas de plano en :3894, y cualquier app_type distinto de master se salta ambos topes por completo. No se rastreó qué tipos de app llegan a esta ruta en la práctica, y eso queda NO VERIFICADO.
- Dos de las rutas de compartición de equipo nunca llegan a un rechazo limpio: team_module:271 y :1286 ejecutan cada una return ret; con un comentario ya presente en el código que dice ret not defined, así que el tope de asientos lanza un ReferenceError en lugar de devolver el objeto -9. Lo que finalmente ve un usuario en esas dos rutas está NO VERIFICADO.
- Contar las apps masterDesde una vista de CouchDB, excluyendo el proyecto de sistema propio de la cuenta
- Leer el registro del planPLAN_OBJ[membership_plan].features, directo de la configuración, sin auxiliar de prestaciones
- Comparar, mayor o igualret_obj.master >= plan.features.projects, y la llamada de creación se detiene ahí
- Contar las comparticiones de equipo activasLa segunda vista, la segunda comparación, el segundo código de rechazo
Los dos rechazos por cuota no son la frase pulida que escribe el control de capacidades.
El control de capacidades compone su mensaje a partir del nombre visible del método y de los nombres visibles de PLAN_OBJ (http_module:555-562), de modo que nombra la característica, nombra el plan y nombra la mejora. Los dos rechazos por cuota no hacen nada de eso. Son literales de plantilla que interpolan la clave interna del plan en lugar de resolverla, no son gramaticales y no señalan ninguna vía de mejora. app_module:1287 y :1306 devuelven el objeto a quien llama sin cambios, así que nada entre la comprobación y el cliente los reescribe. La línea del -8 de abajo se imprime con un conjunto concreto de valores, una cuenta agency en su tope de 1000 proyectos; en todos los demás lugares los corchetes angulares representan un campo que se rellena al momento de la llamada, que es la única forma honesta de imprimir una cadena cuyos valores no existen hasta la llamada.
La palabra unlimited se maneja dos veces, y solo una de ellas es a propósito.
Enterprise T3 es el único peldaño cuyas cinco cuotas numéricas son la cadena unlimited en lugar de un número, y dos funciones distintas se topan con esa cadena por dos rutas de código distintas. dashboard/src/lib/planFeatures.js:5-15 establece el contrato que la plataforma pretende cumplir: un número siempre es un tope real, y solo la palabra literal unlimited significa ilimitado. get_effective_entitlements cumple ese contrato deliberadamente. validate_user_plan lo cumple por accidente. Los dos carriles de abajo responden a las mismas cuatro preguntas en el mismo orden y llegan al mismo lugar, y por eso justamente vale la pena dibujar la diferencia en lugar de describirla.
Lo que esta página no puede decirle sobre los números anteriores.
- Todo lo anterior se leyó del código fuente del repositorio en la rama main, con trabajo sin confirmar en el árbol, y nada de esto se ejecutó contra una cuenta real. Cuando el repositorio y un servidor en ejecución discrepen, esta página está equivocada y el servidor tiene razón.
- PLAN_OBJ no lleva ningún campo de periodo de facturación en ninguno de los siete registros. La lectura mensual viene del renderizador, website-nuxt/pages/pricing.vue:129 y :359, y no del registro, así que todos los precios de arriba son mensuales solo porque lo dice la página que los muestra.
- No existe ninguna tarifa anual en PLAN_OBJ. pricing.vue:476 dice que el pago anual tiene descuento y que se consulte con ventas, así que en esta página no aparece ninguna cifra anual ni ningún porcentaje anual. Un descuento que no podemos leer de un registro es un descuento que no imprimiremos en una tarjeta.
- No se comprobó si las siete cadenas price_id se resuelven a precios reales de Stripe por estos importes. Solo se leyeron las cadenas de la configuración. El price_id también difiere según el entorno, y por eso ninguna página debería mostrar uno jamás.
- La memoria registra que config.json diverge de la configuración maestra en producción, que no se leyó aquí. Todas las cifras anteriores son autoritativas solo respecto al repositorio, y las copias del repositorio y de dev coinciden en los siete registros salvo en los ids de Stripe.
- La aplicación por debajo de esta línea se rastreó solo hasta la frontera HTTP. Si deploy_module vuelve a comprobar más abajo la elegibilidad de datacenter o de balanceador para una cuenta Pro está NO VERIFICADO, así que lea el siguiente bloque como lo que decide la puerta de entrada.
El control que realmente rechaza una característica nunca abre la tarjeta del plan.
El mapa features de un registro de membresía es una descripción de un plan, no un mecanismo. El mecanismo es un registro completamente distinto, cpi_methods en config.json, leído en cada llamada entrante por http_module. Nunca mira el mapa features: mira un único campo opcional del método invocado y decide con una sola comparación de rangos.
Ocho cadenas de capacidad, cinco aplicadas en otro lugar, tres no aplicadas por nada.
Diez de las quince claves de características son cadenas, y ocho de esas diez son binarias: N/A hasta que un peldaño las activa, y luego activas en todos los peldaños superiores, con la escalera estrictamente monótona, de modo que nada activo en el rango N está inactivo en el rango N+1. Como agency activa dos de ellas y enterprise_t1 activa otras dos, los ocho controles caen en seis peldaños distintos y no en ocho. Ninguna de las ocho cadenas la lee código alguno. Lo que sigue es cuánto vale realmente cada una.
Lo que afirma la tarjeta del plan | Lo que realmente lo aplica | Veredicto | |
|---|---|---|---|
| deploy | N/A en Free, Available a partir de Pro | min_plan pro en deploy_spa, deploy_mpa, deploy_pwa, deploy_embed, deploy_api, deploy_cron, deploy_emitter, deploy_preview, deploy_user_group y deploy_another | Coincide, salvo que deploy_mini_app lleva min_plan free |
| marketplace | N/A hasta Agency | min_plan agency en deploy_marketplace, deploy_instance, create_marketplace_listing, update_marketplace_listing y update_marketplace_listing_stat | Coincide |
| upload plugin | N/A hasta Agency | min_plan agency en upload_plugin | Coincide |
| datacenter sync | N/A hasta Enterprise T1, $1,999 | min_plan pro en deploy_datacenter, que cuesta $49 | La tarjeta es más estricta que el código, y lo que se ejecuta es el código |
| load balancer | N/A hasta Enterprise T1, $1,999 | min_plan pro en deploy_load_balancer, que cuesta $49 | La tarjeta es más estricta que el código, y lo que se ejecuta es el código |
| outsourced server | N/A hasta Enterprise T2 | Nada. Cero resultados en cpi, dashboard/src y shared bajo cualquier grafía | Una afirmación, no un control |
| xuda sdk | N/A hasta Enterprise T3 | Nada, según la misma búsqueda exhaustiva | Una afirmación, no un control |
| ai priority | N/A hasta Team | Nada, según la misma búsqueda exhaustiva | Una afirmación, no un control |
Treinta métodos de 1010 llevan un piso de plan, y ninguno está por encima de Agency.
El registro de controles es cpi_methods en config.json: 1010 entradas, 30 con un min_plan y una con un min_support_plan. Los pisos son pro en 19, agency en 6, team en 4 y free en 1. Ningún método lleva un min_plan por encima de agency, así que los tres peldaños enterprise no desbloquean nada en este control y lo que cambian son los cinco números. Un piso de la configuración está simplemente equivocado: set_credit_rules dice min_plan pro mientras que account_module:9339 rechaza cualquier plan inferior a Team con las palabras Credit management is available on the Team plan. El código es el control más estricto.
- Pro, 19 métodos. Diez son la familia deploy: deploy_spa, deploy_mpa, deploy_pwa, deploy_embed, deploy_api, deploy_cron, deploy_emitter, deploy_preview, deploy_user_group y deploy_another. Los otros nueve son deploy_datacenter, deploy_load_balancer, app_visibility_off, set_login_screen, generate_login_screen, change_under_attack_mode, enable_app_branding, create_stripe_account_link y set_credit_rules.
- Team, 4 métodos: add_developer_member, add_admin_member, add_login_sponsor y list_sponsored_users. Así que si puede invitar a un desarrollador lo decide el rango, y a cuántos puede invitar lo decide el número team_members. Dos mecanismos en una misma pantalla.
- Agency, 6 métodos: upload_plugin, deploy_marketplace, deploy_instance, create_marketplace_listing, update_marketplace_listing y update_marketplace_listing_stat.
- Free, 1 método: deploy_mini_app. Un piso que admite a todo el mundo, y la razón por la que el mapa features, que marca deploy como N/A en Free, no cuenta toda la historia.
- free1 método, deploy_mini_app, controlado con un piso que todo el mundo ya cumple
- pro, rango 119 métodos, la familia deploy más nueve controles de app y de cuenta
- team, rango 24 métodos, todos relacionados con añadir una persona a la cuenta
- agency, rango 36 métodos, publicación en marketplace y de plugins, y el piso más alto del archivo
Dieciséis escaleras comparten un objeto, y exactamente dos de ellas cambian su asignación.
PLAN_OBJ contiene 72 registros de plan en 16 categorías, y membership son 7 de ellos. Una función responde a qué tiene derecho realmente una cuenta, y lee tres campos de plan de los dieciséis: membership_plan, ai_workspace_plan y drive_plan. Todo lo demás en ese objeto controla su propio módulo en su propio eje y nunca toca sus créditos ni su almacenamiento.
Las dieciséis escaleras, sus peldaños y sus techos.
PLAN_OBJ contiene 72 registros de plan en estas dieciséis categorías, y membership son solo 7 de ellos. Las otras quince suman 65 peldaños entre todas, y las quince tienen un peldaño de $0, así que cada escalera es una elección y no un muro contra el que se choca. Los precios de abajo son el campo price de los registros, precios de lista mensuales en USD según la configuración del repositorio. La tercera columna es donde está el argumento: exactamente dos de las quince cambian cuánto vale la asignación de su membresía, porque get_effective_entitlements lee solo membership_plan, ai_workspace_plan y drive_plan y devuelve solo ai_credits y drive_gb. Las otras trece controlan su propio módulo, sus propios productos, buzones, tickets y comisiones, y nunca tocan sus créditos ni su almacenamiento. Xucode es el único producto controlado por el rango de membresía en lugar de por su propia escalera: xucode_entitlement (deploy_module/xucode.mjs:32-66) compara el rango de la cuenta contra el min_membership pro de config.json:414, y un id de membresía no reconocido falla cerrando el paso, es decir, ninguna máquina en lugar de una máquina gratuita.
Peldaños | Precio mensual máximo | Cambia la asignación de su membresía | |
|---|---|---|---|
| membership | 7 | $4999, y el peldaño más alto es la palabra call | Es la asignación |
| ai_workspace | 8 | 230 US$ | Sí, créditos y almacenamiento, solo con una membresía de pago |
| drive | 4 | 39 US$ | Sí, almacenamiento, en todos los niveles, incluido el gratuito |
| profile_phone | 6 | 39 US$ | No |
| support | 4 | 4500 US$ | No |
| trust_center | 4 | 299 US$ | No |
| commerce | 4 | 149 US$ | No |
| shipping | 4 | 149 US$ | No |
| tickets | 4 | 149 US$ | No |
| marketplace | 4 | 149 US$ | No |
| finance | 4 | 79 US$ | No |
| bot_protection | 4 | 59 US$ | No |
| xucode | 3 | 59 US$ | No, y es la única escalera con un piso de membresía |
| 4 | 49 US$ | No | |
| auto_response | 4 | 49 US$ | No |
| static_website | 4 | 39 US$ | No |
Cinco cosas sobre las otras quince escaleras que esta página no va a imprimir.
- Dos peldaños de ai_workspace discrepan entre config.json y config_dev.json en dos órdenes de magnitud, y son las dos únicas diferencias de precio en los 72 registros, así que en esta página no aparece ninguna cifra de ninguno de los dos.
- Todos los peldaños de pago de email, tickets, trust_center y auto_response no llevan price_id alguno, y tres de los cinco peldaños de teléfono de pago tampoco. stripe_module:251-258 trata un price_id ausente como dinero que no es una línea de suscripción, y nombra el teléfono como facturado por número y el correo por buzón. No se nombra ningún cargo por recurso equivalente para tickets, trust_center ni auto_response, así que si esos tres son facturables hoy queda NO VERIFICADO.
- config.json:414 fija xucode.enabled en false junto a min_membership pro, así que Xucode tiene tres peldaños con precio, un piso Pro y puede que ahora mismo no sea comprable en absoluto.
- El beneficio para miembros es un único cambio de precio en una única categoría. Todo registro ai_workspace de pago lleva un member_price_id, y ninguna otra categoría ni ningún peldaño de membresía lo tiene. El comentario del código en stripe_module:211-223 lo describe como un 10 por ciento de descuento, aplicado como un precio del 90 por ciento sobre el mismo producto de Stripe. Los importes viven en Stripe y no en el repositorio, así que aquí no aparece ninguna cifra en dólares para miembros.
- Muchos peldaños de complementos llevan un price_id de marcador, y stripe_module:226-300 ahora acuña un precio real de Stripe a partir del propio campo de precio del registro del catálogo en la primera venta, con una clave de búsqueda determinista para que un reinicio u otra región encuentren el mismo precio en lugar de acuñar un segundo. Por eso el número de la configuración es el número cobrado en esas escaleras. Leído del código fuente, nunca probado contra Stripe en producción.
Una mejora cobra el dinero antes de otorgar el plan.
Toda cuenta empieza con el ítem de membresía gratuita, así que comprar un nivel es un cambio de precio de ese único ítem de la suscripción y no una suscripción nueva, y stripe_update_plan decide la dirección comparando el rango dentro de la categoría (:1770-1787). Lo que sigue no es un cambio de plan que después le factura. Es un cargo que, solo una vez aprobado, se convierte en un cambio de plan.
El número del botón es el número que se cobra.
stripe_get_proration devuelve un sobre normalizado en lugar de una factura en bruto de Stripe, que lleva direction, plan_name, currency, renewal_amount, renewal_date, amount_due_now y las proration_lines detalladas (:446-500), y el resumen de pago muestra exactamente eso y nada más. El comentario del código registra el error que esto corrigió: la versión antigua mostraba toda la factura siguiente cuando solo cobraba la diferencia.
Una tarjeta fallida retiene la cuenta antes de suspender nada.
Dos banderas del documento de la cuenta lo abarcan todo, account_billing_hold_status y account_suspension_status. Ambas las activa el webhook invoice.payment_failed y ambas las limpia un webhook distinto, no algo que un agente de soporte haga a mano. La distancia entre la primera y la segunda son tres intentos más sobre la misma factura, y solo la segunda deja de servir sus apps.
- 01
Primer fallo: una retención de facturación
account_billing_hold_status se fija en 1 con una marca de tiempo y una entrada en el registro de la cuenta (stripe_module:1945-1949), y el mismo manejador envía un correo al cliente. El dashboard muestra un aviso que lista las facturas impagadas y el total adeudado con un botón de pagar todo, e indica que algunas acciones de la cuenta están bloqueadas, que es la redacción honesta porque la lista completa no está enumerada en un solo lugar. Marketplace rechaza una compra de plano mientras la retención esté activa (marketplace_module:1252-1254).
- 02
Cuarto intento: suspensión
Cuando webhook_data.attempt_count llega a 4, el mismo manejador activa además account_suspension_status (:1953-1958). Esa no es cosmética: router_module:5697 lanza Account suspended y deja de servir las apps de la cuenta. El calendario de reintentos detrás de attempt_count es configuración del panel de Stripe y no está en el repositorio, así que el tiempo real hasta la suspensión no puede determinarse desde el código. NO VERIFICADO.
- 03
El pago se aprueba: ambas se liberan
customer.subscription.updated limpia ambas banderas una vez que ninguna suscripción de ese cliente está en un estado no activo (:1806-1822). Dos excepciones nunca llegan a nada de esto: la factura única de mejora prorrateada va etiquetada para que una mejora rechazada deje el plan actual en buen estado, y una lista de propietarios y superusuarios nunca queda en retención ni suspendida automáticamente.
¿Por qué esta característica no está en mi plan?
Seis puntos donde la tarjeta del plan y el código discrepan, respondidos desde el código, con los no resueltos marcados.
Esta página explica la forma. Estos tres responden al precio.
Todo lo que está por encima de esta línea es mecanismo: qué comparación puede rechazarle, qué registro decide una capacidad, cuáles dos de las quince escaleras de complementos tocan su asignación y cuáles trece no. Nada de eso le dice qué pulsar. Tres enlaces sí. El primero es el selector de niveles con el flujo de pago detrás, que es la única pregunta que esta página deliberadamente no responde: una página que argumenta que la tarjeta del plan no es la capa de aplicación no debería ser también la página que vende la tarjeta del plan. El segundo es la lectura hermana sobre el único complemento que mueve su número de créditos. El tercero es su propia cuenta, donde las cadenas citadas arriba se muestran contra sus datos en lugar de contra un ejemplo. Esa entrada es el centinela @dashboard y no una URL, y pasa por el mismo resolutor que todos los demás enlaces de aquí, así que llega a donde su dashboard viva realmente.
Los siete peldaños uno al lado del otro, $0, $49, $149, $399, $1,999, $4,999 y un séptimo cuyo campo de precio es la palabra literal call en lugar de un número, con el flujo de pago detrás de cada uno.
Comparar nivelesOcho niveles, qué es realmente un crédito y por qué el saldo impreso junto a su nivel es un número distinto del nivel mismo. El nivel eleva una prestación mostrada; el saldo es un ledger de otorgamientos menos uso registrado, y ningún nivel de workspace acuña nunca un otorgamiento en él. Esa página también nombra los dos peldaños sobre cuyas cifras discrepan los dos archivos de configuración.
Leer la escaleraUna suscripción consolidada que lleva membresía, soporte y AI Workspace como tres ítems en una sola factura, las filas de plan debajo, y cualquier cambio programado mostrando su fecha efectiva junto a un botón de cancelar que libera la programación de Stripe y le deja renovando exactamente donde ya está.
Abrir facturaciónLas pantallas de facturación, en movimiento.
Esta es la grabación que el documento anterior de membership-plans ya llevaba en su campo youtube, conservada aquí en lugar de descartada. Una página armada a partir de claves de configuración, comparaciones de rango y cadenas de rechazo es una mala forma de ver moverse una pantalla de facturación, y el recorrido guiado es la parte del documento antiguo que nada en esta reescritura sustituye. Dos reglas para verlo. Cuando el recorrido y esta página discrepen sobre una cifra, la página es la que se construyó a partir del código fuente: los siete registros de membresía en PLAN_OBJ, los treinta pisos de método en cpi_methods y las rutas de aplicación en account_module, http_module y stripe_module. Y cuando el recorrido muestre una tarjeta de plan que enumera una capacidad, recuerde de qué ha tratado toda la página anterior. La tarjeta es un conjunto de cadenas de configuración que ningún código lee, el control que realmente se ejecuta es una comparación de rangos contra un piso de método, dos de las ocho cadenas de capacidad se controlan más abajo de lo que afirma la tarjeta y tres no se controlan por nada que se encuentre en cpi, dashboard ni shared. Un recorrido por las pantallas no puede mostrarle nada de eso, porque una grabación de pantalla solo puede mostrarle la tarjeta. Por esa razón va después del mecanismo y no en su lugar, y vale la pena verlo por la forma del flujo, dónde se ubican las filas de plan, qué aspecto tiene un cambio programado cuando está pendiente y qué le pone delante la previsualización de pago antes de cobrar nada.
Grabado antes de escribirse esta página, así que trate cualquier cifra en pantalla como exacta a su fecha de grabación y no a la lectura de configuración anterior. Todos los números de esta página salieron de config.json y del código cpi que lo acompaña, no de este video. También se sabe que las copias del repositorio de config.json y config_dev.json divergen de la configuración maestra en producción, así que un precio pronunciado en el recorrido, un número en las tablas de arriba y el importe que realmente se cobra a una cuenta son tres afirmaciones distintas. Solo la del medio se verificó aquí.
Abra la pantalla de facturación y lea su propio registro.
Su membresía es una cadena en el documento de su cuenta, membership_plan, que contiene la clave de uno de siete registros, y todo lo anterior es aquello con lo que se compara esa cadena. Dos comparaciones pueden rechazarle de plano, y ambas son simples pruebas numéricas sobre el mapa features: su número de proyectos contra features.projects y sus comparticiones de equipo activas contra features.team_members, en account_module:3932 y :3947. Ambas imprimen una frase que nombra el tope, devuelta como código -8 y código -9, y ambas nombran la clave interna del plan en lugar del nombre visible. Toda capacidad se decide en un lugar completamente distinto, mediante un registro de treinta pisos de método en cpi_methods comparados por rango en http_module:868, y esa comparación nunca lee la tarjeta del plan. Dos de las otras quince escaleras cambian su asignación, AI Workspace y Drive, y trece no, porque get_effective_entitlements lee exactamente tres campos de plan y devuelve exactamente dos números. Ahora hay cuatro cosas comprobables en su propia pantalla en lugar de sobre una promesa. La fila del plan muestra el nivel que su cuenta tiene realmente. Un cambio programado muestra su fecha efectiva y el botón de cancelar que lo libera, hasta el mismo momento en que se aplica. La suscripción consolidada muestra membresía, soporte y AI Workspace como líneas de una sola factura en lugar de como tres cobros. Y el saldo de créditos impreso junto al nivel es una cifra del ledger, que es exactamente por lo que no es el número de la tarjeta del plan. Mirar no cuesta nada. Si su membresía es gratuita, tenga en cuenta la regla de acumulación mientras esté ahí: el complemento de AI Workspace se cuenta solo cuando la membresía está definida y no es gratuita, así que un nivel de workspace de pago sobre una membresía gratuita no añade ni sus créditos ni su almacenamiento. No se rastreó si el proceso de pago impide que esa compra ocurra en primer lugar, y esta página lo dice en lugar de dar por supuesto que sí.