Forem: manasightgg

80,000 Lines of Code in 51 Days

manasightgg — Sun, 29 Mar 2026 22:15:42 +0000

Four open-source workflow commands, the counterintuitive lesson behind them, and a question: what does your process look like?

Early on, I tried running multiple Claude agents in parallel. Hand them separate issues, let them all implement simultaneously, merge everything at the end. On paper, this should have been the optimal approach. AI writes code fast. More agents means more throughput. Simple math.

It made things worse.

Manasight is a desktop companion for MTG Arena, the free-to-play digital version of Magic: The Gathering. It's a Tauri app: Rust, TypeScript, Astro. One developer. The project and the game don't matter for this post — the development workflow does. The last post covered testing. This one covers building: how GitHub issues become merged pull requests without me writing the code.

The project now has roughly 80,000 lines of code across six repositories. 33,000 lines of production code, 47,000 lines of tests. 616 merged pull requests. Around 6,590 test cases. 51 days.

Why parallel agents made things worse

First, I couldn't keep track of what each agent was doing. Each agent needed small corrections, and those corrections compounded when agents were working from stale context. By the time one agent finished, others had already changed the code it was building on.

Second, merging was painful. Each agent had worked from a different snapshot of the codebase, so figuring out how the changes interacted was harder than reviewing them one at a time.

Claude writes code so fast that running agents in parallel barely improves total wall-clock time. The long pole isn't implementation. It's human review and QA. Sequential processing is slower on paper but faster in practice because the human can actually think.

The lesson: optimize for the human's reasoning capacity, not the AI's coding speed.

Four Claude Code commands, published as open source

I built four workflow commands around that lesson. They're the system behind those 616 merged PRs, and I've open-sourced them at manasight-claude-commands.

I don't know if these patterns generalize beyond one project. This is still evolving, and the best way to pressure-test it is to put it in front of other developers.

The rest of this post walks through the system. The thinking behind the commands is the part I hope is useful regardless of whether you ever use the commands themselves.

Here's how the four commands fit together:

/issue-to-pr          The atomic unit. One issue in, one reviewed PR out.
    |
    +-- /self-review  The review gate. 5 parallel agents score findings
    |                 by confidence, filtering false positives.
    |
/sequential-issues    Chains /issue-to-pr across multiple issues.
    |                 Each PR stacks on the previous branch.
    |
    +-- /merge-stack  Collapses the stack. Retargets all PRs to main,
                      rebases unique commits, squash-merges in order.

Specs before code

The commands don't work without a prerequisite: the work has to be well-specified before Claude touches it.

Every PR starts with a fully specified GitHub issue. Depending on the size of the change, the issue might be backed by a feature spec, an architecture decision record, and/or a research doc — but the specificity lives in the issue itself.

Before implementation, I prompt Claude to review the issue and tell me if it's ready to implement. This is the Implementer/Reviewer pattern applied outside of code: Claude flags ambiguity, missing acceptance criteria, or unstated assumptions before any code gets written. Under-specified work produces code I have to throw away.

During planning, I ask Claude to break work into the fewest issues possible while keeping each under 200 lines of code (the median PR lands at 243). Claude produces noticeably better work at this scope. Above it, I find myself reworking or throwing away PRs. Below it, I haven't. Small, stacked changes are also easier for the human to reason about — reviewing is still my job, and small diffs make that job possible.

Test code outweighs production code by 144%. My last post covered the QA philosophy behind that number.

`/issue-to-pr`

The atomic unit. One GitHub issue URL in, one reviewed PR out (source).

Five phases:

Research. A sub-agent explores the codebase to understand the relevant code paths. This runs in isolation so the search results don't consume the parent's context window.
Implementation. Write the code, write the tests, run the pre-commit checks defined in the project's CLAUDE.md.
PR creation. Branch, commit, push, open the pull request.
Self-review. A fresh-context agent examines the PR. This is the Implementer/Reviewer pattern built directly into the workflow. The review agent has no memory of the implementation decisions. It reads the diff cold, the same way a teammate would on a real pull request.
Iteration. If the review finds issues, the implementation agent fixes them and the reviewer runs again. Up to 10 rounds. Then it's ready for human review.

Most PRs take one to three review iterations. The common findings: missing edge case tests, inconsistent error handling, a function that could be simplified. The things a human reviewer catches too, except this runs automatically on every PR regardless of how tired I am or how late it is.

`/sequential-issues`

My preferred workflow for planned work (source). It chains /issue-to-pr across a list of issues using stacked branches: each PR targets the previous one's branch, so each diff shows only its own changes.

Two gates per issue, both mandatory:

Code review passes (iterative, using /self-review)
CI green (tests, linting, formatting all pass)

The human's work is front-loaded and back-loaded. Front-loaded: planning, writing specs, ordering the issues. Back-loaded: reviewing the PR stack, running QA. The middle is autonomous.

This is where the Implementer/Reviewer pattern scales. Every issue in the sequence gets independent fresh-context review. The fifth PR in a stack gets the same review rigor as the first, because each review agent starts from scratch. No fatigue, no "I already looked at this codebase today" shortcuts. That's something I can't match as a human reviewer at 11 PM on a Tuesday.

`/self-review` and `/merge-stack`

(self-review source | merge-stack source)

/self-review started as a fork of Anthropic's /code-review plugin. Five parallel agents examine the PR independently, each finding scored by confidence. Only findings above a threshold surface in the feedback. Without that filtering, too many false positives and you stop reading the comments.

