ClaimScope
ClaimScope checks whether a GitHub bounty is actually worth a weekend. Funding, eligibility, and competition agents pull public issue data at once. A reviewer throws out a stale write-up when later evidence arrives.
What it does
Public bounty listings often confuse an advertised amount with available payment, and an open issue with an uncontested task. ClaimScope investigates a public GitHub bounty using three independent agents: funding evidence, eligibility and repository status, and related pull requests. A fourth reviewer reacts to partial evidence while the others work, discarding stale reviews when later findings change the shared evidence. The recorded run inspects a real $80 documentation bounty, finds three related open pull requests and keeps funding unverified. Typed facts determine the assessment; model commentary remains advisory. The deployed interactive replay lets judges play, pause and seek through the actual execution trace without installing anything. Evidence appears only at its recorded arrival time, and the final verdict appears only after the current revision is reviewed. This is a replay of a real run, not a live hosted audit. Built during the hackathon with Codex assistance. Runtime inference used local Qwen3, with no paid API. Seven tests and TypeScript typecheck pass. The original video, structured trace and recorded report remain available.
How the agents run concurrently
All four participants use @mozaik-ai/core 4.0.5. A semantic start event fans out to three independent situation processors. Each publishes evidence and starts its own runLoop. The reviewer starts on the first evidence event without waiting for the other source lanes. Shared RuntimeState carries the evidence map and an increasing revision. When a review returns, its input revision is compared with current state; stale answers are discarded and the reviewer starts again. The real 38.248-second run records three overlapping collectors, four overlapping model requests and five model calls. The revision-1 review was discarded at 35.066 seconds; a revision-3 review was accepted at 38.248 seconds. Overlapping requests do not imply parallel token generation inside the local model server. A barrier-based test would deadlock if collectors ran sequentially, and another test ensures a stale answer cannot become the final assessment. The browser replay and raw trace expose the actual timing and revision changes.
