Problem
When a student runs tests from within the JupyterLite notebook editor, the results appear in a panel below the notebook — but the notebook cells themselves give no indication of which cells passed or failed. Students must context-switch between the results panel and their code cells to understand what needs fixing.
Proposed improvement
After tests complete, annotate notebook cells directly with feedback:
- Passing test cells — a subtle green left-border or check indicator
- Failing test cells — a red left-border; the first line of
shortResult shown as a small annotation below the cell (similar to how IDEs show inline errors)
- Error/timeout cells — amber/red indicator with the exception message
- Annotations should be ephemeral (cleared on the next run, not saved to the notebook)
Implementation approach
notebook.js already has access to the result outcomes after BrowserRunner.runAndSubmit() returns. JupyterLite's @jupyterlab/cells API exposes cell metadata and the DOM, but annotating cells from outside the kernel is non-trivial.
A simpler first step: scroll the notebook to the first failing cell after tests complete, and add a CSS class to that cell's DOM node. This requires mapping test names back to cell positions — feasible because test cells are identified by the # TEST: name comment in the first line.
Scope
Public/notebook.js — post-run callback after runAndSubmit() resolves- Possibly
Public/browser-runner.js — expose cell-level metadata in outcome
- JupyterLite cell API research required before implementation
Acceptance criteria
Notes
This is the most technically novel item in the student feedback roadmap. The cell-annotation approach depends on JupyterLite's DOM structure remaining stable. Consider a feature flag or progressive enhancement so it degrades gracefully if the JupyterLite API changes.
Problem
When a student runs tests from within the JupyterLite notebook editor, the results appear in a panel below the notebook — but the notebook cells themselves give no indication of which cells passed or failed. Students must context-switch between the results panel and their code cells to understand what needs fixing.
Proposed improvement
After tests complete, annotate notebook cells directly with feedback:
shortResultshown as a small annotation below the cell (similar to how IDEs show inline errors)Implementation approach
notebook.jsalready has access to the result outcomes afterBrowserRunner.runAndSubmit()returns. JupyterLite's@jupyterlab/cellsAPI exposes cell metadata and the DOM, but annotating cells from outside the kernel is non-trivial.A simpler first step: scroll the notebook to the first failing cell after tests complete, and add a CSS class to that cell's DOM node. This requires mapping test names back to cell positions — feasible because test cells are identified by the
# TEST: namecomment in the first line.Scope
Public/notebook.js— post-run callback afterrunAndSubmit()resolvesPublic/browser-runner.js— expose cell-level metadata in outcomeAcceptance criteria
Notes
This is the most technically novel item in the student feedback roadmap. The cell-annotation approach depends on JupyterLite's DOM structure remaining stable. Consider a feature flag or progressive enhancement so it degrades gracefully if the JupyterLite API changes.