Two things I changed. First, I lowered the confidence threshold from 80 to 75. Second, Anthropic's version won't re-review a PR it's already reviewed. Mine will. In the autonomous loop, /self-review runs after each round of fixes, and it occasionally catches something on the second or third pass that it missed the first time. Because no human is watching the middle of the loop, I'd rather surface more findings and re-review than skip checks and let bugs into the product.

/merge-stack collapses a stack of reviewed PRs into main. It retargets each PR, rebases the unique commits, and squash-merges in order. The bookkeeping that's tedious to do by hand but straightforward to automate.

Both are documented and open-sourced alongside the other two commands.

Your turn

A few weeks ago, frankfaustino found the Manasight parser repo, filed issues, and merged bug fixes. The first outside contributor. Thank you, keep them coming!

All four commands are at manasight/manasight-claude-commands with  markers showing what to adapt. If you've built something different, I'd love to hear about it. The companion repo has Discussions enabled for exactly this.

Optimize for the human. The AI will keep up.

I'm Tim. I'm building Manasight, a desktop companion for MTG Arena, solo with Rust and Tauri. Follow @manasightgg on Twitter and @manasight.gg on Bluesky for build-in-public updates.

Everyone Writes About AI Generating Code. Nobody Writes About AI Testing It.

manasightgg — Thu, 26 Mar 2026 04:22:47 +0000

I play Magic the Gathering (MTG) Arena while background agents file bug reports.

I expected AI-assisted development to help me write code faster. It did. The part I didn't expect was how much it changed testing and debugging.

Manasight is a desktop overlay for MTG Arena, the free-to-play digital version of Magic: The Gathering. It's a Tauri app with a Rust backend, TypeScript frontend, and a companion Astro website. I'm one developer. The project has roughly 70,000 lines of code across six repositories, with over 6,000 tests. Every line was written with Claude Code. Every line was tested with it too.

This post is about the testing side.

Claude Code, slash commands, and agents

If you haven't used Claude Code: it's an AI coding assistant that runs in your terminal. You give it access to your codebase, and it can read files, write code, run shell commands, and use tools, all within a conversation.

Two Claude Code features matter for this post.

Slash commands are reusable prompt scripts. I write a markdown file that describes a workflow: what files to read, what tools to use, what rules to follow, what the output should look like. Then I run it with /command-name. Think of them as executable runbooks. I have commands for debugging, triaging feedback, code review, and turning GitHub issues into pull requests.

Agents are Claude instances that run tasks in the background. The parent conversation spawns them with a specific job ("trace this code path and report what you find"), and they report back when done. You don't wait for them. You keep working.

QA as a solo developer

The standard solo-dev testing experience: write code, switch to testing mode, find bugs, switch back to fix them, test again. Every context switch costs time and focus.

With a game overlay, it's worse. You can't play your own game and debug the overlay simultaneously. You can't run a 41-test-case platform validation protocol yourself across four operating systems. You can't triage user feedback submissions while writing the next feature.

A solo dev without AI either skips QA or stops shipping. I chose a third option.

Debugging while playing

/debug-game is a slash command I wrote for live QA sessions. I launch MTG Arena, start Manasight, and play a match. When something looks wrong: a card missing from the tracker, a lag spike, a panel in the wrong position. I describe it in the conversation or say "look at the latest screenshot." Claude already knows where my screenshot folder is, so there's no file paths or copy-pasting.

No code changes happen during the QA session. Claude launches background agents to investigate: one traces the code path from the game event through the parser to the overlay, another checks the Manasight application log for errors, another reads the Arena Player.log to see what the game client actually reported. Each agent works independently while the parent conversation stays responsive. I keep playing, keep finding things, keep reporting.

At the end of the session, I have a tracker table. Each finding has a type (bug, performance issue, feature request), the repo it belongs to, a description, and an estimated fix size. Each row is ready to file as a GitHub issue.

This is where Agent Teams clicked. Claude Code has a Task mode where you kick off background agents and wait for results -- fine for implementation work. Agent Teams are different: multiple background agents run while the parent conversation stays fully interactive. I keep talking, keep reporting findings, and the investigations happen in parallel without blocking me. QA requires that live back-and-forth. I'm playing, spotting issues, describing them in real time. The parent conversation coordinates while team agents root-cause in parallel.

Feedback pipeline

The /debug-game sessions taught me something: Claude is fast at diagnosing problems when it has logs. The Manasight application log, the Arena Player.log, a description of what happened. That's usually enough. The bottleneck isn't diagnosis. It's getting the right files in front of the right context.

So I built a "Send Feedback" button right into Manasight's UI. Players describe what happened, and the submission automatically uploads the Manasight application log and their Arena Player.log to a backend storage bucket for future debugging.

The macOS crash

What happened next? An early Mac beta-tester reported that the app closed immediately when they clicked Send Feedback. The irony: the crash was in the feature designed to collect diagnostic data, so the automatic log collection couldn't help.

I asked them to send three files manually: the Arena Player.log, the Manasight application log, and the IPS crash report that macOS generates for unexpected app exits. Even before the files arrived, Claude had inspected the Send Feedback code path and narrowed down a short list of suspects based on which function calls could cause a crash on macOS but not Windows.

