DEV Community: tauchi Español

Cómo crear y alojar pequeñas apps internas con Custom App de osFoundry

tauchiii — Fri, 06 Nov 2026 16:48:40 +0000

Es jueves, faltan dos horas para un release y Dari es la única persona que sabe qué pasos del cutover ya están hechos. El checklist vive en una pestaña de una hoja de cálculo, el runbook en una unidad compartida y la discusión en un hilo de chat que nadie encuentra. Lo que el equipo necesita de verdad es una app diminuta con cuatro casillas y dos responsables, justo al lado de los archivos. Escribirla es fácil. Alojarla, darle una base de datos, guardar sus claves de forma segura y conseguirle una URL es la parte que suele atascarse.

Qué es la categoría Custom App

osFoundry agrupa todo lo necesario para crear y ejecutar tus propias apps pequeñas en una sola categoría de la barra lateral de la app de escritorio, llamada CUSTOM APP. Tiene cinco pantallas. Room es el espacio compartido donde las apps viven como pestañas. App Code es el repositorio que hay detrás de una app. Deployed Apps es la lista, a nivel de todo el workspace, de lo que está en producción. Snippets reúne las apps diminutas que nunca necesitaron un repositorio. Domains gestiona las direcciones web desde las que se sirven esas apps. Si conoces Notion, imagina una página cuyas pestañas son apps que funcionan en lugar de documentos, con una pequeña capa de hosting al estilo de Vercel por debajo: cada app tiene su propia base de datos, sus secretos, sus tareas programadas y un subdominio, tal como se describe en la página de la función de apps internas.

Un vistazo a la pantalla de construcción

La forma más rápida de ver cómo nace una app es la vista de construcción de la app de escritorio. Esta captura es del constructor de Websites (proyecto de ejemplo "Hearth Bakery"), que usa el mismo ciclo de describir y construir que ofrece una Room con su cuadro "Describe the app you want".

Pages, a la izquierda: las partes de la app que ya existen, con Add page abajo.
La vista previa, en el centro: lo que estás construyendo, con tamaños de escritorio, tablet y móvil encima. La etiqueta "On this computer" indica que todavía no se ha publicado nada.
El cuadro de descripción: escribes qué hace la app, para quién es y qué sensación debe transmitir, y pulsas Build my site. Maestro, el asistente de IA de la app, escribe los archivos.
El panel de Maestro, a la derecha: la conversación que construye y modifica la app. Use a folder le indica que use tu propio material en lugar de dejar que adivine.
Publish needs credits, arriba: construir y previsualizar ocurre en tu ordenador; el hosting es el paso que consume créditos del workspace.

Dentro de una Room la idea es la misma con otra disposición: una tira de pestañas de apps arriba, la app seleccionada en el centro y un panel derecho con dos pestañas, Maestro y Details.

Caso de uso 1: un equipo de release tiene su checklist donde está el trabajo

Quiénes: una release manager y tres compañeros preparando un lanzamiento.

La situación: los pasos del cutover, el runbook y el tracker del release están repartidos en tres herramientas, y el día del release nadie se fía de la hoja de cálculo.

Qué hacen en osFoundry:

Crean una room llamada "Launch Ops" con New Room y añaden el tracker del release y los archivos del lanzamiento como pestañas.
Pulsan el botón + de la tira de pestañas. El selector New Tab lista las apps instaladas y un catálogo (Incident log, Retro board, On-call rota, Changelog builder), filtrable por All, Forked o Snippets.
En "Describe the app you want" hacen clic en Build a snippet y piden un checklist de cutover con un responsable por tarea. Un snippet es una mini-app ejecutable formada por unos pocos archivos. No tiene repositorio, ni versión, ni deploy, y se ejecuta ahí mismo, en la pestaña.
Siguen hablando con Maestro en el panel derecho mientras el checklist está abierto, y usan la pestaña Details para ver qué es la room y qué ha pasado en ella.

