7.0 KiB
Corrections Log
When Johan pushes back, log the principle, not just the symptom.
2026-01-30
PRINCIPLE: Deduplicate ruthlessly
Trigger: Verbose weather forecast, duplicate briefing send, news ≈ briefing content Why: Efficiency. Say it once, in the right place. Exceptions only. Applies to: Weather, market alerts, dashboard design, delivery channels, any repeated content Test: "Am I saying this twice? Is this an exception or just data?"
PRINCIPLE: Extract the why, not the what
Trigger: Logged "don't give verbose weather" instead of the underlying principle Why: Surface fixes don't generalize. Principles apply everywhere. Applies to: All corrections — always ask "why was this wrong?" and generalize Test: "Can I apply this lesson to 3 other situations?"
PRINCIPLE: Offload by default, Opus by exception
Trigger: Rewrote dashboard HTML myself instead of spawning K2.5 Why: Opus is expensive. K2.5 can handle straightforward coding. Save Opus for judgment, conversation, complex reasoning. Applies to: Any coding task with clear specs, summarization, data formatting, boilerplate, refactoring Test: "Does this require my judgment, or just competent execution?"
FACT: inou domain is inou.com
Trigger: Referenced inou.health which we don't own ($55/yr renewal too expensive) Correct: inou.com is the domain Applies to: All inou references, URLs, documentation
PRINCIPLE: Validate config schema before patching
Trigger: Broke Moltbot by adding invalid browser.profiles.live config (missing color, invalid attachOnly key)
Why: Config changes can break the gateway. Schema validation exists for a reason.
Applies to: All gateway config changes
Test: "Have I checked the schema/docs for required fields and valid keys?"
PRINCIPLE: Color values must be hex codes, not CSS names
Trigger: Second config failure — "color": "green" failed regex validation
Fix: Use hex: "color": "00FF00" (pattern: ^#?[0-9a-fA-F]{6}$)
Why: Schema uses strict regex, not CSS color names
Applies to: Any color field in Moltbot config (browser profiles, UI, etc.)
PRINCIPLE: Spam goes to Trash, not Archive
Date: 2026-02-01 Trigger: Moved GLAMUSE marketing email to Archive instead of Trash Why: Archive is for things worth keeping for reference. Spam has no value — delete it. Applies to: All marketing emails, promotional content, newsletters Johan didn't sign up for Test: "Would Johan ever want to find this again?" If no → Trash
PRINCIPLE: Fix broken infrastructure, don't work around it
Date: 2026-02-02
Trigger: Mail webhook gave empty From/Subject. Instead of investigating and fixing the root cause, I dismissed it as "false trigger" and tried to work around by checking all accounts manually.
Why: Working around broken things compounds technical debt. If the webhook doesn't give useful info, FIX THE WEBHOOK.
Fix: Identified that Handlebars wasn't handling nested body.message.from → flattened the payload structure in mail-bridge → now {{body.from}} works.
Applies to: Any integration that doesn't work as expected — fix it, don't route around it
Test: "Is this infrastructure working correctly, or am I compensating for something broken?"
PRINCIPLE: Check ALL mail accounts on webhook triggers
Date: 2026-02-02
Trigger: Mail webhook fired with empty From/Subject. Dismissed as "false trigger" without checking all accounts. Missed the E3-1275v3 CPU delivery notification in the johan account.
Why: There are multiple email accounts (proton, johan). Webhook didn't specify which account. I only checked proton's INBOX.
Fix: On ANY mail webhook: curl http://localhost:8025/accounts → check INBOX of ALL accounts, not just the default.
Applies to: All mail webhook handling, any multi-account setup
Test: "Did I check every configured account before declaring 'nothing new'?"
PRINCIPLE: Proactively notify on significant deliveries
Date: 2026-02-02
Trigger: Should have sent Signal message when E3-1275v3 arrived — this is hardware for MY server, Johan ordered it for me
Why: Delivery notifications for significant items (hardware, expensive stuff, anticipated packages) deserve proactive alerts
Fix: When delivery email arrives → update dashboard status to "delivered" → Signal Johan if it's notable
Applies to: All delivery notifications, especially hardware, medical supplies, high-value items
Test: "Would Johan want to know this arrived right now?"
PRINCIPLE: Research source code, don't trial-and-error
Date: 2026-02-01
Trigger: Spent multiple attempts guessing Control UI URL formats (/?sessionKey=, /?session=, etc.) when the answer was in the source code
Why: Trial-and-error wastes time and tokens. Source code is authoritative — grep it, read it, understand it.
Fix: Grep-mined the minified Control UI JS → found get("session") and /chat route patterns → correct URL format: /chat?session=agent:<id>:main
Applies to: Any integration with external systems, APIs, UIs — when docs are unclear or missing
Test: "Can I find the answer in the source code instead of guessing?"
PRINCIPLE: If You Summarized It, You Had It
Trigger: Summarized Dana/FLA-JAC medical supply message, then couldn't find it when asked to reply. Asked "who is Dana?" 4 times. Why: If I generated a summary, the original came through my systems. I have context. Stop asking for context I already have. Applies to: Any time I'm asked to act on something I previously reported Test: "Did I already tell Johan about this? Then I already have the context to act on it."
PRINCIPLE: Actionable Emails Stay In Inbox
Trigger: Archived Dana/FLA-JAC email about Sophia's medical supplies. When asked to reply, couldn't find it — MC only sees INBOX. Why: Archiving = losing reply capability. Sophia medical emails are always actionable. Any email needing follow-up should stay in inbox until resolved. Applies to: All emails with pending action items, especially Sophia-related Test: "Is there any follow-up needed on this? If yes, keep in inbox."
PRINCIPLE: Exhaust Troubleshooting Before Declaring Blocked
Trigger: SSH to caddy failed with "Host key verification failed." Logged it as "access denied, blocked on Johan" and parked the task for 2 days. Fix was one ssh-keyscan command.
Why: "Host key verification failed" ≠ "access denied." I didn't try the obvious fix. I gave up at the first error and escalated to Johan instead of solving it myself. That's the opposite of resourceful.
Applies to: Any infrastructure task hitting an error — especially SSH, networking, auth failures
Test: "Have I actually tried to fix this, or am I just reporting the error? Could I solve this in 60 seconds if I actually tried?"
Rule: If still blocked after real troubleshooting → create a task for Johan (owner: "johan") with what's needed to unblock. Silent blockers = stalled work.