Once the logs arrived, Claude identified the root cause immediately. A set_focusable() call that re-enables keyboard input for the feedback form was being called on macOS, where the overlay window is an NSPanel with can_become_key_window: false. That combination causes the app to exit. The fix was a one-line platform guard: #[cfg(target_os = "windows")].

This kind of bug used to be painful. A crash you can't reproduce, on a platform you don't use daily, reported by someone who just wants the app to work. Now I look forward to getting the logs, because the path from "user reported a crash" to "fix deployed" is measured in minutes, not days.

I used to dread bug reports. Now I want them.

Closing the loop

Building a feedback feature creates a second problem: someone has to read the submissions. The usual approach is an admin dashboard. I built a /triage-feedback slash command for Claude Code instead.

/triage-feedback queries a Cloudflare D1 database which tracks feedback submissions, and fetches attached logs and screenshots from a backend storage bucket. For each submission, Claude shows the user comment, the operating system and app version, which log files were attached, and the game context. It summarizes long logs, suggests a priority level, and can create a GitHub issue directly from the triage session.

No admin UI. No web dashboard. The CLI is the dashboard. For a solo developer, that's one less thing to build and maintain.

Implementer/Reviewer pattern

A theme runs through all of this. Whatever an agent builds or investigates, a different agent reviews it with fresh context.

I didn't plan this pattern. I stumbled into it. Early on, I tried a GitHub integration from Anthropic that ran Claude Code inside a GitHub Action to review PRs. Fresh-context agents posted review comments directly on the pull request.

The concept was right. Agents reviewing from fresh context found problems the implementation agent missed, and the PR comments felt like having another person on the team. But it fell apart with multi-language work. Rust feedback was terse and rarely surfaced anything useful. TypeScript was the opposite: commenting on every small detail, not distinguishing must-fix from nice-to-have.

I ended up using Claude Code's built-in code review plugin (/code-review). It runs five parallel agents from a Claude conversation on my developer machine (not Github Actions). Each agent independently scores findings. Only findings scored 80 or above are reported in final feedback. I integrated this review into slash commands I use to raise PRs autonomously.

This Implementer/Reviewer pattern extends beyond code review. Everything I build with Claude gets an independent fresh-context review. Feature specs get fresh-context review before implementation. Task breakdowns that I generate from feature specs often go through multiple rounds of review. Even these blog posts go through 5-10 rounds of agentic review.

Fresh context at every level

The agentic review layers don't eliminate human review. My job is reviewing findings and the final product. How carefully I review depends on the risk:

Infrastructure and security code gets my closest read
Backend APIs, I focus on the tests and behavior
Frontend code gets a lighter pass -- the real validation happens when I run it in the browser
Blog posts I review word by word, multiple times, read aloud

The code is AI-generated. The quality isn't.

I'm Tim. I'm building Manasight, an MTG Arena companion tool, solo with Rust and Tauri. Follow @manasightgg on Twitter for build-in-public updates.

Next up: How my GitHub issues become fully reviewed pull requests autonomously, why sequential beats parallel, and what the human actually does when the AI is writing the code.

Everything We Know About the MTG Arena Log File in 2026

manasightgg — Fri, 13 Mar 2026 15:00:00 +0000

Most of what's been written about the Arena log format is outdated. Here's what it actually looks like.

MTG Arena is the free-to-play digital version of Magic: The Gathering. When I started building a companion tool and needed to parse the Arena log file, I based my initial design on existing community documentation. About half of my assumptions turned out to be wrong.

API method names I pulled from older parsers didn't exist in real logs. Game result detection worked differently than documented. A field I expected to be nested inside another was actually its sibling. An entire parser module I wrote had to be deleted because the log event it targeted doesn't appear in real Player.log files. Parser projects from 2019–2022 documented a format that has changed substantially since, and community gists reference API endpoints that were removed years ago.

This post is what I wish existed when I started. Everything here has been verified against current Arena logs as of early 2026.

Log File Location

Arena writes a single log file per session. When you close and reopen the game, the previous session's log is preserved as a backup.

Platform	Log Path
Windows	`%LOCALAPPDATA%Low\Wizards Of The Coast\MTGA\Player.log`
macOS	`~/Library/Logs/Wizards Of The Coast/MTGA/Player.log`
Previous session	Same directory, `Player-prev.log`

Prerequisite: You must enable "Detailed Logs (Plugin Support)" in Options > Account. Without this, the log contains only basic diagnostic output and none of the JSON game data that parsers need. This is the most common reason new users can't get companion tools working.

The log file used to be called output_log.txt and lived in a different location (renamed in May 2020). If you're reading older parser code and the paths don't match, that's why.

Log Structure

The log isn't a clean structured format. It's a mix of plain text diagnostic lines and embedded JSON objects. Game-relevant entries are marked by the [UnityCrossThreadLogger] header prefix. Other bracketed headers appear in the log ([PhysX], [Manifest], [TaskLogger], etc.) but contain engine diagnostics, not game data.

A typical sequence looks like this:

[UnityCrossThreadLogger]3/11/2026 12:34:56 PM
==> EventJoin {"EventName":"QuickDraft_MKM_20260307","Id":"abc123"}

[UnityCrossThreadLogger]3/11/2026 12:35:01 PM
{"greToClientEvent":{"greToClientMessages":[{"type":"GREMessageType_GameStateMessage",...}]}}

JSON payloads can span multiple lines. Parsing requires accumulating lines between header boundaries and extracting JSON using brace-depth counting (tracking open/close braces while respecting string literals). A new [UnityCrossThreadLogger] header signals the end of the previous entry.