Con qué terminan: una sola room donde el checklist (en la demo: Freeze the 2.4 branch, Run the order-index migration, Smoke-test the order desk, Post the release note) está junto al runbook y al tracker. Más adelante, la pantalla Snippets lista todos los snippets de todas las rooms. Desde ahí alguien puede exportar uno como JSON con Export para otro workspace, o convertirlo en un repositorio de verdad con Promote cuando se le quede pequeña la pestaña.

Caso de uso 2: un desarrollador le da un backend real a una herramienta interna

Quién: un desarrollador en solitario que construye una herramienta de altas y pedidos para el equipo de soporte.

La situación: la primera versión corría en un portátil con un archivo SQLite. Ahora la necesitan tres equipos, tiene que llamar a una API de pagos y hay una limpieza nocturna que debe ejecutarse sin que nadie tenga que acordarse de pulsar un botón.

Qué hace en osFoundry:

Mientras la app todavía corre en local, abre el proyecto en el IDE y hace clic en la pestaña Database. Encuentra los archivos .db y .sqlite de la app y abre una tabla en solo lectura, 200 filas por página (datos de ejemplo arriba), para que veas qué guardó realmente la app antes de mover nada.
Mueve la app a una room compartida. El diálogo Move to cloud copia la app a una Cloud room para que todos sus miembros puedan usarla, e informa de qué tablas se copiaron y cuáles se quedaron en el dispositivo. La app y sus datos siguen también en este dispositivo.
Abre la configuración de la pestaña de la app. En Secrets, App Runtime Secrets lista las claves que declara la app; Add a custom secret guarda una nueva y Rotate reemplaza un valor. La app muestra entonces "Secrets updated. Redeploy to apply changes."
Declara la limpieza en container.cron dentro del manifiesto de la app, abre Scheduled jobs y hace clic en Sync from manifest. Cada tarea se puede pausar, reanudar o lanzar una vez con Run now.

Con qué termina: una app con su propia base de datos Postgres. En osFoundry cada Room App tiene una, con pgvector y TimescaleDB instalados, y la cadena de conexión llega como secreto en tiempo de ejecución (Postgres por app). El explorador de la base de datos tiene un editor de filas con filtros y una vista SQL solo para SELECT, y Database snapshots ofrece New snapshot, Restore y un enlace de descarga. Los cambios de código se hacen en App Code, donde el desarrollador puede trabajar en una versión como version/2.4 sin tocar main, revisar el Manifest (punto de entrada, visibilidad, conectores requeridos) y seguir el árbol de Versions antes de publicar.

Caso de uso 3: la dueña de una tienda publica una página y la tiene vigilada

Quién: alguien que lleva una pequeña panadería y no programa.

La situación: quiere una web sencilla con la carta y el horario, en su propia dirección, y quiere saber cuánto cuesta mantenerla en línea.

Qué hace en osFoundry:

Abre Websites, pulsa New Website, describe la panadería y pulsa Build my site. La primera versión (arriba, de ejemplo) usa textos de relleno, y Maestro lo dice claramente.
Pulsa Use a folder, elige la carpeta con la carta y las fotos reales y pide cambios con palabras normales, como "Make the headline bigger."
Cuando queda bien, la publica. El hosting usa créditos del workspace. Who can open it ofrece Workspace members only, Anyone with the link o el inicio de sesión propio de la app; una web pública de panadería usa Anyone with the link.
En Domains registra un dominio o añade uno que ya tiene, y edita sus registros DNS. Events muestra quién cambió cada registro, y Settings contiene la renovación, la privacidad y el código de transferencia.

Con qué termina: una web con sus propios textos y fotos, servida en su propio dominio. Deployed Apps responde luego a las preguntas que de verdad se hace una dueña. Apps muestra cada app y dónde se sirve, Activity muestra qué ha cambiado, Usage muestra el coste de build y almacenamiento por app, y Previews lista las versiones de vista previa que siguen en marcha.

Cómo encaja con el resto de osFoundry

