Day 57: A UI That Stops Lying
One day before release. The kind of day where the temptation is to add one last thing, and the correct move is to take things away instead. Two cuts today, both in the same spirit: stop telling users something is configurable when it isn't, and stop telling an agent something it can already look up.
Permission Checkboxes That Did Nothing
The agent permissions page had two entries nobody should have been looking at: docs_list and docs_read. They belong to the pinchy-docs plugin — the one Smithers uses to search the platform documentation on demand. Their availability is gated by the plugin's own isPersonal check, not by an agent's allowedTools. On a normal business agent, toggling the checkbox was a no-op. On Smithers — the personal assistant every user gets — the checkbox was redundant with the plugin itself being active.
So the UI was offering admins two levers that weren't actually connected to anything. That's worse than missing a feature. An admin who toggled those boxes on, saved the agent, and then tested it would draw the wrong conclusion about why the tools didn't appear. The fix was to delete the entries from the tool registry, drop them from the seeded agent configs, and let the plugin-level gate be the only mechanism. Nothing changed about what any agent can actually do. The UI just stopped pretending otherwise.
This is the boring half of shipping a permission model: every toggle has to mean something, or none of them mean anything.
Smithers Was Quoting Himself
The second cut was in Smithers's own configuration — the SOUL.md file that defines his personality, procedure, and behavior. Over the last few months, seven sections had crept in: Audit Trail, Settings & Restarts, Domain & HTTPS, Context, Usage & Costs, Enterprise Features, Common Tasks. Each one was a condensed summary of a doc page. Each one had started drifting the moment the underlying docs changed.
The whole point of Smithers's docs access is that he reads them at runtime. CLAUDE.md says so in one sentence: docs are the single source of truth for platform knowledge. Inlining feature summaries into his soul file contradicts that directly. It's also a slow-moving lie: by the time the summary is out of date, nobody remembers to update it, and Smithers confidently tells users about a dashboard that hasn't shipped yet or an option that was renamed last sprint.
Deleted all seven sections. Kept personality, the procedure he uses to look things up, and the onboarding behavior — which is runtime instruction, not feature documentation. Added a regression test that fails if any of those section headings come back.
Why the Regression Test Matters
It would be easy to skip the test. The whole point of deleting the sections is that they shouldn't exist. Adding a test feels like paranoia about my own future self.
Except: this is exactly the kind of thing that comes back. Someone asks "why doesn't Smithers know about the dashboard?" A well-meaning fix is to write a quick summary into his configuration. A week later the dashboard changes, the summary rots, and a user gets confidently wrong information. The test is a load-bearing "no." It documents a design decision in code rather than in a Git blame that nobody will read.
Day 57
Two deletions, zero features, one release left. The permission screen no longer offers toggles that don't do anything. Smithers no longer carries a frozen copy of documentation that updates itself thirty feet away. Less code to explain, less UI to misread, less future drift to clean up. A quiet day before a shipping day.