[Bug]: bare /loopx renders the whole command-pack preview as a persistent widget — TUI truncates it and it covers the working indicator
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 2/5
- Tiempo estimado
- 1-3 horas
- Aptitud para principiantes
- 72/100
- Tipo de issue
- Error
- Claridad
- Bien especificado
- Estado de actividad
- Activo
- Stack tecnológico
- typescript
- Área
- developer-experience
Línea de trabajo
El widget se define en inspectLoopx() en loopx/pi_goal_mode/loopx-goal.ts, que llama a ctx.ui.setWidget("loopx", ...) con packet.message sin procesar recortado a 24 líneas. Lee docs/tui.md para setWidget y la ubicación, y luego reemplaza el texto sin procesar por un resumen de tres líneas construido a partir de goal_id, project_connection.connection_state y recommended_next_step.summary. Está terminado cuando un /loopx sin argumentos muestra un widget belowEditor breve, el texto completo sigue yendo a la entrada loopx-packet y el widget se limpia en session_shutdown.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Bare /loopx dumps the whole command-pack preview into a persistent widget — the TUI truncates it and it covers the working indicator
Affected version: Pi surface installed from release 20261010T034436Z (loopx/pi_goal_mode/loopx-goal.ts, installed as ~/.pi/agent/extensions/loopx/index.ts).
Host surface: pi
Impact: running bare /loopx (or /loopx status) paints a large block of raw packet text above the editor. The widget area can only render a few lines, so it ends mid-sentence with … (Widget truncated) and overlaps the working indicator, which looks like a rendering bug to the user. The same text is already persisted as a session entry, so the widget adds noise rather than information.
Code
// loopx/pi_goal_mode/loopx-goal.ts — inspectLoopx()
const display = typeof packet?.message === "string" ? packet.message : stdout
ctx.ui.setWidget("loopx", display.split("\n").slice(0, 24))
ctx.ui.notify("LoopX packet ready (widget above the editor).", "info")
pi.appendEntry("loopx-packet", { text: display })
packet.messageforbootstrap-command-packis the full multi-section preview (project / goal id / detected state / aRules:list with several long bullet lines) — dozens of lines, and individual lines are wider than a terminal.setWidgetis documented as "Persistent content near the editor" (docs/tui.md), i.e. a fixed-height area; slicing at 24 lines does not make the content fit, it just chops it.- The widget is never cleared: it stays through subsequent turns and only disappears at session end, so a stale packet preview keeps floating over the editor.
Reproduction
- Connect a project to a goal (registry + active state file present).
- Run bare
/loopx(status/inspect path). - Observe the truncated multi-line block above the editor and the working indicator behind it.
Suggested fix
- Render a compact status summary from the structured packet fields instead of the raw message, e.g.
goal_id,project_connection.connection_state,recommended_next_step.summary— three short lines with a width clamp. - Use
placement: "belowEditor"(orctx.ui.setStatus()for a single line) so it cannot cover the working indicator. - Keep the full text in the existing
loopx-packetsession entry (already done viaappendEntry). - Clear the widget with
setWidget("loopx", undefined)onsession_shutdownand when a goal start packet is rendered, so a stale preview cannot linger.
Local interim patch
I already patched the installed copy: the widget now renders three clamped lines (LoopX · <goal_id> / state: <connection_state> · <project basename> / next: <summary>) with placement: "belowEditor", the full packet still lands in the loopx-packet entry, and the widget is cleared on session_shutdown and on /loopx <goal>. Verification harness (same jiti loader Pi uses, mock pi API):
4) widget lines: 3 | placement: belowEditor | max width 96
"LoopX · dfc-ai-knowledge-goal"
"state: connected · dfc-ai-knowledge"
"next: Project is connected; show status, then generate the heartbeat prompt only if the user wa…"
- Lenguaje dominante
- Python
- Estrellas
- 6.2k
- Forks
- 596
- Merge medio
- 6 h 44 min
- PR fusionados (30 d)
- 915
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de loopx-project/loopx
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
loopx-project/loopx#6842 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
loopx-project/loopx#5688 · 2 comentarios ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 60/100
loopx-project/loopx#5632 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
loopx-project/loopx#5443 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
loopx-project/loopx#5026 ·
Los mantenedores suelen responder en 1 día
Todos los issues de loopx-project/loopx
Issues similares
-
Uninstall guide omits the CloudWatch log groups AWS CodeBuild creates for useCodeBuild pipelinesAbiertobug documentation
Dificultad 1/5 1-3 horas Aptitud para principiantes 88/100
awslabs/visual-asset-management-system#552 ·
Los mantenedores suelen responder en 1 día
-
netbox status: needs triage type: documentation
Dificultad 1/5 Menos de una hora Aptitud para principiantes 76/100
netbox-community/netbox#23460 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
awslabs/threat-composer#362 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
ansys/pyansys-common-mcp#213 ·
Los mantenedores suelen responder en 3 días