Custom App casi nunca trabaja sola. Maestro es el asistente del panel derecho de cada Room y de las vistas de construcción; escribe y edita el código contigo. El IDE te da la pestaña Database, el control de versiones y el editor para las apps que empiezan como una carpeta en tu ordenador. Websites es un camino más rápido cuando la "app" es en realidad una web pública. Los Snippets solo se conectan con App Code a través de Promote, así que una herramienta de usar y tirar puede convertirse en un repositorio mantenido sin reescribirla. El trabajo programado dentro de una app lo cubren los cron jobs de app, descritos en la página de la plataforma sobre app cron.

Preguntas que hace quien empieza

¿Una Room es una sala de chat?
No. El núcleo de una Room son sus pestañas de apps. El chat de Maestro está en el panel de acompañamiento de la derecha, junto a los Details de la room.

¿Cuándo conviene crear un snippet en lugar de una app?
Cuando la herramienta son unos pocos archivos y solo tiene que funcionar dentro de una room, como un formateador de fechas o una comprobación de webhooks. Guardar un snippet no instala nada ni despliega nada. Si más adelante necesita versiones, secretos o una base de datos, conviértelo en repositorio con Promote.

¿Pueden dos apps compartir una base de datos?
Cada app tiene su propio Postgres. Compartir pasa por permisos explícitos: la pestaña Database de la room muestra Incoming Requests, Active Grants y Outgoing Access, y cada solicitud se puede aprobar o rechazar.

¿Cuesta algo probarlo?
Construir y previsualizar en tu ordenador no necesita créditos. Publicar, desplegar y registrar dominios usa créditos del workspace. Puedes descargar la app de escritorio en osfoundry.io/es/download.

Qué hace Maestro de osFoundry, un chat de IA que muestra cada paso que dio

tauchiii — Fri, 06 Nov 2026 15:38:09 +0000

Son las 4:40 de un jueves y Priya le ha pedido a un asistente de IA que añada un botón "Eliminar cuenta" a la página de ajustes de su app. La respuesta dice "Hecho, 4 archivos modificados". Antes de publicarlo quiere saber qué cuatro archivos son, qué leyó el asistente para decidirlo y si se acercó al código de facturación. Una ventana de chat normal solo le da el párrafo final.

Maestro en un párrafo

Maestro es el espacio de trabajo de IA con todas las herramientas dentro de la app de escritorio de osFoundry. Escribes la petición como en cualquier chat, pero la respuesta llega con su recorrido: cada archivo que listó, cada búsqueda que lanzó, cada archivo que leyó o editó y cada comando de terminal, cada uno en su propia fila con una duración que puedes desplegar. Puede trabajar dentro de una carpeta de tu ordenador, proponer cambios en lugar de escribirlos sin avisar y detenerse a enseñarte un plan antes de tocar nada. Lo encuentras como Maestro en la barra lateral. Si has usado ChatGPT o Claude en el navegador, imagina la misma conversación con el registro de actividad del agente y unos frenos al lado.

Un vistazo a la pantalla

Pestañas de superficie en la parte superior. Maestro, Model chat, Multi chat, Research, Wiki y Code conviven en esta misma pantalla. Maestro es la pestaña con el conjunto completo de herramientas.
Pestañas de detalle encima de la conversación: Chat, Sources, Files, Changelog, Tools, Pipeline y Logs. Son vistas distintas de la misma ejecución. Sources guarda en qué se basó la respuesta, Changelog lista los archivos que escribió este chat y Logs muestra los pasos y, en Costs, cuánto costó cada petición.
Las filas del proceso en la transcripción. Aquí Maestro listó src/ (38 archivos), hizo grep de deleteUser, encontró 0 coincidencias y luego leyó account.ts y users.ts. Si haces clic en una fila, se abre y muestra la entrada y la salida exactas de esa llamada a la herramienta.
La barra de control sobre el cuadro de mensaje: el interruptor del sandbox, Plan OFF/ON, Tools y Goal. Debajo del cuadro están los selectores de carpeta, proyecto, repo, Router y modelo.
El panel de vista previa a la derecha, donde un archivo, un diff o una página web se abre junto a la conversación en lugar de sustituirla (Open File / App / Page, Browse Files, Browser).

Tres formas de usarlo

Una desarrolladora que quiere ver el plan antes del cambio

