A running log of moments where the user had to correct, redirect, or clarify something the agent (this Rojo) did or misread. Not a blame log - a calibration log. See Agent Conduct for the rule that keeps this updated, and read the most recent entries here before starting non-trivial work, since a pattern repeated twice belongs in a guide instead of staying a log entry.
Across the rojo-editor UI work, the agent repeatedly wrote plain <button> elements, rem units, same-line opening braces, and defaulted to display:flex without being asked - none of which match how this project's owner actually wants HTML/CSS written. Corrected into Writing HTML/CSS so it doesn't need repeating per-component.
The agent first modeled a "layer group" as picking one sibling layer to show and hiding the rest of the group entirely - which would have hidden one eye by default for eyes-right/eyes-left. The user corrected this: a group picks a type name, and every layer in the group shows whichever of its own children matches that name (or nothing, if it has none). Worth re-reading before touching rig/appearance logic again - see the rig-parsing algorithm in source/components/rojo-settings-panel/RojoAppearance.ts.
Asked to build the landing-hero component - explicitly told it would become the real Roject index page, not a throwaway mock - the agent still wrote the logo as plain styled text and hardcoded every copy string directly in the .ts template literal. Two real conventions already existed and were missed: a real logo asset (source/rojos/roject.svg, fetched/inlined/re-framed by project-list-default.ts's _buildLogoHtml(), with a .webp fallback) and a real locale/i18n system (source/locale-data/<lang>/*.txt, source/locales/LocaleManager.ts, source/server/localeGenerator.ts). A keyword grep for "logo" missed the asset because the file is named roject.svg, not anything containing "logo" - the search should have been "how does an existing similar component (e.g. project-list-default) source its logo and copy" rather than a literal string match. User called the session tainted and closed it. Before writing new UI copy or brand assets into a component meant for the real app, check how an existing sibling component sources the same kind of content first.
Across several sessions (this one included), each "Harmonize Toolbar" pass wired a panel onto panel-button/Toolbar Modes but left the toolbar container's own CSS as a fresh, separately-declared rule instead of extending one shared rule - four of five panels ended up with a functionally identical display:flex; align-items:center; gap; background; border-bottom; flex-shrink:0; block, hand-copied with small unintentional drift (gap 4/6/8px, flex-wrap present or missing with no reasoning behind which). This was the same root cause behind that session's row-height alignment bugs - fixing the height contract in toolbar-modes.css fixed height specifically, but the surrounding rule each panel still writes by hand can drift in every other respect. The user pointed out the pattern only after reviewing multiple sessions' worth of "harmonize" work side by side, not from a single session's diff. Documented as a known issue + planned refactor at reference/toolbar-modes. Lesson: when asked to harmonize/consolidate near-identical code across components, actually extract one shared rule - matching-but-separately-declared copies in each file is not harmonized, even if every individual copy looks clean and each session's own diff looks reasonable in isolation. Check for this by diffing the actual per-component rule blocks against each other, not just confirming each one individually "looks right."
Wiring the "Update Roject Index" task's landing-page header, the agent included app-nav.ts/app-nav.css as-is - a component that already existed in the repo but had never actually been used on any page. It still used <span class="nav-brand">/<div class="nav-links">/<div class="nav-user"> instead of custom elements, and same-line opening braces - both already corrected into Writing HTML/CSS on 2026-08-21. The agent had read that guide fresh this same session and still didn't apply it, reasoning (implicitly, never stated) that the file wasn't code it was writing new, just reusing. That's the gap: making a previously-dead file live for the first time is exactly the kind of touch Architecture's On-The-Go Refactoring section means - it should have been brought in line with current convention before being activated, not left as an exception because the diff was small. Also removed dead button/.btn-delete CSS rules in the same file that matched no markup the component ever rendered. Lesson: "I'm not touching this code" doesn't apply once you're the one making it load for the first time - check it against the guides at that point, same as code written from scratch.
Across the Rojo Chat fill-state/action-selector work, the agent wrote several new methods in rojo-chat-panel.ts and all of RojoChatCounter.ts using unbraced single-statement conditionals (if ( !text ) return 0;, if ( x ) return y; chains in URL-builder methods, unbraced for loop bodies) - directly against Writing TypeScript Code's explicit, no-exception rule: every conditional/loop body is a braced block with the opening brace on its own new line. The guide was never read this session before writing the code; the user caught it by name ("did you actually read the writing typescript guide?"). Worth noting for next time: two other guides (writing-backend-routes, and the panel-scaffold example in writing-editor-panels) explicitly show the compact single-line if ( !id ) { ...; return; }/if ( this._initialized ) return; style as their own documented convention for Express route guards and the panel-init boilerplate respectively - so "always brace on a new line" is the default for general class/application logic specifically, not a blanket rule across every guide, and the existing codebase itself is inconsistent about it outside those two carved-out areas. Lesson: for any task that involves writing new TypeScript (not just editing an existing line in-place), read guides/writing-typescript-code at the start - it wasn't in the first-layer read list already covered at session start, but should be treated as required reading the moment a task involves writing new code, the same way writing-backend-routes/writing-editor-panels already get checked for routes/panels.