Keating 2.8 closes a gap between having workspace tools and knowing when to use them. When source access is live, the tutor is now told what it can inspect, where Keating's code lives, and that a question about its own behavior should begin with evidence. This release also separates whether reasoning is available from whether its disclosure starts open, so transparency no longer means surrendering control of the transcript.
The tutor knows when it can read its own implementation
Registering a tool schema was not enough. A model could technically discover workspace_inspect and still answer from memory, claim that it could not see the code, or ask the learner to paste a file that was already mounted. Keating now adds a runtime-derived workspace section to the system prompt whenever a real inspection adapter is connected.
The guidance is deliberately operational: inspect before guessing about a bug or runtime behavior, batch related reads, and do not deny access that exists in the current session. It sits outside the evolvable persona prompt, so restoring an older session or optimized teaching prompt cannot accidentally erase the live capability notice.
The instructions follow the tools that are actually connected
The workspace paragraph is assembled from the current runtime rather than hard-coded into every session. It advertises inspection whenever that operation is available, command execution only when the adapter can execute, and precise changes only when an editing path is connected. Offline sessions receive no fictional workspace promise.
Keating rebuilds the system prompt when the runtime finishes booting or changes, alongside the runtime-filtered tool set introduced in 2.7. The capability marker is replaced rather than appended repeatedly, which keeps long-lived and restored sessions accurate without accumulating duplicate instructions.
NodePod inspection now reaches the files it describes
In the browser sandbox, Keating's bundled source snapshot is mounted at /workspace. The prompt points the model toward the useful areas—/workspace/src/core, /workspace/pi/prompts, and /workspace/web/src/keating—and the composed inspection tool now normalizes relative paths into that mounted tree.
- Directory requests route to the NodePod
fs.listoperation, which is now implemented by the runtime. - Source reads route through
fs.readwith explicit UTF-8 decoding, so TypeScript arrives as readable text. - Diff requests use the sandbox's existing source-diff path instead of pretending the browser mount is a remote host filesystem.
The generated NodePod boot snapshot is refreshed with the same changes, so the code the model can inspect and the runtime executing those tools stay in sync.
Reasoning is available without opening itself
Reasoning remains visible by default as a disclosure inside assistant messages, but a streaming response no longer forces that disclosure open. The ordinary transcript therefore starts compact while preserving a clear Reasoning control for learners who want to inspect it.
A separate persisted setting, Open reasoning automatically, lets learners choose the opposite default. When enabled, each reasoning disclosure starts expanded; when disabled, it starts collapsed and can still be opened manually. Turning off Show reasoning hides the disclosure entirely and disables the dependent auto-open toggle, keeping visibility and initial expansion as two explicit choices.
Display is not reasoning effort
Neither interface toggle changes how much the selected model thinks. The separate Reasoning Level setting continues to control model effort; these settings control only what the transcript shows and whether it begins expanded.
The disclosure states are inspectable in Storybook
The canonical just storybook workshop now includes dedicated reasoning stories for all three behaviors: available and collapsed, opened by the learner, and initially expanded by preference. Interaction assertions exercise the native disclosure state and confirm that the reasoning body becomes visible when expected.
Release integrity
Focused settings and chat tests pin the new default and persistence rules. Workspace contract tests verify that NodePod listings, reads, and diffs reach the correct VFS operations, while capability tests pin the runtime-only prompt and its duplicate-removal behavior. The complete web suite, TypeScript check, production Vite and Nitro build, live Storybook index, version synchronization, and generated NodePod snapshot form the release gate.