El caso de Priya del principio. El cambio toca cuentas y sesiones, así que prefiere leer el plan a revisar un diff sorpresa.

Hace clic en Plan en la barra de control para que ponga Plan ON.
Escribe "Add a Delete account button to settings" y lo envía.
Maestro lee seis archivos y no cambia ninguno. Con el modo plan activado, la propia app de escritorio rechaza cualquier herramienta que escriba un archivo o ejecute un comando, así que "solo lectura" no es una petición amable dentro del prompt.
Llega una tarjeta Plan marcada como "Awaiting approval", con los botones Approve y Cancel.

El plan del ejemplo nombra cuatro archivos, indica que src/billing/ queda intacto porque Stripe guarda sus propios registros y termina con "Nothing has been changed yet." El modo plan se desactiva solo cuando llega el plan. Priya pulsa Approve y solo entonces Maestro edita los cuatro archivos y ejecuta los tests (npm test -- account, 3 passed), todo visible como filas EDIT y TERMINAL. Si el plan no le hubiera gustado, Cancel habría dejado la carpeta exactamente como estaba.

Con qué se queda: un cambio que aprobó de antemano y una transcripción que muestra dónde miró el agente y qué ejecutó.

Un compañero nuevo orientándose en el código

Dan entró en el equipo el lunes. Necesita saber dónde está el bloqueo de login, pero en el código nadie lo llama "lockout", así que una búsqueda de texto no devuelve nada.

En Indexes añade una vez la carpeta del proyecto para que se pueda buscar por significado.
En un chat de Maestro sobre esa carpeta pregunta dónde bloquea la app a la gente tras varios logins fallidos.
Sigue las filas del proceso: una búsqueda en la carpeta que devuelve 2 resultados y luego un READ de throttle.ts.

La respuesta apunta a src/auth/throttle.ts (líneas 1–46) y src/routes/session.ts (líneas 22–61), y explica que el código nunca dice "lock out": tras cinco intentos fallidos fija un tiempo de espera de 15 minutos y devuelve 429 antes de comprobar la contraseña. Como la respuesta incluye rutas de archivo y las filas muestran lo que se leyó, Dan puede abrir esas mismas líneas en el panel de vista previa y comprobarlo él mismo en lugar de fiarse de un resumen. En este caso nada escribe en disco, así que puede dejar Approval Mode en su valor por defecto.

Con qué se queda: los dos archivos que importan, el motivo por el que la búsqueda por palabra clave no los encontró y un chat al que puede volver desde la lista de chats.

Una persona de marketing editando textos en un repo ajeno

Sammy escribe los textos de la página de lanzamiento, pero la página es un archivo React del repo de ingeniería. Quiere que el texto nuevo siga la guía de tono de docs/ y no quiere que se haga commit de nada sin revisarlo.

Abre el menú Approval Mode del compositor y elige Permission & Approve, que pregunta antes de cada llamada a herramienta. Las otras opciones son Auto Accept (la predeterminada, las herramientas se ejecutan al momento), Plan First (planificar antes de ejecutar) y Bypass (ninguna aprobación, ni siquiera para push o envío de formularios).
Activa el sandbox para que las escrituras se preparen en una rama en lugar de caer en la carpeta de trabajo.
Le pide a Maestro un borrador de la página de lanzamiento coherente con la documentación. Lee docs/tone.md, busca en el código y propone un cambio en src/Launch.tsx.
El diff se abre en el panel de vista previa. Lo acepta y luego usa Export to branch para que alguien de ingeniería lo revise como cualquier otro cambio.

Con qué se queda: un texto que cita la guía de tono que siguió (la pestaña Sources la conserva), un diff revisado y una rama en lugar de una sorpresa en main.

Dónde encaja Maestro frente a Model chat, Chat y Multi chat

Maestro comparte pantalla con hermanos más sencillos, y elegir el adecuado ahorra tiempo y dinero.

