Privacy Policy

This Privacy Policy describes how WillBooster Inc. ("WillBooster", "we") handles information in ReviewFixLoop (the "Service"). In this policy, the "Act" means Japan's Act on the Protection of Personal Information.

This policy exists in English and Japanese. If the two versions differ, the Japanese version prevails.

Effective date: 2026-11-05

Terms used in this policy

• Reviewer: a combination of a coding agent program (a "harness"), a model and an effort setting that reviews a pull request.
• Resolver: the coding agent that conducts a review of a pull request: it decides how to treat each finding and changes the code.
• Run: one execution of the review-and-fix loop on one pull request.
• Finding: an issue that a reviewer reports in a run.
• Judgment: the resolver's decision on a finding.
• Judge: the automated classifier with which the Service assigns a tag, a severity and duplicate relations to each finding.
• Workspace: the unit of the Service to which runs belong. A personal workspace is created when you sign in. Members of a workspace can see its runs.
• L0, L1, L2: the three layers of run data, defined under "Run data" below.

Operator

• Operator: WillBooster Inc. (WillBooster株式会社)
• Address: 3F Shinjuku Dainana Hayama Building, 1-36-2 Shinjuku, Shinjuku-ku, Tokyo 160-0022, Japan
• Representative: Kazunori Sakamoto

Information we collect

GitHub identity

You sign in with GitHub OAuth. The Service uses it only to identify you. It requests no scopes and obtains no access to your repositories. From GitHub we receive and store:

• your GitHub numeric user id;
• your GitHub login;
• the creation time of your GitHub account.

At sign-up we also store the country code determined from where the request came from.

Sign-in sessions

When you sign in, your browser's cookie holds a session token. We store only a hash of that token, together with your account and the times the session began and ends. A session ends 30 days after the sign-in, when you sign out, or when you delete your account. An ended session's record is deleted, at the latest at the next daily retention sweep.

The Service uses three cookies, each strictly necessary for signing in: the session, for 30 days; the sign-in's state, for 10 minutes; and a new user's pending sign-up, which holds their GitHub identity, for 30 minutes. It sets no advertising or analytics cookies.

Account and workspace records

We store your workspace memberships, which runs you started, and the settings you save to your account, such as your limits on vendor CLI jobs. We also store the version of the notice you agreed to at sign-up and the time of that consent.

The members of a workspace can see, for each member, how many runs that member started in the workspace and how many judgment requests those runs made (the findings sent to the judge, which count against the free limits) over a period of up to 90 days, and that member's share of the workspace's monthly limit. They do not see per-member counts of findings or of their acceptance.

When a workspace owner invites you, we store the invite with your account. We delete it when it is accepted, declined or withdrawn, when your account or the inviter's is deleted, when the inviter leaves the workspace, and otherwise at the first daily retention sweep after it expires 7 days after it was made. To find the account of a login an owner enters, we read that login's public profile from GitHub. We store nothing from that profile, and nothing about a person who has no account with the Service.

At most once a month, the Service may compute, for a workspace's owner, a recommendation to change the workspace's default reviewers, from the L0 of the workspace's runs of the last 90 days and the public leaderboard's ratings. We store the recommendation with the reviewer ids and counts it rests on, when an owner's browser first showed it, and the owner's decision. When a month's computation recommends nothing, we store only that the workspace's month was computed and when.

An owner of a shared workspace can choose to publish the workspace's roster in the roster gallery. While it is published, anyone can see there the workspace's name, its default reviewers, and the number of its runs of the last 30 days as a range (10 or fewer, 100 or fewer, or more than 100), ranked by the ratings of its reviewers on the public leaderboard. The gallery shows no finding counts, pull requests, repositories or members. Publishing is off by default, a personal workspace cannot publish, and an owner can stop publishing at any time on the workspace's page; the gallery then drops the workspace within a few minutes. Every member of a workspace can see where the workspace's roster would rank among the published rosters, whether or not it is published.

Run data

The Service's CLI sends run data from your machine in three layers.

The Service also receives the identification of the repository and the pull request of each run, and records whether the repository's prSummary setting, which makes the CLI post the run's summary to the pull request, was on for the run. We use that record to learn whether repositories keep the setting on, to decide how to develop the feature. The Service receives nothing of the comment, which the CLI writes on GitHub with your own gh.

L1 and L2 are taken from your repository, your pull requests and your sessions. They can contain personal data if your repository, your pull requests or your sessions contain it.

Keeping session logs is a workspace setting that only its owners can change, and it is off by default. While it is on, the Service's CLI uploads the L2 of each run of the workspace when the run ends. Before uploading L2, with session logs or with a bug report, the CLI masks strings in common credential formats. Masking does not find every secret, so the uploaded L2 can still contain secrets and personal data that the sessions contain. Every member of the workspace can read its stored session logs on the run's page. We use session logs only to show them to the members of the run's workspace: we do not read them for any other purpose, use them to improve the Service, or send them to AI models.

