Estado de la pila web

seed envía un transporte web mínimo operativo más paquetes policy/validation portados. Todavía no existe un marco web completo en lenguaje limpio: las fachadas de servicio integradas (web, web_core runtime, web_runtime, webapp, websocket_server) permanecen archivadas hasta que el bucle persistente de conexión a respuesta, la cancelación y el drenaje de apagado se cierran de extremo a extremo.

Superficie operativa actual

Package/capability	Superficie actual
`web_core`	segmento de transporte operativo: configuración de escucha con reutilización de direcciones, lecturas de bloqueo limitadas, analizador request-line/header de copia cero, enrutamiento method/path sin asignación, generador de respuestas limitadas, reintento de escrituras completas (`EINTR`)
`http_server`	Solo segmento del analizador: analizador de solicitudes HTTP/1.1 limitado y sin asignación (`http_server_available() == false`); sin propiedad de conexión, mantenimiento de conexión, cuerpos fragmentados o TLS
`http_client`, `http_fetch`, `tls13`	lado del cliente HTTP/1.1 a través de TCP sin formato o TLS 1.3 (G12/G14); redirecciones limitadas, tiempos de espera y encuadres
`std-web-request`, `std-web-response`	Destino de formulario de origen delimitado y validación status/body-limit (G15, sin I/O)
`std-web-security`	cookie segura, CSP y marco de políticas (G15)
`std-web-static`	caminos relativos seguros para atravesar (G15); el archivo en sí es propiedad de la aplicación
`std-web-template`	escaped/raw-mode política con validación de texto seguro (G15)
`std-web-middleware`, `std-web-db`	prioridades ordenadas y validación de consultas de backend neutral (G15/G16)
`std-router`	validación de patrón de ruta únicamente; registration/dispatch son capas futuras
`oauth` (`grove/libs/oauth`)	Núcleo del servidor de autorización OAuth 2.0 integrado sobre Ridge: registro, PKCE, intercambio de códigos, rotación de actualización, revocación familiar (prueba de flujo verde; integración del sitio abierta)
`net`, `io`, `byte_buffer`, `text`, `parse`, `task`, `bytes`/`shared_bytes`, `str`/rebanadas	cimientos: enchufes propios, mecanografiados I/O, buffers inicializados, cursor de token, análisis verificado, simultaneidad estructurada, propiedad verificada binary/text vistas

Elementos aún de la hoja de ruta (no operativos): TLS servidor, análisis del cuerpo de la solicitud, transferencia fragmentada, propiedad de la conexión keep-alive, cancellation/drain y servicio WebSocket.

Evidencia desplegada

Ridge Admin (grove/apps/ridge-admin): aplicación basada en navegador servida por un locales seed proceso en loopback - sesión autenticada, CSRF, origin/Host cheques, CSP, limitado HTTP análisis, cierre elegante. Este es el patrón de referencia para servir un sitio en la pila actual.
rastreador web-core-bench: compila web_core mediante una compilación separada y atiende una solicitud de loopback limitada en el puerto 8080 (humo determinista; un servidor de referencia persistente para múltiples trabajadores es un paso de escalado separado).

Grove corpus web

Las fuentes de generación anterior permanecen bajo grove/libs/ (por ejemplo, web, web_request, web_response, web_runtime, web_middleware, web_security, web_static, web_template, web_db, web_metrics). Están transfiriendo entradas, no paquetes limpios actuales: p.

./seed/seed check grove/libs/web/src/lib.sd

falla durante el análisis porque la fuente utiliza nombres nominales heredados en mayúsculas y formas adicionales reemplazadas. En consecuencia, los ejemplos que devuelven tipos como WebAppStable, WebContext, o WebResponse no debe presentarse como limpio operativo seed código. Utilice el std-* puertos y web_core en cambio.

Requisitos para nuevos paquetes web

Un paquete web Grove se actualiza solo después de que cumple con todo lo siguiente:

Utiliza una sintaxis limpia de serpiente inferior y pasa la prueba operativa. parser/type inspector.
Reemplaza las llamadas de tiempo de ejecución heredadas implícitas con paquetes ordinarios actuales o interfaces de tiempo de ejecución auditadas explícitas.
Utiliza bytes/shared_bytes de propiedad y sectores prestados para solicitudes binarias y órganos de respuesta.
Hace visibles la asignación, el bloqueo, el pánico, I/O, FFI y los efectos inseguros.
Codifica la propiedad del socket, la conexión, el cuerpo de la solicitud y el búfer de respuesta con limpieza exacta.
Conserva la procedencia input/receiver para el encabezado, la ruta, la consulta y la copia cero. vistas del cuerpo.
Proporciona errores escritos para análisis, transporte, TLS, tiempo de espera y aplicación. fracasos.
Produce y consume interfaces .sdi actuales sin respaldo de fuente.
Declara requisitos platform/runtime y suministra INSTALL.md para FFI.
Pasa positivo, negativo, desinfectante, entrada mal formada, cancelación y separate-compilation tests.

Reclamaciones de producción

Hasta que se cierren las capas de publicación archivadas, la documentación seed no debe reclamar soporte actual para:

producción (persistente, multitrabajador) HTTP servicio;
TLS operación del servidor;
sesiones de marco, CORS o pilas middleware/WebSocket completas más allá del rebanadas policy/validation portadas;
Rendimiento del producto compatible con TechEmpower a través de la pila limpia;
uso directo de las importaciones web heredadas Grove (web, webapp,…) por parte aplicaciones.

Servicio acotado en bucle invertido en el Ridge Admin patrón, el web_core rebanada de transporte, la G15/G16 puertos de política, y el oauth El flujo está cubierto por sus líneas de base y pruebas nombradas, y puede afirmarse exactamente como se evidencia.

Los puntos de referencia históricos sobre el código Grove pueden permanecer como evidencia histórica etiquetada explícitamente. No establecen soporte operativo para el idioma actual.

Siguientes rebanadas

El segmento de transporte que solicitaba la antigua hoja de ruta ahora existe (web_core). Los siguientes fragmentos creíbles, en orden, son:

1. request-body parsing (bounded, Content-Length; then chunked)
2. persistent connection loop: keep-alive, cancellation, shutdown drain
3. TLS server
4. dispatch router + static-file serving on the verified loop
5. session/middleware composition on std-* policies + oauth

El enrutamiento, el middleware, el TLS, la agrupación, las plantillas y las capas de aplicaciones superiores deben basarse en el segmento de transporte verificado en lugar de preservar las API heredadas únicamente por compatibilidad de origen.

Realice un seguimiento de las prioridades del ecosistema en Hoja de ruta de la biblioteca. la corriente compiler/library El límite está documentado en Referencia de la biblioteca operativa, y Grove las reglas de compatibilidad están en Grove Árbol de compatibilidad. Gate evidencia: G11 (crypto/session/jwt), G12/G14 (HTTP cliente), G15/G16 (puertos de política web, servicio archivado) en seed/compiler/llvm/tests/GROVE_G*.md.