Model chat es una pestaña de la misma pantalla que envía cada turno a un único modelo que eliges. Es una conversación de solo lectura: sin carpeta, sin herramientas que actúen, sin aprobaciones. Ideal para una pregunta rápida.
Chat tiene su propio sitio en la barra lateral. También responde con un modelo que eliges para toda la conversación, pero conserva las capacidades sobre archivos, así que puede proponer un cambio que aceptas (Accept) o rechazas (Reject), registrado en Changelog. Úsalo cuando quieras que un modelo concreto haga el trabajo, sin un router que decida por ti.
Multi chat hace la misma pregunta a varios modelos a la vez. En Compare lees las respuestas en paralelo; en Council los modelos responden, puntúan a ciegas las respuestas de los demás y uno escribe una síntesis.

Desde Maestro el trabajo suele pasar a otras partes de la app. Research convierte una pregunta en un informe con citas, Code ejecuta un agente de programación en su propia rama, Indexes hace que una carpeta se pueda buscar por significado (como en el caso de Dan) y Version → Merge Station es donde se fusionan los cambios del sandbox. Si un turno sale mal, escribir /rewind en el chat restaura los archivos que cambió ese turno. Para profundizar, la página de orquestación de Maestro recorre las pestañas de detalle y la página del modo plan explica el flujo de aprobación.

Las primeras preguntas que hace la gente

¿El modo plan es solo una instrucción en el prompt?
No. Mientras Plan está en ON, cualquier herramienta que no esté en la lista de solo lectura se rechaza cuando la app la despacha, así que el agente puede leer, buscar y navegar, pero no puede editar ni ejecutar comandos hasta que apruebes el plan.

¿Qué diferencia hay entre el interruptor Plan y Plan First en Approval Mode?
Plan es un interruptor puntual para la siguiente petición: investigar, presentar un plan, esperar. Approval Mode es la regla fija del chat para las llamadas a herramientas, de Auto Accept a Bypass. Plan First es uno de sus cuatro ajustes.

Hay muchas filas de proceso. ¿Puedo ocultarlas?
Sí. El ajuste Process Detail alterna entre Full y Compact. Solo cambia cómo se muestran los pasos, no cómo se ejecuta el turno.

¿Qué modelo usa Maestro?
Por defecto el Router elige un modelo en cada turno, y las filas del proceso muestran cuál se ejecutó. Puedes cambiar el modo de modelo (en la nube, local o autoalojado) desde el compositor, o usar Chat cuando quieras fijar un único modelo para toda la conversación.

Puedes descargar la app de escritorio en osfoundry.io/es/download.

Cómo Code, el IDE y Wiki de osFoundry mantienen revisable el trabajo de varios agentes de IA en paralelo

tauchiii — Fri, 06 Nov 2026 13:38:06 +0000

Son las 4 de la tarde y tres agentes de código llevan desde el mediodía trabajando en el mismo repositorio. Uno corrigió el redondeo del total del carrito, otro añadió un código de descuento y el tercero escribió tests. Los tres dicen "done". Antes de que nada toque main, quieres saber dos cosas: ¿dos de ellos reescribieron la misma función? ¿Y los tres cambios siguen pasando los tests cuando se juntan?

Tres pantallas para un mismo código

osFoundry es una app de escritorio que reúne chat, agentes, archivos y herramientas en una sola ventana, y para el código ofrece tres pantallas relacionadas. Code es donde repartes tareas entre varios agentes a la vez: cada ejecución tiene su propia rama de Git y su propia carpeta de trabajo (un worktree), y tú revisas, pruebas y previsualizas el merge antes de decidir nada. Nada se fusiona solo. El IDE es un editor de código para una carpeta local, con explorador, control de versiones, terminal, paneles de problemas y tests, y una columna de asistente que ve el archivo en el que estás. Wiki lee un repositorio de tu máquina y escribe páginas de documentación que citan path:line, y luego marca la página cuando cambia el código que cita. Code y Wiki aparecen como pestañas junto a Maestro, Model chat, Multi chat y Research; el IDE tiene su propia entrada en la barra lateral. Si conoces VS Code con su panel de Git, el IDE te resultará familiar. Code se parece más a una bandeja de pull requests, solo que los autores son tus agentes y las ramas nunca salieron de tu portátil.

