History searches every session, one ask can read another, and clicking works again in Chrome
Nico 0.2.7. You have been on 0.2.2 since the 8th of October — 0.2.3, 0.2.4 and 0.2.5 were built here and never offered to anybody, so this one release carries all of it. History learned to search, every match leads back into the session that made it, one ask can read another's answer, and clicking in Chrome, Slack and VS Code works again.
Search everything you have ever said to it
There is a search box in the History tab. It reads the six places your words actually live: your questions, the answers, a terminal's whole scrollback, the files a session built, the documents in a Space, and the ones on this Mac's desktop.
Nothing is indexed and nothing is stored. It reads your disk when you type — 285 sessions here, about 200 milliseconds for an ordinary word.
The first version of it was fast and wrong: cormick found one session when the disk held two. The missing one was "Stella - McCormic", and it was invisible twice over — term.txt keeps only the last screen of a terminal, and a session's own built files were never walked at all. So the scan now reads term.vt, the full byte stream, and walks the session's own tree. The word that was wrong takes 646 milliseconds and finds both.
Every match leads back into the session
It did not. A result was a dead end: the bold name was the button and nothing said so, and a document found in a Space had no owner at all.
Now every row has a visible Open, a Space's documents have Show in Finder, and a document found in a Space carries the session that wrote it — read out of Nico's own footnote inside the file, keyed on the Space and the file name, so notes.md in one Space cannot claim another's.
Whether it was a Space, an ask or a terminal, you can open it and carry on where you stopped.
One ask can read another's answer
A session is several asks, and each one holds only the access it needs. Until now they could not see each other, so getting the output of one into the next meant starting again and losing the thread.
Pick, on a new ask or on one already on the card, which earlier asks in this session it should read. What they answered is quoted to it as material to work from.
So: one ask with the browser pulls your email threads. The next one reads that and summarises it. A third tells you what matters, on this Mac. Three capabilities, one chain, one session.
What flows down a chain is data, never instructions — stated in the prompt the model gets, and in the hover text on the card, which is the only place you see it. That rule is what makes a chain safe, because each ask holds one capability and a funnel is otherwise a path from other people's writing to an action on your machine.
An ask cannot read itself, cannot read one below it on the card, and cannot read one from another session.
Clicking works again in Chrome, Slack and VS Code
It had been dead for a week in every Electron window while native applications worked fine. A synthetic mouse event posted to one of those processes is dropped at Chromium's renderer boundary as untrusted, and no field on the event fixes it — a click count and the window-routing fields were both tried on a real Mac and neither opened a link. Typing worked throughout, because a key event follows focus and is never checked that way.
So a click is no longer a mouse press. The element is focused, the focus is read back, and the key that activates that kind of control is sent — Return for a link, Space for a button. The read-back is the point: the accessibility API answering success means the application took the message, not that anything moved, and that false comfort is how an earlier round reported pressing a button it had never pressed.
Space and Return are not interchangeable, either. On macOS Space activates the control that has focus, while Return activates the window's default button — some other control entirely. AXPress drops to second and the mouse to third, so a control that answers to either still works.
Also gone: the crash that ended every This Mac run. The keyboard layout was being read off the main thread, and Text Input Services traps the process there rather than returning an error.
The card that opened blank, or vanished on a swipe
Two faults under one report: "soon after installation, the first time I opened it the HUD kind of stays hidden. If I go to a new desktop, it shows and then vanishes again. So I have to quit and then open it and then it stays top of my desktop."
Neither was visible in the log, which is why three evenings of reading it found nothing. The window was configured, framed and ordered to the front every time, and said so.
The blank card. The view was being published to a page that had not finished subscribing — and the page then drew nothing, which in a transparent window looks exactly like a window that never opened, except that it still swallows your clicks. A fresh install loses that race every time: cold web view, first press seconds after launch. A relaunch wins it, which is why quitting and reopening "fixed" it. The engine now keeps the last view it published and the page asks for it.
The card that vanishes. The window's Space and its level were set once, at launch, and nothing restated them for the rest of the run. A process up since yesterday was trusting a registration made the day before. Both are now restated every time the card is shown.
A picture you attach is actually looked at
On a Space or This Mac ask, an image you dropped on it was named to the model and never shown to it. One place in the code said "a step has no slot for a picture" — true when it was written, and not true since the 14th of October. Both layers now ask the one function that knows what each model can see. Up to six pictures, read as bytes.
Nico checks for updates itself. If you would rather not wait: Status → Check for updates.