🤓 Latest Submissions
Rite: Authorization Proof
Authorization bugs often hide outside the path ordinary tests exercise. A customer endpoint may enforce ownership while a support endpoint reaches the same sensitive effect without the same check. Reviewers can inspect one function, see a guard, and still miss the bypass. Rite makes that review workflow explicit. A developer writes the authorization rule, names the entry paths and sensitive sink, and provides a small adapter that exposes observable effects. Rite runs the same literal cases through every mapped entry and records whether the expected result, sink calls, events, and state changes match. It does not treat a crash or an unexecuted branch as security evidence. The included refund sample demonstrates the complete loop. The vulnerable baseline records an unauthorized refund through `supportRefund`. Both entry paths are then routed through a shared authorization gate and all ten mapped checks pass. Rite removes the ownership guard once, confirms both wrong-owner cases fail with the forbidden effect, restores the exact fixed source, and passes again. This bounded mutation shows that the checks detect the defect they claim to cover. IBM Bob IDE was used as the development workflow for defining the policy and cases, tracing both paths, applying the shared repair, and structuring the four-phase proof. The repository preserves that process as a reusable Bob skill at `.bob/skills/rite/SKILL.md`. Rite also exposes the same verifier through a CLI and an MCP server, while the read-only GitHub App reads workflow artifacts and rejects a report whose commit SHA does not match the selected run. Rite is a working prototype with deliberately bounded claims. The public demo uses synthetic in-memory data and checks two named paths. It does not infer that unmapped paths are safe, does not move money, and does not claim exhaustive analysis of arbitrary repositories.
27 Sep 2026
Overcode: a calm signal for your workspace
A working developer maintains more than one repository, watches more than one pull request, and switches between branches, worktrees, and stashes during a normal day. The state is scattered: GitHub, GitLab, the local working tree, the watcher logs, the stash list. There is no single place to answer "what changed, and what needs my attention now." Overcode is a native desktop application that consolidates local Git state, GitHub, and GitLab into one operator workspace, and applies IBM watsonx.ai Granite to translate that state into actionable answers. Repositories are read directly from disk through simple-git in an isolated Electron utility process. Remote provider data is pulled per-account through user-scoped OAuth and cached locally. The data plane is local; there is no Overcode backend. Eleven AI features routed through a single callGranite entry point cover impact analysis on uncommitted diffs, conventional-commit drafting, repository onboarding briefs, plain-language stash labels, worktree vs base-branch comparison, code explanation at any reference, issue triage, daily standup rollups, and three pull-request reviews (full summary, hunk-level inline feedback, per-file deep dive). Each response is validated against a feature-specific JSON schema with one repair retry, then a local-data fallback so a parse error never reaches the panel. IBM Bob built the application. Every meaningful task, from IPC scaffolding and the activity feed to the AI panel, the GitHub and GitLab clients, the commit graph, and the eleven feature implementations, was produced in Bob IDE through the Plan to Code workflow. The bob_sessions folder in the repository contains the verbatim Bob task-history exports. Bob is the build-time partner. watsonx.ai Granite is the runtime intelligence inside the shipped app. The split is intentional and is the core of the submission story.
17 May 2026