Lines before the first [UnityCrossThreadLogger] header in a file are Unity engine boot diagnostics (Mono initialization, GPU info, assembly loading) and should be skipped.

Timestamps

Arena writes timestamps in the user's locale format. This creates a parsing challenge: the log uses multiple date/time formats depending on the player's system settings, plus several machine-oriented formats inside JSON payloads.

Formats observed in real logs:

Format	Example	Where
US 12-hour	`3/11/2026 6:08:07 PM`	`[UnityCrossThreadLogger]` header lines
ISO 8601 + Z	`2026-03-11T22:48:34.663Z`	JSON datetime fields (`progressedDateTimeUTC`, `_dailyRewardResetTimestamp`)
ISO 8601 + offset	`2026-03-11T18:25:33.906174-07:00`	JSON `ServerTime`, `lastRemotePing` fields
.NET ticks	`639088754738962389`	ClientToGRE `timestamp` fields
Epoch milliseconds	`1773278674334`	GRE `timestamp` fields

On European-locale systems, header timestamps likely use a day-first format (e.g., 11/03/2026 12:34:56), but I haven't been able to verify this directly since all my test data comes from a US-locale system.

This ambiguity is problematic: when the day is 12 or less, 3/7/2026 could be March 7 (US) or July 3 (European). There is no reliable way to resolve this from the log alone. My parser uses a US-first convention and accepts the loss for ambiguous dates. When I have EU-based logs to validate with, I am considering updating the parser to take a locale hint to break the tie.

Timestamps appear after the header prefix on the same line. If a header line has no parseable timestamp, store the event without one. Synthetic timestamps break deduplication and chronological ordering.

Client API Messages

Outside of gameplay, the log records REST-style API calls between the Arena client and Wizards' servers. These handle collection data, events, matchmaking, rank, and inventory.

This is the section most existing documentation gets wrong. Older parsers describe a Namespace.MethodName convention with endpoints like PlayerInventory.GetPlayerInventory and PlayerInventory.GetPlayerCardsV3. Most of those endpoints were removed in the August 2021 breaking change and never restored.

Current logs use an arrow-delimited format:

[UnityCrossThreadLogger]==> EventJoin {"id":"abc123","request":"{\"EventName\":\"QuickDraft_MKM_20260307\"}"}

<== RankGetCombinedRankInfo(e1f2a3b4-5678-90cd-ef12-34567890abcd)
{"constructedClass":"Gold","constructedLevel":2,...}

