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

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

What happens electron/package.json:40-41 declares "mac": { "target": ["dmg"], "icon": "icons/icon.icns" }, "win": { "target": ["nsis"], "icon": "icons/icon.ico" } Neither target has ever been exercised by CI or, as far as the history shows, by anyone. A recent audit of an NSIS install on Windows 11 found roughly a dozen breakages, every one of them a first-ten-minutes failure and every one of them the kind CI catches trivially: an env var split on the wrong character, a path prefix test with a hardcoded /, a shell that does not exist. The cost of not having this job is not the bugs. It is that they accumulated invisibly across five releases and were found by a person installing the app, which is the most expensive possible detector. Expected A windows-latest job that boots the sidecar and asserts: 200 on /stats, /projects, /git/repos?all=1 a /terminal/pty socket that yields either a ready frame or a clean disabled frame, never fatal That last assertion is the interesting one: it enco

The gap An agent adds a dependency, pastes a key into a config file, pipes a script into a shell, or loosens a rule in a .tf. Today agentglass shows all of it faithfully and says nothing about any of it. The diff viewer renders the edit, the terminal shows the command, the fleet board counts the tokens. Whether the change was safe is left entirely to whoever is reading. The usual answer is a scanner over the repo. That is a solved, crowded problem — Dependabot, CodeQL, Trivy, Semgrep, osv-scanner and gitleaks all do it for free, and GitHub runs several of them on a push without being asked. Rebuilding any of that here would be a worse copy of something the repo already has. What none of them can do is the thing this app is uniquely placed for: look at a change before it exists. The gate already holds a PreToolUse call with its full tool_input until a human decides. That is a vantage point no repo scanner has, because by the time a scanner sees a commit, the decision was made hours ag

A worktree per agent isolates the code. It does nothing for everything that lives outside the tree and is still shared: one dev database, one port range, one node_modules if it's symlinked, one cache, one .env. Two agents can each get their own branch, both finish green, and still have quietly stepped on the same runtime. The failure that makes this real: two agents race a migration. The second clobbers the first's schema change. Both sessions look healthy, both diffs are clean — because the collision isn't in the code, it's in the shared database. Nothing in a per-session diff can surface it, and by the time you notice, the schema (or the db, or the cache) is already wrong. This is a whole class of problem that the who-touched-what work in #117 cannot catch: #117 makes the in-tree code changes trustworthy per worktree; this is about the out-of-tree state a code diff is blind to by construction. Why the diff can't see it The collision is a side effect on state that no working tree co