ReviewFixLoop never sends your credentials to the Service: the Service does not record which authentication method a vendor's command-line tool uses, and ReviewFixLoop does not read, store or relay the credentials of a vendor's command-line tool. The agent embedded in the ReviewFixLoop command-line tool reads, on your machine, the API key of the model provider you configured for it, and sends the key only to the endpoint configured with it. A credential that a session prints, however, is part of that session's L2: session logs and bug reports send it unless masking recognizes it, as described above.

The web site has no analytics tooling. Its fonts and scripts are served by the web site itself.

The Service keeps operational logs, with your GitHub login on security events such as sign-ins and token changes, for 7 days. These logs are not removed early when you delete your account. Your IP address reaches the Service and Cloudflare with each request. The Service uses it to limit request rates and to determine your country, and it stays with the request's other headers in the same logs for 7 days.

Escaped defects

The Service counts the defects that the reviewers of a run missed and that were fixed after the pull request was merged, to show them on the public leaderboard. Once a day per repository, the Service's CLI looks, in your checkout, for commits on the default branch that change lines a pull request added, for pull requests merged within the last 30 days whose run is of a workspace that contributes to the public leaderboard. For each such commit, it sends the commit's id, its message and the parts of its change (hunks, with three lines around each) that change lines the pull request added. It does not send a commit in which a secret-looking string is detected. The Service passes the message and the changes to the judge and does not store them. It stores the commit's id, the run, the time and the judge's probabilities that the commit fixes a defect and that each finding of the run described it.

Beta measurement events

The Service is in open beta. To decide which features to develop and which to offer as paid features, we record the following events of the use of the Service's features. A record holds the workspace, which event occurred, and the time. We record each event at most once per workspace and UTC day.

• A member of a workspace opens a run of it whose L1 has already been emptied under the retention rules.
• A member of a workspace opens a run of it whose stored session logs have already been deleted under the retention rules.
• An owner of a workspace accepts or rejects a recommendation to change its default reviewers.

Error diagnostics

We collect production errors from the web site and server with an error collection system we operate. Reports contain the exception type, message, stack trace, cause chain, occurrence time, environment and release. We remove request URLs, user identifiers, browser details, breadcrumbs and arbitrary context before sending, and mask secret-looking strings in exception text. Exception text can still contain personal data. Diagnostic reports are accessible to the developers and their coding agents and are retained for up to 90 days. We do not collect page views or analytics sessions.

Feedback box

The web site's Feedback button, which the CLI's feedback command also opens, shows a feedback box we operate. Anyone can read the public posts in it. When you use it while signed in, to read your own posts, post or support a post, we receive:

• your account's id in the Service;
• a display name: your GitHub login if you chose to show your name as a contributor on the leaderboard, and otherwise "ReviewFixLoop user";
• what you write, and which posts you support.

A post has a title, public details and private details. The title, the public details and the display name are published at once to everyone who opens the feedback box. The private details are read only by the developers and their coding agents. With a post, we also receive the full address of the page you posted from, and a record of what happened before on that page: the pages you moved between, the requests the page made (their addresses without query strings, and their results) and the error and warning messages the page logged.

A post is deleted at the latest 365 days after its last activity (a post, a support or a change of its status). You can withdraw your own post from "My posts" in the feedback box, which deletes it with its public and private details. Deleting your account does not delete your posts, so withdraw them first if you want them gone.

Purposes of use

We use the information above for the following purposes:

• to identify you and to provide the Service, including showing runs to the members of their workspace, and showing them each member's counts of runs and judgment requests in it;
• to recommend to a workspace's owner changes to its default reviewers;
• to publish, in the roster gallery, the rosters that workspace owners chose to publish;
• to judge findings and their duplicate relations;
• to compute and publish the leaderboard, including measuring the validity of its ratings and counting the defects the reviewers missed;
• to apply the eligibility rules and the free limits of the Terms of Service;
• to show which notice you consented to at sign-up, and to tell whether a changed notice needs your consent again;
• to decide which features to develop and which to offer as paid features, from the beta measurement events, from whether the recommendations of default reviewers were shown and accepted, and from counts of runs and of usage against the free limits, counted per workspace and per account;
• to investigate the bugs you report (L2);
• to show the stored session logs of a run to the members of its workspace (L2);
• to investigate and fix production failures using error diagnostics;
• to receive, publish and respond to feedback on the Service in the feedback box;
• to protect the Service from abuse and to investigate security events.

Retention

• The same periods apply whether the repository is public or private.
• L1 is kept while a run is active. The L1 of a run whose findings another run inherited is kept while the inheriting run still holds its L1. Both exceptions extend beyond the periods in the table and also apply after account deletion.
• Deletion empties the L1 and keeps the L0 rows.
• An API token unused for 90 days is deleted at the next daily retention sweep.
• A beta measurement event is deleted at the first daily retention sweep after 180 days have passed since it was recorded.
• A recommendation of default reviewers is deleted at the first daily retention sweep after 180 days have passed since it was made.
• The record of an escaped-defect judgment holds no text and is kept indefinitely, like L0.
• Deleted data can remain in backups for up to 30 days.

