Publishing a long development history leaves old feature descriptions in circulation. Embedded self-repair was an important browser experiment, but it differs from the current control model. I retain version and integration state so a reader does not mistake a historical success for a promise about a current button.
Historical success has a specifically verified scope
Earlier focused-repair records include a fragment proposal followed by host checks, installation and resumption of the original request. They also retain missing preparation artifacts, failed checks, final-answer budget exhaustion and insufficient reading evidence. One final success does not summarize a product that automatically resolves every defect.
A guidance-sentence change differs in difficulty from editor, video or reservation failures. Success on one route also cannot become current support for another. I retain what changed and what remained unverified. A version is an applicability condition for the feature description, not a decorative date attached to a story.
Distinguish removal from record compatibility
The version 0.1.148 record removes embedded CLI gateways, model connections, automatic model-repair runtime and associated input/model UI. Historical conversations/settings remain for compatibility and source moves into archive. Source remaining in a repository differs from the installed product executing that route.
The removal audit checks that retired CLI and model SDK are absent from ASAR and associated UI/IPC are not exposed. It does not mean a separate external Codex installation or login was removed. Product-internal execution and surrounding work tools need separate descriptions to explain what was preserved and what was retired.
Recheck the current entry points
Current bootstrap gives TaskController an internal next that throws INTERNAL_AGENT_REMOVED. The IPC registration loop skips retiredShellCommands. Readable historical schemas therefore are not advertised as executable current APIs.
Current external MCP calls and program execution have separate contracts. An external agent being able to investigate and edit code also differs from unrestricted automatic repair. Work remains bounded by the actual request, available tools and preservation conditions, followed by verification. Quietly restoring the former internal loop through another profile or model would not be a continuation of this account.
Retain screen checks that did not complete
The removal-stage record verifies installed MCP connectivity and Python/notebook/native-input checks, while a post-restart manuscript restoration click remains OUTCOME_UNKNOWN. It also records an additional screen check blocked by automatic review and the narrower read-only stored-data comparison. Matching stored values differs from completed live editor restoration.
That historical hold is not generalized into failure of every current restoration. Later versions may have separate verification, so request and version matter. I retain unverified results without freezing an old state as the entire current product. A technical journal needs reading rules that follow feature lifetime as well as implementation details.
Separate shared teaching material from the current feature list
The public structural-report, outcome-comparison and target modules are independent synthetic examples. They run no original repair model or installer. Extracting a principle into a small experiment differs from restoring an operational feature, and the module documentation retains that distinction.
This writing reviews current source and historical audit/development records without calling the original CLI or repair runtime. Readers can learn why a boundary existed and evaluate current capability through current integration evidence. Deeper disclosure should include architectural changes and retired features as precisely as successful history, so the accumulated journal remains useful rather than misleading.