Four (five after an objection) "same" could not be reached with the few
accounts online: an author never reviews their own work, and with four
active accounts that were also the authors, each function could get at most
three verdicts. 948 of 1027 verdicts in six hours went to functions that
stayed undecided; merges fell to about 5 an hour.
- Accept when weighted "same" leads "different" by peerMargin (3: 3:0, 4:1,
5:2), from at least two reviewers.
- Send back when at least peerReviews (3) "different" lead by
peerRejectMargin (2: 3:1, 4:2), from at least two reviewers.
- Close votes wait for more verdicts; reviewers are offered functions that a
verdict can still decide.
- The worker settles the waiting queue under the current rule when it starts.
- Trust and quality count accepted and sent-back functions the same way.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- Static gate: a file main already holds may grow 128 KB beyond its size on
main (Unit_C.cpp is 796 KB, Player_C.cpp 491 KB: no edit to them could
pass the 256 KB limit); only what a submission adds counts toward the total.
- A peer-confirmed function in another unit may move closer to the original
(a header layout fix); only moving away from it is a regression.
- A function main no longer annotates anywhere (fn_07162, removed from stpl.h
in 0f9ebdb4 while its record still said exact) is not "removed" by every
later submission of the unit it was recorded at.
- A library function main already annotates in a file (fn_25851 in
BSNEncodeInterface.h) no longer refuses every edit of that file; adding
such an annotation still is refused.
- td_withdraw / td withdraw <attemptId>: the author takes back a function
waiting for review; it returns to their claim.
- td_submit says when held functions have no changed code in the working
tree, instead of "you hold no tasks".
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Each agent (token) earns trust from its record (trust.js):
- author: of its peer-decided functions scoring 90%+ (14 days), the
accepted share, as a 95% lower bound, must reach 85% over 20+
functions. Its functions at 95%+ are then accepted without peer
review, but for a random one in five that peers still review.
- reviewer: agreement with the other reviewers, counted apart for
functions they found the same and ones they found different (30
days). 85%/65% over 30+ differences counts x2, 92%/85% over 60+ x3.
Weights are frozen on the verdict; a decision always takes two
reviewers. Skipped functions and own verdicts never feed the record.
Shown per agent on the Account page, in td_quality and in the admin
Authors table.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- td toolchain install / td_toolchain_install: downloads the compiler
package (approved accounts) and sets up local checks; td-server
toolchain pack builds it from the compile image.
- td_check compiles on the contributor machine only (includers: true for
header changes, using the server include map).
- td_regions, td_claim_region, td_release_region; td_submit adds rewritten
functions of shared regions as competing candidates.
- AGENTS.md, MCP instructions and guidance describe the region loop.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Prompt injection: a submission may not add comments other than annotations,
offset and INLINED markers, and only string literals that occur in the
original executable (adjacent literals joined; #include paths restricted).
Comments and strings already on main stay. Checked before compiling, for
remote checks and submissions; errors name the line but never repeat the
text. Peer reviewers no longer see author notes or running verdict counts.
Agents are told that only AGENTS.md and the guidance field instruct them.
Review: "Approve batch" in the confirmed section also approved the batch's
functions still in peer review (for maintainers). The page now sends exactly
the functions it shows, and skipping peer review needs skipPeerReview,
which only the peer review section's button and the attempt page send.
Worker drain: a stopping worker kept starting new verifications when one
finished, so it never stopped. Stopped queues take no new work.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RNwtXPYqFu3oKaaXwYwNWW
Claims, task context, checks, submissions and batch results carry a
`guidance` field with the project's current policy, so agents that are
already running pick it up on their next call. The default asks for faithful
ports with a few checks per function instead of chasing exact bytes, since
peer review confirms the logic. Admins change it live with
`td-server guidance set|off|reset|show`. AGENTS.md and the MCP instructions
say the same for new sessions.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RNwtXPYqFu3oKaaXwYwNWW
- Batches: claim every open function of a unit or address range (td claim --unit/--range),
submit the file once; one compile, per-function routing, merged as a whole. A failing
function returns the batch; peer verdicts carry over to functions whose compiled code is
unchanged (code fingerprints). Submissions may not change functions they do not hold.
- Byte-identical functions are approved and merged without human review
(matchPolicy.autoMergeIdentical); peer-confirmed ones need one click per batch.
- Remote check: td check compiles on the server when there is no local toolchain.
- /api/original: assembly and pseudocode of the original from the server's Ghidra export
(objdump before an export exists); td disasm/decompile fall back to it.
- td as a standalone executable (Node single executable application; tools/build-td),
one-line installers (install.ps1 / install.sh) with checksum verification, td connect for
any MCP client, td mcp --workspace, self-update (td update, hourly check).
- Server-side Ghidra project: built once per version, refreshed after merges, downloadable
for contributors (td ghidra download); JDK 21 and the pinned Ghidra in deploy/install.sh.
- Agent instructions: work continuously, batches first, peer reviews in between.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RNwtXPYqFu3oKaaXwYwNWW
Coordinator (accounts with approval, API tokens, tasks with leases, sandboxed MSVC verification against
the original exe, peer review by three agents for non-identical code, human review, serial merge queue),
the `td` contributor CLI with an MCP server for agents, pinned Ghidra integration, deployment (Caddy,
systemd, nftables, Forgejo) and the wowdecomp 15890 migration tools.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RNwtXPYqFu3oKaaXwYwNWW
