When Persistence Becomes a State Machine
The Pi/OMP implementation of i-have-adhd has to preserve more than a piece of text. It must keep a user’s choice, the visible status of that choice, and the rules actually present in the model’s context aligned across commands, reloads, and compaction. This chapter traces that state machine and explains why tolerant context inspection is safer than assuming one host API will remain unchanged.
Three states that must agree
A simple on/off switch suggests one state: the mode is either enabled or disabled. The extension has a more difficult problem because three facts can diverge.
The first fact is the user’s choice. The extension records enable or disable decisions in a custom session entry. It can also derive an initial default from an explicit startup flag, a configuration setting, or an always-on flag file. A saved choice takes precedence over the default. That means a session can be configured to start in the mode by default while a user’s explicit decision for the current session turns it off.
The second fact is what the interface displays. When the mode is enabled, the extension shows a status entry with a success dot and “ADHD ON,” unless the user has configured the status to be hidden. The status is useful because it makes an invisible instruction visible. It is not the source of truth for the model’s behavior: a status indicator can be present while the rules have been lost from context, or hidden while the rules remain active.
The third fact is what the model actually receives. The extension injects the rules as a custom message when it determines that they are not already in context. When the user turns the mode off, it adds a disabled notice that tells the model to ignore the earlier ruleset and return to its default style. The conversation history therefore contains markers that describe the current context state, while the session entry records the user’s choice.
Keeping these channels separate prevents a common persistence bug. If the extension stores only a Boolean, it may know that the reader wants the mode on but not know whether compaction removed the rules. If it inspects only the conversation, it may see an old active message after the user has turned the mode off. If it updates only the status bar, it can signal success without changing the model’s context. The adapter needs all three views to decide what action is safe.
The startup path illustrates the distinction. When a new Pi session begins, the extension restores the saved state or calculates a default from the startup flag, configuration, and always-on file. It then updates the status and synchronizes the context. If enabled and no active rules marker is present, it sends the rules once. If disabled and an active marker is still present, it sends a disabled notice.