SirAllap/agentglass

The one thing missing Web Push is wired end to end: the encryption is pinned byte-for-byte against http_ece (the library web-push uses), the store, the routes, the call from deliver(), the service worker, the settings switch, the device list, and tapping a notification to land on the queue. All of it is covered by tests and by a browser drive against a real server. Exactly one link in that chain has never run: PushManager.subscribe against a real push service. That needs a device and a route to Google's, Mozilla's or Apple's service, which no container and no CI job has. Everything either side of it is proven; this is the join in the middle. Until someone does it, "push works" is an inference rather than an observation. What this issue asks for Turn it on and use it. Concretely: Subscribe. Settings → Push to this phone → Turn on. Grant the permission. The row should end on "Alerts reach this phone with the screen off" with a Test button next to it. Test. Press it. A notification s

What problem would this solve? The cockpit knows what a session has spent, how long its tools take, what has errored, and what is blocked. The agent producing all of that knows none of it. It cannot answer "how much have I burned on this task" or "is anything of mine waiting on a human", so it cannot moderate its own behaviour. Proposed solution Expose a read-only MCP server over the existing HTTP surface: session status and lifecycle, spend and token breakdown for a session or project, tool latency percentiles, recent errors, and pending gates. Read-only to start. Writes and control can come later, if ever. One design rule matters more than the tool list: every response has a size ceiling, and when a result would exceed it, return a smaller well-formed response with a field naming what was dropped, so the model can narrow the next call. Truncating a payload in the middle burns context and teaches the model nothing. Alternatives considered The REST endpoints exist, but an agent has no

What problem would this solve? The diff panel shows exactly what the fleet changed, and the chat panel can talk to an agent, but the path between them is me retyping. I see a bad line, switch panels, describe where it was and what's wrong, and hope the agent finds it. The cockpit already knows the file, the line and the code. Proposed solution Let a diff line take a comment, the way a pull request review does. Comments accumulate into a pending review with an editable intro and outro, and one action sends the whole thing to the agent as a single structured prompt rather than a stream of messages. The detail that makes it survive contact with a working agent: capture the code snippet at the moment the comment is written. When the agent edits the file and the anchor moves, show the comment as stale, and still send the captured snippet. A review that silently loses its anchor is worse than no review. Alternatives considered Copying the hunk by hand into chat. It works, it is slow, and the

What problem would this solve? Prompt caches expire. When a turn resumes after the window has passed, the whole prefix is re-encoded at the write rate instead of read at the cheap one, and the difference is real money that never appears as a line item. It looks like ordinary spend. As someone watching a fleet I can see that a session cost a lot, but not that part of it was paid twice for the same context. Proposed solution A cost insight that detects and prices avoidable re-encodes. We already ingest cache_creation_tokens, cache_read_tokens, a timestamp per turn, and whether the turn belongs to a subagent. Partition a session's turns by a lineage proxy (model plus main/subagent), then flag a large cache_creation that lands after a gap longer than the cache window on a lineage that previously had an established prefix. The penalty is exactly cache_write - cache_read per token, which pricing.ts already knows. Surface it as a first-class insight next to the existing spend and burn kinds:

Split out of #98 (closed by #140). That issue laid out three steps for Windows; step 2 (fail honestly when the terminal can't run) shipped in #140. This is step 1, which is independent and still unproven. The one thing missing Nobody has actually run the Windows build. electron-builder produces an nsis installer (the win target in electron/package.json) and the Bun server sidecar compiles for Windows, so a build exists — but "it builds" is not "it works". We don't know what a user sees after they install it. What this issue asks for Anyone with a Windows machine: build, install, open, and report what you see. That's the whole task. Concretely: Does the installer run and the app launch? Or does it break before a window ever appears? Does the Bun server sidecar come up? (It backs everything — chat, git panels, projects.) Do the non-terminal panels work? Projects, git/diff, chat, gates. Does the terminal now fail gracefully (greyed buttons + the "not available on Windows yet" notice