==> marks a client request. <== marks a server response, followed by a UUID in parentheses (matching the request's id field) and a JSON payload. Note that ==> lines carry the [UnityCrossThreadLogger] prefix, but <== lines appear bare with no header prefix. Request payloads often contain string-escaped JSON nested inside a request field.

What's Available in 2026

Direction	Method	What It Contains
`==>`	`EventJoin`	Player joins an event
`==>`	`EventClaimPrize`	Prize claim after an event
`==>`	`EventEnterPairing`	Player enters matchmaking
`<==`	`RankGetCombinedRankInfo`	Constructed and Limited rank, tier, level
`<==`	`StartHook`	Startup data: inventory (gold, gems, wildcards), deck summaries, card metadata, server time
`==>` / `<==`	`DraftCompleteDraft`	Human draft completion (request and response)
`==>` / `<==`	`BotDraftDraftPick`	Bot draft pack presentation and pick selection

StartHook is the primary startup data delivery mechanism. It arrives as a single large response containing InventoryInfo (gold, gems, wildcards, vault progress), DeckSummariesV2, CardMetadataInfo, and a dozen other fields. Notably, the player's card collection (owned cards) does not appear in any ==> / <== API call in current logs. The old GetPlayerCardsV3 endpoint was removed in August 2021 and was not replaced with an equivalent in this API layer.

A complete catalog of every API method that can appear in the log doesn't exist. You discover new ones by watching the log during different game activities.

GRE Messages

GRE (Game Rules Engine) messages contain the actual game data: every card, zone, phase transition, and player action. This is what makes deck tracking, action logs, and replay viewers possible.

GRE messages are wrapped in a greToClientEvent envelope:

{
  "greToClientEvent": {
    "greToClientMessages": [
      {
        "type": "GREMessageType_GameStateMessage",
        "gameStateMessage": { ... }
      }
    ]
  }
}

GRE Message Types

Type	Description
`GREMessageType_ConnectResp`	Initial connection response with starting game state
`GREMessageType_GameStateMessage`	Full or partial game state update
`GREMessageType_QueuedGameStateMessage`	Queued state update (same structure as above)
`GREMessageType_TimerStateMessage`	Rope timers and timeout info
`GREMessageType_IntermissionReq`	Between-game transition in Bo3 (contains game result)
`GREMessageType_SubmitDeckReq`	Sideboarding prompt between Bo3 games
`GREMessageType_UIMessage`	UI-related noise
`GREMessageType_SetSettingsResp`	Settings acknowledgment

Client-to-GRE Messages

Player actions also appear in the log:

Type	Description
`ClientMessageType_MulliganResp`	Keep or mulligan decision
`ClientMessageType_SelectNResp`	Card selection (e.g., discard, scry ordering)
`ClientToGREUIMessage`	UI interactions (hover, chat). Noise.

Some client-to-GRE payloads contain string-escaped JSON nested inside JSON. Your parser needs to handle both already-parsed objects and string-encoded payloads that need a second deserialization pass.

GameStateMessage

This is the core data structure. Each GameStateMessage contains some or all of these fields:

{
  "gameStateMessage": {
    "gameObjects": [ ... ],
    "zones": [ ... ],
    "gameInfo": {
      "stage": "GameStage_Play",
      "matchState": "MatchState_GameInProgress"
    },
    "turnInfo": {
      "turnNumber": 3,
      "phase": "Phase_Main1",
      "activePlayer": 1,
      "decisionPlayer": 1
    },
    "annotations": [ ... ],
    "timers": [ ... ],
    "diffDeletedInstanceIds": [ 101, 202 ]
  }
}

Note that turnInfo is a sibling of gameInfo, not nested inside it. I initially had it as gameStateMessage.gameInfo.turnInfo, which returned null every time. This is the kind of structural assumption that only breaks when you test against real data.

Key Fields

gameObjects: Every card and permanent in the game. Each object has an instanceId, grpId (the card's global ID), zoneId, ownerSeatId, controllerSeatId, visibility, cardTypes, subtypes, power, toughness, and more. The name field is a numeric ID, not a human-readable string; card names require a separate database lookup. Tracking zone transitions of game objects is how you build a deck tracker.

zones: Library, hand, battlefield, graveyard, exile, stack, and others. Each zone has a zoneId, type (e.g., ZoneType_Hand), ownerSeatId, and objectInstanceIds listing what's in it.

annotations: Records of game actions: zone transfers, damage, counters, life total changes. The format is less intuitive than you'd expect (see next section).

timers: Rope timer state, timeout counts, priority timing.

diffDeletedInstanceIds: Instance IDs that should be purged from your local game state. When Arena sends incremental updates (not full state snapshots), this field tells you what no longer exists. If you don't process this, your tracker will show phantom cards.

Full State vs. Incremental Updates

A GameStateMessage can be a full state snapshot or a partial delta containing only what changed. There's no explicit flag that distinguishes them. In practice, early messages in a game (especially from ConnectResp) tend to be full snapshots, and subsequent messages tend to be deltas. Your parser needs to merge incoming fields into a running game state and remove anything listed in diffDeletedInstanceIds.

Annotations

Annotations record game actions within a GameStateMessage. Their format is worth calling out because it's less intuitive than the rest of the GRE schema.

You might expect named wrapper objects with camelCase fields. What Arena actually writes:

{
  "id": 47,
  "affectorId": 312,
  "affectedIds": [455],
  "type": ["AnnotationType_ZoneTransfer"],
  "details": [
    { "key": "zone_src", "type": "KeyValuePairValueType_int32", "valueInt32": [29] },
    { "key": "zone_dest", "type": "KeyValuePairValueType_int32", "valueInt32": [31] },
    { "key": "category", "type": "KeyValuePairValueType_string", "valueString": ["PlayLand"] }
  ]
}

Two surprises here. First, type is an array of strings, not a plain string. In every annotation I've seen in current logs, it's a single-element array, but the array wrapper is always present.

Second, the data lives in a uniform details array of key-value pairs, each with a typed value field (valueInt32, valueString, etc.). The key names use snake_case (zone_src, orig_id, new_id), not camelCase. You need helper functions to search the details array by key name.

Annotation types include AnnotationType_ZoneTransfer, AnnotationType_ObjectIdChanged, AnnotationType_ResolutionComplete, AnnotationType_DamageDealt, AnnotationType_ModifiedLife, AnnotationType_CounterAdded, AnnotationType_PhaseOrStepModified, AnnotationType_TappedUntappedPermanent, and others.

Message Batching

This is the implementation detail I most wish someone had told me upfront.

Arena frequently batches multiple GameStateMessage values into a single greToClientMessages array. In my testing across multiple play sessions, over half of all GRE events that contain game state data have two or more GameStateMessage entries bundled together. A single log entry might contain three or four game state updates.

{
  "greToClientEvent": {
    "greToClientMessages": [
      { "type": "GREMessageType_GameStateMessage", "gameStateMessage": { ... } },
      { "type": "GREMessageType_GameStateMessage", "gameStateMessage": { ... } },
      { "type": "GREMessageType_QueuedGameStateMessage", "gameStateMessage": { ... } }
    ]
  }
}

If you use a find-first approach to extract the GameStateMessage from this array, you silently discard the rest. In my case, the parser was missing turn changes, creature deaths, and annotation data until I refactored it to iterate every message in the batch. This was the source of most of my "why is the tracker missing data" bugs.

Match Lifecycle

Match Start

Match boundaries come from matchGameRoomStateChangedEvent JSON entries:

{
  "matchGameRoomStateChangedEvent": {
    "gameRoomInfo": {
      "stateType": "MatchGameRoomStateType_Playing",
      "gameRoomConfig": {
        "matchId": "abc123",
        "eventId": "Constructed_BestOf1",
        "reservedPlayers": [
          { "systemSeatId": 1, "userId": "...", "playerName": "..." },
          { "systemSeatId": 2, "userId": "...", "playerName": "..." }
        ]
      }
    }
  }
}

This gives you the match ID, event type, and both players' seat assignments.

Game Result

Game results are embedded in GRE GameStateMessage payloads, not in a separate event type. When a game ends, the gameInfo field inside a GameStateMessage transitions to:

{
  "stage": "GameStage_GameOver",
  "matchState": "MatchState_GameComplete",
  "results": [
    { "scope": "MatchScope_Game", "result": "ResultType_WinLoss", "winningTeamId": 1, "reason": "ResultReason_Game" }
  ]
}

There's a catch: Arena sends two GameStage_GameOver messages per game end. The first has matchState: "MatchState_GameComplete" (game-scope result). The second has matchState: "MatchState_MatchComplete" (match-scope result, which also includes both MatchScope_Game and MatchScope_Match entries). If you emit a game result event for both, you get duplicates. Filter on MatchState_GameComplete and skip MatchState_MatchComplete.

I initially built a separate game result parser around LogBusinessEvents entries with a WinningType field, based on documentation from older parsers. That event never appeared in any real log I tested. The entire module had to be deleted.

Match Complete

Match completion uses the same matchGameRoomStateChangedEvent structure:

{
  "matchGameRoomStateChangedEvent": {
    "gameRoomInfo": {
      "stateType": "MatchGameRoomStateType_MatchCompleted",
      "finalMatchResult": {
        "matchId": "abc123",
        "matchCompletedReason": "MatchCompletedReasonType_Success",
        "resultList": [
          { "scope": "MatchScope_Game", "result": "ResultType_WinLoss", "winningTeamId": 1 },
          { "scope": "MatchScope_Match", "result": "ResultType_WinLoss", "winningTeamId": 1 }
        ]
      }
    }
  }
}

For Bo3 matches, resultList contains one MatchScope_Game entry per game played, plus a final MatchScope_Match entry for the overall result. In a 2-0 match, for example, the list contains three entries: two game-scope results and one match-scope result. Between games, the GRE sends GREMessageType_IntermissionReq (containing the game result) followed by GREMessageType_SubmitDeckReq for sideboarding.

Draft Events

Draft parsing requires handling two completely different log formats depending on the draft type.

Bot Drafts (Quick Draft)

Bot draft messages use a CurrentModule/Payload envelope, where the payload is string-escaped JSON. Pack presentation arrives as a BotDraftDraftPick response:

{
  "CurrentModule": "BotDraft",
  "Payload": "{\"Result\":\"Success\",\"EventName\":\"QuickDraft_ECL_20260223\",\"DraftStatus\":\"PickNext\",\"PackNumber\":0,\"PickNumber\":0,\"NumCardsToPick\":1,\"DraftPack\":[\"98361\",\"98498\",\"98358\",...],\"PickedCards\":[...]}"
}

Note that DraftPack is an array of strings, not integers. Same for PickedCards.

Pick selection is sent as a ==> BotDraftDraftPick request (no underscore) with PickInfo containing the chosen CardIds (plural, an array), PackNumber, and PickNumber:

==> BotDraftDraftPick {"id":"...","request":"{\"EventName\":\"QuickDraft_ECL_20260223\",\"PickInfo\":{\"EventName\":\"QuickDraft_ECL_20260223\",\"CardIds\":[\"98546\"],\"PackNumber\":0,\"PickNumber\":0}}"}

Draft completion for bot drafts does not use DraftCompleteDraft. Instead, the final BotDraftDraftPick response returns "DraftStatus":"Completed" with a full PickedCards array and an empty DraftPack. The response also includes DTO_InventoryInfo with card grant details.

Human Drafts (Premier/Traditional)

Pack presentation uses a Draft.Notify entry with draftId, SelfPack, SelfPick, and PackCards (a comma-separated string of card IDs, not an array). One caveat: the very first pick of pack 1 does not generate a Draft.Notify. The first one appears at SelfPick:2. New packs (pack 2 and pack 3) do generate Draft.Notify for their first pick.

Pick selection arrives as EventPlayerDraftMakePick with DraftId, GrpIds (an array of selected card IDs), Pack, and Pick numbers. In formats that allow picking multiple cards (like Pick Two Draft), GrpIds contains more than one entry.

Draft Completion

Human drafts emit a DraftCompleteDraft entry when the draft finishes. Note the exact name: no underscore between "Draft" and "Complete." The request contains EventName and IsBotDraft: false in string-escaped JSON. The response includes CourseId, InternalEventName, and CardPool (an array of integer card IDs — the complete pool of drafted cards).

Bot drafts (QuickDraft) do not emit DraftCompleteDraft. Completion is signaled by the final BotDraftDraftPick response with DraftStatus: "Completed" (see above).

Session Events

A few log events track the player session:

Signature	What It Contains
`authenticateResponse`	Login confirmation with `clientId`, `sessionId`, and `screenName`
`FrontDoorConnection.Close`	Logout or disconnect (includes reason, e.g., `"OnDestroy"`)

authenticateResponse is the primary source of player identity. It appears at session start and again on each match server reconnection. Identity data also appears in matchGameRoomStateChangedEvent, where the reservedPlayers array includes userId and playerName for both players in a match.

If you're building a tool that processes this data, strip or hash identity fields before anything leaves the user's machine. WotC has been moving in this direction themselves: screen names were removed from most log entries in July 2021, and opponent display name tags were removed in July 2024 (see the breaking changes timeline below). Treat the remaining identity fields as data you have access to, not data you're entitled to store or transmit.

About the Parser

The parser described in this post is open source on GitHub (Rust, MIT/Apache-2.0). I'm using it to build a desktop overlay for Arena. If you're working on Arena tooling, I'd love to hear what you're building.

Appendix

Breaking Changes

Fair warning: the log format is unstable and has broken without notice before.

In the 2021.8.0.3855 update, Wizards removed several log endpoints without warning:

PlayerInventory.GetPlayerInventory: removed
PlayerInventory.GetPlayerCardsV3: removed
Inventory.Updated: removed
Several draft-related endpoints: removed

Collection tracking, inventory updates, and draft pick logging all broke overnight. A community feedback thread collected over 700 votes. Some data eventually reappeared through different endpoints (inventory now comes through StartHook), but the format changed and old parsers needed rewrites. Card collection data (GetPlayerCardsV3) was not replaced with an equivalent in the current API layer.

That wasn't an isolated incident. A timeline of data removals:

Date	What Changed
Sept 2019	Vault progress info removed
May 2020	Log file renamed from `output_log.txt` to `Player.log`, path changed
July 2021	Screen name removed from most log entries
Aug 2021	Collection, inventory, and draft endpoints removed (partially restored later in new format)
Aug 2022	MMR/rating data removed
July 2024	Opponent display name tag removed

The trend is obvious. Wizards has been reducing the data available in the log over time, not expanding it. If you're building a tool that depends on the log, design for resilience. Assume any field can disappear in the next patch. Anything your parser extracts today might not be there tomorrow.

Open-Source Parsers

If you're building something, start by reading existing implementations. Status as of early 2026:

manasight-parser
Rust · Active
My project. Verified against current logs. Full GRE, client API, draft, and match lifecycle parsing. MIT/Apache-2.0.

rconroy293/mtga-log-client
Python · Active
17Lands' official client. Clean, focused on draft and game event upload.

gathering-gg/parser
Go · Unmaintained (2019)
Comprehensively typed. Good for understanding message structures, but the format has changed.

mtgatool/mtgatool-desktop
TypeScript · Low activity (last release Oct 2024)
Full Electron app with log watcher and message dispatcher.

mtgatracker/mtgatracker
Python · Unmaintained (2020)
Websocket-based overlay. Historical reference.

Razviar/mtgap
TypeScript · Archived (April 2025)
MTGA Pro Tracker. Rewrote its parser multiple times as the format evolved.

riQQ/MtgaProto
Protobuf · Updated periodically
Extracted .proto definitions from Arena's installation files. Reference, not a parser.

Manasight is not affiliated with, endorsed by, or sponsored by Wizards of the Coast or Hasbro.

Have corrections or additions? I'd love to hear from other developers working in this space.

Why I Chose Tauri v2 for a Desktop Overlay in 2026

manasightgg — Mon, 09 Mar 2026 03:54:18 +0000

How a prototype spike validated a framework decision on real hardware.

Building an overlay that sits on top of a fullscreen game sounds straightforward until you start listing requirements. Transparent background. Always on top. Click-through on empty space. Rich UI with styled lists and icons. Windows and Mac. Low CPU and RAM overhead.

The list of frameworks that can do all of that is short.

My project is Manasight, a companion overlay for Magic: The Gathering Arena. I'd committed to Windows and Mac from day one but hadn't picked the framework yet. This post is the story of how I chose one, what scared me about it, and how I tested whether those fears were justified.

What an overlay requires

Manasight's overlay needs to do a few things that most desktop apps don't. It has to render transparent panels on top of a running game, stay visible at all times, and let mouse clicks pass through to the game on transparent areas while capturing clicks on the UI panels themselves.

That last requirement, selective click-through, eliminates most options immediately.

The overlay also isn't just a technical exercise. It needs to look like a modern app: styled card lists, a scrollable event log, opacity controls, responsive layout that adapts to panel resizing. Users expect the polish of a web app, not the look of native system controls.

So the framework needs transparent always-on-top windows and rich UI rendering.
That means HTML/CSS in an overlay, which narrows the field fast.

Ruling out options

Electron was the first to go. Bundling Chromium means 200-300 MB of memory before the app does anything. For a tool that runs alongside a game, that overhead matters.

Overwolf is Windows-only and takes up to a 30% revenue cut. Flutter Desktop has no selective click-through support. Qt/QML has had recurring macOS transparency issues since Qt 5.15 and comes with complex LGPL licensing.

That left two real options: Tauri v2 or going fully native.

Tauri vs. native

I have years of C++ and Win32/Direct2D experience (I even worked on the Microsoft team that originally built Direct2D nearly 20 years ago). Building the Windows overlay natively was on the table. Native gives you first-class selective click-through on both platforms (WM_NCHITTEST on Windows, hitTest on macOS) and the lowest possible resource footprint.

But my experience also told me it would be painful. Going fully native means two separate rendering implementations. Direct2D on Windows, Core Animation on macOS. Manual pixel-level layout to achieve what a few lines of CSS give you for free: flexbox, web fonts, scrollable containers, hover states. No hot reload, no browser dev tools. I estimated weeks of additional UI work just to get something that would look worse than HTML/CSS.

macOS was a blank slate for me -- I have never built a macOS app in my life. Building the same UI twice in two rendering frameworks, as one person, would at least double the implementation timeline. That's plenty of time for a side project to lose momentum.

Tauri avoids that trade-off. The backend is Rust, so system-level code like log parsing, file watching, and cursor polling runs at native speed. The UI is HTML/CSS rendered in the platform's built-in webview. You're not choosing between Rust and "not Rust." You're choosing where Rust does the work.

Tauri also handles distribution: a built-in auto-updater with Ed25519 signature verification, MSI/NSIS installer generation for Windows, DMG generation for macOS, and code signing for both platforms.

What I knew I was giving up

Tauri won on development speed and single-codebase economics, but it came with known costs:

No native click-through. Tauri doesn't expose per-region hit-testing. The workaround: a Rust loop polls cursor position at ~60fps and toggles setIgnoreCursorEvents based on whether the cursor is over a UI panel or transparent space. It sounds expensive, but it's a tight compiled loop, not JavaScript.
macOS transparency bugs. There were three open issues in Tauri's tracker. E.g., transparent windows reportedly worked in development but rendered with an opaque background in production .app bundles. If true, that would make the overlay unusable on Mac.
macOSPrivateApi: true. Required for transparency, and it permanently disqualifies the Mac App Store. It's acceptable for Manasight (distributed via DMG), but a real constraint.
WebView differences. WebView2 (Chromium-based) on Windows, WebKit on macOS. Minor rendering inconsistencies are expected.
Framework dependency. Tied to Tauri's project health and release cadence.

If Tauri didn't pan out, I had a fallback plan: build native window shells with embedded WebView2/WKWebView, keeping the HTML/CSS rendering advantage while gaining full native window control.

Prototype spike

I used Claude Code to research Tauri's GitHub issue tracker, dig through platform-specific overlay mechanics (Win32 WM_NCHITTEST behavior, AppKit hitTest overrides), and study how existing tools in this space implement their overlays. That research surfaced six specific risks, some of which looked like potential hard blockers. The question was whether they were real on actual hardware.

Rather than assume, I built a validation spike: I opened 20 GitHub issues covering 5 risk areas including transparency, click-through, focus management, multi-monitor behavior, and performance. Testing covered five OS versions: Windows 10, Windows 11, macOS Sonoma, macOS Sequoia, and macOS Tahoe. If the overlay couldn't pass validation on all target platforms, the project would fall back to native with embedded WebView.

This wasn't a "move fast and see what happens" prototype. It was a risk-reduction exercise with a solid plan B.

Testing on real hardware

Claude generated the prototype code. GitHub Actions built the installers for Windows and Mac. For macOS testing, I bought an M2 Mac Mini specifically because it could run all three recent macOS versions (Sonoma, Sequoia, and Tahoe). It was the cheapest way to get real hardware coverage across OS generations.

That purchase says something about how seriously I take Mac support. I bought hardware before writing a line of product code.

Claude was one of the first things I installed on each OS. It walked me through a 30+ test case protocol on every platform, giving me step-by-step instructions, gathering resource metrics automatically, and running installers directly from CI artifacts.

What didn't break

Six risks from the research simply didn't reproduce:

Transparency lost in production builds. Worked fine on all three macOS versions.
Sonoma visual glitches after focus change. Didn't happen.
Ghost titlebar artifact on Windows. Didn't happen.
Taskbar z-order issues. Didn't happen.
Shadow artifacts with transparency. Didn't happen.
Monthly Screen Recording re-authorization on Sequoia. Never triggered because the app doesn't need the permission at all.

AI-assisted research identified these risks. AI-assisted prototyping proved most of them weren't real.

What did break

macOS being macOS:

Overlay invisible over fullscreen apps. macOS isolates fullscreen apps from other windows by default. I fixed this with tauri-nspanel, a third-party plugin that converts the window to an NSPanel that macOS allows to float above fullscreen apps.
App appearing in Dock and Cmd+Tab. I needed to set ActivationPolicy::Accessory to hide the overlay from the app switcher.
CSS backdrop-filter: blur() broken with transparency. Cosmetic only, but means frosted-glass effects aren't available on the overlay.

And some problems nobody warned about:

Windows overlay stealing focus on click. Clicking a UI panel pulled focus from the application underneath. Required platform-specific window flag adjustments.
macOS Tahoe using ~4x the RAM of Sequoia. 110 MB vs. 29 MB on identical hardware, running identical code. An OS-level webview regression, not something the application can control.
NSIS installer not bootstrapping WebView2 on Windows 10. WebView2 doesn't ship with Win10. During testing Edge provided it, but on a clean Win10 machine without Edge the app would fail to launch. Fix: a single config line to bundle the bootstrapper.

Performance numbers

On Windows 11: 14 MB RAM and under 1% CPU. Tauri uses the system webview instead of bundling Chromium, and the backend is compiled Rust with no garbage collector, no runtime, no interpreter. The only overhead is a webview rendering HTML panels.

macOS varied by version:

macOS Version	RAM
Sequoia	20-29 MB
Sonoma	66 MB
Tahoe	110 MB

All within the 200 MB RAM and 15% CPU upper bounds I'd set. Active CPU was borderline on Tahoe (15.6%) but acceptable. The overlay runs alongside a game without the player noticing it.

Decision validated

Most risks didn't reproduce. The ones that did had workarounds. Nothing was a hard blocker. The native fallback still exists if something changes in a future Tauri release or macOS update.

Tauri earned the "proceed" verdict through testing, not faith.

The prototype is now complete. Product code is underway, and the framework decision is validated with real numbers on real hardware. That's the kind of foundation I want to build on.

Now there's evidence, not just a belief.

I'm Tim -- I'm building Manasight, an MTG Arena companion tool, solo with Rust and Tauri. Follow @manasightgg on Twitter or read the full blog at blog.manasight.gg.