v0.65.0

Minor Changes

• Your own skills are no longer hidden from git by OpenKnowledge's sharing setting. A project set to Only me was adding a .git/info/exclude entry for every skill OK had installed into an editor folder, so a skill you wrote could be missing from git status without anything saying why — and which skills were affected depended on what happened to be installed when you first set the project up. Whether your skills are committed is now yours to decide. OK's own files (.ok/, .okignore) and the editor config files it adds an entry to still follow the setting, so trying OK on a work repo still keeps its MCP entry out of the team's diff.

  If an older version left entries behind, they clear the next time OpenKnowledge applies your sharing setting. ok config-sharing unshare, or ok init on a project already set to Only me, clears them without changing anything else — you do not have to switch to Shared to get your skills back. Switching to Shared clears them too. Two cases need a manual check: if an OK file is already committed the run stops with a tracked-file warning before clearing anything, and entries for a skill you have since uninstalled cannot be cleared automatically, because the record naming them is gone. ok config-sharing status now lists leftover .claude/skills/… entries even when it can no longer match them to a skill, so run it to see whether any remain; clearing those means deleting the lines from .git/info/exclude yourself.

  Also removes the Share skills prompt above the Skills sidebar, which offered to un-hide .ok/skills — no longer where skills are kept, so for most projects the button changed nothing the message promised while the skills it named stayed hidden. The Settings → Sync & sharing row that undid it is gone with it. Removed from the published surface: readSkillsShared and setSkillsShared from @inkeep/open-knowledge, setSkillsShared from the desktop bridge, and the skillsShared field from ok config-sharing status --json. Added: getInstalledSkillProjectionPaths to @inkeep/open-knowledge. Scripts reading ok config-sharing status --json or share --json should note that excluded[] and removed[] can now contain skill-folder paths such as .claude/skills/<name>/, plus the two older **/.ok/* and !**/.ok/skills/ entries when a project carries them.

Patch Changes

• Document names are now replaced with a short fingerprint in the basic bug report. The app's diagnostics gained a record of scrolling and outline clicks, which is what makes a "the page jumped" report diagnosable at all, but each of those records named the document it happened in, and several routine log lines already did the same. That turned a report from an ordinary session into a readable list of the files you had open, sent under a notice that mentions logs and system info and says nothing about documents. The support team can still tell which records belong to the same document and follow what happened in it; they no longer receive the list of names. Detailed diagnostics, which you opt into separately and which does say it includes document names, is unchanged.

  To be straight about how strong this is: the fingerprint is not reversible in bulk, but it is not a secret either. Someone who already suspects a specific filename can check that guess against a fingerprint. It removes the list, not the possibility of confirming a name someone has reason to try.

• Bug reports about scrolling and about the outline panel now carry the numbers needed to diagnose them. Two related blind spots.

  The editor already measured a lot about restoring your scroll position when you return to a document, but those measurements only ever existed inside the running app and were never written down, so they went with the window when it closed and three separate scroll bugs were investigated without a single scroll measurement between them. Those measurements now also go to the app log a report collects, and each one identifies the document it belongs to along with how far down the document was scrolled, how tall it was, and how much of it was on screen — enough to tell "the editor scrolled past the end of the document" apart from "the content had not finished drawing yet", which previously took a purpose-built reproduction to establish.

  Clicking a heading in the outline panel recorded nothing at all. If it took you to the wrong section, or appeared to do nothing, a report could not say which row was clicked, which heading answered, or whether the editor scrolled. It now records all three, in both the visual and the source editor, including the case where something else was already controlling the scroll position and the click was correctly declined — which looks identical to a broken click from the outside. It also records where the clicked heading actually sits in the document, so an outline whose rows have drifted out of step with the page reports the size of the drift directly instead of presenting as an unreproducible complaint.

  Headings are user-written text and no report has ever included document prose, so none of this records the heading text itself — the positions alone answer the question.