[SrStamm]

Related issue / Issue relacionada

Issue: #187
ODD: plan v2 aprobado como fuente única en #187 (comment); evidencia de implementación y smoke con API key real en #187 (comment)

Scope / Alcance

Provider nativo OpenCode Go (Kind::Subscription, grupo «sub»): cuotas de 5 h, semanal y mensual (ciclo de facturación) vía GET https://opencode.ai/zen/go/v1/usage con la API key de Go, sin x-opencode-org-id.

• Backend (src-tauri/src/providers/opencode_go.rs): fetch, parseo tolerante por ventana con ids estables (five_hour/weekly/monthly), validación de percent (finito en [0,100]) y resetsAt independiente, degradación parcial explícita con un único Warning que nombra todas las ventanas afectadas, y precedencia de errores HTTP sobre el parseo (status_for_http puro, testeable sin red).
• Config/secretos: OpenCodeGoConfig, OPENCODE_GO_API_KEY, ACCOUNT_PROVIDERS 11→12, tipos TS, toggle de visibilidad, cuentas adicionales con clave scoped.
• UI: pestaña «OpenCode Go» en Suscripciones, sección en Ajustes con SecretInput/HealthStep y enlace a Console, monograma OC, filas en README.md/README.es.md.
• Exclusiones (no-alcance del plan): desglose por modelo, saldo Extra Usage/USD, detección Go vs Go Plus, S1b («ventana no iniciada»: el reset recibido se muestra tal cual), OAuth de Console.

ODD feat/opencode-go-provider completo (T1–T9).

Coordination / Coordinación

• Para ODD: asignaciones y solapamientos revisados — Proveedor OpenCode Go: cuotas de 5 h, semanal y mensual #187 asignada a SrStamm con status:approved; sin PR solapadas (verificado contra issues/PRs abiertas del repo antes de arrancar).

Contributor / Contribuidor: @SrStamm
Claim or agreement evidence / Evidencia de asignación o acuerdo: asignación del mantenedor egdev6 en #187 (2026-10-27) y aprobación del plan v2 (2026-10-28, issuecomment-6472310756: «Plan aprobado: OK de arranque de T7»).

Acceptance and validation / Aceptación y validación