Un vistazo a la pestaña Code

Lo que ves en esta pantalla (las ejecuciones son datos de ejemplo):

El aviso en la parte superior de la columna. "3 agents finished · they disagree on 1 file" nombra el archivo, aquí src/cart.js, antes de que abras un solo diff. El botón Review together inicia una revisión conjunta.
La columna de ejecuciones. Se agrupan según lo que necesitan de ti: Ready to review, Needs attention y un History plegado. Cada fila muestra la tarea, las líneas añadidas y eliminadas, cuánto tiempo trabajó y su rama.
La conversación en el centro. Haz clic en una ejecución y lees qué se le pidió al agente y qué fue diciendo mientras trabajaba.
El panel derecho. Las pestañas Changes, Files, Commits, Review y PR muestran el diff real de cada ejecución: primero el trabajo sin commit y después lo que ya está en su rama.
La Merge station abajo a la derecha. Seleccionas las ejecuciones terminadas y aquí las pruebas y previsualizas cómo quedaría fusionarlas juntas.

Caso de uso: una tech lead con tres agentes en un repo

Dana lidera un pequeño equipo web y reparte un sprint de checkout en tres ejecuciones de agentes: corregir el redondeo en los totales del carrito, añadir un código de descuento al checkout y añadir tests para el formateador de precios. Cada ejecución empezó desde New run con una tarea de una línea y un agente elegido para ella, así que cada una tiene su propia rama y carpeta, y ninguna puede pisar los archivos de las otras mientras trabaja.

Cuando el aviso dice que no coinciden, marca las tres ejecuciones y pulsa Review together. El panel Merge muestra "3 runs · conflicts not checked yet · 3 not yet tested", un "todavía no lo sabemos" honesto en lugar de una luz verde. Debajo, src/cart.js aparece marcado como contested y los hunks de cada rama se listan uno al lado del otro: tanto la corrección del redondeo como el código de descuento reescribieron total().

Luego pulsa test en cada ejecución. Los tests corren dentro del worktree de esa ejecución, así que su propio checkout no se toca nunca. Por defecto, "Tests must pass before a branch can merge", y esa regla se puede cambiar en Settings. Los tres pasan, pero pasar por separado no es lo mismo que pasar juntos, así que pulsa Preview combined merge. La app fusiona primero las ramas en una copia desechable y devuelve el resultado: dos se fusionan limpiamente y una tiene conflicto.

Fusiona las dos ramas limpias en su rama actual. Solo en ese momento cambia su rama. La rama del código de descuento se queda donde está, para que el agente rehaga su cambio sobre la corrección del redondeo. Si hubiera querido la mejor parte de cada intento en vez de ramas enteras, Combine into a branch le permite marcar hunks sueltos y crear una rama nueva con ellos.

Un detalle más que importa en los días largos: si la app se cierra mientras una ejecución está trabajando, la ejecución vuelve como Interrupted, no como "running", con la nota de que su rama se conserva.

Caso de uso: un desarrollador en solitario refactorizando con un asistente

Kenji mantiene él solo el front end de una tienda. Esta mañana tiene que cambiar formatPrice y no está seguro de quién la llama. Abre la carpeta del proyecto en el IDE desde la barra lateral. La disposición del editor es la de siempre: Explorer y Source Control a la izquierda, pestañas en el centro, Terminal, Output, Problems y Tests abajo, y el Assistant a la derecha, donde puede iniciar un chat sincronizado o un chat local que se queda en el dispositivo.

Hace clic derecho en formatPrice y elige Show Code Graph. El panel lista Callers y Calls. Un punto relleno significa que la llamada se leyó del propio código; un punto hueco significa que se infirió, así que esa merece una revisión manual. Impact of change sigue a los llamadores de los llamadores y, en este ejemplo, muestra "15 symbols · 14 files · 3 tests". Al hacer clic en una fila salta a esa línea, y Send to chat le pasa el grafo entero al asistente como contexto.

