44 lines
8.6 KiB
Plaintext
44 lines
8.6 KiB
Plaintext
<!DOCTYPE html>
|
|
<html lang="en"><head>
|
|
<meta charset="UTF-8">
|
|
<title>Corrections</title>
|
|
<style>
|
|
@import url('https://styles.rokojori.com/get-font?family=Barlow&weights=100,400,700,900');
|
|
</style>
|
|
</head>
|
|
<body>
|
|
<page--header></page--header>
|
|
|
|
<page--root>
|
|
<full--width--block>
|
|
<full--width--area><h1>Corrections</h1><p>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 <a href="../../guides/agent-conduct/index.page">Agent Conduct</a> 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.</p></full--width--area>
|
|
</full--width--block>
|
|
|
|
<full--width--block>
|
|
<full--width--area><h2>2026-08-21</h2><h3>HTML/CSS conventions</h3><p>Across the rojo-editor UI work, the agent repeatedly wrote plain <code><button></code> elements, <code>rem</code> units, same-line opening braces, and defaulted to <code>display:flex</code> without being asked - none of which match how this project's owner actually wants HTML/CSS written. Corrected into <a href="../../guides/writing-html-css/index.page">Writing HTML/CSS</a> so it doesn't need repeating per-component.</p></full--width--area>
|
|
</full--width--block>
|
|
|
|
<full--width--block>
|
|
<full--width--area><h2>2026-08-21</h2><h3>Layer group visibility semantics</h3><p>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 <code>eyes-right</code>/<code>eyes-left</code>. The user corrected this: a group picks a <em>type name</em>, 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 <code>source/components/rojo-settings-panel/RojoAppearance.ts</code>.</p></full--width--area>
|
|
</full--width--block>
|
|
|
|
<full--width--block>
|
|
<full--width--area><h2>2026-08-28</h2><h3>Skipped existing asset/i18n conventions when building a "real app" component</h3><p>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 <code>.ts</code> template literal. Two real conventions already existed and were missed: a real logo asset (<code>source/rojos/roject.svg</code>, fetched/inlined/re-framed by <code>project-list-default.ts</code>'s <code>_buildLogoHtml()</code>, with a <code>.webp</code> fallback) and a real locale/i18n system (<code>source/locale-data/<lang>/*.txt</code>, <code>source/locales/LocaleManager.ts</code>, <code>source/server/localeGenerator.ts</code>). A keyword grep for "logo" missed the asset because the file is named <code>roject.svg</code>, not anything containing "logo" - the search should have been "how does an existing similar component (e.g. <code>project-list-default</code>) 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.</p></full--width--area>
|
|
</full--width--block>
|
|
|
|
<full--width--block>
|
|
<full--width--area><h2>2026-09-02</h2><h3>"Harmonize Toolbar" never actually harmonized the toolbar container itself</h3><p>Across several sessions (this one included), each "Harmonize Toolbar" pass wired a panel onto <code>panel-button</code>/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 <code>display:flex; align-items:center; gap; background; border-bottom; flex-shrink:0;</code> block, hand-copied with small unintentional drift (gap 4/6/8px, <code>flex-wrap</code> 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 <code>toolbar-modes.css</code> 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 <a href="../../reference/toolbar-modes/index.page">reference/toolbar-modes</a>. 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."</p></full--width--area>
|
|
</full--width--block>
|
|
<full--width--block>
|
|
<full--width--area><h2>2026-09-17</h2><h3>Activated a pre-existing non-compliant file without bringing it up to convention first</h3><p>Wiring the "Update Roject Index" task's landing-page header, the agent included <code>app-nav.ts</code>/<code>app-nav.css</code> as-is - a component that already existed in the repo but had never actually been used on any page. It still used <code><span class="nav-brand"></code>/<code><div class="nav-links"></code>/<code><div class="nav-user"></code> instead of custom elements, and same-line opening braces - both already corrected into <a href="../../guides/writing-html-css/index.page">Writing HTML/CSS</a> 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 <a href="../../reference/architecture/index.page">Architecture</a>'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 <code>button</code>/<code>.btn-delete</code> 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.</p></full--width--area>
|
|
</full--width--block>
|
|
|
|
<full--width--block>
|
|
<full--width--area><h2>2026-09-21</h2><h3>Wrote new TypeScript without reading the "Writing TypeScript Code" guide</h3><p>Across the Rojo Chat fill-state/action-selector work, the agent wrote several new methods in <code>rojo-chat-panel.ts</code> and all of <code>RojoChatCounter.ts</code> using unbraced single-statement conditionals (<code>if ( !text ) return 0;</code>, <code>if ( x ) return y;</code> chains in URL-builder methods, unbraced <code>for</code> loop bodies) - directly against <a href="../../guides/writing-typescript-code/index.page">Writing TypeScript Code</a>'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 (<code>writing-backend-routes</code>, and the panel-scaffold example in <code>writing-editor-panels</code>) explicitly show the compact single-line <code>if ( !id ) { ...; return; }</code>/<code>if ( this._initialized ) return;</code> 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 <code>guides/writing-typescript-code</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 <code>writing-backend-routes</code>/<code>writing-editor-panels</code> already get checked for routes/panels.</p></full--width--area>
|
|
</full--width--block>
|
|
</page--root>
|
|
|
|
<page--footer></page--footer>
|
|
|
|
</body></html>
|