• Criterios cumplidos: 1 (smoke con API key real: tres ventanas con % y reinicio; evidencia visual en la issue), 2–9 y 11 (verificación completa en verde, ver abajo). Criterio 10: S1b fuera según el plan — el reset recibido se muestra tal cual.
• Comprobaciones ejecutadas y resultados (post-rebase sobre main vigente, chore(i18n): inventario estable, contrato de CI estructural y mensajes de drift (#160) #186/feat(i18n): migrar la tira y el detalle a los catálogos ES/EN — T2c slice 1 (#66) #195/feat(i18n): migrar las secciones no-provider de Ajustes a los catálogos ES/EN — T2c slice 2 PR-A (#66) #199/chore(release): prepare 0.8.0 #200):
  • cargo test: 322 passed, 0 failed (15 tests propios del provider).
  • cargo fmt --check: OK. cargo clippy --all-targets: 0 warnings en opencode_go.rs y en los archivos tocados.
  • npm test: 715 (vitest) + 240 (node scripts) passed, 0 failed — incluye el it.each de settings-visibility cubriendo opencode_go.
  • npm run typecheck: limpio.
  • node scripts/i18n-inventory.mjs --check (contrato CI de chore(i18n): inventario estable, contrato de CI estructural y mensajes de drift (#160) #186): OK tras regenerar el inventario (React 770→776 textos).
• Comprobaciones no ejecutadas y motivo: verificación Windows (desarrollo desde Linux, no se afirma).
• Bloqueos pendientes: ninguno. Sobre el tamaño: diff de 15 archivos (+770/−12, de los cuales ~230 son el doc ODD y ~30 el inventario i18n) — decidimos PR única; si el mantenedor prefiere dividir, se encadena sin recortar tests (nota 3 del plan).

An open PR does not mean integration. Release, secrets and signing operations require separate authorization.
Una PR abierta no implica integración. Release, secretos y firma requieren autorización separada.

[egdev6]

@SrStamm gracias por la PR. Está muy alineada con el plan v2. Integraste todo lo previsto: secreto en ALL y for_provider, ACCOUNT_PROVIDERS, CONFIG_KEY/MainKey, dataKey, clave aislada en cuentas adicionales, OFFICIAL_USAGE_URL y monograma. El módulo está registrado desde T7, sin dead_code. La precedencia HTTP, el Warning único compuesto y S1b fuera respetan el contrato. También corregiste la etiqueta de evidencia de «ventana no iniciada» en el documento ODD. CI en verde en las cinco plataformas.

Un cambio necesario antes de integrar y algunos ajustes menores.

Bloqueante: validación de resetsAt (criterio 6)

parse_usage acepta cualquier string no vacío como resetsAt. Un valor como "garbage" pasa sin diagnóstico y llega al frontend, donde Date.parse devuelve NaN (src/lib/pace.ts). El contrato indica que un resetsAt inválido o ausente conserva el porcentaje, deja el reinicio como desconocido y lo advierte. chrono ya es dependencia del proyecto (zai.rs); con DateTime::parse_from_rfc3339 se resuelve. Añade un test con un string no interpretable que verifique: porcentaje conservado, resets_at: None y aviso emitido.

Cobertura de S4 (no bloqueante, pero estaba comprometida en el plan)

• Faltan casos: el límite percent: 100, que S4 nombra explícitamente, y el JSON vacío o renombrado ({} o usage con otra clave).
• Aserciones más estrictas:
  • rate_limited_window_warning_keeps_meters usa contains("rolling") || contains("tarifa"). Con ||, el test no garantiza que se nombre la ventana.
  • percent_validation_bounds debería verificar que weekly y monthly se conservan y que no se crea el medidor de five_hour.
  • unknown_status_or_missing_status debería comprobar que se diagnostican ambas ventanas, weekly y monthly.
• Estado final del informe: ningún test verifica que el UsageReport termine en Status::Warning; solo se comprueba el vector de avisos. La nota 2 de la revisión del plan pedía que el test lo verificara. Extraer el tramo final de fetch a una función pura (por ejemplo build_report) permite probarlo sin red.
• Procedencia de fixtures: el comentario de entitlement_body() describe la procedencia del 429 («no reproducido en vivo…»). El cuerpo del 403 es documental (openusage), no sintético.

Mensajes y copy (sugerencias)

• Los avisos usan las claves internas del payload (rolling, monthly), pero el usuario ve «5 h» y «ciclo de facturación». Sugiero usar la etiqueta del medidor para que el mensaje sea accionable.
• «Ventana limitada por tarifa» no transmite bien rate-limited. Una alternativa: «Límite de uso alcanzado en la ventana de 5 h».
• La descripción de la pestaña dice «mensual», mientras la sección y el README hablan de «ciclo de facturación». Conviene unificarlo.
• El guard de informe vacío (meters.is_empty() && warnings.is_empty()) no se cumple nunca, porque parse_usage siempre emite avisos cuando no hay medidores. El resultado actual es razonable (un Warning con diagnóstico), pero conviene eliminar esa rama o documentar que el diagnóstico la sustituye.

Tamaño

Teniendo en cuenta que el documento ODD y el inventario i18n son mecánicos, el código propio queda en un tamaño revisable. Mantenemos PR única, sin necesidad de partirla.

Con el ajuste de resetsAt y los tests reforzados, vuelvo a revisar. Esta revisión no autoriza merge ni release.

[SrStamm]

Gracias por la revisión, muy fina. Resuelto el bloqueante y aplicados los refuerzos, en 3 commits (cd70933, 82b8613, ef046c7).

Bloqueante: validación de resetsAt

parse_usage valida el string con chrono::DateTime::parse_from_rfc3339, la convención ya usada en el repo (cursor.rs, grok.rs). Un valor no interpretable conserva el porcentaje, deja el reinicio como desconocido y emite el aviso (criterio 6). Test nuevo con strings no interpretables, escrito primero y observado en rojo antes del fix.

Cobertura S4

• percent: 100 como límite válido, sin diagnóstico y sin avisos.
• JSON vacío ({}), usage renombrado y usage vacío: sin medidores y con diagnóstico; en el último caso cada ventana ausente se nombra y se componen en un único Warning.
• Aserciones estrictas: el aviso de rate-limited nombra la ventana; percent_validation_bounds verifica que weekly y monthly se conservan y que five_hour no se crea; unknown_status_or_missing_status verifica que ambas ventanas quedan diagnosticadas.
• build_report extraída del tramo final de fetch: dos tests verifican el estado final del informe (Warning con diagnósticos, Ok sin ellos) sin red.
• Comentario del 403 corregido a procedencia documental.

Copy

• Los avisos usan la etiqueta visible del medidor («Cuota · 5 h», «Cuota · semana», «Cuota · ciclo de facturación») en lugar de las claves internas rolling/monthly.
• Rate-limited ahora: «Límite de uso alcanzado en Cuota · 5 h».
• El guard de informe vacío quedó documentado como rama defensiva (inalcanzable hoy porque parse_usage siempre emite avisos sin medidores).
• La pestaña dice «ciclo de facturación», unificada con la sección y los READMEs.

Verificación (post-cambios)

cargo test: 326 passed (19 del provider, +4). cargo fmt --check OK; clippy sin warnings en opencode_go.rs. npm test: 715 (vitest) + 240 (node scripts) passed. npm run typecheck limpio. node scripts/i18n-inventory.mjs --check OK. Verificación desde Linux, no se afirma Windows.

[egdev6]

@SrStamm gracias por la respuesta tan completa. He revisado de nuevo el diff (7f91f67): todo lo de mi revisión anterior queda resuelto.

• resetsAt se valida con DateTime::parse_from_rfc3339; un valor no interpretable conserva el porcentaje, deja el reinicio desconocido y avisa, con test para garbage, not-a-date y 2026-13-45T99:99:99Z.
• Cobertura de S4 completa: percent: 100, JSON vacío, usage renombrado y usage vacío con un único Warning que nombra las tres ventanas; aserciones estrictas en rate-limited, percent_validation_bounds y unknown_status_or_missing_status.
• build_report extraída y probada sin red para Warning y Ok; procedencia del 403 corregida; los avisos usan la etiqueta visible y la pestaña dice «ciclo de facturación».
• Los 19 tests llevan #[test] y los 5 checks están en verde en el head.

Falta un paso: rebase sobre main

La PR está en conflicto porque #204 ya está en main, y cambia cómo se declaran las pestañas:

• PROVIDER_TABS ya no lleva desc literal sino descKey: 'settings.providers.desc.*'. La nueva entrada necesita descKey: 'settings.providers.desc.opencodeGo' y la clave correspondiente en es.ts y en en.ts (el contrato tipado obliga a las dos; tsc falla si falta una).
• Desde feat(i18n): migrar el armazón de la página de Proveedores a los catálogos ES/EN — T2c slice 2 PR-B (#66) #204 todos los SecretInput reciben locale: pásalo también en los dos nuevos (pestaña y AccountEditor).
• Regenera el inventario (node scripts/i18n-inventory.mjs) tras el rebase.

Coordinación con C1

@danielgap, para que lo tengas en cuenta: los textos del panel de OpenCode Go (kicker, nota, pasos, etiqueta y ayuda de la API key) quedan en español literal, lo que es correcto aquí porque migrar los paneles por proveedor es tu C1. Si #201 entra antes, C1 debería incluir este panel; si C1 entra antes, SrStamm lo adapta al rebasear.

Con el rebase y el CI en verde, la doy por aprobada.

[SrStamm]

Rebase hecho sobre 4e973d6 (#204). Head: 359f9c3. CI en verde en las cinco comprobaciones, incluida Windows.

Al resolver el conflicto adapté lo que pediste: PROVIDER_TABS usa descKey: 'settings.providers.desc.opencodeGo' con la clave en es.ts y en.ts, y los dos SecretInput nuevos reciben locale. Inventario i18n regenerado.

Un extra que apareció: el fixture de Settings-providers-i18n.test.tsx que viene de main no conocía opencodeGo y rompía 4 tests. Lo amplié y añadí la descripción nueva al array, así queda cubierta en ES y EN.

Nota sobre el historial: 82b8613 (unificar «ciclo de facturación») quedó vacío al rebasear, porque ese texto ya vive en la clave opencodeGo añadida en be7da93. Git descarta commits vacíos, por eso el conteo no sube aunque añadí el commit del test.

Con esto quedo pendiente de tu aprobación para que el review deje de bloquear el merge.

[egdev6]

Aprobado sobre 359f9c3. Los cambios pedidos en la revisión del 28 (validación de resetsAt con RFC 3339, cobertura de S4, build_report y textos de los avisos) quedan resueltos, y el rebase sobre #204 incorpora descKey, locale en los SecretInput e inventario regenerado. CI en verde en las cinco comprobaciones.

[egdev6]

@SrStamm ¡muchas gracias por esta PR! He revisado el rebase (359f9c3) y está todo en orden: descKey con la descripción en es y en, locale en los dos SecretInput nuevos, inventario regenerado y el fixture del test de proveedores ampliado para cubrir OpenCode Go. El código del proveedor es el mismo que ya habíamos revisado.

Ha sido un trabajo de manual de principio a fin: evidencia real con tu API key, un plan ODD claro, tests escritos primero y respuestas a cada punto de la revisión sin dejar nada en el aire. Incluso el detalle del commit que quedó vacío al rebasear lo explicaste antes de que nadie preguntara. Así da gusto revisar.

Queda aprobada. Bienvenido OpenCode Go a la tira 🎉