Más tarde, el asistente le edita un archivo de configuración. En Source Control el archivo aparece como modificado y, al abrirlo, una pequeña marca de robot y la barra de estado indican que lo escribió por última vez la IA, con el modelo y el motivo que dio. Review abre un diff lado a lado contra la copia guardada justo antes de esa escritura, así que ve solo ese cambio. Aquí muestra un timeout recortado de 30 segundos a 3, justo debajo de un comentario que dice que las subidas grandes tardan 20 segundos o más. Lo detecta antes de hacer commit.

Si un agente escribe en un archivo mientras él todavía tiene cambios sin guardar, el editor avisa de que el archivo cambió en disco mientras lo editaba y ofrece Keep mine o Use the disk version, en lugar de elegir uno en silencio.

Caso de uso: una ingeniera de soporte que necesita entender el código, no cambiarlo

Priya trabaja en atención al cliente y a menudo le preguntan cómo se comporta una parte del producto. Sabe leer código, pero no quiere ponerse a hacer grep en un repositorio que no es suyo. En Wiki usa Open a folder (o Clone a public repository con una URL https o git@), y la app lee la estructura del proyecto en su máquina.

Antes de escribir nada dentro del proyecto, Wiki pregunta. Un diálogo nombra la carpeta exacta que va a crear dentro del repo y, si pulsa Not now, no se escribe nada. Cuando acepta, usa Generate pages o Write a page para un tema concreto. Los ajustes deciden a partir de cuánto código fuente se escribe cada página (Depth: Quick, Standard o Deep) y cuántas afirmaciones se comprueban (Verification: Off, Sample o Full, donde Full duplica aproximadamente el coste). El coste se muestra antes de generar una página.

Cada página cita path:line, y al hacer clic en una cita se abre esa línea en el IDE. Un mes después, una página de la columna aparece marcada porque "a file this page cites has changed since it was written", lo que le indica que debe regenerarla antes de fiarse de ella. Para una pregunta rápida y puntual usa el chat junto a las páginas, cuyas respuestas también citan path:line de ese proyecto, y donde además puede pedir una página nueva con palabras normales, como "write a page about the retry policy". Las páginas en sí son archivos markdown dentro del repositorio, así que el equipo puede revisarlas en los mismos pull requests que el código.

Dónde se pasan el trabajo Code, el IDE y Wiki

Estas tres pantallas se pasan trabajo entre sí y con el resto de la app. Una cita de Wiki abre el IDE en la línea citada, y el IDE tiene un botón Wiki for this folder para el camino inverso. El Assistant del IDE y el chat junto a las páginas de Wiki están construidos sobre Maestro, el mismo asistente que usas en el resto de osFoundry, así que preguntar ahí funciona igual que en cualquier chat de Maestro. Para buscar en un código por significado y no por palabras exactas, Indexes crea un índice de búsqueda local que Maestro puede usar. Y cuando una ejecución de Code está lista para salir de tu portátil, Open PR abre un pull request para su rama.

Las páginas del producto muestran demos interactivas de cada uno: Code y el IDE.

Lo primero que pregunta la gente

¿Necesito la app de escritorio?
Sí. Code, el IDE y Wiki trabajan con carpetas locales, worktrees de Git, una shell y servidores de lenguaje, así que funcionan en la app de escritorio de osFoundry.

¿Un agente puede fusionar en mi rama por su cuenta?
No. Las ejecuciones trabajan en sus propias ramas y en sus propias carpetas. Tu rama actual solo cambia cuando pulsas merge y, por defecto, solo para ramas cuyos tests pasaron.

¿Wiki es una wiki de equipo como Notion?
No. Escribe documentación a partir de un repositorio de código, citando archivo y línea, y marca las páginas cuando ese código cambia. Está pensada para documentación del código, como una visión general de la arquitectura o notas de onboarding.

¿Qué pasa con una rama que tiene conflicto?
Se queda donde está. Puedes fusionar ya las ramas limpias y dejar que el agente rehaga la conflictiva encima de ellas, o elegir hunks sueltos con Combine into a branch.

La app de escritorio se descarga gratis en osfoundry.io/es/download.