Account deletion

When you delete your account, we remove your GitHub numeric user id, login, account creation time and sign-up country from your account record. We end your sessions, revoke your API tokens, remove your workspace memberships and saved vendor CLI limits, and stop displaying your contributor name. The account record remains so that the runs you started still count as one account in the aggregates. The record of the consent you gave at sign-up, the version of the notice and its time, also remains in that record.

To prevent deletion and re-registration from resetting the free limits, we temporarily retain a keyed digest (HMAC) of your GitHub numeric user id in that record. The Service can match it to the same GitHub account at a later sign-up, so the record is not yet fully detached from that GitHub account during this period.

You can sign up again at or after the later of 24 hours from deletion and the start of the next calendar month in UTC. The next daily retention sweep removes the digest after that time. The run metadata and aggregates remain.

Deleting your account reduces the L1 retention of your personal workspace to zero days. Its ended runs become eligible for the next retention sweep unless another run still holding L1 inherits their findings, and their session logs are deleted with their L1. Runs in shared workspaces keep that workspace's retention rules. The beta measurement events and the recommendations of default reviewers of your workspaces remain until 180 days after they were recorded or made.

Publication on the public leaderboard

Free use of the Service requires contributing your runs to the public leaderboard.

• The aggregates rest on AI judgments, and the leaderboard says so.
• The CLI masks strings that look like secrets in evidence before sending it.

Service providers and AI processing

We entrust the storage of data and the judging of findings to cloud service providers and AI inference providers. These providers are companies in the United States of America, and they can handle the data in the United States and in other countries where they operate. The providers we use can change among companies in the United States.

• To judge findings, we send the file, line, title, body and evidence of a finding, and of its duplicate candidates, to external AI models. To measure the validity of judgments, we also send the resolver's reason for a sample of judged findings.
• To count escaped defects, we send the message and hunks of a commit that the CLI sent, with the file, line, title and body of the run's findings in the files it changed, to an external AI model.
• What we send includes findings and commits from private repositories. The validity measurement leaves out findings and reasons in which a secret-looking string is detected.
• We request a route on which the data we send is not used to train models. We do not require that the providers retain no data at all.
• Deleting your account cannot recall data that was already sent to a provider.

We choose a provider after checking the terms and data-handling conditions it publishes, and we check them again when they change. Some AI models are reached through another provider's service and are used under that service's terms. On request to the contact below, we tell you without delay the names of the providers and a summary of the measures we take.

Except where the law requires it, we do not provide personal data to any third party other than these providers without your consent.

Provision to third parties in a foreign country

Entrusting data to the providers above is a provision of personal data to third parties in a foreign country under the Act. We do it with your consent: when you sign up, you are shown the information below, and your account is created only if you agree. We record the version of the notice you agreed to and the time.

• Country: the United States of America.
• Its system for protecting personal information: the United States has no comprehensive federal law on personal information; federal laws for particular sectors and state laws such as California's apply. It takes part in the APEC Cross-Border Privacy Rules system. The European Union's adequacy decision for it covers only organisations certified under the EU–US Data Privacy Framework. See the survey by Japan's Personal Information Protection Commission.
• Measures the providers take: they handle the data under the terms they publish, to provide their service. We request a route on which the data is not used to train models. A provider can keep the data for a limited time, for example to monitor abuse. No contract between us and the AI inference providers commits them to the measures Japanese law requires of us, and we have not confirmed that each of them takes every such measure.

Before we provide your data to a provider in another country, we ask for your consent again.

Security measures

We take the measures necessary and appropriate to prevent the leakage, loss or damage of personal data, such as encrypting communications, limiting who handles the data, and checking the conditions of the providers. On request to the contact below, we tell you what these measures are.

The Service holds no e-mail address or other contact address of its users. If a leakage, loss or damage of personal data occurs that the Act requires us to notify you of, we therefore publish it on the Notices page in place of notifying you individually. The notice states what the Act requires a notification to state, and names the contact below, where you can ask whether your data is affected. For 30 days after it is posted, the web site shows it on every page and the Service's CLI shows it at the start of each run.

Requests and contact

You may request access to, or the correction, cessation of use or erasure of, your personal data, and ask about this policy, at contact@willbooster.com. A request is separate from account deletion, and you can make one while re-registration is blocked, without creating a new account.

We request only the information needed to verify your identity and locate the relevant data, assess each request under the Act, and notify you of the outcome. If we decline a request in whole or in part, we explain our reasons.

Changes to this policy

When we change this policy, we post the new text and its effective date on this page, and a notice of the change on the Notices page.